Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    What's involved in fixing VLAN's?

    Scheduled Pinned Locked Moved 2.1 Snapshot Feedback and Problems - RETIRED
    18 Posts 6 Posters 4.3k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      markuhde
      last edited by

      This topic is partially to draw attention to bug 2349 https://redmine.pfsense.org/issues/2349 - but more to ask what it realistically will take to fix this bug? The bug description makes it sound like a core functionality got broken in FreeBSD 8.3 and fixing this bug will be a rather long ordeal that may or may not even happen? To be honest, I'm just learning about FreeBSD (just setup a FreeBSD web server last night as a test/sandbox - something I've always used Linux for!) and I'm also just starting to learn more about using VLAN tagging. This sounds more like an underlying OS problem or change, and I'm trying to understand it better not only for pfSense but also for using FreeBSD in general. I've been very impressed with the stability and uptime I'm getting on pfSense, even the 2.1 snapshots, and want to learn more advanced networking.

      I do run a small business, but most of my clients are just using off-the-shelf routers plugged in with maybe a couple extra access points. I'm learning larger (thus, more profitable) installs starting with a camp that's friendly to me (that's where the pfSense 2.1 install is) and a couple other friendly clients of mine. Thus, the need to learn things like VLAN tagging, QoS traffic shaping (the feature I'm anxiously awaiting patiently being able to use in pfSense 2.1 - the major bug was fixed and now 2349 keeps it from working), RADIUS authentication, 802.1x, etc.

      1 Reply Last reply Reply Quote 0
      • C
        cmb
        last edited by

        It's not fixing VLANs, it's fixing ALTQ. It's not designed to work on virtual interfaces, we have a kernel patch that accommodates that which has to be adapted every base version change.

        1 Reply Last reply Reply Quote 0
        • M
          markuhde
          last edited by

          Ah, so basically FreeBSD doesn't actually support traffic queues on virtual interfaces, thus every release of FreeBSD requires the pfSense team to add this functionality?

          Sorry if that's not exactly correct, that's why I'm asking - I'm trying to learn this. My initial idea was I was going to give up on pfSense on this install, and just install FreeBSD 9.0 and learn to configure the functionality I needed myself - I came here thinking pfSense was nothing more than a configuration GUI on top of FreeBSD. I'm starting to learn that pfSense really is in many ways it's entirely own software project, with a lot of added functionality one can't get simply by installing ports on FreeBSD. Impressive stuff and thank you guys very much for all you do!

          1 Reply Last reply Reply Quote 0
          • M
            markuhde
            last edited by

            Okay, so while I'm waiting on this to be fixed - since it doesn't seem to be an easy or quick fix likely to happen anytime soon - does anyone know a way to traffic shape just my WAN port (since it's on a physical interface)? Basically, I just want to prioritize ACK's at least so that the upstream can't get saturated and force the downstream to a crawl on the extremely off-balance 10 Mbps/768 kbps ADSL connection

            1 Reply Last reply Reply Quote 0
            • rcfaR
              rcfa
              last edited by

              @cmb:

              It's not fixing VLANs, it's fixing ALTQ. It's not designed to work on virtual interfaces, we have a kernel patch that accommodates that which has to be adapted every base version change.

              Is there a reason why the FreeBSD folks don't just incorporate that patch once and for all in their code base?
              It's kind of strange that someone fixes it, and they keep going on with the same old…
              ...at least that's what it sounds like.

              1 Reply Last reply Reply Quote 0
              • D
                dhatz
                last edited by

                Is there a reason why the FreeBSD folks don't just incorporate that patch once and for all in their code base?

                FreeBSD's pf is several years behind OpenBSD's.

                I wish FreeBSD would make "pf" their primary packet-filter … as Apple has apparently done recently. This might also encourage them to fix some of the long-standing issues of pf under FreeBSD, e.g. GRE+NAT (for PPTP), NAT before IPsec etc

                1 Reply Last reply Reply Quote 0
                • C
                  cmb
                  last edited by

                  @dhatz:

                  I wish FreeBSD would make "pf" their primary packet-filter … as Apple has apparently done recently. This might also encourage them to fix some of the long-standing issues of pf under FreeBSD, e.g. GRE+NAT (for PPTP), NAT before IPsec etc

                  Most of those issues have nothing to do with FreeBSD, they're the same in Open to this day. They do at least have a NAT+IPsec work around for isakmpd, but GRE and other things are no different there.

                  @rcfa:

                  Is there a reason why the FreeBSD folks don't just incorporate that patch once and for all in their code base?
                  It's kind of strange that someone fixes it, and they keep going on with the same old…
                  ...at least that's what it sounds like.

                  We're doing what we can to get more involved upstream so we don't have to keep patching and re-patching and re-patching.

                  1 Reply Last reply Reply Quote 0
                  • M
                    markuhde
                    last edited by

                    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!

                    1 Reply Last reply Reply Quote 0
                    • M
                      markuhde
                      last edited by

                      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.

                      1 Reply Last reply Reply Quote 0
                      • jimpJ
                        jimp Rebel Alliance Developer Netgate
                        last edited by

                        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.

                        Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                        Need help fast? Netgate Global Support!

                        Do not Chat/PM for help!

                        1 Reply Last reply Reply Quote 0
                        • M
                          markuhde
                          last edited by

                          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?

                          1 Reply Last reply Reply Quote 0
                          • jimpJ
                            jimp Rebel Alliance Developer Netgate
                            last edited by

                            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.

                            Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                            Need help fast? Netgate Global Support!

                            Do not Chat/PM for help!

                            1 Reply Last reply Reply Quote 0
                            • M
                              markuhde
                              last edited by

                              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?

                              1 Reply Last reply Reply Quote 0
                              • jimpJ
                                jimp Rebel Alliance Developer Netgate
                                last edited by

                                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.

                                Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                                Need help fast? Netgate Global Support!

                                Do not Chat/PM for help!

                                1 Reply Last reply Reply Quote 0
                                • M
                                  markuhde
                                  last edited by

                                  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.

                                  1 Reply Last reply Reply Quote 0
                                  • jimpJ
                                    jimp Rebel Alliance Developer Netgate
                                    last edited by

                                    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.

                                    Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                                    Need help fast? Netgate Global Support!

                                    Do not Chat/PM for help!

                                    1 Reply Last reply Reply Quote 0
                                    • M
                                      markuhde
                                      last edited by

                                      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

                                      1 Reply Last reply Reply Quote 0
                                      • T
                                        trunix
                                        last edited by

                                        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.

                                        1 Reply Last reply Reply Quote 0
                                        • First post
                                          Last post
                                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.