Pi Zero's coming online but no IP on Clusterhat

[George -]

Hi all.

Just got the Clusterhat, physically assembled.

The controller is getting a IP from the DHCP, but none of the 4 Zero's are ?

I can see the zero's in Ifconfig as ethpi1-4, with associated MAC addresses: 00:22:82:ff:fe:01-4

Any ideas.

G

[Chris Burton]

Hi, 

The controller is getting a IP from the DHCP, but none of the 4 Zero's are ?

I can see the zero's in Ifconfig as ethpi1-4, with associated MAC addresses: 00:22:82:ff:fe:01-4

I assume you're running the Cluster HAT images and using the Ethernet port rather than wireless as ethpiX are only bridged to ethernet?

Can you check on the controller the bridge exists and shows ethpiX and eth0 under the interfaces column when you run "brctl show br0".

Check the interfaces again on the controller have actually come up "ifconfig -a" should show them with "UP" on the flags line.

If all of that looks good then I'd log into the Pi Zeros with "minicom p1" press enter and wait for the login prompt (to exit press CTRL-A, press Q then enter to exit without reset).

And run "ifconfig usb0" to see what the interface looks like from the Pi Zero side.

If you can let me know the output of these commands either here or you can email them to sup...@8086.net.uk I'll take a look.

Thanks,

 Chris.

[Paul Miller]

I have a similar problem and I find it very annoying that the last poster never came back with outputs and a solution if they found it. Sadly we often only hear from someone when they want help. 

I have no ips for the zeros either, the leds come on when I type "clusterhat on" so that seems to be working and the leds are all lit up next to the zeros. 

The output for ifconfig is: 

br0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
       ether 00:22:82:ff:fe:01  txqueuelen 1000  (Ethernet)
       RX packets 70  bytes 8274 (8.0 KiB)
       RX errors 0  dropped 0  overruns 0  frame 0
       TX packets 64  bytes 8831 (8.6 KiB)
       TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
       inet 192.168.0.9  netmask 255.255.255.0  broadcast 192.168.0.255
       inet6 fe80::ddf7:c20:dd57:ae01  prefixlen 64  scopeid 0x20<link>
       ether b8:27:eb:3a:1f:c9  txqueuelen 1000  (Ethernet)
       RX packets 741  bytes 62549 (61.0 KiB)
       RX errors 0  dropped 0  overruns 0  frame 0
       TX packets 2022  bytes 151386 (147.8 KiB)
       TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ethpi1: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
       inet6 fe80::222:82ff:feff:fe01  prefixlen 64  scopeid 0x20<link>
       ether 00:22:82:ff:fe:01  txqueuelen 1000  (Ethernet)
       RX packets 0  bytes 0 (0.0 B)
       RX errors 0  dropped 0  overruns 0  frame 0
       TX packets 1  bytes 90 (90.0 B)
       TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ethpi2: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
       inet6 fe80::222:82ff:feff:fe02  prefixlen 64  scopeid 0x20<link>
       ether 00:22:82:ff:fe:02  txqueuelen 1000  (Ethernet)
       RX packets 0  bytes 0 (0.0 B)
       RX errors 0  dropped 0  overruns 0  frame 0
       TX packets 1  bytes 90 (90.0 B)
       TX errors 1  dropped 0 overruns 0  carrier 0  collisions 0

ethpi3: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
       inet6 fe80::222:82ff:feff:fe03  prefixlen 64  scopeid 0x20<link>
       ether 00:22:82:ff:fe:03  txqueuelen 1000  (Ethernet)
       RX packets 0  bytes 0 (0.0 B)
       RX errors 0  dropped 0  overruns 0  frame 0
       TX packets 1  bytes 90 (90.0 B)
       TX errors 2  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 965  bytes 84242 (82.2 KiB)
       RX errors 0  dropped 0  overruns 0  frame 0
       TX packets 965  bytes 84242 (82.2 KiB)
       TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


I have a raspberry pi 3 B+ and I have run apt-get update and apt-get upgrade and I was using the NAT image. Could that have gotten rid of the scripts for the NAT image? 

You can see I have an ipv6 address for each pi zero but they don't work either. 

I tried minicom p1 and got: 

pi@hat ~> sudo minicom p1
minicom: cannot open /dev/ttypi1: No such file or directory

I then tried minicom ethp1 (as I figured that was the interface name but got no luck: 

Welcome to minicom 2.7

OPTIONS: I18n  
Compiled on Apr 22 2017, 09:14:19.
Port /dev/tty8, 19:05:36

Press CTRL-A Z for help on special keys

There was no login screen.

Let me know if I left out any details. 

I'm keen to fix this. 

cheers

Paul

[Paul Miller]

I also tried sshing with -6 to the ipv6 addresses and had no luck, eg: 

ssh -6 pi@fe80::222:82ff:feff:fe03
ssh: connect to host fe80::222:82ff:feff:fe03 port 22: Invalid argument

cheers

Paul

[Paul Miller]

this output shows the bridge not having an ip but later it comes up with one but the pis still don't have an ip.

On Saturday, 23 June 2018 05:08:38 UTC+10, Paul Miller wrote:

[Chris Burton]

Hi,

> I have a similar problem and I find it very annoying that the last poster 

> never came back with outputs and a solution if they found it. Sadly we

> often only hear from someone when they want help. 

>

> I have no ips for the zeros either, the leds come on when I type 

> "clusterhat on" so that seems to be working and the leds are all

> lit up next to the zeros. 

Which Pi are you using for the controller and what version Cluster HAT do you have?

What changes have you made to the standard ClusterHAT images other than running "sudo apt-get update" "sudo apt-get upgrade" ? (I've just started out with fresh SD and tested before and after upgrading and it looks to be working OK here still)

> pi@hat ~> sudo minicom p1 

(You shouldn't need to use sudo, "minicom p1" should work OK from the "pi" user as it's in the dialout group)

It's strange you're seeing eth1-eth3 but not the /dev/ttypiX devices. Does "ls -l /dev/ttypi* /dev/ttyACM*" and "dmesg|grep -i acm" show any tty devices?

> I also tried sshing with -6 to the ipv6 addresses and had no luck, eg: 

When you look at ethpi3 on the controller you're looking at the controller side of the USB Gadget Ethernet - you can think of it as 2 network cards one on the Controller (ethpi1) connected via a virtual cable and the other network card on the Pi Zero (usb0). 

On the controller side (ethpiX) doesn't have an IP address, br0 which will get it's fallback IP 172.19.181.254 should be bridged to ethpi1-4 so it can communicate with the IP on the Pi Zero side.

You can check the bridge with "brctl show", it should show eth1-ethX interfaces on br0.

Assuming brctl shows ethpi1 on br0 can should be able to ping the Pi Zero from the controller with "ping -c 2 p1.local" after they've been powered on for a minute or so.

> this output shows the bridge not having an ip but later it comes 

> up with one but the pis still don't have an ip.

This is to be expected the as the br0 interface initially tries to obtain an IP via DHCP (which is used in non-NAT mode) and will then fallback to 172.19.181.254.

Chris.

[Paul Miller]

Hi There

I'm using a raspberry pi 3 B+ and as I mentioned for that reason I have used the NAT image. 

I'm also using the ClusterHAT-2018-03-13-1 images.

Just in terms of minicom, if I use minicom while not root I get the followin message: 

minicom ethpi1

minicom: cannot open /dev/tty8: Permission denied

I have verified I am a member of dialout: 

pi adm dialout cdrom sudo audio video plugdev games users input netdev gpio i2c spi

brctl is also not accessible with the pi account. 

It seems /sbin is not in the path for the pi user. 

ls /dev/ttypi* gives:

lrwxrwxrwx 1 root root 7 Jun 23 17:13 /dev/ttypi2 -> ttyACM0
lrwxrwxrwx 1 root root 7 Jun 23 17:13 /dev/ttypi3 -> ttyACM1
lrwxrwxrwx 1 root root 7 Jun 23 17:13 /dev/ttypi4 -> ttyACM2

brctl show outputs: 

bridge name     bridge id               STP enabled     interfaces
br0             8000.002282fffe01       no              ethpi1
                                                       ethpi2
                                                       ethpi3

It's interesting to note that it doesn't show a pi4 device. 

I can ping 1,2,3 pis, but not 4 although 4 does light up with the leds. 

I did use a smaller sd card for pi4 as I ran out of 16 gb cards. So could that be a failed install on that card? (used an 8 gig card but it's an older one).

Ok, I can now ssh onto p1 and p3. p2 is giving me connection refused - likely because sshd is not running? I thought I enabled that so I'll check it. 

Thanks very much for your help. 

There are still a few issues though: 

1) why ifconfig isn't listing ips for p1, p2, p3 when they are clearly receiving traffic from the controller. 

2) issues with having to become root to do things that I should not have to be root for. 

But I've got a start and grateful for that.

cheers

Paul

--
You received this message because you are subscribed to the Google Groups "ClusterHAT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clusterhat+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/clusterhat/ebd32ce3-da54-4192-a3e8-93b0568567a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Paul Miller]

Just a note: I was able to get ssh to 3 out of 4 pis so I'm convinced there was an installation problem on pi 4 probably a faulty sd card. 

I'm looking into that. 

cheers

[Chris Burton]

Hi,

Just in terms of minicom, if I use minicom while not root I get the followin message: 

minicom ethpi1

minicom: cannot open /dev/tty8: Permission denied

You still need to run "minicom p1" and not something with ethpiX as that's the controller side of the USB Gadget Ethernet device and nothing to do with serial.

 

I have verified I am a member of dialout: 

pi adm dialout cdrom sudo audio video plugdev games users input netdev gpio i2c spi

brctl is also not accessible with the pi account. 

What do you mean by not accessible? Flashing the 2018-03-13 lite-NAT logging in and running "brctl show" as the pi user it runs OK here.

pi@cnat:~$ brctl show

bridge name     bridge id               STP enabled     interfaces

br0             8000.000000000000       no

  

It seems /sbin is not in the path for the pi user. 

In which case I'll ask again what changes have you made? As running on a fresh install /sbin/ is in the path of the pi user.

pi@cnat:~$ echo $PATH

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games

ls /dev/ttypi* gives:

lrwxrwxrwx 1 root root 7 Jun 23 17:13 /dev/ttypi2 -> ttyACM0
lrwxrwxrwx 1 root root 7 Jun 23 17:13 /dev/ttypi3 -> ttyACM1
lrwxrwxrwx 1 root root 7 Jun 23 17:13 /dev/ttypi4 -> ttyACM2

brctl show outputs: 

bridge name     bridge id               STP enabled     interfaces
br0             8000.002282fffe01       no              ethpi1
                                                       ethpi2
                                                       ethpi3

It's interesting to note that it doesn't show a pi4 device. 

If you're seeing both of the above outputs then you've most likely got the SD card images mixed up as the serial access for /dev/ttypi1 is picked up from the position in the Cluster HAT and the ethernet name is picked up from the image on the Pi Zero SD card.

 

I can ping 1,2,3 pis, but not 4 although 4 does light up with the leds. 

As above, I think there's something mixed up with the order of the images on the SD cards - fixing that may help with the missing P4.

  

I did use a smaller sd card for pi4 as I ran out of 16 gb cards. So could that be a failed install on that card? (used an 8 gig card but it's an older one).

Ok, I can now ssh onto p1 and p3. p2 is giving me connection refused - likely because sshd is not running? I thought I enabled that so I'll check it. 

 

SSH is only enabled by putting the "ssh" file in the boot partition, so yes if it isn't there on one of the images it won't enable the SSH service.

 

1) why ifconfig isn't listing ips for p1, p2, p3 when they are clearly receiving traffic from the controller. 

See my previous reply, you're expecting the IP addresses to be on the controller this isn't how it works - the IP address is on the Pi Zero side which you can't see from the controller.

 

2) issues with having to become root to do things that I should not have to be root for. 

Which is why I keep asking what changes you've made after installing the image as lots of this doesn't look as it should :).

It might be worth imaging all SD cards again and starting a fresh and keeping notes of any changes you make so I can try to replicate the issue you're seeing.

Chris.

[Ernst Bokkelkamp]

I suggest you swap the Pi zeros in port 1 and port 4 so that port 1 has Pi4 with the sd card from Pi1.

If the Pi fails in port 1 then you may have a faulty Pi Zero, this happened to me (interestingly on port 4) for no apparent reason,

where the OTG sense line seems to be shorted somewhere, meaning the PiZ can not be used in gadget mode but it can be used as USB host.

[Paul Miller]

Hi There

Sorry for the delay in response but I've had to put work before this.

I have since rewritten each sd card but this time I decided to use the nat lite cards and the intermediate method where I use the same image and just change the name of the device on each sd card. 

That seems to be working well although I still can't access minicom at all unless root.

The clusterhat commands are now available to the pi user. 

I did notice on the first update that it redirects a bunch of files to a different location - I don't know if that's relevant. 

Other than that it's a pretty standard install - I've updated software, expanded the filesystem and install mpich on it.  

I have updated and restarted each device in the cluster. I turned on ssh on each device

cheers

--

You received this message because you are subscribed to the Google Groups "ClusterHAT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clusterhat+...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/clusterhat/0843d67f-a7e0-4c82-bacc-593b8e36cbc9%40googlegroups.com.

[Chris Burton]

Hi,

I have since rewritten each sd card but this time I decided to use the nat lite cards and the intermediate method where I use the same image and just change the name of the device on each sd card. 

This is how all of the non-controller images are setup (on first boot including the NAT image) so it does look like something went wrong with the imaging of the cards previously.

 

That seems to be working well although I still can't access minicom at all unless root.

I'm still not sure how this would happen, "minicom p1" should work from the "pi" user unless the pi users groups or permissions on the device have changed somehow.

 

The clusterhat commands are now available to the pi user. 

I did notice on the first update that it redirects a bunch of files to a different location - I don't know if that's relevant. 

That sounds like the standard Raspbian (which is what the images are) way of updating the kernel.

 

Other than that it's a pretty standard install - I've updated software, expanded the filesystem and install mpich on it.  

I have updated and restarted each device in the cluster. I turned on ssh on each device

Again to be able to try and replicate the minicom issue I'd need to know exactly what you've ran on the controller especially the "install mpich" part as there looks to be many different sets of instructions for this.

Chris.

[Paul Miller]

Hi There

I just restarted the pi cluster and the p1.local, etc, are gone again. 

I can see the pi devices in /dev so that's not the issue. 

I can connect to p1, p2, etc via minicom. 

I have no usb0 network though. 

Do you have an ideas as to what I can do to fix this? 

cheers

[Chris Burton]

On Saturday, 25 August 2018 17:58:14 UTC+1, Paul Miller wrote:

Hi There

I just restarted the pi cluster and the p1.local, etc, are gone again.

Are you using "cnat" or "controller" image? Are you trying to access "p1.local" from the Controller or the local network? Are the ethpiX interfaces there, do they show up with "ifconfig -a" are the interfaces in the bridge "sudo brctl show"?

 

I can see the pi devices in /dev so that's not the issue. 

I can connect to p1, p2, etc via minicom. 

I have no usb0 network though. 

I assume when you say no usb0 you're logging into the Pi Zeros through minicom and then seeing no usb0 interfaces?

If this is the case then please reboot both controller and Pi Zero and then provide the output of "dmesg" from both. To get these I'd advise running 

sudo bash -c "(ifconfig;lsusb -t;brctl show;dmesg) > /boot/CHdebug.txt"

on both the controller/pi zero and then transferring the SD to a machine where you can access the CHdebug.txt files on the boot partition and email them to sup...@8086.net.uk and I'll take a look.

 

Chris.