The Gateway stops communication with platform immediately or a few sec’s after reboot.
Packet forwarder seems to work and send/receive is ok.
But even GSM modem is not working, any idea
Try looking at these in reverse order:
But even GSM modem is not working, any idea
This is probably your root cause. Expired data plan, cell site down, provider’s configuration (APN etc) changed, provider locked out a modem because they want the firmware updated, broken antenna, fried hardware - you need to fix that or switch to some other means of backhaul
Packet forwarder seems to work and send/receive is ok.
Yes, probably - but many packet forwarders will give up if they stop hearing from the network. Which is likely if the backhaul modem is having issues
1 Like
Thanks, but…even the ETH gives up after …like ½ hour.
Do anyione knows where to find the description of all SW topology and spec. of the files?
i see LoRa uplinks in pck forw. but even when i am linked via ETH it do not show in trafic on GW page on the console.
What exactly do the logs show at the point where it gives up?
i see LoRa uplinks in pck forw. but even when i am linked via ETH it do not show in trafic on GW page on the console.
That makes it sound like it’s not actually connected (at least through to a key part of the infrastructure - there have been a lot of reports of trouble lately) and perhaps giving up due to a lack of acks
Well, the pck forwarder looks like this:
10:10:38.763707 IP 192.168.1.32.46969 > 52.169.76.203.1700: UDP, length 123
E....
@.@.Q.... 4.L..y..........rv.....w{"stat":{"time":"2019-12-14 10:10:38 GMT","rxnb":0,"rxok":0,"rxfw":0,"ackr":100.0,"dwnb":0,"txnb":0,"ping":35}}
10:10:40.207310 IP 192.168.1.32.46969 > 52.169.76.203.1700: UDP, length 261
E..!..@.@.P.... 4.L..y.......V..rv.....w{"rxpk":[{"tmst":1798713835,"time":"2019-12-14T10:10:40Z","chan":0,"rfch":1,"freq":868.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":10.5,"rssi":nan,"size":42,"data":"QA9FABCASQEBdZD4IeWuFjZFl87F4orqOrfdtChEVTl4v7WjZsNMabEL"}]}
10:10:44.016609 IP 192.168.1.32.38652 > 52.169.76.203.1700: UDP, length 153
E.....@.@.P%... 4.L...........:....K...w{"stat":{"time":"2019-12-14 10:10:44 GMT","lati":55.65959,"long":12.59145,"alti":30,"rxnb":0,"rxok":0,"rxfw":0,"ackr":0.0,"dwnb":0,"txnb":0}}
10:10:47.633282 IP 192.168.1.32.42464 > 52.169.76.203.1700: UDP, length 12
E..(..@.@.P.... 4.L.......Y..u.....K...w
10:10:47.763275 IP 192.168.1.32.38670 > 52.169.76.203.1700: UDP, length 12
E..(..@.@.P}... 4.L.......t...+.rv.....w
10:10:49.061615 IP 192.168.1.32.46969 > 52.169.76.203.1700: UDP, length 237
E.. .X@.@.OO... 4.L..y....T~.!..rv.....w{"rxpk":[{"tmst":1807561332,"time":"2019-12-14T10:10:49Z","chan":5,"rfch":0,"freq":867.500000,"stat":1,"modu":"LORA","datr":"SF11BW125","codr":"4/5","lsnr":9.8,"rssi":nan,"size":24,"data":"QH+vE6iAqQEBz8eJdJMYYLmL4gr24ExF"}]}
10:10:53.525802 IP 192.168.1.32.46969 > 52.169.76.203.1700: UDP, length 228
E....(@.@.N.... 4.L..y..........rv.....w{"rxpk":[{"tmst":1812039284,"time":"2019-12-14T10:10:53Z","chan":7,"rfch":0,"freq":867.900000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":5.8,"rssi":nan,"size":18,"data":"QMszABCABwABbXxIYo2aI6C5"}]}
10:10:57.763336 IP 192.168.1.32.38670 > 52.169.76.203.1700: UDP, length 12
E..(.M@.@.O;... 4.L.............rv.....w
10:10:57.833262 IP 192.168.1.32.42464 > 52.169.76.203.1700: UDP, length 12
E..(.R@.@.O6... 4.L..........Ov....K...w
10:10:59.612467 IP 192.168.1.32.46969 > 52.169.76.203.1700: UDP, length 253
E.....@.@.M.... 4.L..y....nt....rv.....w{"rxpk":[{"tmst":1818105228,"time":"2019-12-14T10:10:59Z","chan":1,"rfch":1,"freq":868.300000,"stat":1,"modu":"LORA","datr":"SF11BW125","codr":"4/5","lsnr":6.8,"rssi":nan,"size":36,"data":"QDpY76iAMwcBnMW5ZVkebRLz4bjlnfZrWJy8FcsfE0+dvlvU"}]}
10:11:01.977223 IP 192.168.1.32.46969 > 52.169.76.203.1700: UDP, length 261
E..!..@.@.Mz... 4.L..y..........rv.....w{"rxpk":[{"tmst":1820490547,"time":"2019-12-14T10:11:01Z","chan":0,"rfch":1,"freq":868.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":10.0,"rssi":nan,"size":42,"data":"QAVFABDAkAABqaTaLhW/LOsO4+oSBcXUiCHqV8S3NxJE3G1GhxAgHD+B"}]}
10:11:08.033335 IP 192.168.1.32.42464 > 52.169.76.203.1700: UDP, length 12
E..(..@.@.L.... 4.L........P..~....K...w
10:11:14.022854 IP 192.168.1.32.38652 > 52.169.76.203.1700: UDP, length 153
E.....@.@.J.... 4.L........ .d.....K...w{"stat":{"time":"2019-12-14 10:11:14 GMT","lati":55.65959,"long":12.59145,"alti":30,"rxnb":0,"rxok":0,"rxfw":0,"ackr":0.0,"dwnb":0,"txnb":0}}
10:11:18.233231 IP 192.168.1.32.42464 > 52.169.76.203.1700: UDP, length 12
E..(.e@.@.I#... 4.L................K...w
10:11:28.433233 IP 192.168.1.32.42464 > 52.169.76.203.1700: UDP, length 12
E..(.i@.@.H.... 4.L..........a.....K...w
10:11:38.633208 IP 192.168.1.32.42464 > 52.169.76.203.1700: UDP, length 12
E..(..@.@.D.... 4.L.......=<.......K...w
10:11:44.020186 IP 192.168.1.32.38652 > 52.169.76.203.1700: UDP, length 153
E....z@.@.B.... 4.L.......Z...g....K...w{"stat":{"time":"2019-12-14 10:11:44 GMT","lati":55.65959,"long":12.59145,"alti":30,"rxnb":0,"rxok":0,"rxfw":0,"ackr":0.0,"dwnb":0,"txnb":0}}
10:11:48.834373 IP 192.168.1.32.42464 > 52.169.76.203.1700: UDP, length 12
E..(..@.@.B.... 4.L........{.......K...w
And it keeps repeating.
That is the output of a program like tcpdump spying on the packet forwarder, it is not a packet forwarder log.
As such it won’t contain any error messages.
What we can see from this is that the gateway is throwing mentions of packets heard towards some target on the Internet. We don’t see anything coming back, enough time is covered that it seems like something should but its still a fairly small sample.
You really need to find the actual log and especially look for message to the effect that it is giving up due to lack of ever hearing anything back from the network infrastructure.
1 Like
That’s still not a packet forwarder log - typically that would be in syslog or similar.
However what your file does show is an entirely unreasonable frequency of re-enumeration of the GSM modem, suggesting either failed hardware or perhaps something like an insufficient power supply, or possibly incorrect configuration of the daemon managing it. It’s quite possible that this is causing other downstream failures.
1 Like