Queclick GL300 and invalid TCP or UDP checksums
Where and how did you check checksum validity?
Hi Anton,
Thanks for the assist... I wasn't getting any hex or log-lines in traccar server, so being a network engineer, I started at the network layer to see if I was getting the traffic.
I used tcpdump -i eth0 -vvvv -s0 -X port 5004 to verify if I was seeing packets at the port for the GL200 protocol
Spot the (incorrect -> 0xc815) in the middle. The TCP Session doesn't get past the SYN stage.
~ Rich
p.s. I tried to post a snippet from my output, but it seems the forum doesn't like it. Pasted it here instead - pastebin.com/hc0ms1Lt
If that's true, the issue is likely with the hardware.
I thought so too...
But I'm seeing some UDP SACK Packets with invalid UDP Checksums too on the return leg: pastebin.com/CTDcgqbd
~ Rich
Actually sorry, i'm confusing myself here.
The invalid checksums are being generated by traccar. Not the devices. Here's the raw output form TCPDump, no obfuscation:
~ Rich
Traccar doesn't implement its own TCP or UDP stacks, obviously. Those are provided by the operating system you are using.
Hrm... Seems outbound checksum is being done in hardware offload. Which is an interesting default...
Looks like tcpdump is capturing the unmodified packets.
Hi guys,
Bit of an odd-one. I've got a GL300N that I'm trying to get working with Traccar.
I realise this isn't a queclink support forum, but I'm wondering if anyone else has seen this behaviour:
Basically, if I enable TCP connections, the TCP packet checksum is invalid, and the traffic gets dropped. If I swap it to UDP, the checksum is still invalid, but eventually something happens and I start getting GTHBD from the device...
Anyone ever seen this before? I'm trying to evaluate these trackers for use in the field, but right now... I'm kinda erring on the side of "find another device"...
~ Rich