My nephew is loving the hEX/RB750Gr3, but my RB4011 showing error under dhcp client.
It’s working fine based on speedtests and no packet loss, but yet shows “error” under DHCP Client and doesn’t show the usual expires after 60 min, it says 5d etc. I don’t have any errors in the logs oddly enough. Have you encountered the same error before? If so, should I worry about it or just ignore it?
EDIT: Did a reboot and that seems to have resolved it.
Man, I’ve tried everything that I can think of to get the supplicant method to work on my CCR1009, but it’s all been a no-go. I tried to duplicate wojo’s switch in front method with a TP-Link TL-SG105E, but I couldn’t get authenticated with his settings. I ended up actually getting authenticated once when I enabled MTU Vlans and used the ONT interface as an uplink (go figure), but even that wasn’t kosher because then I could never get a DHCP address from the network afterwards. At this point, I’ve given up since whenever I take the Internet down in this house…it’s practically World War III. Specifically, I’ve got a CCR1009-7G-1C-1S+PC for what it’s worth. I’d really like to get the RGW out of the way here, but for now…here it sits.
That switch might not do VLAN filtering, try this switch from TP-Link if it doesn’t work out return it to Amazon. Specifically model T1500G-8T.
To summarize, you are authenticating fine, but you still need a switch or software bridge to remove the vlan headers/strip them, so you can pass traffic through and obtain an IP via dhcp-client.
If you give up it’s understandable, but either try the wojo script again or using the switch that wojo and I have it working with. If you sell your CCR1009 you can use the funds to easily cover the cost of a RB4011 if you chose to go that route.
Personally I tried an Aruba 2530 (HPE), Ubiquiti Edgeswitch 10x, and an older tp-link smart switch. None of them worked, except the TP-Link T1500G-8T that wojo recommended.
The limitation that the bridge is not handling VLAN 0 has been present for a while. Has anyone filed a bug report to MT support about the shortcoming? Or is the only option to use a device with the appropriate switch chip?
Wojo has a script that can do everything without a switch chip on the router.
That being said using a $49 tp-link in front of an RB750Gr3 works fine. I haven’t seen my nephew with issues, personally I might even buy a hEX since the RB4011 I own heats up the small office I work in a little more than I’d like, plus it’s overkill for me.
The hEX RB750Gr3 has truly impressed me, when paired with $49 Tp-Link in front and my Aruba 2930f switch for LAN, it’s getting over 900/900 with fast-tracking on and less than 50% cpu usage:
It’s quite good! In fact, selling my CCR1009 and keeping the RB4011 as my primary, and the hEX RB750Gr3 as my backup on the shelf (along with a TP-Link switch) as a backup. It’s more than capable if you can do FastPath.
Agreed! I am thinking of doing the same, since my RB4011 cooks me sometimes in my small office it would be nice to use the hEX RB750Gr3 + tp-link on hot busy days.
I’m glad you are happy with your equipment, we are running CCRs and need to stay with those. The best option would be for the bridge to be able to strip VLAN 0, but isn’t that something MT needs to fix? @Wojo workaround is good, but not the ultimate solution.
If you prefer to not use a software bridge the $49 tp-link works well, if you need to use enterprise gear only tell me which switches you like etc. I tried Aruba and Ubnt in front of the hEX and they didn’t work, but I suspect a Mikrotik CRS112 would work fine, just not sure if it’d remove the headers with cpu or the switch chip.
I don’t mind buying more gear to test, helps out our bypass/community effort.
I think email is probably the best method. If we pool efforts with a clear description of what we need and get requests in via email so it’s know how wide the impact is, we have the best chance probably of getting their attention. Some older posts:
Why MikroTik chooses to ignore packets that are priority tagged (but no VLAN, hence VLAN ends up being 0x000) is the root of the cause I believe. There are the following situations that can work:
If both the 802.1x and TCP traffic function with the 802.1Q only containing a 802.1P priority tag, everything would be simple and ideal (no bridge). Traffic would be treated as if not tagged by a VLAN with 802.1Q.
If attached to a bridge with VLAN filtering, allowing 802.1x to function (which is currently broken)
If attached to a bridge without VLAN filtering, it should allow traffic (similar to #1, both situations would allow for VLAN 0 traffic to be treated as non-tagged in terms of 802.1Q VLANs)
@wojo - your summary is excellent. I have emailed MT support and we’ll find out if there is any chance that we can get a full featured 802.1x solution.
Currently, RouterOS interfaces do not accept packets with VLAN-ID 0 and there is no option to create a VLAN interface with VLAN-ID 0. However, there is a possible workaround - add the interface into a bridge with enabled vlan-filtering. VLAN filtering will treat these packets as untagged, but currently, there is no option to force the reply packets to respond with a VLAN-ID 0.
How would you expect to treat VLAN-ID 0 packets in RouterOS? Should we allow the users to configure a special-purpose VLAN interface that accepts these packets? How should RouterOS respond - with or without VLAN-ID 0 header?
Glad to see them thinking about it. I don’t yet know the right answer, other than allow for us to sendandreceive802.1p packets, of any ID, not just 0. The reason they mention a bridge, is because to enable this across all of their product line, they would need to do it in software, hit the CPU. I would like a way to avoid that, if possible. But I understand this would be a business decision for them.
I just got an RB4011 and got it setup per these instructions perfectly (using the supplicant method). Now I’m attempting to get an IPv6 address and it’s just not happening. This is my entire IPv6 config right now:
I’m not able to get an address, or a prefix. The IPv6 web UI just shows “Status: searching…” in the DHCPv6 Client settings. The weird thing is that I was able to get an IPv6 address this morning, but in my attempt to get the IPv6 Server working, I somehow broke the client. I’m not sure if this is related to AT&T or not, but considering the work required to get this to work, that’s my suspicion. A related question I have, does the DUID matter? I was previously using pfAtt on pfSense and that required a special DUID workaround to get an IPv6 address. Considering it was working for me at one point, and it’s apparently working for some others, my guess is that it’s not required, but I’d love confirmation of that.
Does anyone have any suggestions on what I might do to get any sort of IPv6 address or prefix?
I think we chatted on reddit, but if not then first thing to do is check ND, in fact have you watched a video that shows ipv6 setup on RouterOS/mikrotik? I’d recommend starting with that since there are quite some differences from pfSense.