_______               __                   _______
       |   |   |.---.-..----.|  |--..-----..----. |    |  |.-----..--.--.--..-----.
       |       ||  _  ||  __||    < |  -__||   _| |       ||  -__||  |  |  ||__ --|
       |___|___||___._||____||__|__||_____||__|   |__|____||_____||________||_____|
                                                             on Gopher (inofficial)
   URI Visit Hacker News on the Web
       
       
       COMMENT PAGE FOR:
   URI   Indoor Wi-Fi Roaming with OpenWRT
       
       
        rubenbe wrote 29 min ago:
        I'm developing opensoho as a central controller for SOHO OpenWrt
        setups. I've recently added support for usteer and I did notice a
        significant drop in wireless clients with a bad connection.
        
   URI  [1]: https://github.com/rubenbe/opensoho
       
        MiracleRabbit wrote 59 min ago:
        With Wi-Fi 8 we will finally get steerable friendly roaming like
        cellular radio is doing for almost 40 years now.
        
        This "here's a neighbor table, disassoc and fuck you&good luck"-method
        we must use right now is just super painful. It's super complicated to
        build reliable networks that way.
       
        geeunits wrote 1 hour 23 min ago:
        Warning all, the website has a hidden prompt injection in the footer.
       
        drnick1 wrote 1 hour 32 min ago:
        I still like the TP-Link E610 (flashed to OpenWRT) better. They are
        more compact and presumably more durable than "residential" devices. I
        also dislike anything that has "mesh" in its name.
        
        To me at least, the gold standard for a large home is a standalone
        cable modem or ONT connected to an x86 PC that serves as home server
        and router, and as many ceiling mounted APs as necessary to ensure good
        WiFi coverage. No cloud, apps, or proprietary software anywhere. With
        such a networking backbone it is also easy to integrate self-hosted
        security cameras and other appropriately hacked IoT devices.
       
        tra3 wrote 1 hour 39 min ago:
        Question for the wifi experts in this thread...
        
        What's a good off the shelf multipoint wifi system these days? I have
        Amazon's Eero right now and it's ok.
        
        I'd love to go back to my linksys wrt54 roots but that's not in the
        cards currently..
       
          downrightmike wrote 24 min ago:
          ubiquity
       
        bobbob1921 wrote 1 hour 53 min ago:
        I do a lot of work on very large Wi-Fi networks (i.e. hotel/apartment
        complexes with 80 to 500+ access points), for a very rough quick test
        of coverage quality and roaming performance, find a Ping app for your
        phone that allows you to set a super low interval (i.e. time between
        pings sent), and ping your gateway router (i.e. 192.168.1.1) and while
        that is running walk around your home/location.
        It’s important that the Ping app keeps sending pings even if they
        drop, i.e. it should just look like a waterfall/constant stream of fast
        pings that show you red/green pings and ideally a summary at the end. 
        On iOS the app I tell people to use is called “Ping” with a blue
        icon, I usually have to share the link to the app as there are several
        with this name (I’m not on my phone currently or I would share the
        link) there are several ping apps that do offer this fast ping feature.
       
        raj_db_dev wrote 2 hours 2 min ago:
        Curious if you think usteer is viable without wired backhaul. I have
        two OpenWRT routers in different rooms in differnt part of the house
        and not possible to connect them by ethernet. Would the usteer overhead
        make things worse if they're just communicating over wifi?
       
        acidburnNSA wrote 2 hours 4 min ago:
        I spent a long time recently setting pretty much this same thing up.
        When in my office my Android phone battery rapidly died, I guess
        because usteer kept trying to steer it or something. I ended up turning
        off usteer and 802.11r and just deal with slow roaming. Maybe I should
        try again with the static neighbor reports.
       
        goodbirb wrote 2 hours 7 min ago:
        99% of what he did is not needed. Only 2 things are needed: enable fast
        roaming (FT), and change DTIM from the openwrt default of 2, to 3.
        That's all. No need to install usteer, extra hostapd fields. Nothing.
        
        By lucky chance, while he set up usteer, he modified DTIM to 3 thus
        fixing the fast transition roaming, which doesn't work well on default
        openwrt because of DTIM. Especially Apple devices really hate DTIM=2
        (they need the extra off-time given by DTIM to properly scan the other
        channels).
       
          rcarmo wrote 1 hour 6 min ago:
          Actually, no. DTIM was always 3, if you'd bothered to read the
          original post - [1] I do know what Apple devices "like" (it's kind of
          my thing, hence the domain name).
          
   URI    [1]: https://taoofmac.com/space/reviews/2025/09/14/1630
       
        TimTheTinker wrote 2 hours 16 min ago:
        Not to be that guy, but...
        
        If you want multiple SSIDs, roaming, daily neighbor scanning and auto
        channel selection, etc, but don't like to spend hours tinkering with
        your equipment beyond the physical setup, then Ubiquiti UniFi equipment
        is great.
        
        I stopped recommending UniFi around 2020 (several of their best
        engineers had left, and they made some dumb choices), but IMO they're
        back to being a decent choice. And I appreciate that they're become a
        one-stop solution for all home/SOHO as well as mid size enterprise IT
        needs.
       
          rcarmo wrote 1 hour 9 min ago:
          Ubiquity would have added another zero (at least) to the price here
          and bring cloud features I very determinedly did not want to have in
          the first place (check the original post at [1] ).
          
          This wasn't hours of tweaking. Well, over almost a year, maybe two
          hours, but no more than that.
          
   URI    [1]: https://taoofmac.com/space/reviews/2025/09/14/1630
       
          bdavbdav wrote 1 hour 17 min ago:
          Yep exactly. This stuff quickly falls into “choose your battles”
          for me, and I’d rather just offload the issue
       
            rcarmo wrote 1 hour 2 min ago:
            As long as you're happy with having your home wi-fi potentially
            controlled by the cloud...
       
        wwweeee wrote 2 hours 57 min ago:
        Using only 6ghz, turned off 2.4 & 5. Problem solved.
       
          Chihuahua0633 wrote 1 hour 18 min ago:
          How's that working out for your IoT Devices?
       
        lxgr wrote 3 hours 4 min ago:
        > The obvious advice for roaming is “use one SSID everywhere”, and
        that is often correct if you’re running Wi-Fi in an office, a public
        venue, or generally somewhere where you don’t have (or care about)
        legacy devices.
        
        What difference does the presence of legacy devices make? Is the intent
        to isolate them from modern devices from a network perspective? Then
        create a separate SSID on both 2.4 and 5 GHz for modern devices.
        
        I can't think of any legitimate reason for split SSIDs anymore. Linux
        clients used to be pretty bad at preferring 5 over 2.4 GHz if RSSIs
        were both excellent but 2.4 was slightly better, but I haven't seen
        that in years.
       
          esseph wrote 1 hour 21 min ago:
          > I can't think of any legitimate reason for split SSIDs anymore.
          
          Different networks / vlans / firewall rules.
       
            lxgr wrote 31 min ago:
            These are all not splits by frequency, though.
       
          rcarmo wrote 2 hours 32 min ago:
          There is zero benefit to using 2.4 for me, really, since it's crowded
          as heck. I'd rather skip it altogether.
       
            lxgr wrote 2 hours 26 min ago:
            If you don't need it, of course, you might as well deactivate it.
            But if you do, I don't see the point of having two different SSIDs
            if you don't need them for another reason anyway.
       
              rcarmo wrote 2 hours 22 min ago:
              I do need it, but the IoT devices are conveniently close to most
              APs, so that sort of evens out.
       
        thenthenthen wrote 3 hours 21 min ago:
        Cool! I dont need this anymore since im broke and moved to a 1 room
        apt. but yeah the ‘set the same ssid’ “trick” def. is not
        enough and often achieves the opposite effect.
       
        Jabdoa2 wrote 3 hours 23 min ago:
        You can also "just" set the 802.11k entries manually. Add 802.11r and
        you should be mostly good. Usteer makes it slightly better by moving
        clients to the best AP when they stay stationary for longer whiles.
       
          pickdan wrote 1 hour 26 min ago:
          There is a pretty interesting option "nrsyncd" that uses UPNP rather
          than having to add the 802.11k entries by hand/script.    Seems to work
          quite well, takes a few minutes to gather the information about the
          other devices.
          
   URI    [1]: https://github.com/Fail-Safe/nrsyncd/blob/main/README.md
       
          rcarmo wrote 2 hours 21 min ago:
          Yeah, that is actually what the OpenWRT package does, except it grabs
          the data for me. Saves me the scripting :)
       
        ruptwelve wrote 3 hours 40 min ago:
        When I move from Europe to the US I realized that roaming is not as
        prevalent here as it is back home. The (mostly) wooden houses enable me
        to just use one really powerful AP for most of my needs.
       
        ghrl wrote 3 hours 40 min ago:
        I don't quite understand the benefit of the setup. If there are legacy
        IoT devices that need unique named 2.4G network, just broadcast another
        SSID for them. So each router broadcasts main 5G (common name, fast
        roam etc), main 2.4G (same as above) and legacy IoT 2.4G (with a
        different name for each AP, and possibly worse encryption and maybe
        even TKIP). That wouldn't hold back the network for legacy devices.
       
          rcarmo wrote 2 hours 34 min ago:
          I _am_ broadcasting a second SSID, in case that was not obvious from
          the text... I just don't want there to be 3.
       
          toast0 wrote 3 hours 20 min ago:
          I run a single ssid dual band network ... what tends to happen is
          5Ghz is effectively ignored. 2.4Ghz has better coverage, so
          everything wants to live there. At least wifi 6 brought improved
          encoding to 2.4Ghz.
          
          I haven't had luck with the roaming extensions; when I run them, some
          of my devices won't connect or won't stay connected and it's a pain
          to monitor. I guess I could run a different SSID with roaming
          enhancement, but effort.
       
            neogodless wrote 9 min ago:
            My current experience is that out of ~20 devices, about 6 are on
            5Ghz and the rest choose 2.4Ghz. And it's basically perfect.
            
            Because the 6 devices on 5Ghz: laptops and smartphones.
            
            The rest are "smart" devices that work perfectly on 2.4Ghz.
       
            Marsymars wrote 1 hour 4 min ago:
            > I run a single ssid dual band network ... what tends to happen is
            5Ghz is effectively ignored. 2.4Ghz has better coverage, so
            everything wants to live there.
            
            That hasn't been my experience at all. Checking my current network
            status, I've got 24 devices connected to 5GHz and only two devices
            (my two Nest Doorbells, for whatever reason) connected to 2.4GHz
            that also supports 5GHz.
       
            ssl-3 wrote 1 hour 36 min ago:
            That's been my experience as well.
            
            My workaround for part of that is using many SSIDs.
            
            A.  The SSID that covers both bands, in all areas
            
            B.  Two more SSIDs, one for each band -- again, used in all areas
            
            C.  Another SSID just for the AP in the garage (which also has A
            and B SSIDs)
            
            It has some advantages:   I like being able to set a portable
            device to SSID A.  These things usually figure it out well-enough
            while moving around.  When someone visits and asks for wifi access,
            I give them SSID A.  It works; it's just not always perfectly
            ideal.
            
            It also prevents fixed devices in the garage from deciding to use
            APs in the house; it never works well for them when that happens. 
            (The opposite problem hasn't been observed to be an issue yet.)
            
            And it lets me decide whether any device is able to use 2.4 or
            5GHz, in the usual way of having per-band SSIDs.  If my TV streamer
            weren't plugged in with ethernet, then I'd set it to use the
            5GHz-only SSID.
            
            ---
            
            A big downside is that it's ugly.  Another is that the per-device
            config is spread out amongst all of the devices instead of
            centralized, but that's not so bad: I just make the SSID decision
            at initial device setup and forget about it.
       
              esseph wrote 1 hour 24 min ago:
              This also impacts maximum throughout / performance. You want to
              try at limit to 4 BSSIDs per AP, tops.
       
                ssl-3 wrote 38 min ago:
                I'm at 4.
                
                What are the nuts-and-bolts reasons that would make 5 perform
                worse?
       
            lxgr wrote 3 hours 2 min ago:
            This used to be pretty common on at least Linux and Android clients
            some years ago.
            
            Not sure if they finally got around to making the BSSID selection
            algorithm a bit smarter or whether all my access points just
            support active steering at this point, but I haven't seen this in
            the past couple of years.
       
            opan wrote 3 hours 13 min ago:
            You can turn down the power on the 2.4GHz radio so it's not as
            overpowering.
       
              toast0 wrote 2 hours 37 min ago:
              I do, but I can only turn it down so much or I lose outdoor
              coverage.
       
                esseph wrote 1 hour 23 min ago:
                Add outdoor AP, shrink all coverage areas. You should end up
                with better performance.
       
        goodburb wrote 3 hours 45 min ago:
        You can stick to 802.11r only by lowering the transmission power and
        have all the APs on the same channel, in my tests it ended up switching
        much faster than K/V. (~75ms)
        
        On iOS, equal channel with correct ESS will switch liberally. On
        Android 14+ with Broadcom chip it will start conservative, then switch
        liberally after the first poor signal switch-over event, up until
        disconnection.
        
        Android (Pixel/Moto) will never switch (even with K/V) on large network
        activity, only VoIP/video call. It depends on vendor implementation.
        [0]
        I use "dp.logcatapp" log reader while roaming,
        "com.android.location.fused" can be used to show score and current
        load.
        
        Samsung is known to push protocol support early: 802.11r in 2013,
        802.11w 2015, some models do not use Android's default connectivity
        manager.
        
        To add, WPA3 with 802.11r is known to have issues on Apple hardware
        before 2021 on all iOS versions, many Android devices, especially smart
        TVs don't support it, will not connect or are unreliable (protected
        beacon frame), can be searched in buried report results at OpenWrt
        forum mega threads and Ubiquity. WPA2+FT and forced MFP with a long
        password is a safe alternative. 802.11r use PMK push on WPA3 compared
        to WPA2, which was known to be problematic on older hardware.
        
        802.11K/V is more suitable for campus and load balancing, tuning it
        based on RSSI and station metrics is very difficult, enterprise
        hardware rely on network traffic and air time.
        
        [0]
        
   URI  [1]: https://source.android.com/docs/core/connect/wifi-network-sele...
       
          js2 wrote 2 hours 11 min ago:
          Apple has some minimal recommendations as well:
          
   URI    [1]: https://support.apple.com/en-us/102766
       
          rcarmo wrote 2 hours 34 min ago:
          Yeah, I tried the same channel thing, but I can't change the power,
          really - the flat is wrapped around two elevator shafts :)
       
            goodburb wrote 53 min ago:
            The elevators are probably causing rapid blind spots (shadows)
            while the user is moving around, 802.11k is indeed useful in this
            case for cutting down scan time, since iOS will still scan with
            filtered channels.
            
            It's an interesting setup, looking forward to an update.
       
              rcarmo wrote 17 min ago:
              You're not getting it. The lift shafts are lined, this is an
              armored concrete building in Europe.
       
          dheera wrote 2 hours 35 min ago:
          On my Unifi setup at home with multiple APs I had to disable 802.11r
          to get things to roam fast. I have Android and Linux laptop, wife has
          iPhone and MacBook.
          
          With 802.11r on, things would disconnect for 60+ seconds before
          reconnecting. It was a constant frustration of "arrrrrrrggghhhh
          fucking connect damnit I'm standing a meter in front of the AP can't
          you fucking see it fuck fuck fuck just connect, it's right THERE,
          connect NOW, arghhh" and then it would completely disconnect (no wifi
          found) and then reconnect a minute later.
          
          With 802.11r off things just roam smoothly. I guess the people who
          inventned the tech didn't test it thoroughly enough.
       
          OptionOfT wrote 3 hours 30 min ago:
          To be fair, I don't require my 85" TV to roam, as it's not as
          portable as my iPhone.
       
            cj wrote 2 hours 55 min ago:
            Until it gets stuck on a far away AP because it was the first AP to
            come online the last time the network rebooted.
            
            Not sure if roaming is actually the fix for this problem. For
            whatever reason my Ring cameras just love connecting to the worst
            and most far away AP in my house.
       
              giobox wrote 2 hours 45 min ago:
              Not sure how widely available this feature is, but the unifi
              controller software for the popular Ubiquiti APs lets you bind
              individual client devices to specific APs such that they can only
              connect to the ones you choose.
              
              I had to solve a similar issue for some crap IoT lights that
              would join the incorrect AP after a power cut every time.
              
              >
              
   URI        [1]: https://community.ui.com/questions/Lock-Client-to-Specif...
       
                bobmcnamara wrote 55 min ago:
                This, of course, breaks clients that try to connect to the
                loudest RSSI when the loudest RSSI that they hear is not the
                one that is chosen.
       
                  giobox wrote 29 min ago:
                  Yet to encounter this side effect. So far every crappy wifi
                  device I've tried has obliged.
       
                anotherhue wrote 2 hours 19 min ago:
                for static clients that works well, though you can usually set
                a min rssi and get the same benefit without so much clicking.
       
                  ssl-3 wrote 1 hour 56 min ago:
                  That works for fixed devices like a TV, but also tends to
                  shrink the effective coverage area of the wireless network as
                  a whole.
                  
                  That can mean that the portable wifi speaker-widget (which
                  itself doesn't need much bandwidth) might go from working
                  fine on the back deck or well-enough about anywhere else in
                  the yard, to not working at all outside.
       
                    esseph wrote 1 hour 26 min ago:
                    > That works for fixed devices like a TV, but also has the
                    effect of shrinking the effective coverage area of the
                    wireless network as a whole.
                    
                    Which is normally a good thing to push the clients to roam
                    to a better AP, OR you walked out of the building and want
                    you phone to disconnect. But yes, does impact overall
                    coverage area size.
       
                      ssl-3 wrote 39 min ago:
                      That only works if there's a better AP to roam to.  It's
                      often very easy to add more APs indoors; but hanging them
                      outside is a whole different animal.
                      
                      Meanwhile:  As a practical matter, shrinking coverage
                      means "Hey, honey! I fixed the TV!" gets met with a
                      response like "Oh, so that's why I can't listen to
                      Audible on the veranda anymore!"  :)
       
            keanebean86 wrote 3 hours 5 min ago:
            Good luck watching the office when your cat pushed your upstairs AP
            off the balcony. Your tv won't auto switch to the downstairs AP
            which is now closer than the one that's suddenly in the driveway.
       
            basilikum wrote 3 hours 10 min ago:
            Glad it works for you.
            
            I need my TV to rapidly switch APs in very heavy load wide area
            networks with thousands of devices while I'm cruising through the
            venue with my motorized couch and entertainment system.
            
            Now I want to actually build that for GPN24 next week. Wouldn't use
            AndroidTV for that though.
       
              bobmcnamara wrote 54 min ago:
              My favorite is the WiFi television/sign on an elevator.
       
        jauntywundrkind wrote 3 hours 49 min ago:
        I'd used DAWN for band steering/roaming at my last place, which worked
        ok. uSteer is a little newer & is an official openwrt project. [1] [2]
        DAWN has a wild amount of knobs to tune, which aren't super well
        described. I haven't been running it since a single AP covers my
        current place very well. But it would be interesting to go evaluate
        DAWN & it's config with an LLM, to dice in & see more. uSteer too.
        
        Great write up, good information to share. This really is such an
        important next step for many people's wifi and it's documentation is
        pretty so-so.
        
   URI  [1]: https://github.com/berlin-open-wireless-lab/DAWN
   URI  [2]: https://openwrt.org/docs/guide-user/network/wifi/dawn
       
        jonhohle wrote 4 hours 0 min ago:
        I need to spend some time on it but I purchased two Omada APs to pair
        with my OpenWRT router thinking roaming would just work with mostly
        Apple devices. That didn’t happen. I’m hoping some of this article
        applies and I can improve the situation a bit.
       
          biggc wrote 1 hour 9 min ago:
          I had a hell of a time getting WiFi roaming to work in my house
          between Omada APs in a low-interference suburban neighborhood.
          
          Any combination of 802.11r and k/v seemed to just cause my phone's
          connection to drop for minutes at a time when moving around the
          house.
          
          I wish I could remember my exact solution for you, I believe I just
          turned off 802.11r and k/v, set channel selection to automatic, and
          undid any manual or automatic power tuning.
       
          andor wrote 3 hours 32 min ago:
          For Omada devices, you need a "Controller". You can run the Omada
          Controller software on an existing computer, get one of their
          controller devices, or use their cloud-based service, which should be
          free at your scale.
       
            jonathanlydall wrote 2 hours 12 min ago:
            I’m pretty happy with my Omada controlled EAPs around my house.
            
            Running Omada on my Windows Server was painful (doesn’t really
            run properly as a service, software updates are a chore), but since
            I moved it to run on Proxmox using a super simple LXC image (I
            maybe got terminology wrong here) it’s been very nice.
            
            Supposedly I should have excellent roaming between the APs, but
            I’m not sure how to check. Certainly, walking from one end of the
            house the other while on a Teams or WhatsApp call on my phone has
            maybe only a super minimal amount of time that I might not hear the
            other person (sub second for sure, if at all), but mostly I don’t
            notice.
       
            neogodless wrote 3 hours 29 min ago:
            The Omada device* I researched also supports standalone mode and
            hosts the web UI like any other consumer router.
            
            *
            
   URI      [1]: https://www.omadanetworks.com/us/business-networking/omada...
       
              joshred wrote 2 hours 48 min ago:
              Having the controller is still nice. It's relatively user
              friendly, and consolidates all the devices and their interfaces
              under a single UI.
       
       
   DIR <- back to front page