TTN GATEWAY central

Hi,

I also received my TTN-gateway, and activated it.
It forwards packets nicely, but it stops forwarding packets after a certain time.
The TTN-console still shows the gateway as active.
The HTTP-interface on the TTN-gateway also still responds.
I am still trying to find out if this problem occurs with a regular interval.

My TTN-gateway is connected via Ethernet, and it gets a static lease from my DHCP-server.
The TTN-gateway gets its IP-address, and starts forwarding packets nicely.
It works for hours, and after a while it does a DHCP-request for IP-address 0.0.0.0
I think this is strange.
I think that this should be a DHCP-request for the IP-address that it already has obtained, or a DHCP-discover.
But not a DHCP-request for 0.0.0.0

-> Is this a bug? Or am I missing someting?

My hypothesis is that the above event causes the IP-stack of the TTN-gateway to be reinitialized.
Can this be the reason why my TTN-gateway stops forwarding packets?

regards,

Egon

=== DHCP server log ===
Jan 28 15:05:52 my_server dhcpd: DHCPREQUEST for 0.0.0.0 from <TTN_GW_MAC_ADDRESS> via lan: wrong network.
Jan 28 15:05:52 my_server dhcpd: DHCPNAK on 0.0.0.0 to <TTN_GW_MAC_ADDRESS> via lan
Jan 28 15:05:55 my_server dhcpd: DHCPDISCOVER from <TTN_GW_MAC_ADDRESS> via lan
Jan 28 15:05:55 my_server dhcpd: DHCPOFFER on <TTN_GW_IP_ADDRESS> to <TTN_GW_MAC_ADDRESS> via lan
Jan 28 15:05:55 my_server dhcpd: DHCPREQUEST for <TTN_GW_IP_ADDRESS> (MY_DHCP_SERVER) from <TTN_GW_MAC_ADDRESS> via lan
Jan 28 15:05:55 my_server dhcpd: DHCPACK on <TTN_GW_IP_ADDRESS> to <TTN_GW_MAC_ADDRESS> via lan
--
Jan 28 15:50:54 my_server dhcpd: DHCPREQUEST for 0.0.0.0 from <TTN_GW_MAC_ADDRESS> via lan: wrong network.
Jan 28 15:50:54 my_server dhcpd: DHCPNAK on 0.0.0.0 to <TTN_GW_MAC_ADDRESS> via lan
Jan 28 15:50:56 my_server dhcpd: DHCPDISCOVER from <TTN_GW_MAC_ADDRESS> via lan
Jan 28 15:50:56 my_server dhcpd: DHCPOFFER on <TTN_GW_IP_ADDRESS> to <TTN_GW_MAC_ADDRESS> via lan
Jan 28 15:50:56 my_server dhcpd: DHCPREQUEST for <TTN_GW_IP_ADDRESS> (MY_DHCP_SERVER) from <TTN_GW_MAC_ADDRESS> via lan
Jan 28 15:50:56 my_server dhcpd: DHCPACK on <TTN_GW_IP_ADDRESS> to <TTN_GW_MAC_ADDRESS> via lan

Hy My TTN gateway does EXACTLY the same as your gateway even without pushing the reset button. It does it continuously. So the conclusion is that this is a common problem. Hope TTN guys will solve this ASAP.

I just connected a lab supply in stead of the standard supply. I cut the cable (is about the same length). The supply can deliver 3A. Average current consumption is about 300 mA @ 12 volt. The reset issue is still there. After increasing the voltage to 13.5 volt it seems the gateway gets fully up and running more often and keeps running longer (few minutes). It does not fix the issue, but seems to influence it.

Could it be that buffer capacitance on an internal supply is to small? Please provide me with the schematics so I can do a few measurements and solder additional capacitances on internal supplies.

3 Likes

The thing to keep faith in , is that the TTN gateway does work for a lot of people.
Chances are it is the environment / router rather than a hardware / quality control problem.
It could be that the TTN gateway is vulnerable to noisy environments (Other RF / WiFi instability from router / poor mains filtering), but the existance of working gateways show that it can be made to be OK.

So with that in mind, just thinking of things to try.

Does anyone with an unsuccessful gateway live near someone who has a working gateway?

Someone takes the “unsuccesssful” gateway to the person who has a “successful” gateway, and tries to activate it there?
Obviously, the one who has a working gateway, switches it off while the experimenting is going on. If this works, then maybe leave the gateway there for a few days to see how it performs?

This should help indicate if the gateway does work in a similar environment

My gateways works, so I’m happy to test my environment for others if they are nearby in NW of UK, just PM me .

N.B. I use a guest wifi network on an ASUS router, and the gateway connects fine, but I have had problems with the gateway getting stuck if I switch the gateway on before the router wifi. so I always ensure the correct power on sequence.
I also have the gateway fairly close to the WiFi router?

Is there anyone else in other areas that are willing to voluenteer?

1 Like

My contribution to this topic is that:

While software is in many cases the same, I identyfy two possible causes:

  1. Hardware failure.
  2. the network environment in which the gateway is placed.

Interesting … :thinking:

1 Like

could we have two issues here, as some gateways are running but keep reset after a period (memory leak) while other seem to reset during activation and or as LoRA card startup (power supply) ? just a thought :thinking:

Exactly 24 hours? Or at much less exact intervals, say “between 22 and 26 hours”?

ok so a reboot every 24hrs while not great; is somewhat different to my experience, the gateway isn’t up for a more than a few seconds, I don’t even thing it completes its boot sequence fully :’(

that is after initial configuration

Of course many hours is different from seconds, but “many hours” is also very different from “24 hours” (the first maybe indeed indicating some memory leak, while the latter possibly indicating some daily job failing).

or a DHCP lease ? hmmm

1 Like

Same for my gateway: it is a few seconds between the reboots. Have initialized it a few times, also on different networks (1: my home network, wired and wireless; 2: using the personal wifi hotspot of an iPhone, with its mobile data plan). The sequence in which the various leds light up differ slightly in all cases, but it reboots every few seconds.

I got a reply from Johan Stokking, maybe he report back here as well I don’t know.
But for now here is his response translated from Dutch to English:
Thank you for your message, sorry to hear about your problems.
There were multiple boot-loop issues reported, there is beta firmware build already which will be made available very soon.
It will be loaded over the network to your gateway if you have the beta firmware option enabled in console, and the gateway stays running long enough to download and apply it of course.
A separate image is also being made available for local update via an SD-card.
Even though some people are/were ill at TWTG (TweeTonig) they are working very hard to get this firmware available asap.
Keep an eye out on this topic.

8 Likes

…now making sure I have one ready to use :slight_smile:

1 Like

That doesn’t explain the reboot …

No actually it seems to happen more often, will try to get a better understanding of how often it happens

This is how my DHCP log looks like

    Jan 29 10:05:34 ha-30 dhcpd[10401]: DHCPDISCOVER from 00:1e:c0:3a:f8:c5 (THINGS-GATEWAY) via enp0s31f6
    Jan 29 10:05:35 ha-30 dhcpd[10401]: DHCPOFFER on 192.168.223.68 to 00:1e:c0:3a:f8:c5 (THINGS-GATEWAY) via enp0s31f6
    Jan 29 10:05:35 ha-30 dhcpd[10401]: DHCPREQUEST for 192.168.223.68 (192.168.223.27) from 00:1e:c0:3a:f8:c5 (THINGS-GATEWAY) via enp0s31f6
    Jan 29 10:05:35 ha-30 dhcpd[10401]: DHCPACK on 192.168.223.68 to 00:1e:c0:3a:f8:c5 (THINGS-GATEWAY) via enp0s31f6
    Jan 29 10:55:56 ha-30 dhcpd[10401]: DHCPDISCOVER from 00:1e:c0:3a:f8:c5 (THINGS-GATEWAY) via enp0s31f6
    Jan 29 10:55:57 ha-30 dhcpd[10401]: DHCPOFFER on 192.168.223.68 to 00:1e:c0:3a:f8:c5 (THINGS-GATEWAY) via enp0s31f6
    Jan 29 10:55:57 ha-30 dhcpd[10401]: DHCPREQUEST for 192.168.223.68 (192.168.223.27) from 00:1e:c0:3a:f8:c5 (THINGS-GATEWAY) via enp0s31f6
    Jan 29 10:55:57 ha-30 dhcpd[10401]: DHCPACK on 192.168.223.68 to 00:1e:c0:3a:f8:c5 (THINGS-GATEWAY) via enp0s31f6
    Jan 29 11:56:54 ha-30 dhcpd[10401]: DHCPDISCOVER from 00:1e:c0:3a:f8:c5 (THINGS-GATEWAY) via enp0s31f6
    Jan 29 11:56:55 ha-30 dhcpd[10401]: DHCPOFFER on 192.168.223.68 to 00:1e:c0:3a:f8:c5 (THINGS-GATEWAY) via enp0s31f6
    Jan 29 11:56:55 ha-30 dhcpd[10401]: DHCPREQUEST for 192.168.223.68 (192.168.223.27) from 00:1e:c0:3a:f8:c5 (THINGS-GATEWAY) via enp0s31f6
    Jan 29 11:56:55 ha-30 dhcpd[10401]: DHCPACK on 192.168.223.68 to 00:1e:c0:3a:f8:c5 (THINGS-GATEWAY) via enp0s31f6
    Jan 29 14:40:54 ha-30 dhcpd[10401]: DHCPDISCOVER from 00:1e:c0:3a:f8:c5 (THINGS-GATEWAY) via enp0s31f6
    Jan 29 14:40:55 ha-30 dhcpd[10401]: DHCPOFFER on 192.168.223.68 to 00:1e:c0:3a:f8:c5 (THINGS-GATEWAY) via enp0s31f6
    Jan 29 14:40:55 ha-30 dhcpd[10401]: DHCPREQUEST for 192.168.223.68 (192.168.223.27) from 00:1e:c0:3a:f8:c5 (THINGS-GATEWAY) via enp0s31f6
    Jan 29 14:40:55 ha-30 dhcpd[10401]: DHCPACK on 192.168.223.68 to 00:1e:c0:3a:f8:c5 (THINGS-GATEWAY) via enp0s31f6

My Gateway is working as expected over ethernet. (I missing POE to it, maybee next version)
But I can’t disable the unprotected AP-mode with default pw.
I especkt at leased I can shut down the WiFi and change the default User name - password

Regards

Johan

Hi All
It should be possible to have ssh in to the gateway for diagnostics? and monitoring.
Becouse everybody place his gateway on the attic. And managed his nework device’s from livvingroom are something like that.
What do I want to see/do (reboot, see connetionand his registration procces with his ttn.router.eu

How can we make that possible?

Regards

Johan

My “reboots” if this is what it is happen not exactly 24 hours apart but every morning when I log on to TTN I have to power cycle the gateway. Not sure exactly when it is happening, but it happens once a day.