Dell XPS 13 L321X WiFi "out of range" Intel 6230 (2012 model)

Comments

6 comments

  • Forrest Smith

    hm... very interesting. I don't know much about the Intel 6230 in particular, but I'd naively expect it to work.

    Here are some questions that might help diagnose the problem:

    1. Does it behave any better if you _do_ use rfkill/airplane button/physical wifi toggle (whichever your machine has) to reset wifi prior to connecting?
    2. Does the wifi connect to other networks? Perhaps a phone hotspot or a public wifi network?
    3. Is your network 2.4GHz or 5GHz or both? Any way to check if there's a difference between the two when separated?
    4. Does the BIOS have any settings around wifi that can be disabled? I think we've seen Dell's with wifi "catcher" functionality act funny until that is disabled... though perhaps that's older?
    5. Does it work any better on v75.1 after updating over the dev channel?
    0
    Comment actions Permalink
  • D O

    I agree, from finding experiences I thought I'd had a go with this old, bit still nice quality laptop.

    I'll answer your bullets accordingly:

    1. I don't see a change in behavior when toggling with physical or software switches to enable or disable WiFi. My laptop has a physical button on the F2 button (to combine with the fn button or not, based on your preference).
    2. I have tried a phone hotspot (Lenovo G5 plus with 8.1) on both 2.4 and 5 GHz bands, both connect just fine.
    3. My home WiFi is on both bands: 2.4 and 5 GHz. Both have the same SSID, I know there are different opinions on which approach is best: each band its own SSID name or not. I've had that in the past: no problems. I've used the same SSID on both bands the last few years: also no problems with any WiFi client in my house, including this XPS 13 which had several flavors of Ubuntu installed. But connecting to a phone hotspot kinda already tell's me something about a difference.
    4. The BIOS has no setting around WiFi that can be disabled. I remember on a previous Dell D830 there was indeed a WiFi catcher button located that would flash an LED light if a WiFi signal was detected when you momentarily slid that button, but no, I don't have that catcher stuff nor do I have any extra settings in BIOS surrounding WiFi. Disabling Bluetooth in BIOS isn't possible, only in software (OS).
    5. I've updated to v75.1 from the dev channel. Although the dmesg log is exactly the same, I know see "Unrecognized error: unknown-failure" in the white message box at the right bottom instead of "network out of range" with the stable release.

    Regarding the difference in behavior between connecting to a phone hotspot (working) or my OpenWRT router, there might be settings I have enabled on my OpenWRT router that somehow don't mix well with CloudReady. But a Chromium OS build from Arnold the Bat has the exact same behavior. Then again, this exact same hardware (XPS 13) has worked fine with Ubuntu 16.04 and 18.04 (and intermediate updates on those LTS versions) on both 2.4 and 5 GHz bands.

    I don't know the differences between Ubuntu's kernel, kernel module (iwlwifi), firmware and wpa_supplicant between the same being used by CloudReady. I might forget about a part of the network stack that's used but not on my radar. But this behavior is clearly reproducible here, the XPS 13 is authenticated, then associated and "immediately" deauthenticated by local choice (by CloudReady I guess) for an unknown reason.

    If it helps, here are my OpenWRT settings for WiFi:

    config wifi-device 'radio0'
    option type 'mac80211'
    option hwmode '11a'
    option path 'soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
    option legacy_rates '1'
    option country 'US'
    option txpower '23'
    option channel 'auto'
    option htmode 'VHT80'

    config wifi-iface 'default_radio0'
    option device 'radio0'
    option network 'lan'
    option mode 'ap'
    option wps_pushbutton '0'
    option encryption 'psk2+ccmp'
    option key 'SomeLongHardToGuessKey'
    option ssid 'SomeRedactedSSID'
    option ieee80211w '2'

    config wifi-device 'radio1'
    option type 'mac80211'
    option hwmode '11g'
    option path 'soc/1b700000.pci/pci0001:00/0001:00:00.0/0001:01:00.0'
    option htmode 'HT40'
    option country 'US'
    option legacy_rates '1'
    option txpower '30'
    option channel 'auto'

    config wifi-iface 'default_radio1'
    option device 'radio1'
    option network 'lan'
    option mode 'ap'
    option encryption 'psk2+ccmp'
    option wps_pushbutton '0'
    option key 'SomeLongHardToGuessKey'
    option ssid 'SomeRedactedSSID'
    option ieee80211w '1'

    And here's the relevant log part from OpenWRT by the way, the dmesg output on CloudReady is exactly the same as in my first post:

    Fri Jun 28 10:04:56 2019 daemon.info hostapd: wlan1: STA 00:db:df:05:e0:60 IEEE 802.11: authenticated
    Fri Jun 28 10:04:56 2019 daemon.info hostapd: wlan1: STA 00:db:df:05:e0:60 IEEE 802.11: associated (aid 7)
    Fri Jun 28 10:04:56 2019 daemon.info hostapd: wlan1: STA 00:db:df:05:e0:60 RADIUS: starting accounting session 42AB58BD6AC40313
    Fri Jun 28 10:04:56 2019 daemon.info hostapd: wlan1: STA 00:db:df:05:e0:60 WPA: pairwise key handshake completed (RSN)
    Fri Jun 28 10:06:10 2019 daemon.info hostapd: wlan1: STA 00:db:df:05:e0:60 IEEE 802.11: authenticated
    Fri Jun 28 10:06:10 2019 daemon.info hostapd: wlan1: STA 00:db:df:05:e0:60 IEEE 802.11: associated (aid 7)
    Fri Jun 28 10:06:10 2019 daemon.info hostapd: wlan1: STA 00:db:df:05:e0:60 RADIUS: starting accounting session 7C6D6333CDB63C4D
    Fri Jun 28 10:06:10 2019 daemon.info hostapd: wlan1: STA 00:db:df:05:e0:60 WPA: pairwise key handshake completed (RSN)
    0
    Comment actions Permalink
  • D O

    @Forrest Smith: I have an update:

    I've been playing around with settings on my OpenWRT router, and I now have a WiFi connection to it. But only on the 5GHz band. I've searched and tried settings, first only on the 2.4GHz band since it's an older or should I say: "less advanced" combo of hardware and possible configurations? Well I thought I'd start with that, since both bands were working on my phone hotspot.

    On 2.4GHz

    1. First I disabled WMM mode, that didn't make a difference.
    2. then I made OpenWRT not "Disassociate On Low Acknowledgement", so OpenWRT would be more forgiving to clients on a far range, that didn't make a difference.
    3. Then I tried both at the same time, that also didn't make any difference.

    On 5GHz

    1. I started by disabling PMF (802.11w) on OpenWRT since I found some Bugzilla reports on wpa_supplicant not being able to work with PMF in some occasions. I've discovered when forcing this on 5GHz, the 2.4GHz clients don't support this being forced, so it wasn't forced on 2.4GHz.
    2. Then I disabled WMM mode, that didn't make a difference.
    3. Then I made OpenWRT not "Disassociate On Low Acknowledgement", so OpenWRT would be more forgiving to clients on a far range, that didn't make a difference.
    4. Then I tried both at the same time, that worked! 

    I know I have some settings I force on OpenWRT, because they matter to me and all my other WiFi clients support them. I have a mixture of macOS, iOS, Windows 10, Android, Chromecast, WiFi speakers and IoT-devices connected via WiFi. All accept my settings, except CloudReady (or should I say Chrome OS?)

    For instance, I care about:

    • WMM mode, since there are devices streaming media (Chromecast, WiFi speakers, iPads)
    • PMF a.k.a. 802.11w, since it doesn't allow devices on 5GHz to be forced off an access point and to allow capturing of authentication frames
    • I force WPA2-PSK with only CCMP (AES) as encryption method, since its the most recent and therefore suggested to be more secure by closing holes and improving on older concepts from the past.
    • I don't mind that OpenWRT "Disassociates On Low Acknowledgement" for clients that are practically out of range. I have a Netgear R7800 that has enough tx power with OpenWRT and recent WiFi clients that seamlessly switch from 5GHz to 2.4GHz when I walk further away from the router.

    I've mentioned these points above to provide you guys with some context on what might or might not be conflicting in recent CloudReady builds. I'm sure the hardware is OK, both the XPS 13 and the Netgear R7800 are in good working order, judging from the other WiFi devices. So the difference is made in software. I've used this XPS 13 for almost 7 years now and most recently with Ubuntu 18.04 LTS, up to date. In that configuration, both 2.4 and 5GHz bands worked fine. When I got closer to the router, it connected via 5GHz, when I moved further away, it switched to 2.4GHz, with the wireless settings I posted in my previous post. Perhaps this provides some more clues should you guys decide to investigate on what's biting each other in a similar set up? 

    0
    Comment actions Permalink
  • Forrest Smith

    I can't say for sure what's happening here, and since your OpenWRT and settings together are highly uncommon compared to most environments, you may be the first person to run across this particular issue/bug.

     

    I think it's possible that Chromium OS does not support some of your specific settings (802.11w, WMM mode, CCMP-only) which would explain why AtB and CloudReady have this issue.

    If you can isolate a single setting that makes the difference, it would be a lot easier to look into. Certainly if we see a similar issue with any other environment or device we'd look for similarities as well.

    0
    Comment actions Permalink
  • D O

    I believe the issue I'm facing with CloudReady and AtB are related to upstream Chromium OS development. I've used and still use open source products because of its concept and the win-win situation it can imply. In my opinion CloudReady is a great product, from what I've seen in a few days, I'd really like to learn and experience more from it and with it. I believe in sharing my experience with the community, some might have a handle on why something doesn't work in their set-up. And perhaps, along the way someone from the company behind the product gets an even bigger picture of how to help, support others.

    So nothing but thumbs-up for CloudReady +1

    About my particular WiFi set-up on OpenWRT, it might be uncommon, I don't know. It might even be highly uncommon, don't know either. From my point of view, I tend to think I'm creating a somewhat secure/safe WiFi network at home, which mostly focuses on recent devices by letting go of older specs (enabling 802.11w) and toggling features that seem more common to use streaming services (enabling WMM) and making switching to different bands between distance more obvious (by disassociating on low acks).

    Since I'm using OpenWRT, it's pretty easy and straightforward to create 2 additional WiFi networks (on the 2.4 and 5GHz band) specifically for my CloudReady enabled XPS 13. This allows me to toggle features without disturbing other WiFi clients and also without compromising the WiFi features I care about for all the other WiFi clients that are being used in our house.

    So I'll be looking further in what specific item makes it tick or not. I can't promise results soon (in a few days) since holiday is coming up soon and I'll be abroad for about 3 weeks. I'll will be bringing this CloudReady enabled XPS 13 along with it so see how it fares abroad :-)

    0
    Comment actions Permalink
  • D O

    BTW, I've gone with a simple approach on booting this CloudReady installation on this XPS 13 (which doesn't support UEFI).

    I've taken a very small USB-stick, which is partitioned as MBR, formatted as fat32 and installed grub2 on it. I've booted a Ubuntu Live USB stick and inserted this small USB-stick, available als /dev/sdc and one partition, I've remounted it under /mnt:

    sudo mount /dev/sdc1 /mnt
    grub-install --boot-directory=/mnt/boot

    I've than added a grub.cfg in /mnt/boot/grub. I've basically took an existing grub.cfg and stripped out stuff which isn't available, like the memtest and other possible menuentries found by the os-prober. The part that's important to add in grub.cfg is this:

    menuentry "CloudReady" {
    insmod part_gpt
    insmod ext2
    insmod chain
    set root='hd1'
    chainloader +1
    }

    If this is your only menuentry (which it is in my case), modify the timeout:

    set timeout_style=menu
    if [ "${timeout}" = 0 ]; then
    set timeout=1
    fi

    I've set it at 1 second instead of the default 10 seconds but change as pleased. The 1 second was a hint for me which part in this simplified grub chainloading would fail... Since this USB-stick is so small, I leave it in there. I've found a 32GB USB 3.1 stick which might come in handy too with a FAT32 filesystem. Okay I can't store files larger than 4GB on it this way but hey, I've still got a 256 GB SSD in the XPS 13. 

    0
    Comment actions Permalink

Please sign in to leave a comment.