Pi Zero USB GPIO Expander

[infman]

Good day,

I have a Pi 3 Model B+ with Raspbian that has a fresh version of 'buster' installed with current updates.

I've been following the tutorial at https://bennuttall.com/raspberry-pi-zero-gpio-expander/ to connect a Pi Zero (no SD card) to the Pi 3 via USB to utilize as a GPIO expander.

USBBOOTGUI installs fine, recognizes when I plug in the Pi Zero and successfully sets up the Pi Zero as a GPIO expander.

usb0 shows up when I do an 'ifconfig', however it does not have an IPv6 address as the tutorial (and everywhere else I've researched the issue) says their should be. Everywhere says I should be able to ping the Pi Zero with 'ping6 fe80::1%usb0'. I cannot. Therefore I cannot communicate with the GPIO's from python script (or anything else for that matter).

Here's that part of my 'ifconfig':

usb0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 169.254.226.157 netmask 255.255.0.0 broadcast 169.254.255.255
ether fa:00:10:5e:49:a9 txqueuelen 1000 (Ethernet)
RX packets 8 bytes 584 (584.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 26 bytes 4223 (4.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

pigpio installs fine, however I also I seem to have trouble getting pigpiod running properly I think. Here's the status of that service after I run it manually:

pi@raspberrypi:~ $ systemctl status pigpiod
● pigpiod.service - Daemon required to control GPIO pins via pigpio
Loaded: loaded (/lib/systemd/system/pigpiod.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/pigpiod.service.d
└─public.conf
Active: failed (Result: exit-code) since Tue 2019-10-15 20:23:06 CDT; 21h ago
Process: 1817 ExecStart=/usr/bin/pigpiod (code=exited, status=0/SUCCESS)
Main PID: 1818 (code=exited, status=1/FAILURE)

Oct 15 20:23:06 raspberrypi systemd[1]: Starting Daemon required to control GPIO pins via pigpio...
Oct 15 20:23:06 raspberrypi pigpiod[1817]: 2019-10-15 20:23:06 initInitialise: Can't lock /var/run/pigpio.pid
Oct 15 20:23:06 raspberrypi pigpiod[1817]: Can't initialise pigpio library
Oct 15 20:23:06 raspberrypi systemd[1]: Started Daemon required to control GPIO pins via pigpio.
Oct 15 20:23:06 raspberrypi systemd[1]: pigpiod.service: Main process exited, code=exited, status=1/FAILURE
Oct 15 20:23:06 raspberrypi systemd[1]: pigpiod.service: Failed with result 'exit-code'.

That being said, I get a number result when I run 'pigs t'

pi@raspberrypi:~ $ pigs t
3010731011

While I'm not a COMPLETE noob, I probably only know enough to be dangerous... any help would be appreciated!

Thanks!
Infman

[hippy]

usb0 shows up when I do an 'ifconfig', however it does not have an IPv6 address as the tutorial (and everywhere else I've researched the issue) says their should be.

usb0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 169.254.226.157 netmask 255.255.0.0 broadcast 169.254.255.255
ether fa:00:10:5e:49:a9 txqueuelen 1000 (Ethernet)
RX packets 8 bytes 584 (584.0 B)

Indeed; it does seem there's a lack of IPv6 on your usb0. Having an IPv4 is also odd as the Zero GPIO gadget should be ( annoyingly so, IMO ) IPv6 only.

I don't have any answer but it worked fine, got an IPv6, no IPv4, when I plug a cardless Zero W into my Pi 3B (non-plus) Buster ...

Code: Select all

usb0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::662b:6507:36a5:47fa  prefixlen 64  scopeid 0x20<link>
        ether fa:00:c2:08:75:5b  txqueuelen 1000  (Ethernet)
        RX packets 2  bytes 112 (112.0 B)

Could you have downloaded the wrong thing using usbbootgui ? Have you been playing around with diskless booting ?

Important Update : The above worked. I then unplugged my Zero W, plugged it in again, downloaded the GPIO Gadget again, and ifconfig shows just as the OP's does ...

Code: Select all

usb0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 169.254.86.189  netmask 255.255.0.0  broadcast 169.254.255.255
        ether fa:00:c2:08:75:5b  txqueuelen 1000  (Ethernet)
        RX packets 7  bytes 520 (520.0 B)

lsusb shows it as -

Code: Select all

Bus 001 Device 045: ID f055:0001

so there is something odd going on.

[incognitum]

usb0 shows up when I do an 'ifconfig', however it does not have an IPv6 address as the tutorial (and everywhere else I've researched the issue) says their should be.

All network interfaces must always have at least an IPv6 link local address.
Is eth0 also missing one?

Double check there is nothing wrong with modules (lsmod should list ipv6), you didn't disable anything ipv6 by cmdline.txt options, and you do not have anything special in /etc/dhcpcd.conf

[hippy]

Note my update; that I replicated the OP's experience after having had it work. There is something more than things not being set-up correctly here.

I did note that if the 'ifconfig' was done soon after the GPIO gadget download had completed, 'usb0' showed no IP address, though reverted to IPv4 soon after ...

Code: Select all

usb0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether fa:00:c2:08:75:5b  txqueuelen 1000  (Ethernet)
        RX packets 6  bytes 472 (472.0 B)

Code: Select all

usb0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 169.254.86.189  netmask 255.255.0.0  broadcast 169.254.255.255
        ether fa:00:c2:08:75:5b  txqueuelen 1000  (Ethernet)
        RX packets 8  bytes 584 (584.0 B)

That '169.254.*.*' is a private, link local address which perhaps suggests the Zero didn't respond in a timely manner so the host had it fall back to a link local address.

[incognitum]

Note my update; that I replicated the OP's experience after having had it work.

Is ipv6 still functional on other interfaces like eth0?
All interfaces MUST at least have an IPv6 link local address (starting with fe80::)
It is derived from MAC address and should always be there.
If not, there are bigger issues.

[infman]

Thank you for your help!! I'm somewhat happy to know that the issue is "duplicatable" (which helps my sanity)

Could you have downloaded the wrong thing using usbbootgui ? Have you been playing around with diskless booting ?

I guess I may have downloaded the wrong usbbootgui, but I'm not sure how I could have since I installed via "sudo apt install usbbootgui" after "sudo apt update"

I haven't been really "playing" with anything other than trying to get the GPIOextender to work. I haven't done anything with diskless booting to my knowledge. Just following that tutorial.

I am at work now and won't be able to answer the other questions with detail until I get home. I'll add more then.

Thanks again!!!
Infman

[hippy]

Is ipv6 still functional on eth0?

Yes, there for 'eth0' and 'lo' ...

Code: Select all

pi@Pi3B:~ $ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.130  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::6abe:74e4:ba9b:f713  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:8b:d2:9f  txqueuelen 1000  (Ethernet)
        RX packets 40629  bytes 7495236 (7.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 14890  bytes 1230996 (1.1 MiB)
        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 1284  bytes 77232 (75.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1284  bytes 77232 (75.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

usb0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 169.254.86.189  netmask 255.255.0.0  broadcast 169.254.255.255
        ether fa:00:c2:08:75:5b  txqueuelen 1000  (Ethernet)
        RX packets 8  bytes 584 (584.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 68  bytes 11476 (11.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether b8:27:eb:de:87:ca  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

After numerous retries, selecting GPIO gadget, downloading the Card Reader gadget first, leaving the Zero disconnected, even shorting 0V to 5V to discharge it, I have not had it give an IPv6 address since the first time I tried it.

It responds to pings on its IPv4 address so I guess it's working - which is how I'd have preferred the GPIO gadget to be anyway ! I don't have anything connected to the Zero which would allow me to test actual remote GPIO reading or writing.

Rebooting with it still connected produced the GUI when the desktop appeared, but after another down still showed the same IPv4 link local address.

Disconnect, reboot, connect, download did the same.

It now seems, despite it working the first time, I can't get anything other than an IPv4 link address after downloading the GPIO gadget.

However; this got things working again, removed the IPv4 link address, gave me the expected IPv6 ...

Code: Select all

sudo ip link set usb0 down
sudo ip link set usb0 up

So it seems to me, everything is working, that my "not responding in a timely manner" may be somewhat right, or something needs a kick it isn't getting.

I'd suggest 'infman' tries the down/up trick, sees if that works for them

[incognitum]

After numerous retries, selecting GPIO gadget, downloading the Card Reader gadget first, leaving the Zero disconnected, even shorting 0V to 5V to discharge it, I have not had it give an IPv6 address since the first time I tried it.

Note that the gadget is not responsible for setting the IPv6 link local address for the host.
Host should set link local address automatically and instantly the moment a network interface shows up, regardless how the gadget side of things is behaving.
It is not like DHCP where network communication from the other side does matter.


Does "journalctl -b -u dhcpcd" perhaps indicate dhcpcd is messing with the address?
(It should not do that, but it may if you have played with other settings, such as setting a static IP address).

It responds to pings on its IPv4 address so I guess it's working - which is how I'd have preferred the GPIO gadget to be anyway !

That has other downsides.
Like that having more than one Pi Zero attached would be problematic.
Are only allowed to have IPv4 169.254.x.x link local addresses on a single network interface.
While you do can have IPv6 link local adresses on multiple interfaces thanks to link scope identifiers (fe80::1%usb0, fe80::1%usb1, etc.)

[hippy]

Does "journalctl -b -u dhcpcd" perhaps indicate dhcpcd is messing with the address?

I don't believe that's the problem given it worked once, then never worked again, until down/up. But here's the journal output for that 3B -

Code: Select all

-- Logs begin at Thu 2019-10-17 14:45:16 BST, end at Thu 2019-10-17 15:21:28 BS
Oct 17 14:45:20 Pi3B systemd[1]: Starting dhcpcd on all interfaces...
Oct 17 14:45:20 Pi3B dhcpcd[345]: dev: loaded udev
Oct 17 14:45:20 Pi3B dhcpcd[345]: forked to background, child pid 402
Oct 17 14:45:21 Pi3B systemd[1]: Started dhcpcd on all interfaces.
Oct 17 14:45:21 Pi3B dhcpcd[402]: eth0: waiting for carrier
Oct 17 14:45:21 Pi3B dhcpcd[402]: wlan0: waiting for carrier
Oct 17 14:45:21 Pi3B dhcpcd[402]: eth0: carrier acquired
Oct 17 14:45:21 Pi3B dhcpcd[402]: DUID 00:01:00:01:24:9e:79:8a:b8:27:eb:de:87:c
Oct 17 14:45:21 Pi3B dhcpcd[402]: eth0: IAID eb:8b:d2:9f
Oct 17 14:45:21 Pi3B dhcpcd[402]: eth0: adding address fe80::6abe:74e4:ba9b:f71
Oct 17 14:45:21 Pi3B dhcpcd[402]: eth0: probing address 192.168.0.130/24
Oct 17 14:45:21 Pi3B dhcpcd[402]: wlan0: carrier acquired
Oct 17 14:45:21 Pi3B dhcpcd[402]: wlan0: IAID eb:de:87:ca
Oct 17 14:45:21 Pi3B dhcpcd[402]: wlan0: adding address fe80::457b:ac4c:eaf8:74
Oct 17 14:45:21 Pi3B dhcpcd[402]: wlan0: probing address 10.10.10.10/24
Oct 17 14:45:21 Pi3B dhcpcd[402]: wlan0: carrier lost
Oct 17 14:45:21 Pi3B dhcpcd[402]: wlan0: deleting address fe80::457b:ac4c:eaf8:
Oct 17 14:45:21 Pi3B dhcpcd[402]: eth0: soliciting an IPv6 router
Oct 17 14:45:22 Pi3B dhcpcd[402]: eth0: carrier lost
Oct 17 14:45:22 Pi3B dhcpcd[402]: eth0: deleting address fe80::6abe:74e4:ba9b:f
Oct 17 14:45:22 Pi3B dhcpcd[402]: eth0: carrier acquired
Oct 17 14:45:22 Pi3B dhcpcd[402]: eth0: IAID eb:8b:d2:9f
Oct 17 14:45:22 Pi3B dhcpcd[402]: eth0: adding address fe80::6abe:74e4:ba9b:f71
Oct 17 14:45:22 Pi3B dhcpcd[402]: eth0: probing address 192.168.0.130/24
Oct 17 14:45:22 Pi3B dhcpcd[402]: eth0: soliciting an IPv6 router
Oct 17 14:45:27 Pi3B dhcpcd[402]: eth0: using static address 192.168.0.130/24
Oct 17 14:45:27 Pi3B dhcpcd[402]: eth0: adding route to 192.168.0.0/24
Oct 17 14:45:27 Pi3B dhcpcd[402]: eth0: adding default route via 192.168.0.1
Oct 17 14:45:35 Pi3B dhcpcd[402]: eth0: no IPv6 Routers available
Oct 17 14:47:12 Pi3B dhcpcd[402]: usb0: waiting for carrier
Oct 17 14:47:12 Pi3B dhcpcd[402]: usb0: carrier acquired
Oct 17 14:47:12 Pi3B dhcpcd[402]: usb0: IAID c2:08:75:5b
Oct 17 14:47:12 Pi3B dhcpcd[402]: usb0: adding address fe80::662b:6507:36a5:47f
Oct 17 14:47:12 Pi3B dhcpcd[402]: usb0: carrier lost
Oct 17 14:47:12 Pi3B dhcpcd[402]: usb0: deleting address fe80::662b:6507:36a5:4
Oct 17 14:47:12 Pi3B dhcpcd[402]: usb0: carrier acquired
Oct 17 14:47:12 Pi3B dhcpcd[402]: usb0: IAID c2:08:75:5b
Oct 17 14:47:12 Pi3B dhcpcd[402]: usb0: soliciting a DHCP lease
Oct 17 14:47:12 Pi3B dhcpcd[402]: usb0: soliciting an IPv6 router
Oct 17 14:47:17 Pi3B dhcpcd[402]: usb0: probing for an IPv4LL address
Oct 17 14:47:22 Pi3B dhcpcd[402]: usb0: using IPv4LL address 169.254.86.189
Oct 17 14:47:22 Pi3B dhcpcd[402]: usb0: adding route to 169.254.0.0/16
Oct 17 14:50:22 Pi3B dhcpcd[402]: usb0: carrier lost
Oct 17 14:50:22 Pi3B dhcpcd[402]: usb0: deleting route to 169.254.0.0/16
Oct 17 14:50:25 Pi3B dhcpcd[402]: usb0: carrier acquired
Oct 17 14:50:25 Pi3B dhcpcd[402]: usb0: IAID c2:08:75:5b
Oct 17 14:50:25 Pi3B dhcpcd[402]: usb0: adding address fe80::662b:6507:36a5:47f
Oct 17 14:50:25 Pi3B dhcpcd[402]: usb0: soliciting a DHCP lease
Oct 17 14:50:26 Pi3B dhcpcd[402]: usb0: soliciting an IPv6 router
Oct 17 14:50:30 Pi3B dhcpcd[402]: usb0: probing for an IPv4LL address
Oct 17 14:50:35 Pi3B dhcpcd[402]: usb0: using IPv4LL address 169.254.86.189
Oct 17 14:50:35 Pi3B dhcpcd[402]: usb0: adding route to 169.254.0.0/16
Oct 17 14:50:39 Pi3B dhcpcd[402]: usb0: no IPv6 Routers available
Oct 17 15:08:53 Pi3B dhcpcd[402]: usb0: carrier lost
Oct 17 15:08:53 Pi3B dhcpcd[402]: usb0: deleting address fe80::662b:6507:36a5:4
Oct 17 15:08:54 Pi3B dhcpcd[402]: usb0: deleting route to 169.254.0.0/16
Oct 17 15:08:54 Pi3B dhcpcd[402]: usb0: removing interface

Trying it on a 1B is even more interesting. After downloading the GPIO gadget using usbbbootgui it ends up with an IPv4 private, local link address, and also an IPv6 address in which the ":dead:" part may be indicative of something but I don't know -

Code: Select all

usb0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 169.254.86.189  netmask 255.255.0.0  broadcast 169.254.255.255
        inet6 fe80::dead:703b:dc67:bca5  prefixlen 64  scopeid 0x20<link>
        ether fa:00:c2:08:75:5b  txqueuelen 1000  (Ethernet)
        RX packets 3  bytes 208 (208.0 B)

The journal suff for that is as follows. -

Code: Select all

-- Logs begin at Thu 2019-10-17 15:28:05 BST, end at Thu 2019-10-17 15:32:07 BS
Oct 17 15:28:29 Pi1B-DPF systemd[1]: Starting dhcpcd on all interfaces...
Oct 17 15:28:30 Pi1B-DPF dhcpcd[263]: dev: loaded udev
Oct 17 15:28:32 Pi1B-DPF dhcpcd[263]: forked to background, child pid 316
Oct 17 15:28:32 Pi1B-DPF systemd[1]: Started dhcpcd on all interfaces.
Oct 17 15:28:33 Pi1B-DPF dhcpcd[316]: eth0: waiting for carrier
Oct 17 15:28:33 Pi1B-DPF dhcpcd[316]: eth0: carrier acquired
Oct 17 15:28:33 Pi1B-DPF dhcpcd[316]: DUID 00:01:00:01:24:9e:79:a0:b8:27:eb:4d:
Oct 17 15:28:33 Pi1B-DPF dhcpcd[316]: eth0: IAID eb:b8:17:49
Oct 17 15:28:33 Pi1B-DPF dhcpcd[316]: eth0: adding address fe80::25dd:552a:dbd4
Oct 17 15:28:33 Pi1B-DPF dhcpcd[316]: eth0: soliciting an IPv6 router
Oct 17 15:28:34 Pi1B-DPF dhcpcd[316]: eth0: rebinding lease of 192.168.0.212
Oct 17 15:28:34 Pi1B-DPF dhcpcd[316]: eth0: carrier lost
Oct 17 15:28:34 Pi1B-DPF dhcpcd[316]: eth0: deleting address fe80::25dd:552a:db
Oct 17 15:28:35 Pi1B-DPF dhcpcd[316]: eth0: carrier acquired
Oct 17 15:28:35 Pi1B-DPF dhcpcd[316]: eth0: IAID eb:b8:17:49
Oct 17 15:28:35 Pi1B-DPF dhcpcd[316]: eth0: adding address fe80::25dd:552a:dbd4
Oct 17 15:28:35 Pi1B-DPF dhcpcd[316]: eth0: rebinding lease of 192.168.0.212
Oct 17 15:28:35 Pi1B-DPF dhcpcd[316]: eth0: probing address 192.168.0.212/24
Oct 17 15:28:36 Pi1B-DPF dhcpcd[316]: eth0: soliciting an IPv6 router
Oct 17 15:28:41 Pi1B-DPF dhcpcd[316]: eth0: leased 192.168.0.212 for 86400 seco
Oct 17 15:28:41 Pi1B-DPF dhcpcd[316]: eth0: adding route to 192.168.0.0/24
Oct 17 15:28:41 Pi1B-DPF dhcpcd[316]: eth0: adding default route via 192.168.0.
Oct 17 15:28:48 Pi1B-DPF dhcpcd[316]: eth0: no IPv6 Routers available
Oct 17 15:31:52 Pi1B-DPF dhcpcd[316]: usb0: waiting for carrier
Oct 17 15:31:52 Pi1B-DPF dhcpcd[316]: usb0: carrier acquired
Oct 17 15:31:53 Pi1B-DPF dhcpcd[316]: usb0: IAID c2:08:75:5b
Oct 17 15:31:53 Pi1B-DPF dhcpcd[316]: usb0: adding address fe80::dead:703b:dc67
Oct 17 15:31:53 Pi1B-DPF dhcpcd[316]: usb0: carrier lost
Oct 17 15:31:53 Pi1B-DPF dhcpcd[316]: usb0: deleting address fe80::dead:703b:dc
Oct 17 15:31:53 Pi1B-DPF dhcpcd[316]: usb0: carrier acquired
Oct 17 15:31:53 Pi1B-DPF dhcpcd[316]: usb0: IAID c2:08:75:5b
Oct 17 15:31:53 Pi1B-DPF dhcpcd[316]: usb0: adding address fe80::dead:703b:dc67
Oct 17 15:31:53 Pi1B-DPF dhcpcd[316]: usb0: soliciting a DHCP lease
Oct 17 15:31:54 Pi1B-DPF dhcpcd[316]: usb0: soliciting an IPv6 router
Oct 17 15:31:58 Pi1B-DPF dhcpcd[316]: usb0: probing for an IPv4LL address
Oct 17 15:32:03 Pi1B-DPF dhcpcd[316]: usb0: using IPv4LL address 169.254.86.189
Oct 17 15:32:03 Pi1B-DPF dhcpcd[316]: usb0: adding route to 169.254.0.0/16
Oct 17 15:32:07 Pi1B-DPF dhcpcd[316]: usb0: no IPv6 Routers available

On the 1B I can "ping6 fe80::1%usb0" and "ping 169.254.86.189" so that may be right. No idea.

On the 1B the 'ifconfig' as usbbootgui proceeds and Zero W presumably boots-up progresses as follows -

Code: Select all

usb0: error fetching interface information: Device not found

Code: Select all

usb0: flags=4098<BROADCAST,MULTICAST>  mtu 1500
        ether fa:00:c2:08:75:5b  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)

Code: Select all

usb0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::dead:703b:dc67:bca5  prefixlen 64  scopeid 0x20<link>
        ether fa:00:c2:08:75:5b  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)

Code: Select all

usb0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 169.254.86.189  netmask 255.255.0.0  broadcast 169.254.255.255
        inet6 fe80::dead:703b:dc67:bca5  prefixlen 64  scopeid 0x20<link>
        ether fa:00:c2:08:75:5b  txqueuelen 1000  (Ethernet)
        RX packets 2  bytes 112 (112.0 B)

On the 1B I seem to get an IPv6 every time, but not on the 3B.

[incognitum]

Something strange is going on here:

Code: Select all

Oct 17 14:47:12 Pi3B dhcpcd[402]: usb0: carrier acquired
Oct 17 14:47:12 Pi3B dhcpcd[402]: usb0: IAID c2:08:75:5b
Oct 17 14:47:12 Pi3B dhcpcd[402]: usb0: adding address fe80::662b:6507:36a5:47f
Oct 17 14:47:12 Pi3B dhcpcd[402]: usb0: carrier lost
Oct 17 14:47:12 Pi3B dhcpcd[402]: usb0: deleting address fe80::662b:6507:36a5:4
Oct 17 14:47:12 Pi3B dhcpcd[402]: usb0: carrier acquired
Oct 17 14:47:12 Pi3B dhcpcd[402]: usb0: IAID c2:08:75:5b
Oct 17 14:47:12 Pi3B dhcpcd[402]: usb0: soliciting a DHCP lease

- Interface goes up (carrier acquired), and it gets a fe80 address the first time. All fine.
- Interface goes down, address is gone. Also normal.
- Interface goes up again. But this time no link local address?!

Also strange that it ping pongs up, down and up again within a second.

[hippy]

Something strange is going on here:

Code: Select all

Oct 17 14:47:12 Pi3B dhcpcd[402]: usb0: carrier acquired
Oct 17 14:47:12 Pi3B dhcpcd[402]: usb0: IAID c2:08:75:5b
Oct 17 14:47:12 Pi3B dhcpcd[402]: usb0: adding address fe80::662b:6507:36a5:47f
Oct 17 14:47:12 Pi3B dhcpcd[402]: usb0: carrier lost
Oct 17 14:47:12 Pi3B dhcpcd[402]: usb0: deleting address fe80::662b:6507:36a5:4
Oct 17 14:47:12 Pi3B dhcpcd[402]: usb0: carrier acquired
Oct 17 14:47:12 Pi3B dhcpcd[402]: usb0: IAID c2:08:75:5b
Oct 17 14:47:12 Pi3B dhcpcd[402]: usb0: soliciting a DHCP lease

Possibly. Though it's similar on the 1B. The difference on the 1B is it re-adds the address after the second IAID -

Code: Select all

Oct 17 15:31:52 Pi1B-DPF dhcpcd[316]: usb0: carrier acquired
Oct 17 15:31:53 Pi1B-DPF dhcpcd[316]: usb0: IAID c2:08:75:5b
Oct 17 15:31:53 Pi1B-DPF dhcpcd[316]: usb0: adding address fe80::dead:703b:dc67
Oct 17 15:31:53 Pi1B-DPF dhcpcd[316]: usb0: carrier lost
Oct 17 15:31:53 Pi1B-DPF dhcpcd[316]: usb0: deleting address fe80::dead:703b:dc
Oct 17 15:31:53 Pi1B-DPF dhcpcd[316]: usb0: carrier acquired
Oct 17 15:31:53 Pi1B-DPF dhcpcd[316]: usb0: IAID c2:08:75:5b
Oct 17 15:31:53 Pi1B-DPF dhcpcd[316]: usb0: adding address fe80::dead:703b:dc67
Oct 17 15:31:53 Pi1B-DPF dhcpcd[316]: usb0: soliciting a DHCP lease

I have seen carrier acquired/lost in quick succession with dmesg logs for eth0 so just put that down to however dhcpcd does it's thing. I have never really paid too much attention to what it's doing.

[incognitum]

The difference on the 1B is it re-adds the address after the second IAID -

See it also goes up, down and up for me, but does add the IPv6 for me, even on Pi 4.

Perhaps a timing specific bug in dhcpcd then.
Hard to report to the author though, if it is not so reproducible.

[infman]

Thank you for the insightful conversation and all you've done to help me troubleshoot this!!

All network interfaces must always have at least an IPv6 link local address.
Is eth0 also missing one?

Double check there is nothing wrong with modules (lsmod should list ipv6), you didn't disable anything ipv6 by cmdline.txt options, and you do not have anything special in /etc/dhcpcd.conf

Similar to mentioned above, IPv6 seems fine on other interfaces.

Code: Select all

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.2.130  netmask 255.255.255.0  broadcast 192.168.2.255
        inet6 fe80::f38b:d683:4c57:107d  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:32:01:3e  txqueuelen 1000  (Ethernet)
        RX packets 259352  bytes 49511983 (47.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 52800  bytes 5958226 (5.6 MiB)
        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 427  bytes 37076 (36.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 427  bytes 37076 (36.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

usb0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 169.254.226.157  netmask 255.255.0.0  broadcast 169.254.255.255
        ether fa:00:10:5e:49:a9  txqueuelen 1000  (Ethernet)
        RX packets 8  bytes 584 (584.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5294  bytes 1549817 (1.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.2.118  netmask 255.255.255.0  broadcast 192.168.2.255
        inet6 fe80::5210:93b9:5e60:4cb  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:67:54:6b  txqueuelen 1000  (Ethernet)
        RX packets 128886  bytes 12682292 (12.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2951  bytes 658004 (642.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

When I do

Code: Select all

sudo ip link set usb0 down
sudo ip link set usb0 up

The IPv6 does indeed show and I can ping the interface

Code: Select all

pi@raspberrypi:~ $ sudo ip link set usb0 down
pi@raspberrypi:~ $ sudo ip link set usb0 up
pi@raspberrypi:~ $ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.2.130  netmask 255.255.255.0  broadcast 192.168.2.255
        inet6 fe80::f38b:d683:4c57:107d  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:32:01:3e  txqueuelen 1000  (Ethernet)
        RX packets 259639  bytes 49569668 (47.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 52940  bytes 5972581 (5.6 MiB)
        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 427  bytes 37076 (36.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 427  bytes 37076 (36.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

usb0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::4cf8:5b28:479:9565  prefixlen 64  scopeid 0x20<link>
        ether fa:00:10:5e:49:a9  txqueuelen 1000  (Ethernet)
        RX packets 8  bytes 584 (584.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5306  bytes 1551875 (1.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.2.118  netmask 255.255.255.0  broadcast 192.168.2.255
        inet6 fe80::5210:93b9:5e60:4cb  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:67:54:6b  txqueuelen 1000  (Ethernet)
        RX packets 128992  bytes 12689647 (12.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2951  bytes 658004 (642.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

pi@raspberrypi:~ $ ping6 fe80::1%usb0
PING fe80::1%usb0(fe80::1%usb0) 56 data bytes
64 bytes from fe80::1%usb0: icmp_seq=1 ttl=64 time=0.849 ms
64 bytes from fe80::1%usb0: icmp_seq=2 ttl=64 time=0.416 ms
64 bytes from fe80::1%usb0: icmp_seq=3 ttl=64 time=0.426 ms
64 bytes from fe80::1%usb0: icmp_seq=4 ttl=64 time=0.418 ms

Any other thoughts on this issue? Would a work around be to make some sort of script that runs on start up that takes the link down and brings it back up?

This is strange.

Thanks again!
Infman

[hippy]

When I do

Code: Select all

sudo ip link set usb0 down
sudo ip link set usb0 up

The IPv6 does indeed show and I can ping the interface

Excellent news. And interesting that it is just one IPv6 address, no IPv4.

Any other thoughts on this issue? Would a work around be to make some sort of script that runs on start up that takes the link down and brings it back up?

That script would have to run on the host Pi, after bootloading the Zero. I suppose, ideally, usbbootgui ought to be modified to check it can ping the ipv6 after it's bootloaded to ensure that has worked, could down/up the interface a couple of times before throwing up an alert that it hasn't worked.

A script or Python program which calls rpiboot directly could probably do the same. I believe you will need to 'apt-get purge usbbootgui' then 'apt-get install rpiboot' to make that work and not have the GUI pop-up and conflict.

You could even have a background script or program which auto-detects connection of a Zero for USB booting, boot it, check it, kick it, and have that all automatic.

I've got some VideoCore Assembler I need to test on my list of things to do so this can bump that up and I'll see what I can create. That will likely be after the weekend though.

[hippy]

And interesting that it is just one IPv6 address, no IPv4.

Solved that mystery I think. Leave it long enough and it will acquire an IPv4 private, local link address in addition to the IPv6.

Here's a rough and ready Python program which waits for a diskless Pi to be programmed by usbbootgui and then kicks it with a down/up to get an IPv6 address. Set it going in a terminal, then plug the Zero in -

Code: Select all

#!/usr/bin/python

import os
import time

def GetIfConfig():
  lines = os.popen("ifconfig usb0 2>/dev/null").read().strip().split("\n")
  if len(lines) <= 1:
    return False, "",""
  IPv4 = ""
  IPv6 = ""
  for line in lines:
    part = " ".join(line.split()).split(" ")
    if   part[0] == "inet"  : IPv4 = part[1]
    elif part[0] == "inet6" : IPv6 = part[1]
  return True, IPv4, IPv6

def HandleConnection():
  print("Waiting for Diskless Pi to be programmed")
  present, IPv4, IPv6 = GetIfConfig()
  while not present:
    time.sleep(1)
    present, IPv4, IPv6 = GetIfConfig()
  print("Diskless Pi has been programmed")
  if IPv6 != "":
    print("Diskless Pi has IPv6 address "+IPv6)
    return
  timeout = 5
  while timeout > 0:
    time.sleep(1)
    timeout = timeout - 1
    present, IPv4, IPv6 = GetIfConfig()
    if not present:
      print("Diskless Pi was disconnected")
      return
    if IPv6 != "":
      print("Diskless Pi has IPv6 address "+IPv6)
      return
    if IPv4 != "":
      if not IPv4.startswith("169.254."):
        print("Diskless Pi has IPv4 address "+IPv4)
        return
      print("Diskless Pi has IPv4 local link address "+IPv4)
      timeout = 0
  print("Kicking Diskless Pi into IPv6")
  os.popen("sudo ip link set usb0 down").read()
  time.sleep(0.5)
  os.popen("sudo ip link set usb0 up").read()
  timeout = 5
  while timeout > 0:
    time.sleep(1)
    timeout = timeout - 1
    present, IPv4, IPv6 = GetIfConfig()
    if not present:
      print("Diskless Pi was disconnected")
      return
    if IPv6 != "":
      print("Diskless Pi has IPv6 address "+IPv6)
      return
    if IPv4 != "":
      if not IPv4.startswith("169.254."):
        print("Diskless Pi has IPv4 address "+IPv4)
        return
  print("Diskless Pi has IPv4 local link address "+IPv4)

def WaitForDisconnect():
  present, IPv4, IPv6 = GetIfConfig()
  if present:
    print("Waiting for disconnection of Diskless Pi")
    while present:
      time.sleep(1)
      present, IPv4, IPv6 = GetIfConfig()
    print("Diskless Pi disconnected")

def Main():
  while True:
    HandleConnection()
    WaitForDisconnect()
    print("")

Main()

[hippy]

Perhaps a timing specific bug in dhcpcd then.
Hard to report to the author though, if it is not so reproducible.

It does seem to be. Today on my Pi 3B it's not giving either IPv4 nor IPv6 until a long time later, then it gets the IPv4 local link address. Though it did get the initial IPv6 as you noted, passed it on to avahi-daemon ( and hence kernel ) before deciding it had lost the carrier and revoked that.

I have no idea what a dhcpcd "carrier lost" actually means or indicates.

This is the syslog for when the Zero was plugged in, then programmed by usbbootgui.

Code: Select all

Oct 18 07:34:18 Pi3B kernel: [60537.948228] usb 1-1.2: new full-speed USB device number 34 using dwc_otg
Oct 18 07:34:19 Pi3B kernel: [60538.088034] usb 1-1.2: New USB device found, idVendor=0a5c, idProduct=2763, bcdDevice= 0.00
Oct 18 07:34:19 Pi3B kernel: [60538.088053] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Oct 18 07:34:19 Pi3B kernel: [60538.088063] usb 1-1.2: Product: BCM2708 Boot
Oct 18 07:34:19 Pi3B kernel: [60538.088072] usb 1-1.2: Manufacturer: Broadcom
Oct 18 07:34:19 Pi3B mtp-probe: checking bus 1, device 34: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2"
Oct 18 07:34:19 Pi3B mtp-probe: bus: 1, device: 34 was not an MTP device
Oct 18 07:34:19 Pi3B mtp-probe: checking bus 1, device 34: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2"
Oct 18 07:34:19 Pi3B mtp-probe: bus: 1, device: 34 was not an MTP device
Oct 18 07:34:19 Pi3B systemd[1]: Starting usbbootgui.service...
Oct 18 07:34:19 Pi3B usbbootgui[8398]: g_value_type_compatible: assertion 'G_TYPE_IS_VALUE (src_type)' failed
Oct 18 07:34:19 Pi3B usbbootgui[8398]: /home/pi/dev/gtk+2.0-2.24.32/gtk/gtkliststore.c:612: Unable to convert from (null) to gchararray
Oct 18 07:34:25 Pi3B kernel: [60544.308248] usb 1-1.2: USB disconnect, device number 34
Oct 18 07:34:26 Pi3B kernel: [60545.628254] usb 1-1.2: new full-speed USB device number 35 using dwc_otg
Oct 18 07:34:26 Pi3B kernel: [60545.761522] usb 1-1.2: not running at top speed; connect to a high speed hub
Oct 18 07:34:26 Pi3B kernel: [60545.771398] usb 1-1.2: New USB device found, idVendor=0a5c, idProduct=2764, bcdDevice= 0.00
Oct 18 07:34:26 Pi3B kernel: [60545.771418] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=1
Oct 18 07:34:26 Pi3B kernel: [60545.771428] usb 1-1.2: Product: BCM2710 Boot
Oct 18 07:34:26 Pi3B kernel: [60545.771437] usb 1-1.2: Manufacturer: Broadcom
Oct 18 07:34:26 Pi3B kernel: [60545.771447] usb 1-1.2: SerialNumber: Broadcom
Oct 18 07:34:26 Pi3B mtp-probe: checking bus 1, device 35: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2"
Oct 18 07:34:26 Pi3B mtp-probe: bus: 1, device: 35 was not an MTP device
Oct 18 07:34:26 Pi3B mtp-probe: checking bus 1, device 35: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2"
Oct 18 07:34:26 Pi3B mtp-probe: bus: 1, device: 35 was not an MTP device
Oct 18 07:34:42 Pi3B kernel: [60561.460247] usb 1-1.2: USB disconnect, device number 35
Oct 18 07:34:42 Pi3B systemd[1]: usbbootgui.service: Succeeded.
Oct 18 07:34:42 Pi3B systemd[1]: Started usbbootgui.service.
Oct 18 07:34:44 Pi3B kernel: [60563.038311] usb 1-1.2: new high-speed USB device number 36 using dwc_otg
Oct 18 07:34:44 Pi3B kernel: [60563.169438] usb 1-1.2: New USB device found, idVendor=f055, idProduct=0001, bcdDevice= 4.04
Oct 18 07:34:44 Pi3B kernel: [60563.169458] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Oct 18 07:34:44 Pi3B kernel: [60563.169468] usb 1-1.2: Product: Pi Zero - GPIO expansion board
Oct 18 07:34:44 Pi3B kernel: [60563.169478] usb 1-1.2: Manufacturer: Raspberry Pi
Oct 18 07:34:44 Pi3B kernel: [60563.169487] usb 1-1.2: SerialNumber: 00000000c208755b
Oct 18 07:34:44 Pi3B kernel: [60563.177394] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device
Oct 18 07:34:44 Pi3B kernel: [60563.183546] cdc_ether 1-1.2:1.2 usb0: register 'cdc_ether' at usb-3f980000.usb-1.2, CDC Ethernet Device, fa:00:c2:08:75:5b
Oct 18 07:34:44 Pi3B mtp-probe: checking bus 1, device 36: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2"
Oct 18 07:34:44 Pi3B mtp-probe: bus: 1, device: 36 was not an MTP device
Oct 18 07:34:44 Pi3B systemd-udevd[8409]: Using default interface naming scheme 'v240'.
Oct 18 07:34:44 Pi3B mtp-probe: checking bus 1, device 36: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2"
Oct 18 07:34:44 Pi3B mtp-probe: bus: 1, device: 36 was not an MTP device
Oct 18 07:34:44 Pi3B kernel: [60563.379820] IPv6: ADDRCONF(NETDEV_UP): usb0: link is not ready
Oct 18 07:34:44 Pi3B dhcpcd[402]: usb0: waiting for carrier
Oct 18 07:34:44 Pi3B dhcpcd[402]: usb0: carrier acquired
Oct 18 07:34:44 Pi3B dhcpcd[402]: usb0: IAID c2:08:75:5b
Oct 18 07:34:44 Pi3B dhcpcd[402]: usb0: adding address fe80::662b:6507:36a5:47fa
Oct 18 07:34:44 Pi3B avahi-daemon[339]: Joining mDNS multicast group on interface usb0.IPv6 with address fe80::662b:6507:36a5:47fa.
Oct 18 07:34:44 Pi3B avahi-daemon[339]: New relevant interface usb0.IPv6 for mDNS.
Oct 18 07:34:44 Pi3B dhcpcd[402]: usb0: carrier lost
Oct 18 07:34:44 Pi3B avahi-daemon[339]: Registering new address record for fe80::662b:6507:36a5:47fa on usb0.*.
Oct 18 07:34:44 Pi3B kernel: [60563.409959] IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready
Oct 18 07:34:44 Pi3B dhcpcd[402]: usb0: deleting address fe80::662b:6507:36a5:47fa
Oct 18 07:34:44 Pi3B avahi-daemon[339]: Withdrawing address record for fe80::662b:6507:36a5:47fa on usb0.
Oct 18 07:34:44 Pi3B avahi-daemon[339]: Leaving mDNS multicast group on interface usb0.IPv6 with address fe80::662b:6507:36a5:47fa.
Oct 18 07:34:44 Pi3B avahi-daemon[339]: Interface usb0.IPv6 no longer relevant for mDNS.
Oct 18 07:34:44 Pi3B dhcpcd[402]: usb0: carrier acquired
Oct 18 07:34:44 Pi3B dhcpcd[402]: usb0: IAID c2:08:75:5b
Oct 18 07:34:45 Pi3B dhcpcd[402]: usb0: soliciting a DHCP lease
Oct 18 07:34:45 Pi3B dhcpcd[402]: usb0: soliciting an IPv6 router
Oct 18 07:34:50 Pi3B dhcpcd[402]: usb0: probing for an IPv4LL address
Oct 18 07:34:55 Pi3B dhcpcd[402]: usb0: using IPv4LL address 169.254.86.189
Oct 18 07:34:55 Pi3B avahi-daemon[339]: Joining mDNS multicast group on interface usb0.IPv4 with address 169.254.86.189.
Oct 18 07:34:55 Pi3B avahi-daemon[339]: New relevant interface usb0.IPv4 for mDNS.
Oct 18 07:34:55 Pi3B dhcpcd[402]: usb0: adding route to 169.254.0.0/16
Oct 18 07:34:55 Pi3B avahi-daemon[339]: Registering new address record for 169.254.86.189 on usb0.IPv4.
Oct 18 07:35:01 Pi3B ModemManager[338]: <info>  [device /sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2] creating modem with plugin 'Generic' and '2' ports
Oct 18 07:35:01 Pi3B ModemManager[338]: <warn>  Could not grab port (tty/ttyACM0): 'Cannot add port 'tty/ttyACM0', unhandled serial type'
Oct 18 07:35:01 Pi3B ModemManager[338]: <warn>  Couldn't create modem for device '/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2': Failed to find primary AT port

[incognitum]

Today on my Pi 3B it's not giving either IPv4 nor IPv6 until a long time later, then it gets the IPv4 local link address. Though it did get the initial IPv6 as you noted.

That IPv4 takes ages is normal.

IPv4 link local is only given if there is no response to DHCP, so DHCP has to timeout first, and then it still needs some more time to choose random address and ping if that is still available.
And it can only be given if there is not any other network interface already with a link local address.
(The moment any interface gets a 169.254.x.x address, all traffic with a destination in subnet 169.254.0.0/16 will be routed through that interface.
So it is not possible to have a second network interface with an IP inside that range).

IPv6 link local does should always be there the moment interface goes up.
(IPv6 link local address is calculated from MAC, and routing is done through link scope identifier).
So should be much more reliable, if it weren't for bugs like this.

[infman]

And interesting that it is just one IPv6 address, no IPv4.

Solved that mystery I think. Leave it long enough and it will acquire an IPv4 private, local link address in addition to the IPv6.

Here's a rough and ready Python program which waits for a diskless Pi to be programmed by usbbootgui and then kicks it with a down/up to get an IPv6 address. Set it going in a terminal, then plug the Zero in -

Code: Select all

#!/usr/bin/python

import os
import time

def GetIfConfig():
  lines = os.popen("ifconfig usb0 2>/dev/null").read().strip().split("\n")
  if len(lines) <= 1:
    return False, "",""
  IPv4 = ""
  IPv6 = ""
  for line in lines:
    part = " ".join(line.split()).split(" ")
    if   part[0] == "inet"  : IPv4 = part[1]
    elif part[0] == "inet6" : IPv6 = part[1]
  return True, IPv4, IPv6

def HandleConnection():
  print("Waiting for Diskless Pi to be programmed")
  present, IPv4, IPv6 = GetIfConfig()
  while not present:
    time.sleep(1)
    present, IPv4, IPv6 = GetIfConfig()
  print("Diskless Pi has been programmed")
  if IPv6 != "":
    print("Diskless Pi has IPv6 address "+IPv6)
    return
  timeout = 5
  while timeout > 0:
    time.sleep(1)
    timeout = timeout - 1
    present, IPv4, IPv6 = GetIfConfig()
    if not present:
      print("Diskless Pi was disconnected")
      return
    if IPv6 != "":
      print("Diskless Pi has IPv6 address "+IPv6)
      return
    if IPv4 != "":
      if not IPv4.startswith("169.254."):
        print("Diskless Pi has IPv4 address "+IPv4)
        return
      print("Diskless Pi has IPv4 local link address "+IPv4)
      timeout = 0
  print("Kicking Diskless Pi into IPv6")
  os.popen("sudo ip link set usb0 down").read()
  time.sleep(0.5)
  os.popen("sudo ip link set usb0 up").read()
  timeout = 5
  while timeout > 0:
    time.sleep(1)
    timeout = timeout - 1
    present, IPv4, IPv6 = GetIfConfig()
    if not present:
      print("Diskless Pi was disconnected")
      return
    if IPv6 != "":
      print("Diskless Pi has IPv6 address "+IPv6)
      return
    if IPv4 != "":
      if not IPv4.startswith("169.254."):
        print("Diskless Pi has IPv4 address "+IPv4)
        return
  print("Diskless Pi has IPv4 local link address "+IPv4)

def WaitForDisconnect():
  present, IPv4, IPv6 = GetIfConfig()
  if present:
    print("Waiting for disconnection of Diskless Pi")
    while present:
      time.sleep(1)
      present, IPv4, IPv6 = GetIfConfig()
    print("Diskless Pi disconnected")

def Main():
  while True:
    HandleConnection()
    WaitForDisconnect()
    print("")

Main()

Very cool, I will try this soon. Back at work again and have a full weekend ahead of which I'm out of town, so I may be delayed in trying it. Thanks a ton!

Since I did the down/up I haven't had a chance to get back and check to see if it has retained the info for IPv6 without a reboot. I hope I get a chance to at least check that as soon as I get home from work. I'm hoping it has. That will at least help.

I really appreciate the assistance you guys have provided. Hopefully it helps someone else in the future as well, and hopefully the bug will get fixed too

Regards,
Infman

[incognitum]

Managed to reproduce it on a 3B+, reported it to dhcp's author, and he issued a fix.

If you want the updated version, you will need to compile it from source for now:

Code: Select all

git clone --depth 1 git://roy.marples.name/dhcpcd.git
cd dhcpcd
./configure
make
sudo make install

[hippy]

Managed to reproduce it on a 3B+, reported it to dhcp's author, and he issued a fix.

Excellent. Many thanks for doing that, and to Roy for fixing it.

[infman]

Sweet!!! thanks so much!

You guys have been fantastic!

[ShiftPlusOne]

Fixed apt package available for testing here - https://www.raspberrypi.org/forums/view ... 6&t=255072