Useless error messages from Wifi/Network stack e.g. err: wlan0: ipv4_addroute: File exists

[holzingk]

During boot of the board I always get this error message:

notice: wlan0: link state changed to UP
err: wlan0: ipv4_addroute: File exists

[c-mauderer]

That's an expected behavior. I'm not 100% sure where it is originated but it doesn't hurt (except for the misleading output). I would say it is an enhancement to remove the message.

[c-mauderer]

Note that this problem also exists on other systems. For example Arch linux: https://wiki.archlinux.org/index.php/Netctl#dhcpcd:_ipv4_addroute:_File_exists

I don't think that we have any simple way of getting rid of this message.

[peerst]

This is exemplatory of many error messages on the output which are not pointing to a error.
At the moment all our existing users and ourselves are totally confused by the messages especially from the network tasks.

• Lots of error messages mean nothing

• If the Wifi really is not working, none of the messages help in any way to pinpoint the problem, its just different gobbledygook on the console

We can't leave it like this, noone except maybe someone very knowledgable in the Wifi sourecode can troubleshoot Wifi problems.

Just one more example, apparently the Wifi dropped for a moment here and I get this mix of error messages.

(grisp@base0101)1> err: wlan0: ipv4_addroute: File exists

That was from the initial connect

notice: wlan0: link state changed to DOWN
wlan0: CTRL-EVENT-DISCONNECTED bssid=00:1f:f3:c1:b1:c0 reason=0

Ok its dicsonnected with a reason=0 hmm what does that mean?

debug: ifa_maintain_loopback_route: deletion failed for interface wlwlan0: Trying to associate with 00:1f:f3:c1:b1:c0 (SSID='Stritzinger-Gnotice: wlan0: link state changed to UP

Some hard to read mixup of two messages from two threads I suppose. I guess the link is now UP again.

wlan0: Associated with 00:1f:f3:c1:b1:c0
err: wlan0: ipv4_sendrawpacket: No buffer space available

I see this quite often, what does it mean? Is it bad?

wlan0: WPA: Key negotiation completed with 00:1f:f3:c1:b1:c0 [PTK=CCMPwlan0: CTRL-EVEerr: wlan0: ipv4_addroute: File exists

Garbled again, mix of messages. Maybe everything is ok again? Have to try to reconnect to be sure it works, the messages give no indication.

[peerst]

The main problem here is when it fails it doesn't look much different, sometimes it says "DOWN" shortly after the "UP" but the output is so noisy that it stops being helpful.

[peerst]

Here a counter example for when the Wifi didn't work:

Successfully initialized wpa_supplicant
notice: wlan0: link state changed to UP
notice: wlan0: link state changed to DOWN

Here we actually get no error messages just that the link is going "UP and then "DOWN" ? What does this mean? Whats wrong? We can't say!

[dch]

Hi @peerst I hope this helps you a bit.

err: wlan0: ipv4_sendrawpacket: No buffer space available

This error comes from a race condition - the interface is created, and associated, but not actually ready to
receive traffic, but the dhclient script/tool is already trying to get an IP. It's harmless but annoying.

Re notice: wlan0: link state changed to DOWN link state flapping, for wired ethernet you'll see this when the patch cable from your computer to the switch is unplugged. I can only speculate that the physical layer is unable to negotiate a connection for some reason, or possibly it's decided to power down the interface for some reason, which might also trigger this error.

In native FreeBSD I use this to see more info about what's happening at the wlan layer:

sudo wlandebug debug+scan+assoc+auth+rate+power

Or add a -d flag to set this for defaults for new connections.

IIRC it's simply modifying sysctl net.wlan.0.debug flags directly, so maybe this is a possibility in grisp to see more info. See https://www.freebsd.org/cgi/man.cgi?query=wlandebug and https://www.freebsd.org/cgi/man.cgi?query=wlan&sektion=4

[dch]

BTW as a grisp user, all I'd need is to have those above errors simply documented somewhere, like a "troubleshooting network connectivity" page, and if it turns out its possible to enable wlan debugging flags, then add a few example of working / failing logs.