WiFi Dongle Says Host Down - Reports Up and No Errors

GoPiGo
1

(This is not a DI related support issue, so posting here in case any users have run across this problem)

Sometimes after a week or two of a “life segment”, my GoPiGo3 robot Carl’s WiFi dongle address stops responding

ssh pi@X.0.0.X … pi@X.0.0.X Host is down

and when I connect with WiFi built-in address X.0.0.Y, everything looks fine in ifconfig - up, no RX or TX errors.

I’m wondering if the issue might be in my WiFi router (Xfinity SCIENTIFIC ATLANTA DPC3941T), not the dongle.

Don’t know how to debug this.

pi@Carl:~/Carl $ packet_write_poll: Connection to X.0.0.X port 22: Host is down
Mac$ ssh pi@X.0.0.X
ssh: connect to host X.0.0.X port 22: Host is down
Mac$ ssh pi@X.0.0.Y
pi@X.0.0.Y's password: 
Linux Carl 4.14.98-v7+ #1200 SMP Tue Feb 12 20:27:48 GMT 2019 armv7l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sat Jan 18 00:44:42 2020 from X.0.0.Z
pi@Carl:~ $ ifconfig
eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether b8:...:86  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 3112  bytes 186720 (182.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3112  bytes 186720 (182.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet X.0.0.X  netmask 255.255.255.0  broadcast X.0.0.255
        inet6 fe80::..1  prefixlen 64  scopeid 0x20<link>
        inet6 26..ff  prefixlen 128  scopeid 0x0<global>
        ether b4..b  txqueuelen 1000  (Ethernet)
        RX packets 2173  bytes 907969974 (865.9 MiB)
        RX errors 0  dropped 258  overruns 0  frame 0
        TX packets 3675  bytes 106031839 (101.1 MiB)
        TX errors 0  dropped 6 overruns 0  carrier 0  collisions 0

wlan1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet X.0.0.Y  netmask 255.255.255.0  broadcast X.0.0.255
        inet6 26...9a  prefixlen 128  scopeid 0x0<global>
        inet6 fe8...ce5  prefixlen 64  scopeid 0x20<link>
        inet6 26...aa  prefixlen 64  scopeid 0x0<global>
        ether b8:...d3  txqueuelen 1000  (Ethernet)
        RX packets 245090  bytes 26383152 (25.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1873  bytes 403869 (394.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

pi@Carl:~ $
2

Question:
Do you have IPv6 enabled anywhere on your network?

It may sound strange, but IPv6 has been known to do this in the past. So much so that I wrote about it on my own blog back in 2009 in The Case of the Vanishing Internet.

A former colleague of mine recently referenced this article in a software bug report for her company and I’ve run into this a few times in the last year or so.

Take a peek and let us know what happens.

1 Like
3

Don’t get me started on that subject - IPv6 was biting my apt-get update/upgrade last year, so I disabled IPv6. A few months later, I got “shamed” into turning it back on and the update/upgrade seemed to be unaffected. For several years now, I have been chasing periodic 1-3 second delays, and these periodic wlan1 not reachable but the bot is just fat, dumb, and happy - well he’s always all that, but…

I rebooted after the last time, so I lost the logs (I think). The only suspicious thing in the dmesg log

[86790.429641] TCP: request_sock_TCP: Possible SYN flooding on port 8888. Sending cookies.  Check SNMP counters.

(8888 is the RPI-Monitor port), but everything is working for two days now. I don’t need IPv6 but supposedly that is the future.

1 Like
4

IMHO, punt the shaming and ditch IPv6. Everywhere.

1 Like
5

Yea, right!

If it ain’t broke, don’t fix it. You & Carl have enough fish to fry already. :crazy_face: :face_with_symbols_over_mouth:

1 Like