broke something with wlan when trying to reduce connection drops

GoogleGroups
1

I updated wl18xx firmware/packages in an attempt to reduce the high frequency of dropped WiFi connections. That didn’t go smoothly and I had to take a few passes at it.

I now have no (WiFi) connectivity at all. I rebooted after the troublesome package upgrade and the wlan0 interface worked - but now it does not, despite many subsequent reboots (and days of trying to think what could have happened - but no action taken).

The only thing other than the package upgrade that was changed was removing some unneeded packages (reported by apt-get) using “apt-get autoremove” - and removal of some packages to free up eMMC space. I didn’t document this, but my recollection is that the only packages removed were chrome-related.

I have been able to access the BBBW using the USB interface for debugging. It seems the wlan0 interface is up but not active:

debian@BBB:~$ ifconfig -v wlan0

wlan0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx

UP BROADCAST MULTICAST DYNAMIC MTU:1500 Metric:1

RX packets:0 errors:0 dropped:0 overruns:0 frame:0

TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

debian@BBB:~$ sudo /opt/scripts/tools/version.sh

…

pkg:[bb-wl18xx-firmware]:[1.20180328-0rcnee2~jessie+20180328]

pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~jessie+20180328]

…

Rather than trying to bind the adapter or manually configure with an IP address, I’m looking to understand what has gone wrong to prevent the expected auto-configuration and acquisition of a valid IP address (which my router is configured to specify as the network DHCP server).

Ideas where to look next?

2

Update: I realized that the MAC address for wlan0 had changed - didn’t expect that. Will it remain the same until another firmware upgrade?

debian@BBB:~$ connmanctl

tether wifi disable

enable wifi

scan wifi

services

agent on

connect <wifi_*_managed_psk>

quit

#are these settings “sticky” or do I need to put them in /etc/network/interfaces to persist past a reboot?

and modified router settings with the new wlan0 MAC address. So now I can connect…

…but the connection remains unreliable. Once a connection is established, if not active (e.g. ssh with command line being used or constant pinging) it is dropped. A subsequent ping will fail - but then waiting a few minutes and trying again will succeed.

When the connection is up, arp on another machine on the same network reports:

$ arp 192.168.1.12

bbbw (192.168.1.12) at on en0 ifscope [ethernet]

and when down:

$ arp 192.168.1.12

bbbw (192.168.1.12) at (incomplete) on en0 ifscope [ethernet]

3

Yes the mac address did change (for new installs).. For old installs
with package updates, thru apt there is no change..

It turns out the wl1835 has a built-in mac address.. So instead of
generating our own unique mac address on first boot-up and using
custom one, we use the wl1835 one..

You can disable this new mac address via editing:

/etc/default/bb-wl18xx

Change:

USE_INTERNAL_WL18XX_MAC_ADDRESS=yes
to

#USE_INTERNAL_WL18XX_MAC_ADDRESS=yes"

and reboot and it will return to the old address.

Regards,

4

@RobertCNelson thanks for that info. IMO it is preferable to use a built-in (guaranteed unique and immutable??) MAC address so I will stay with the new method. I’ve configured my router for the new address anyway.

Any insight or ideas where to look on the continued dropped connection problem? This …

`
$ arp 192.168.1.12
bbbw (192.168.1.12) at (incomplete) on en0 ifscope [ethernet]

`

I can’t figure out why the arp table entry would expire so quickly. Some references I found on the subject say the default is 20 minutes. Even if the entry expires, an ARP packet should be able to quickly reestablish the IP/MAC binding.

5

@RobertCNelson thanks for that info. IMO it is preferable to use a built-in
(guaranteed unique and immutable??) MAC address so I will stay with the new
method. I've configured my router for the new address anyway.

So the nice thing about using the built-in wl1835 mac address, on
"first" bootup it saves around 30 seconds.

With the old mac, we'd have to read it, +1/etc to the value, patch the
firmware, update the initramfs, then load the module..

With the new mac method, the kernel knows how to load it from the
wl1835.. (the trick was patching the firmware with a mac of 00:00...00
and the kernel knew what to do, it just wasn't documented very well)

On 2nd/3rd/++ boot no change.

Any insight or ideas where to look on the continued dropped connection
problem? This ...

$ arp 192.168.1.12
bbbw (192.168.1.12) at (incomplete) on en0 ifscope [ethernet]

I can't figure out why the arp table entry would expire so quickly. Some
references I found on the subject say the default is 20 minutes. Even if the
entry expires, an ARP packet should be able to quickly reestablish the
IP/MAC binding.

This might be power-managment related..

i'd try:

sudo iwconfig wlan0 power off

Regards,

6

So are you saying that using the old method of setting MAC address, for the initial boot the MAC value was read (from where?) and then incremented and/or modified in some way? If every BBB started with the same initial value, how did that not end up in collisions? (Clearly I’m misunderstanding).