I am assuming you captured the packet on outgoing interface on the MT which is doing the NAT. In the case if the network card does support IP checksum offloading the operating system will not spend CPU cycles on updating the checksum because it knows the card will calculate it during packet transmission. Packet sniffer sees the packets before they are delivered to the network card so there is still non-valid checksum
Client (see “sent” dump) <—TP5 Cable —> (LAN port) MT(WAN Port) <---- internet ----> (see “received”) – Server
It’s not a matter where is computing check sum by stack or by NIC …
On server side we see:
Apr 7 12:59:28 hs1-nl kernel: [3735394.447354] UDPLite: bad checksum. From xx.zz.221.217:36499 to aa.bb.32.27:15500 ulen 8
Apr 7 12:59:29 hs1-nl kernel: [3735394.983904] UDPLite: bad checksum. From xx.zz.221.217:50325 to aa.bb.32.27:15500 ulen 8
So, it’s looks like that MT NAT don’t know about of the UDPLite at all.
Yes , the MT box threats the packets as usual UDP packets and it is IMHO ok.
I am not still sure where you captured the packets. If you captured them on the server (on the NIC which received the packets) the UDP sum should be OK here and the packets are corrupted (unless the NIC driver the packet is not subject of receive offloading which could glue multiple packets together - which I think can occur with TCP packets only). IMHO the sum could be incorrect (and the packet still fully OK) only when you capture the packets on the transmitting end (just before they are sent out of the box and only if the box changed the packets or created them).
Anyway if you have the serer under control you can try to disable temporarily offloading on it NIC card to verify if something changes.
Use ethtool -k ethX if the server is linux based to see wheter offloading is enabled…
of course. But when cheksum offloading is active the NIC does this and operating system IP stack doesn’t bother with updating the checksums. So in some cases the packet sniffer captures the packets with incorrect checksums because the they will be calculated later by NIC hardware.
In the quoted note above I was trying to say that MT box ( or any router) can treat UDP lite as usual IP packets. I mistakenly used UDP here.
If you see ‘UDPLite: bad checksum’ on the server’s message/kernel log (or some similar logfile) then the UDPLite packets were discarded by IP stack because of problem with UDP lite header. So even if the MT box knows nothing about UDP lite it shouldn’t be the cause of the problem - because it is changing only the IP header and not the UDPlite one not UDPLite payload.
If you can you could try to capture packets just behind MT box and just before the router to see if they looks OK there.
dade,
check sum offloading is not a matter in this case, it’s only a warning from Wireshark. MT box don’t recalculating the checksum for unknown protocol (136), so …
U can see that in the dumps, and messages from the Linux box also signaling that UDPlite datagrames comming with invalid check sum. The dumps i had posted was “before” and “after” the MT-router.
So, it’s a my mistake in the configuration or it’s a bug of the router’s software. I suspect that it’s a bug of the router’s software.
I had the impression that there is internet cloud between your server and the MT box which could do something with the packet too…
if you have proofs that the MT box is causing the problem you should contact support@mikrotik.com with details.
I have no personal experience with UDPLite. And I am not sure if it is really widely supported in routers (I mean the part of specification which requires ignoring link level CRC for damaged UDP Lite packets). I tried to dig some info about cisco and UDPLite and I found near nothing…
How is your NAT configured? I have checked thelist of protocols in NAT rules and there is no UDP-lite protocol option. So I have no explanation how the MT box can affect the packet at all (SRC IP).
Ehhhhh… content of the packet is OK. 100%. Incorrect the check sum in the UDP Lite header, the check sum is calculated as (src IP, dst IP, src Port, dst Port). Linux kernal drop the UDP Lite datagrames due check sum incorrectness.
I asked for NAT CFG just because it is suspicious that only SRC IP was translated but not the SRC port of the packet. It could happen when 1:1 NAT is in action (but I never tried it on MT so I don’t know how ROS behaves).
Since I found no UDP-Lite protocol in ROS protocol list (when configuring NAT rules) I thing it doesn’t support UDP-Lite. The strange thing is that it translates the SRC IP of UDP-Lite packet. And if it doesn’t change the UDP-Lite header why its checksum is damaged.
