Pings to halow link 1

General
1

I’m investigating ping drops from beagle bone industrial to halow link1 (in extender mode). I’ve connected directly from eth0 on bbi to lan port of HL1. I configured the eth0

sudo ip addr add 10.22.121.110/31 dev eth0
sudo ip route add 10.22.121.111 dev eth0 scope link

in order to test this. and the ping record (abbreviated is here):slight_smile:

64 bytes from 10.22.121.111: icmp_seq=166 ttl=64 time=0.907 ms
64 bytes from 10.22.121.111: icmp_seq=167 ttl=64 time=0.786 ms
64 bytes from 10.22.121.111: icmp_seq=168 ttl=64 time=1.06 ms
64 bytes from 10.22.121.111: icmp_seq=169 ttl=64 time=0.894 ms
64 bytes from 10.22.121.111: icmp_seq=170 ttl=64 time=0.789 ms
64 bytes from 10.22.121.111: icmp_seq=171 ttl=64 time=0.778 ms
^C
— 10.22.121.111 ping statistics —
172 packets transmitted, 162 received, 5.81395% packet loss, time 171441ms
rtt min/avg/max/mdev = 0.719/0.886/1.548/0.099 ms

pinging to 192.168.12.1 is about the same:

64 bytes from 192.168.12.1: icmp_seq=45 ttl=64 time=7.67 ms
64 bytes from 192.168.12.1: icmp_seq=46 ttl=64 time=4.90 ms
64 bytes from 192.168.12.1: icmp_seq=47 ttl=64 time=4.62 ms
64 bytes from 192.168.12.1: icmp_seq=48 ttl=64 time=4.50 ms
64 bytes from 192.168.12.1: icmp_seq=49 ttl=64 time=9.82 ms
64 bytes from 192.168.12.1: icmp_seq=50 ttl=64 time=4.73 ms
64 bytes from 192.168.12.1: icmp_seq=52 ttl=64 time=4.59 ms
64 bytes from 192.168.12.1: icmp_seq=53 ttl=64 time=4.60 ms
64 bytes from 192.168.12.1: icmp_seq=54 ttl=64 time=5.49 ms
^C
— 192.168.12.1 ping statistics —
54 packets transmitted, 51 received, 5.55556% packet loss, time 53129ms
rtt min/avg/max/mdev = 4.368/5.900/24.362/3.321 ms

and pinging 8.8.8.8 is also about the same

64 bytes from 8.8.8.8: icmp_seq=131 ttl=114 time=14.9 ms
64 bytes from 8.8.8.8: icmp_seq=132 ttl=114 time=11.1 ms
64 bytes from 8.8.8.8: icmp_seq=133 ttl=114 time=16.4 ms
64 bytes from 8.8.8.8: icmp_seq=134 ttl=114 time=10.7 ms
^C
— 8.8.8.8 ping statistics —
135 packets transmitted, 129 received, 4.44444% packet loss, time 134358ms
rtt min/avg/max/mdev = 9.890/15.736/61.683/7.531 ms

WHEREAS when i connect the BBB directly to my home router via ethernet again I get 0% packet loss after 1 hour of pings. Here I did ping 192.168.1.1 | nl -v 0 (notice the first column is 3665 and the icmp_seq is also 3665) there were no timeouts.

3658  64 bytes from 192.168.1.1: icmp_seq=3658 ttl=64 time=0.753 ms
3659  64 bytes from 192.168.1.1: icmp_seq=3659 ttl=64 time=0.714 ms
3660  64 bytes from 192.168.1.1: icmp_seq=3660 ttl=64 time=0.811 ms
3661  64 bytes from 192.168.1.1: icmp_seq=3661 ttl=64 time=0.778 ms
3662  64 bytes from 192.168.1.1: icmp_seq=3662 ttl=64 time=1.02 ms
3663  64 bytes from 192.168.1.1: icmp_seq=3663 ttl=64 time=0.809 ms
3664  64 bytes from 192.168.1.1: icmp_seq=3664 ttl=64 time=0.696 ms
3665  64 bytes from 192.168.1.1: icmp_seq=3665 ttl=64 time=0.754 ms

Note that sometimes this packet loss to 10.22.121.111 is up to 20% right now it is t 5%.

Note that there are no other devices connected to the HL1 as an extender and the AP that the HL1 extender is connected to is in AP mode not mesh.

The ethtool output is

debian@KEPLER-TST1-03:~$ sudo ethtool eth0
[sudo] password for debian:
Settings for eth0:
Supported ports: [ TP    MII ]
Supported link modes:   10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes:  10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes:  10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 100Mb/s
Duplex: Full
Auto-negotiation: on
Port: Twisted Pair
PHYAD: 0
Transceiver: external
MDI-X: Unknown
Supports Wake-on: d
Wake-on: d
Current message level: 0x00000000 (0)
    Link detected: yes

Any thoughts?

Thanks for your previous help. I have not seen the same issue with the device problems in AP mode as in Mesh but have not continueed down that route.

Bradley

2

Also note that pinging 192.168.12.1 FROM a device directly connected to the LAN port on the AP HL1 gives

97  64 bytes from 192.168.12.1: icmp_seq=97 ttl=64 time=0.910 ms
98  64 bytes from 192.168.12.1: icmp_seq=98 ttl=64 time=0.905 ms
99  64 bytes from 192.168.12.1: icmp_seq=99 ttl=64 time=0.941 ms
100  64 bytes from 192.168.12.1: icmp_seq=100 ttl=64 time=0.899 ms
101  — 192.168.12.1 ping statistics —
102  100 packets transmitted, 100 received, 0% packet loss, time 99186ms
103  rtt min/avg/max/mdev = 0.690/0.927/1.577/0.129 ms

So this seems to be something only affecting the extender…. not the AP.

3

What kind of packet loss do you get when you use a laptop/desktop in the first scenario? Laptop in place of the BBI with IP address 10.22.121.110/31 and pinging 10.22.121.111 wired into the HL1 extender’s LAN port? Just curious if the issue is unique to the BBI + HL1 extender combination.

4

What happens if you don’t use the management IP and instead let your BB get an IP via DHCP? This is primarily intended for debugging devices that have lost connectivity; you should avoid using it if the Extender is associated, since the AP will have the same management IP. Instead prefer the DHCP allocated address from the AP.

5

ok so more updates on this. Sorry for delay the holiday got in the way. Ok so I’ve made alot of progress on this. The setup is BeagleBone devices connected by ethernet to Halowlinks. 1:1 halow link to for each iot device/beaglebone black. Pinging 10.22.121.111 to from BBB to the immediately connected (via ethernet cable) to LAN port on <> yields up to 20% ping loss. The halowlinks are in AP mode with one AP and 11 extenders (12 total IOT devices).

The key facts are as follows.

  1. When I connected the beagle bone to any other router (Eero, Etherwan, Linksys) it did not have a ping loss.

  2. When I connected the beagle bone directly to the AP no packet loss. (via ethernet cable to LAN port)

  3. When I connected a macbook to AP or extender – !!! no packet loss. (all via ethernet cable)

  4. It was only when I connected the BBB to HL1 in extendermode to LAN port that I had a problem.

Now more new info after I got the message above saying that the thought was that it was something peculiar about the BBB and the HL1 in extender mode. And this is true.

I have the BeagleBone mounted on a custom PCB. The PCB is powered by a 120v AC→12v DC MeanWell PSC-100A. This gets transformed to 5v to go into BBB on the Cape.

Now here’s the kicker. When I replaced this 12v power temporarily with a Shareplus 12V Power Supply (Plugin wall 120v→12v) there were no bad pings to the extender.

From researching the Meanwell has some ripple current issues that the wall wart plug does not and that destaablizes the PHY0 on the bbb. But why does it only interfere meaninfully with pings when we ping the extender LAN port and not the AP lan port? I do not know. It may have something to do with the change on the extenders of linking together the WAN and LAN port and some type of bad resonance or feedback (I’m not an EE so forgive the speculation).

So this is very peculiar. I don’t have a definitive answer about why this happen with pings to the extender but its’ true.

Note that pining 192.168.12.1 has the same problem of course as the pings still have to go through the LAN interface.

I’m going to try putting some ferrite beads clamp on the Meanwell leads to the PCB and will report to see if that helps. Any further info or speculation on cause would be welcome.

Cheers, Bradley

7

David, actually testing the laptop in place of BBB shows no ping loss. As explained in most recent post the issue is unique to BBB powered by MeanWell PSC-100A (to PCB board) → cape→BBB and then pinging extender. When I power the PCB with a wall plug instead of the meanwell i don’t see the problem. This seems very odd but i’ve stripped down the components pretty well and that’s what I see.

8

James, the same ping loss occurs to 192.168.12.1 for instance. I noticed it because I was getting ping loss to 8.8.8.8 and then traced it back to this first jump over ethernet (which one would expect to be near perfect, or at least better than any wireless jump).

9

This is not testing the same thing. I’m more saying you should ping 192.168.12.X (where X is the address of your extender). You should not use 10.22.121.111 if your Extender is associated with your AP, as the AP and all the other Extenders also have that address.

Is there a reason you want to use that address?

(having said that, from everything else you’ve said - i.e. that it works with the laptop and a different PSU - it sounds like something far stranger is happening)

10

James,

The same (or a tiny bit more) error rates happen to 192.168.12.1. And slightly same error rates to 8.8.8.8. So I don’t know if it’s testing the same thing – you be the judge of that. But let’s just say the same ping errors happen EVEN on the 10.22.121.111 interface as when I ping the extender’s IP 192.168.12.212 address, as when I ping 192.168.12.1 as when I ping 8.8.8.8. I only used the 10.22.121.111 to try to isolate the first place in the chain where I got the pings–indeed that may not be the first place it might be (192.168.12.212)–but i thardly matters from this standpoint as all of these get the failed pings.

11

James,

I now have 192.168.12.212 on a clean power source and not getting ping. So I’ll show results for another one of the BBB/Halowlink extenders. The Ip of this extender is 192.168.12.135. the ping command uses the ping 192.168.12.135 | nl -v 0 so you can see the number of success in the first column. A quick check shows: 131 64 bytes from 192.168.12.135: icmp_seq=136 ttl=64 time=0.575 ms
132 64 bytes from 192.168.12.135: icmp_seq=137 ttl=64 time=0.826 ms
133 64 bytes from 192.168.12.135: icmp_seq=138 ttl=64 time=0.844 ms
134 64 bytes from 192.168.12.135: icmp_seq=139 ttl=64 time=0.856 ms
135 64 bytes from 192.168.12.135: icmp_seq=140 ttl=64 time=0.974 ms.

135 successes in 140 attempts.

So 4.6% error rate here. This is actually pretty good for the trials normally the error rate is higher. Note the patch cables are all brand new cat6 cables.

1 Like
12

James/David,

Any further ideas here? When I said 4.6% error rate is pretty good that was just comparatively. It still makes this unworkable without further changes. Any ideas of why extender mode is different here?

Bradley

13

Sorry, I have no insight here. It’s not possible to just change your BBB PSU, since that resolves the issue?

14

Unfortunately we now have over 80 of these units deployed and we would have to update them all, so looking to see if there is a settings fix on halowlink (again as this only happens when halow is in extender mode). Any tips on further debugging this with Multimeter oscilliscope or anything? I

15

I’m afraid I’m not an EE either. All I can think of is software side experimentation to try to narrow the scope…

e.g. try

  • the Extender is not associated,
  • removing the wan port from the lan network on the Extender (via Quick Config)
  • removing the usblan port from the lan network on the Extender (via Quick Config)
  • turning off the 2.4 on the Extender (via Quick Config)
  • turning off the HaLow on the Extender (via Quick Config)
16

Hi @semicolonsutra

Curiously, when you pinged with the laptop, was the laptop plugged into a wall socket, or running off battery?

Otherwise did you get a chance to narrow things down as James has suggest?

We do have a Beagle Play board in the office in Sydney, so we can try that to see if we can reproduce the problem.