[HN Gopher] Recent Apple Updates Leading to WiFi Issues
       ___________________________________________________________________
        
       Recent Apple Updates Leading to WiFi Issues
        
       Author : bradleybuda
       Score  : 65 points
       Date   : 2022-12-08 17:59 UTC (5 hours ago)
        
 (HTM) web link (www.meter.com)
 (TXT) w3m dump (www.meter.com)
        
       | macshome wrote:
       | I really don't like that the page asks users to blindly curl and
       | execute a script that then curl and executes another script all
       | to run a one line `ifconfig` command.
       | 
       | Why not just share the command?
        
       | varenc wrote:
       | Their actual solution for disabling AWDL is running this script
       | in the background:                   while true; do
       | if ifconfig awdl0 |grep -q "<UP"; then                 (set -x;
       | ifconfig awdl0 down)             fi            sleep 1
       | done
       | 
       | That just checks the awld0 interface every second and turns it
       | off if it's on. Apple really doesn't offer any other way to
       | disable awdl?
       | 
       | Note that setting AirDrop to "No One" doesn't fully disable awdl.
       | It's used for other things like screen sharing, AirPlay, bonjour
       | device/service discovery, etc. Though perhaps disabling AirPlay
       | is enough to stop the WiFi issues. You can sniff awdl traffic
       | with `sudo tcpdump -i awdl0`
        
         | more_corn wrote:
         | I've been digging for a way to do this with defaults write and
         | plists. So far I haven't figured it out.
        
         | InvaderFizz wrote:
         | I've been having this problem for months. The solution I
         | settled on was a root cronjob that just does `ifconfig awdl0
         | down` every minute.
         | 
         | It makes shared clipboard not work as well with my iPhone, but
         | at least I get 180Mbps/70ms on the work VPN instead of
         | 4mbps/70-700ms.
         | 
         | The interface stays down till the laptop sleeps, so most of the
         | time it's a no-op.
        
         | mrtesthah wrote:
         | You might also try something like:                  sudo
         | /usr/libexec/airportd en0 prefs AWDLEnabled=YES
         | 
         | (Edit: see varenc's reply below)
         | 
         | Or you could create a kext (using deprecated KPIs) that
         | continuously blocks the interface from coming up:
         | errno_t awdlblock_ioctl_handler(void *cookie, ifnet_t
         | interface, protocol_family_t protocol, unsigned long ioctl_cmd,
         | void *ioctl_arg) {                  if (SIOCSIFFLAGS ==
         | ioctl_cmd) {          struct ifreq *ifr = (struct
         | ifreq*)ioctl_arg;                    if (ifr &&
         | ((ifr->ifr_flags) & IFF_UP) != 0) {           return
         | EJUSTRETURN;          }         }         return ENOTSUP;
         | }                kern_return_t awdlblock_start(kmod_info_t *
         | ki, void *d)        {            struct iff_filter filter = { 0
         | };            errno_t err = ifnet_find_by_name("awdl0",
         | &p_ifnet);            if (err) {
         | printf("interface awdl0 not found\n");                return
         | KERN_SUCCESS;            }            filter.iff_name     =
         | "AWDLBlock";            filter.iff_ioctl    =
         | awdlblock_ioctl_handler;            iflt_attach(p_ifnet,
         | &filter, &p_filter);                        return
         | KERN_SUCCESS;        }
        
           | varenc wrote:
           | Wow I didn't know about that undocumented ability to change
           | Airport prefs!
           | 
           | I was able to somewhat disable AWDL by doing this like you
           | suggest:                   sudo /usr/libexec/airportd en0
           | prefs AWDLEnabled=YES
           | 
           | And then restarting airportd so that it picks up the change:
           | sudo launchctl kickstart -k system/com.apple.airportd
           | 
           | This worked without having to disable SIP and modify
           | com.apple.airportd.plist
           | 
           | It doesn't take the awdl0 interface down, and I still see
           | some traffic on it, but I can confirm that it disables some
           | awdl features like "Unlock with Watch" and Screen Sharing
           | over awdl. (Screen Sharing will work over your wifi network
           | instead, but normally it'll prefer a direct awdl link)
        
             | mrtesthah wrote:
             | That's good to hear that's all it takes!
             | 
             | Yes, Bonjour name resolution, which Screen Sharing uses,
             | can also run over AWDL, but of course it does not have to.
             | 
             | There was a bug in OS X Yosemite and older versions of iOS
             | which caused any AWDL activity to severely increase network
             | jitter and latency; this sounds like a regression.
             | 
             | https://medium.com/@mariociabarra/wifried-ios-8-wifi-
             | perform...
        
       | runxel wrote:
       | Had big issues with Zoom today indeed - for how long has this bug
       | existed?
       | 
       | I'm still on Monterey but have not yet updated to 12.6.1.
        
       | snarf21 wrote:
       | I _really really really_ wish that Apple would always use DHCP
       | and get an open IP instead of assuming their last one is still
       | good just so they can say they connect to WiFi 100 ms faster than
       | anyone else. It is so infuriating and causes all the devices in
       | my house to fight for their rightful slot.
        
         | kitsunesoba wrote:
         | Perhaps this is more of a problem with some router
         | manufacturers/firmwares than others? I've had a bunch of
         | difference devices running several different OSes (including
         | several Apple devices) connected to a Netgear router running
         | stock firmware for the past year and some change and have had
         | no trouble at all.
        
           | acdha wrote:
           | Quite likely. Google WiFi notoriously had problems with Apple
           | devices which they never bothered to fix. Switching to Eero
           | completely resolved the random ~45 second hangs we'd see a
           | few times a day.
        
         | tristor wrote:
         | Is this true? I hadn't even noticed, because I assign every
         | device a static DHCP assignment so I can categorize devices
         | numerically. That is really messed up, and akin to what Google
         | does with TCP/HTTP for connections to google.com in order to
         | ensure it gets first byte faster. Companies are doing all sorts
         | of "performance hacks" that just straight our break standards,
         | and therefore break interop. I know for Apple devices I had to
         | disable some standardize WiFi functionality on my access points
         | because these devices cannot handle it despite claiming to
         | support the standard.
        
           | lilyball wrote:
           | Apple isn't breaking a standard. If the IP address was
           | reassigned to another device it'll just get told that upon
           | attempting to use it.
        
         | lilyball wrote:
         | Why are they fighting? Why is your router aggressively reusing
         | the IPs as soon as the lease expires?
         | 
         | In my house, all of my devices end up with pretty stable IPs
         | (even non-Apple ones) and I haven't done anything special to
         | configure this. I assume my router holds onto previously-
         | assigned IPs in case the device comes back as long as there's
         | still unassigned IPs available to give out to new devices,
         | though I haven't investigated it.
        
           | error503 wrote:
           | Clients will usually request their previous IP in the
           | request, and servers will often prefer to give clients their
           | previous IP even if they don't request it. It's also pretty
           | common that the client still has a valid lease (as far as the
           | server is concerned), which it makes sense for the server to
           | reissue.
        
       | nighthawk454 wrote:
       | does this impact iOS wifi as well? My local HomeAssistant detects
       | my phone on wifi for presence detection, and suddenly lately it's
       | been all out of whack. it takes much longer to connect to wifi
       | when I get home. and sometimes while home the presence status
       | 'flickers', turning all the lights on/off. never used to happen
        
         | drdaeman wrote:
         | Could be. I've noticed my iPhone started to accidentally
         | intermittently lose WiFi connection, only to reconnect again in
         | ~3-5 seconds. I wasn't sure if this is iOS or UniFi AP bug, but
         | I suppose it could be the former.
        
           | nighthawk454 wrote:
           | As it happens, I'm also on a Unifi AP, so that's curious.
           | Would not hesitate to assign blame there... Although, I have
           | long since abandoned their automatic firmware updates which
           | has really helped with stability, so I'm not sure what
           | would've changed on the AP _recently_.
        
       | mkw5053 wrote:
       | I really hope this fixes my WiFi issues
        
       | LeoPanthera wrote:
       | I (used to) work in academic IT and I hate articles like this.
       | 
       | People would assume there is a serious problem, turn off a bunch
       | of services, run a bunch of random-ass shell scripts, and then
       | _forget_ that they 'd done all that and at some random point in
       | the future discover that some feature wasn't working, and blame
       | me.
        
         | jcynix wrote:
         | I mostly agree. But the article isn't the main problem, the
         | sloppy script is. When I install such hot fixes, I have them
         | check if the cause still exists (e.g. still running under
         | Monterey?) and, additionally, add a timeout based on a date.
        
           | more_corn wrote:
           | If you simply disable the nic apple helpfully reenables it 15
           | min later. There's blame to be assigned here. Pretty sure it
           | belongs to apple.
        
         | bin_bash wrote:
         | don't forget all the cargo-cult of people stumbling on this
         | article with unrelated wifi issues!
        
         | crazygringo wrote:
         | I swear I really wish there were a way to output an entire OS's
         | "diff" from default settings. Every preference pane, every
         | terminal setting, every changed system file.
         | 
         | So that you could both discover, in cases like this, what's
         | changed -- but also simply so you could export your settings in
         | a space-efficient way and (selectively) re-import on a new OS
         | install.
        
           | m3drano wrote:
           | With the sealed system volume modern macOS uses, shouldn't
           | this relatively doable? (It'd be a long long diff of XML
           | plists I guess)
        
             | fathyb wrote:
             | Most macOS settings are saved under the current user home
             | directory, which isn't sealed.
        
           | dwohnitmok wrote:
           | This has gotta be some sort of HN meme at this point but...
           | NixOS gives you this (with the tradeoff of course of a really
           | steep learning curve and very opinionated packaging
           | structure)!
        
             | noasaservice wrote:
             | The asymptote for NixOS approaches -infinity.
             | 
             | Once it actually is usable, sure, I'll take a look.
        
           | djxfade wrote:
           | This should definetly be possible to write for macOS, since
           | the recovery partiton contains the base OS
        
         | lxgr wrote:
         | Couldn't have said it better.
         | 
         | That script will be hanging around on people's laptops for
         | years, if not decades (for people that migrate their macOS
         | installations to new machines) at the end of the long tail.
        
         | more_corn wrote:
         | I just spent the last week diagnosing catastrophic Wi-Fi issues
         | at a client location. 90% of macs wouldn't connect to Wi-Fi,
         | when they would association would take 45 seconds. Sometimes
         | you couldn't route or ping the gateway. When you could you'd
         | get disassociated within a minute. Turning off the
         | airdrop/anirplay interface fixes it instantly. sudo ifconfig
         | awdl0 down
         | 
         | It took us 5 days to figure it out. We had no less than a dozen
         | professionals on it. Each with at least a decade of experience.
         | We combed the Wi-Fi and network config repeatedly to figure out
         | what we did wrong. (It wasn't till we had the hint that it was
         | client side that we sniffed the nic to see the packet of death)
         | 
         | So I'm going to respectfully disagree. Articles like this are
         | important. If I'd seen this last Monday it'd have saved me a
         | week of hell and saved my client a week of vastly diminished
         | productivity. Not to mention the tens of thousands of dollars
         | spent diagnosing it and the millions of dollars of lost revenue
         | from the deals they couldn't close because calls kept dropping
         | in the office (because enough people were on hotspots to
         | saturate cell service in the area)
        
           | acdha wrote:
           | Information is important, but this post didn't have enough
           | technical information about how to tell if this is your
           | problem. How many people would say they haven't experienced
           | "slow internet connection" or "drops in Zoom calls"?
           | "entirely losing a WiFi connection" is less common but does
           | that mean "it happened once and then it came back" or
           | something like the hell you're describing.
           | 
           | That's important for the reasons the person you're responding
           | to mentioned. I too have seen many problems caused by this
           | kind of thing where someone had something they didn't like,
           | made a ton of low-level config changes based on random blog
           | posts, and then forgot about that when it broke something
           | else.
        
       | johnklos wrote:
       | That is absolutely the WRONG way to do this. You want people to
       | download a shell script that then downloads another shell script,
       | then runs that shell script via sudo? That second shell script
       | could be changed at any time.
        
       | lapcat wrote:
       | > Note: if you opt to not use the script and want to use the UI,
       | you have to disable both Bluetooth and AirDrop.
       | 
       | Periodic reminder that Apple re-enables Bluetooth on every OS
       | update: https://lapcatsoftware.com/articles/bluetooth.html
        
         | soziawa wrote:
         | It also resets custom DNS settings for all networks.
        
       | moffatman wrote:
       | I found just disabling these kind of Wi-Fi direct / local sharing
       | features on macOS solved some latency I was seeing during online
       | games. For example: Universal Control when enabled would cause
       | the connection to choke for a few seconds when waking my iPad
       | nearby.
        
       | bink wrote:
       | Please don't recommend people pipe curl output to a shell. Yikes.
        
         | datalopers wrote:
         | Wait until you find out nearly every modern package manager
         | installs stuff directly from github repos.
        
           | johnklos wrote:
           | Nope. See pkgsrc.
        
         | rrauenza wrote:
         | How did piping shell scripts from web sites become acceptable?
         | 
         | > bash <(curl -sL https://www.meter.com/awdl.sh)
         | 
         | Eek!
        
           | secabeen wrote:
           | It's really common in the Mac world, homebrew does it too:
           | https://brew.sh/
        
         | btgeekboy wrote:
         | What could someone do with a curl pipe that they couldn't do
         | with a signed, obfuscated executable?
        
         | efficax wrote:
         | eh it's fine. sure, technically speaking you're giving your
         | machine over to whoever wrote that script. they could do
         | anything! but actually, the script is usually useful and safe.
         | Like this one.
        
           | lxgr wrote:
           | You know that, I know that, but the thousands of people
           | getting desensitized and trained to run random terminal
           | commands like this to "fix their wi-fi" usually don't.
           | 
           | The problem isn't even pasting curl output into sh - it's
           | instructing non-technical users to run _any_ terminal
           | commands, in my opinion.
        
       | acdha wrote:
       | Any idea what the trigger is? This doesn't happen normally so I'm
       | wondering whether there some relationship with the vendor UCLA
       | uses or some other network condition.
        
       ___________________________________________________________________
       (page generated 2022-12-08 23:00 UTC)