Showing results for 
Search instead for 
Did you mean: 
Walkthrough Wednesdays

VCS Expressway - TCP checksum error


I am having trouble registering a SIP SX20 with my VCS-E.

I checked firewall rules (addresses and ports) and is as expected.

I performed a "tcpdump" on VCS-E and captured the following information:

172.X.X.2 = VCS-E

172.X.X.65 = SX20

~ # tcpdump -vvvv -nn -i eth0 host 172.X.X.65

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

17:09:33.495399 IP (tos 0x0, ttl 55, id 17587, offset 0, flags [DF], proto TCP (6), length 60)

172.X.X.65.59797 > 172.X.X.2.5061: Flags [S], cksum 0xcad0 (correct), seq 3664194400, win 3440, options [mss 860,sackOK,TS val 4294834816 ecr 0,nop,wscale 5], length 0

17:09:33.495415 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)

172.X.X.2.5061 > 172.X.X.65.59797: Flags [S.], cksum 0x74a6 (incorrect -> 0x1e45), seq 807564912, ack 3664194401, win 5792, options [mss 1460,sackOK,TS val 1312992283 ecr 4294834816,nop,wscale 7], length 0

I performed a tcpdump on my internal firewall, Fortigate 311B, (the SX20 is on another network, routed through the Internet) and did not detect any record of SYN ACK on the firewall, towards the VCS-E for the SX20.

Then this same check performed on another endpoint, also an SX-20 in another network under the same conditions.

I've found that the same problem occurs TCP checksum error, but the same internal firewall SYN ACK packet is forwarded in the sense VCS-E for the SX20.This equipment is typically logs in VCS-E (SIP port: 5061 transport: TLS).

I performed another check in VCS-E in relation to its NIC, referring the "checksum offloading" was enabled:

I accessed the VCS-E via an SSH connection, and gave the following command:

ethtool - show-offload eth0

In response I got:

Offload parameters for eth0:

rx-checksumming: on

tx-checksumming: on

scatter-gather: on

tcp-segmentation-offload: on

udp-fragmentation-offload: off

generic-segmentation-offload: on

generic-receive-offload: off

large-receive-offload: off

ntuple-filters: off

receive-hashing: off

For the answer above is not the problem this variable, I have no idea what could cause this error, since I have another VCS-E and performed the same tests and got the same results.

Martin Koch

Hi Alexander!

Dont get fooled by that errors. I would recomend if you want to check that that you either use a

transparent network analyzer which you put in between or a switch with a monitoring port.

The rx/tx checksumming should be off if you would like to expect not to see any checksum errors

with a local tcpdump. Anyhow I would recomend you not to mangle with the linux system itself,

you never know if the system relays on something which on the first view does not look obvious.

Do you have a chance to put an enpoint in the same subnet that your vcs is located in?

Then you coud easily rule out the firewall.

Anyhow I would first start to look at the eventlog of the vcs and the all log of the endpoint,

possibly increasing the log levels as well.

As we do not know much about your deployment it would be fishing in the dark, but from

I would say less then one promille of registration issues I have seen were related to network issues.

Often its a configuration issues, lacking sip domains, wrong authentication or other generic

configurations are a key player besides alg/l3-gw/nat helper, ....

Please remember to rate helpful responses and identify

Content for Community-Ad

Spotlight Awards 2021