Setting up your first gateway

Gateways
26

I see traffic going from the kerlink to 54.229.214.112.

2015-11-16 19:21:12 Information Firewall type=ACL Rule;action=Permit;Proto=UDP;SrcPort=52817;DstPort=1700;Len=40;SrcMacAddr=02:4b:08:06:05:29;DstMacAddr=d4:8c:b5:21:78:c3; 10.1.0.117 54.229.214.112

I’m using NAT rules and service forwarding for port 1700. I do not see traffic coming in, just goint out.

27

Running with NAT as well, traffic in both directions, using connection tracking on the firewall.

Running ‘tcpdump -i eth0 -n -vvvX host 54.229.214.112’ on a MultiTech:

19:30:02.060869 IP (tos 0x0, ttl 64, id 2657, offset 0, flags [DF], proto UDP (17), length 40)
  172.16.253.1.33474 > 54.229.214.112.1700: [udp sum ok] UDP, length 12
    0x0000:  4500 0028 0a61 4000 4011 79fc ac10 fd01  E..(.a@.@.y.....
    0x0010:  36e5 d670 82c2 06a4 0014 61ca 015a bc02  6..p......a..Z..
    0x0020:  0080 0000 0000 a050                      .......P
19:30:02.099706 IP (tos 0x0, ttl 48, id 52938, offset 0, flags [DF], proto UDP (17), length 32)
   54.229.214.112.1700 > 172.16.253.1.33474: [udp sum ok] UDP, length 4
    0x0000:  4500 0020 ceca 4000 3011 c59a 36e5 d670  E.....@.0...6..p
    0x0010:  ac10 fd01 06a4 82c2 000c 02ac 015a bc01  .............Z..
    0x0020:  0000 0000 0000 0000 0000 0000 0000       ..............

If you are not seeing return traffic your return IP address on the outbound interface could be wrong.

28

My firewall logging was off for capturing packets from WAN to LAN, the tcpdump command gives similar output as yours.

29

Ok, looks right to me. If you are using the basic packet forwarder this is all you will see until a node sends data to TTN using your gateway as the basic packet forwarder does not send status information shown on the gateway page of the API.

Do you have a node to send some test data?

30

Thanks. I have an arduino node with me, but have still to do the programming to get the test data.
Is there an other way to generate test data from a PC, the gateway itself or Mac?

31

@kersing: Running a GPS on a stationary gateway to me is a waste of energy. Can you please tell me how to configure Fake GPS. My gateway is running for some weeks now but because the lack of GPS its not showing on ttnstatus but node data is showing up when I do a query on the database.

1 Like
32

@Sycorax No problem, make sure you are running a gps version of the packet forwarder, as this depends on your hardware I can’t help you with that part. Next find local_conf.json or if not present global_conf.json and add to the gateway_conf section:

        "fake_gps": true,
        "ref_latitude": 10,
        "ref_longitude": 20,
        "ref_altitude": -1,

Use Google Maps to find your latitude and longitude by finding and zooming to your position and clicking on the right spot on the map. Now the position should be shown in a window at the bottom of the map. Guestimate your altitude.
Restart the packet forwarder and you are done.

2 Likes
33

Thanks kersing,

Fake GPS is working like a charm.

34

I’m setting up a gateway based on Raspberry Pi and mCard, like @nestorayuso. It seems to work, packages from my node can be seen on the server, but the gateway itself doesn’t show in
http://thethingsnetwork.org/api/v0/gateways/

In tcpdump, I see:

10:31:53.238179 IP (tos 0x0, ttl 64, id 19385, offset 0, flags [DF], proto UDP (17), length 40)
    192.168.178.106.57096 > 54.229.214.112.1700: [bad udp cksum 0x808e -> 0xf7e8!] UDP, length 12
        0x0000:  4500 0028 4bb9 4000 4011 6ea3 c0a8 b26a  E..(K.@.@.n....j
        0x0010:  36e5 d670 df08 06a4 0014 808e 01f2 fb02  6..p............
        0x0020:  0080 0000 0000 a452                      .......R
10:31:53.261429 IP (tos 0x0, ttl 49, id 62056, offset 0, flags [DF], proto UDP (17), length 32)
    54.229.214.112.1700 > 192.168.178.106.57096: [udp sum ok] UDP, length 4
        0x0000:  4500 0020 f268 4000 3111 d6fb 36e5 d670  E....h@.1...6..p
        0x0010:  c0a8 b26a 06a4 df08 000c 9ccc 01f2 fb01  ...j............
        0x0020:  0000 0000 0000 0000 0000 0000 0000       ..............

Does the “bad udp chksum” have anything to do with the gateway not showing up?

My global_conf.json contains:
“gateway_conf”: {
“gateway_ID”: “008000000000A452”,
“server_address”: “54.229.214.112”,
“serv_port_up”: 1700,
“serv_port_down”: 1700,
“keepalive_interval”: 12,
“stat_interval”: 20,
“push_timeout_ms”: 120,
“forward_crc_valid”: true,
“forward_crc_error”: false,
“forward_crc_disabled”: true,
“fake_gps”: true,
“ref_altitude”: -1,
“ref_latitude”: 52.366976,
“ref_longitude”: 4.937145
}

Confusing: in http://thethingsnetwork.org/api/v0/nodes/BEEFBEEF/ you can see that message from “gateway_eui”: "008000000000A452 do arrive at the server.

Any ideas on what I should do to make my gateway visible in the gateway listing on http://thethingsnetwork.org/api/v0/gateways/ ?

35

The /gateways view shows status updates sent by gateways; I guess something goes wrong with those, while node packages are received fine. @Fokko / @devlaam?

37

Bit strange, i did added some fields to the json status recently. If the TTN parser was not updated and is not resilient against field changes (which is a ‘bit rot’ bug), than it can cause this problem. The extra fields were: “pfrm”, “mail” and “desc”. These changes were communicated.

See also this thread: New Gateway Registration

38

Adding pfrm, mail and desc doesn’t seem to change the behaviour. Still no show at http://thethingsnetwork.org/api/v0/gateways/

39

I don’t understand your remark. You cannot add these fields, or you can, but that does not change anything of course, these new fields [which are part of the communication between the forwarder and the backend] may be the cause of the problems because of the TTN parser. It’s hard to imagine since this would really be a sign of bad code design on that side, but if so, it could explain it. Just a moment, i can think i can test this quickly.

40

if you want to use gps log and lat to apear on some status/map you need to run gps_pkt_fwd, not basic_pkt_fwd

fake_gps field in json is used only in gps_pkt_fwd (and beacon_pkt_fwd)

41

Okay, after some tests i found the following on TTN:

  1. Already existing gateways in the list http://thethingsnetwork.org/api/v0/gateways/ work with and without the extra fields in the general status.
  2. New gateways (i.e. with unknown gateway id’s) are NOT added to this list. Some there is a bug in the update mechanism there somewhere
  3. http://www.ttnstatus.org is completely broken, gateways last seen at 2015-11-12 are reported as up. Updates to reach the gateway list on http://thethingsnetwork.org/api/v0/gateways/ do not reach ttnstatus.org
  4. gateways that appear in http://thethingsnetwork.org/api/v0/gateways/ do not appear in http://thethingsnetwork.org/api/v0/nodes/ although node data was emitted.
  5. On iot.semtech.org gateways are recognised immediately after they transmit there status (also with the extra fields).

So … their is some heavy maintenance work to be done here it seems @turiphro

42

and on the poly forwarder

43

The status updates are broken indeed (they were implemented using the deprecated DB instead of API; @Jorma is fixing it). Unrelated to the API though. The /gateways/ shows GW status packets, the /nodes/ shows packets, so they’re not necessarily both there if one of the two packet types aren’t sent.

@johan can there be some reason gateway status messages with new IDs don’t get through? Or can you help debugging this problem? (give him some time, he’s workshopping downstairs ;))

44

I followed @nestorayuso 's advice and changed from basic_pkt_fwd to gps_pkt_fwd. Immediately, my gateway showed up in http://thethingsnetwork.org/api/v0/gateways/008000000000A452/ and I see packages in the tcpdump containing this info.

Not all available fields are shown, but they are also not showing on other hosts, so I guess that’s on the server todo list.

Now it’s time to make the gateway waterproof and hang it on the roof!

45

I understand, so i made sure packets were send and locally sniffed if the status messages were there too.
Btw, this nodes list [ http://thethingsnetwork.org/api/v0/nodes/ ] is ridiculously short, none of my node packets are show there, while in the gateway lists is says (few snapshots …)
{
“longitude”: 4.70053,
“last_seen”: “2015-11-20T12:38:19.599Z”,
“latitude”: 52.69021,
“status_packets_count”: 1368,
“eui”: “1DEE1DB50A0D5C5E”,
“altitude”: 5.0
}
…
{
“longitude”: 4.70053,
“last_seen”: “2015-11-20T13:17:57.024Z”,
“latitude”: 52.69021,
“status_packets_count”: 1389,
“eui”: “1DEE1DB50A0D5C5E”,
“altitude”: 5.0
}
…
{
“longitude”: 4.70053,
“last_seen”: “2015-11-20T13:44:27.010Z”,
“latitude”: 52.69021,
“status_packets_count”: 1416,
“eui”: “1DEE1DB50A0D5C5E”,
“altitude”: 5.0
}

so the status packet counter is increasing and i send much more RF packets than node packets:
Nov 20 13:03:33 lorank8 lorank8v1[12672]: # RF packets forwarded: 2 (74 bytes)
Nov 20 13:03:34 lorank8 lorank8v1[12672]: # RF packets forwarded: 3 (111 bytes)
Nov 20 13:03:34 lorank8 lorank8v1[12672]: # RF packets forwarded: 3 (111 bytes)
Nov 20 13:05:07 lorank8 lorank8v1[12672]: # RF packets forwarded: 3 (111 bytes)
Nov 20 13:05:08 lorank8 lorank8v1[12672]: # RF packets forwarded: 3 (111 bytes)
Nov 20 13:05:08 lorank8 lorank8v1[12672]: # RF packets forwarded: 1 (37 bytes)
Nov 20 13:45:08 lorank8 lorank8v1[12672]: # RF packets forwarded: 3 (111 bytes)
many more repetitions …
Nov 20 13:48:02 lorank8 lorank8v1[12672]: # RF packets forwarded: 3 (111 bytes)

46

Intersting, given the data
{
“longitude”: 6.55738,
“last_seen”: “2015-11-20T13:47:12.764Z”,
“latitude”: 53.18977,
“status_packets_count”: 7210,
“eui”: “008000000000A050”,
“altitude”: 5.0
}
and the fact that the forwarder sends out a status packet every 30 SECONDS is seems that this gateway is already recognised for 7210/2/60 = 60 hours! How could that be?