Pygate - ethernet reliability issues

[jcaron]

@Jaap-Crezee This looks like a good starting point. You probably want to add a loop and send a counter in the client, and print the counter on both client (TX and RX) and on the server, with timestamps.

It's regular Python but I don't think there's much to change.

Other examples here and here if needed.

[shubharora shubharora]

I am on a noisy network. I could also try moving to a less noisy network (although I would argue that a device should not get slower by receiving some broadcasts; we are talking about 0.5-1kbyte/s here.). And we are not always in control of the networks we should be connecting to.

[Jaap Crezee]

@jcaron said in Pygate - ethernet reliability issues:

Meanwhile, I investigated a bit further:
It seems RX related.
I come to this conclusion because of the following:
I have a few Lora devices. They can only join the LoraWAN network just after a reset of the Pygate. For joining a LoraWAN network it seems the Lora device should be able to receive a packet back. That stops functioning after a while.
This correlates with ICMP pings getting slower and slower until they timeout and no longer work (and will never work again).
It seems packets no longer arrive at the Pygate, but it can still send data from a (wireless) Lora device to the LoraWAN (TTN) backend. So TX remains operational. I also see this (packet wise) behavior while sniffing the network. I also notice the >>> console getting very slow if this problem is present.

With this in mind, I understand people state that the Pygate will remain operational because Lora packets keep arriving at the LoraWAN backbend (TTN for example), but I think this claim is not true in some noisy networks because packets from the backend are not getting back through the Pygate gateway to wireless LoraWAN devices.
Unfortunately, I do not have time to investigate myself in more detail at the moment, but - if desirable - I could produce some excerpts of the broadcast packets which are normally present on my network and which could trigger this problem.

[shubharora shubharora]

@schmelpe said in Pygate - ethernet reliability issues:

Hi,
ok. I can confirm that the PyGate with WiPy3 stops responding to PING requests a few minutes after startup with PoE.
But I can't confirm that the PyGate didn't work anymore. The Gateways status within the TTN Console is updated every 30 Seconds or so for the last 15 days.

Hi,
ok. I can confirm that the PyGate with WiPy3 stops responding to PING requests a few minutes after startup with PoE.
But I can't confirm that the PyGate didn't work anymore. The Gateways status within the TTN Console is updated every 30 Seconds or so for the last 15 days.

[Richard Martineau]

Hi,

my 2 cents concerning this issue...

I was using an Ethernet cable with the POE adapter, without providing power(POE), and also using a USB cable to power up the PYGATE, .... I had all kind of problems.

Since I removed the USB cable, and replaced it with a POE injector over the Ethernet cable only, .... storm is over.

Regards.

Richard.

[Gijs]

Interesting... I'll have to try that for myself, thanks! (also tagging @peterp in this)

[Jaap Crezee]

@Richard-Martineau said in Pygate - ethernet reliability issues:

I was using an Ethernet cable with the POE adapter, without providing power(POE), and also using a USB cable to power up the PYGATE, .... I had all kind of problems.
Since I removed the USB cable, and replaced it with a POE injector over the Ethernet cable only, .... storm is over.

If this helps, I still think it should be fixed without the Po. I do not want to use PoE I just need the E from it..

[Gijs]

The only issue I can think of here right now, is that the USB 'communication' is the potential issue here (I cannot see a reason how it would be related to the power distribution of the PoE and USB devices, but you probably know about Murphy's law). Could you perhaps try a USB cable without communication link (or like connected to a powerbank?)

[Gijs]

Hi @Richard-Martineau
Over the last weeks we did some tests with the method you describe, but unfortunately no resolution there :(

[shubharora shubharora]

This post is deleted!