What's involved in fixing VLAN's?
-
Well I see the bug report says it's fixed today, thanks guys for your awesome work! I'm gonna need to become a paid member soon! Way cheaper than buying commercial firewall products!
-
Hi, I just thought I'd bump this so anyone in my shoes can know not to upgrade snapshots right now - I haven't upgraded thankfully because I subscribed to the bug report, but there was a note posted to the bug report that the patch to fix this has been reverted due to it causing problems with connecting to attached managed switches.
-
That is correct. The changes for ALTQ broke communication for VLANs in some settings, so they had to be reverted.
The ticket will be updated when a new fix is found.
-
Thanks jimp, for what it's worth I'm seeing no problems at all other than I think the queue status is under-reporting the amount of traffic in the queues (for example, HTTP on the staff network goes into QOthersHigh - on the guest network it goes to Squid and seems to show up on QLink). Yet, during a speed test, seeing the full 10mbps down of the DSL line, QOthersHigh on LAN (the staff network) will only show like 2-3Mb in the queue status?
-
Perhaps you're not on a current build. Shaper rules would fail to apply to a vlan interface at all, stating that they do not support altq.
-
Correct, I'm not - that's my point :) I made sure not to upgrade because I stayed subscribed to the ticket. What I was wondering was what didn't work with the fix - the system I have is working perfectly?
-
We had one developer and a couple customers find themselves in situations where some devices would be unreachable on the VLAN. ARP would go out but never reply. Meanwhile other hosts could reach them without issue. Backing out the VLAN changes made it work again.
Not sure exactly what was different about the hosts that could not be reached, but the person who would be able to debug that in depth is out on vacation for another week yet so we backed it out for now.
-
Hmmm, that makes me wonder if I should update and give up traffic shaping. I haven't had any issues that I've been able to observe, but this is at a public place that sees hundreds of users on their Wi-Fi in a week, if even a few would have issues, perhaps it's better to not have traffic shaping… Thanks.
-
Well this is also only the ALTQ shaper that is affected (hfsc, priq, cbq, etc), afaik limiters worked fine. Many things can be expressed similarly in limiters.
-
Okay, so the big thing for me is to prioritize upstream ACK's. Is there any way to do this without traffic shaping? The campground this is installed at is in the middle of a large event now, and while I've heard no Wi-Fi complaints, the occasional "can't connect" amidst a large group of people who CAN connect would probably go unreported. Thus, I'm planning to update and remove the shaping IFF I can keep a couple upload-heavy users from having the ability to bring down the entire connection (It's very off-balance, 10 Mbps downstream, 768 Kbps upstream).
Well, that and concerns I won't be able to get the new PBI of FreeRadius 2 working if I update
-
Running through the appropriate traffic shaping wizard will set up a prioritized ACK queue for the WAN interface (qACK). I think you'll need to select some type of traffic to utilize the ACK queue otherwise it'll just fill up the default queue. All this can be done very easily within the wizard. Are you worried about a small subset of camp customers uploading large YouTube videos and ruining it for everyone else? Why not just prioritize HTTP & HTTPS traffic? I find that when people complain about "the Internet" not working it's usually due to some slow loading webpage.
