Thinking of setting up a gateway with the Mcard. Made a bom list;
gateway setup
antenna; sunhans 40EU
Cabinet ; maten ntb 10EU
RASPBERRY; 35EU
VOEDING 5EU
TOTAL BOM 248EU
Want to put the whole thing on the roof to minimize cable.
Any ideas on this setup (not sure about the antenna)?
I have the Kerlink Gateway up and running, but I cannot see anywhere if it is working. How to check this? The croft servers seems not responding: http://croft.thethings.girovito.nl:8083/ ?
Bin there, but it shows only 20 gateways (and not mine). The page www.ttnstatus.org shows many more. What should be my next step?
Gateways are only shown on that page when sending status information. Are you running a GPS forwarder (set to fake GPS with manual configuration if no actual GPS present) or a basic forwarder?
If possible check for network traffic between the gateway and 54.229.214.112.
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.
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.
My firewall logging was off for capturing packets from WAN to LAN, the tcpdump command gives similar output as yours.
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?
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?
@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.
@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.
Thanks kersing,
Fake GPS is working like a charm.
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/ ?
The /gateways view shows status updates sent by gateways; I guess something goes wrong with those, while node packages are received fine. @Fokko / @devlaam?
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
Adding pfrm, mail and desc doesnât seem to change the behaviour. Still no show at http://thethingsnetwork.org/api/v0/gateways/
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.
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)
Okay, after some tests i found the following on TTN:
So ⌠their is some heavy maintenance work to be done here it seems @turiphro