Having trouble getting the Zero's recognized

Gregg Dille

unread,

Mar 22, 2024, 4:07:45 AMMar 22

to ClusterHAT

I am using
-Raspberry Pi 3b+ (8GB) as the host for the Clusterhat v2.4
-1 Raspberry Pi Zero
-2 Raspberry Pi Zero W's
-1 Raspberry Pi Zero WH with RTC adapter

I started with the intent of booting them up with no SD cards and had originally gotten image files from https://dist1.8086.net/clusterctrl/usbboot/bullseye/2023-05-03/, but was unable to get them to boot.

I originally had trouble getting images to load on the 3b+, but through trial and error with dd on an Ubuntu machine, or with the "Use custom" option in Raspbery Pi Imager v1.8.5, I believe I can reliably get Bookworm and Bullseye images up and running on multiple different microSD cards and multiple USB drives. I've gotten CBRIDGE and CNAT images up and running, as well as installing from scratch and getting Clusterctrl installed and working.

However, in whatever configuration I have on the pi3 (CBRIDGE or CNAT), I cannot get the Zero's to come up in any meaningful way.

I believe I have noticed that no matter what, brint is assigned 172.19.180.254, but the contents of dhcpcd.conf attempts to serve IPs via 172.19.181.254. I'm not sure if that is correct, or what I should be expecting to see via any ping attempts:

pi@cbridge:~ $ ifconfig
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.3.10 netmask 255.255.255.0 broadcast 192.168.3.255
inet6 fd0c:331f:16ad:7285:ce3:a279:8161:17c prefixlen 64 scopeid 0x0<global>
inet6 fe80::9de4:91a1:4ea0:13b8 prefixlen 64 scopeid 0x20<link>
ether b8:27:eb:16:5f:01 txqueuelen 1000 (Ethernet)
RX packets 98579 bytes 14938717 (14.2 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 26976 bytes 2339086 (2.2 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

brint: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.19.180.254 netmask 255.255.255.0 broadcast 172.19.180.255
inet6 fe80::7804:aff:fe1f:8aca prefixlen 64 scopeid 0x20<link>
ether 7a:04:0a:1f:8a:ca txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 46 bytes 5390 (5.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether b8:27:eb:16:5f:01 txqueuelen 1000 (Ethernet)
RX packets 100229 bytes 16422044 (15.6 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 26976 bytes 2339086 (2.2 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 10 bytes 1576 (1.5 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 10 bytes 1576 (1.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

sample contents of /etc/dhcpcd.conf:

# Example static IP configuration:
#interface eth0
#static ip_address=192.168.0.10/24
#static ip6_address=fd51:42f8:caae:d92e::ff/64
#static routers=192.168.0.1
#static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1

# It is possible to fall back to a static IP if DHCP fails:
# define static profile
#profile static_eth0
#static ip_address=192.168.1.23/24
#static routers=192.168.1.1
#static domain_name_servers=192.168.1.1

# fallback to static profile on eth0
#interface eth0
#fallback static_eth0
# ClusterCTRL
reboot 15
denyinterfaces ethpi* ethupi* ethupi*.10 brint usb0.10 eth0

profile clusterctrl_fallback_usb0
static ip_address=172.19.181.253/24 #ClusterCTRL
static routers=172.19.181.254
static domain_name_servers=8.8.8.8 208.67.222.222

profile clusterctrl_fallback_br0
static ip_address=172.19.181.254/24

interface usb0
fallback clusterctrl_fallback_usb0

interface br0
fallback clusterctrl_fallback_br0

I guess I don't know what to expect, but using CBRIDGE, I do not see any attempts to obtain an IP address on my PFsense router. Using CNAT, I attempted to ping 172.19.180.1-4 and 172.19.181.1-4. All ping attempts are unsuccessful.

I found Troubleshooting missing Pi Zeros in a ClusterHat at https://8086.support/content/23/115/en/troubleshooting-missing-pi-zeros-in-a-clusterhat.html

Step 1: is fine.
Step 2: is fine.
Step 3: yields the following:

pi@cbridge:~ $ lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/3p, 480M
|__ Port 1: Dev 4, If 0, Class=Vendor Specific Class, Driver=lan78xx, 480M
|__ Port 2: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 480M
pi@cbridge:~ $

It shows the same results with "clusterctrl on" or "clusterctrl off". "clusterctrl hub on/off" seems to have no effect.

I used multiple cables, and reseated each Zero as well as the ClusterHat. clusterctrl works in turning lights on and off.

step 4 and 5: the lights come on
step 6: I do not see that, even after reseating everything

step 7: Not sure what I should see

step 8 does not show anything for ttypi or ttyACM

pi@cbridge:/dev $ ls

autofs loop1 ram2 tty13 tty38 tty62 vcsa5
block loop2 ram3 tty14 tty39 tty63 vcsa6
bsg loop3 ram4 tty15 tty4 tty7 vcsm-cma
btrfs-control loop4 ram5 tty16 tty40 tty8 vcsu
bus loop5 ram6 tty17 tty41 tty9 vcsu1
cachefiles loop6 ram7 tty18 tty42 ttyAMA0 vcsu2
cec0 loop7 ram8 tty19 tty43 ttyprintk vcsu3
char loop-control ram9 tty2 tty44 ttyS0 vcsu4
console mapper random tty20 tty45 uhid vcsu5
cuse media0 rfkill tty21 tty46 uinput vcsu6
disk media1 sda tty22 tty47 urandom vhci
dma_heap media2 sda1 tty23 tty48 v4l video10
dri mem sda2 tty24 tty49 vchiq video11
fd mqueue serial0 tty25 tty5 vcio video12
full net serial1 tty26 tty50 vc-mem video13
fuse null sg0 tty27 tty51 vcs video14
gpiochip0 ppp shm tty28 tty52 vcs1 video15
gpiochip1 ptmx snd tty29 tty53 vcs2 video16
gpiomem pts stderr tty3 tty54 vcs3 video18
hwrng ram0 stdin tty30 tty55 vcs4 video20
i2c-1 ram1 stdout tty31 tty56 vcs5 video21
i2c-2 ram10 tty tty32 tty57 vcs6 video22
initctl ram11 tty0 tty33 tty58 vcsa video23
input ram12 tty1 tty34 tty59 vcsa1 video31
kmsg ram13 tty10 tty35 tty6 vcsa2 watchdog
log ram14 tty11 tty36 tty60 vcsa3 watchdog0
loop0 ram15 tty12 tty37 tty61 vcsa4 zero
pi@cbridge:/dev $

step 9 does not show ethpi1 - 4 and I do not see any renameX interfaces.

Any help getting these recognized would be greatly apprciated.

On a different note, just FYI:

https://clusterhat.com/setup-control has a link to the clusterctrl script that links to https://github.com/burtyb/clusterhat-image/blob/master/files/sbin/clusterctrl, which yields a 404.

Chris Burton

unread,

Mar 26, 2024, 5:05:38 AMMar 26

to ClusterHAT

Hi,

I found Troubleshooting missing Pi Zeros in a ClusterHat at https://8086.support/content/23/115/en/troubleshooting-missing-pi-zeros-in-a-clusterhat.html

Step 1: is fine.
Step 2: is fine.
Step 3: yields the following:

pi@cbridge:~ $ lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/3p, 480M
|__ Port 1: Dev 4, If 0, Class=Vendor Specific Class, Driver=lan78xx, 480M
|__ Port 2: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 480M
pi@cbridge:~ $

If you're using the official CBRIDGE image on the controller when you're running through the troubleshooting guide I would advise double checking the USB cable supports both data and power by trying to plug one of the Pi Zeros without an SD card into the controller Pi with it and see if "lsusb -t" shows any extra devices after a few seconds (you might need to run it a couple of times in case rpiboot reboots the Pi Zero).

If it does then it sounds like there's a fault with the Cluster HAT itself (in which case contact sup...@8086.net.uk ) if it doesn't show up then try with an alternate USB cable.

On a different note, just FYI:

https://clusterhat.com/setup-control has a link to the clusterctrl script that links to https://github.com/burtyb/clusterhat-image/blob/master/files/sbin/clusterctrl, which yields a 404.

Thanks, I've updated the URL.

Chris.

Gregg Dille

unread,

Mar 27, 2024, 4:58:41 AMMar 27

to ClusterHAT

I swapped out a few cables and took the Zero that was in P1, but at most the only effect I could make was below, which appears to just be changing device numbers around. I'm not an expert, but this kinda makes me think the 3b+ itself is bad...does that sound right? It's not the end of the world, It still functions as a power hub that can be controlled up/down. I have an old router I can dedicate to them and just run a Docker Swarm that way. Thanks for the help.

BEFORE:

pi@swarm0:~ $ lsusb -t

/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/3p, 480M
|__ Port 1: Dev 4, If 0, Class=Vendor Specific Class, Driver=lan78xx, 480M

|__ Port 2: Dev 6, If 0, Class=Human Interface Device, Driver=usbhid, 12M

AFTER

lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/3p, 480M

|__ Port 1: Dev 5, If 0, Class=Vendor Specific Class, Driver=lan78xx, 480M
|__ Port 2: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 12M

Chris Burton

unread,

Mar 27, 2024, 5:17:55 AMMar 27

to ClusterHAT

Hi,

I swapped out a few cables and took the Zero that was in P1, but at most the only effect I could make was below, which appears to just be changing device numbers around. I'm not an expert, but this kinda makes me think the 3b+ itself is bad...does that sound right? It's not the end of the world, It still functions as a power hub that can be controlled up/down. I have an old router I can dedicate to them and just run a Docker Swarm that way. Thanks for the help.

Do you have it setup something like the attached image - with or without ClusterHAT on top but making sure the USB cable to the Pi Zero is plugged into it's USB port (not PWR)?

If that's how you have it connected I'd try taking the USB cable to the Pi Zero out of the Controller Pi and plugging it directly into a desktop/laptop computer if you have one as it should show up as a device there too and if it doesn't then it's looking like a problem with the Pi Zero itself or back to the USB cable.

Chris.

IMG_20240327_090310999s.jpg

Gregg Dille

unread,

Mar 30, 2024, 10:52:48 AMMar 30

to ClusterHAT

All tests were performed with microSD cards in place. I will test without, if that matters.

test: clusterctrl on, existing micro USB cable, 4 zeros populated:

pi@swarm0:~ $ lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/3p, 480M

|__ Port 1: Dev 5, If 0, Class=Vendor Specific Class, Driver=lan78xx, 480M
|__ Port 2: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 12M

test: clusterctrl off, existing micro USB cable, 4 zeros populated:

pi@swarm0:~ $ lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/3p, 480M

|__ Port 1: Dev 5, If 0, Class=Vendor Specific Class, Driver=lan78xx, 480M
|__ Port 2: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 12M

test: clusterctrl off, existing micro USB cable, p1 and p4 populated, p2 and p3 removed, p3 connected with new cable to USB of 3b+ (this should match the picture provided

pi@swarm0:~ $ lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/3p, 480M

|__ Port 1: Dev 5, If 0, Class=Vendor Specific Class, Driver=lan78xx, 480M
|__ Port 2: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 12M

test: same as above, but also p2 connected to usb with a new cable

pi@swarm0:~ $ lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/3p, 480M

|__ Port 1: Dev 5, If 0, Class=Vendor Specific Class, Driver=lan78xx, 480M
|__ Port 2: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 12M

test: same as above, but with a new micro USB cable to the ClusterHat:

$ lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/3p, 480M

|__ Port 1: Dev 5, If 0, Class=Vendor Specific Class, Driver=lan78xx, 480M
|__ Port 2: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 12M

test: same as above, but clusterctrl on:

pi@swarm0:~ $ lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/3p, 480M

|__ Port 1: Dev 5, If 0, Class=Vendor Specific Class, Driver=lan78xx, 480M
|__ Port 2: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 12M

test: same as above, but with p4 removed, then plugged into a USB port of the 3b+ and no microSD car

lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/3p, 480M
|__ Port 1: Dev 5, If 0, Class=Vendor Specific Class, Driver=lan78xx, 480M
|__ Port 2: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 12M

To me, it looks like the 3b+ is just not recognizing devices correctly, but I'm not sure on that. The ClusterHat still responds as expected as far as enabling and disabling ports.

Regardless of the above issue, it appears all my troubleshooting may have done something to p2 as it no longer turns off,. Meaning, 'clusterctrl off p2' has no effect, and it remains on. As long as there is power applied, p2 is always on. Is there a way to reset that? Or maybe reset the board to factory defaults?

Thanks.

Reply all

Reply to author

Forward