2

I'm having an issue with getting the actual ping process to receive the reply even though I can clearly see the response in the tcpdump output.

I'm running on:

  • Mac OS X 10.11.4 El Capitan
  • Bridge interface with tap interface as a member
  • qemu is running a VM instance of IncludeOS

The bridge is created as follows:

sudo ifconfig bridge5 create
sudo ifconfig bridge5 10.0.0.5 netmask 255.255.255.0 up

The tap interface is a tuntap device and is linked to the bridge as follows:

sudo ifconfig bridge5 addm tap0

I launch my VM using qemu without issues and here is what I observe:

  1. Connecting to a TCP service running on the VM works without issue. I'm able to load a webpage.
  2. Performing an arping works great.
  3. A normal ping 10.0.0.42 gives me Request timeout for icmp_seq, but when I check out the tcpdump output I see the following:

    $ tcpdump -i bridge5 -vvv
    tcpdump: listening on bridge5, link-type EN10MB (Ethernet), capture size 262144 bytes
    15:11:40.014240 IP (tos 0x0, ttl 64, id 47005, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->aedd)!)
        10.0.0.5 > 10.0.0.42: ICMP echo request, id 24337, seq 8, length 64
    15:11:40.014808 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto ICMP (1), length 118)
        10.0.0.42 > 10.0.0.5: ICMP echo reply, id 24337, seq 8, length 98 (wrong icmp cksum af73 (->3b17)!)
    

The one thing I notice with this output is that the checksum is bad. We have had this exact same solution working on Ubuntu for a long while, and when I checked there there was also an icmp checksum error on the replies.

Any ideas for what could be stopping the replies from going through to the ping application?

1 Answer 1

4

wireshark see the packet before the firewall in reception. that mean a firewall or a similar product filter your reception. (reference)

the bad checksum just mean usually that tcp checksum offload is enabled on the nic.

TCP checksum offloading (lots of checksum errors)

There are causes where you might see lots of checksum errors.

If you capture on a recent Ethernet NIC, you may see many such "checksum errors". This is due to TCP Checksum offloading often being implemented on those NICs and thus, for packets being transmitted by the machine. The checksum will not be calculated until the packet is sent out by the NIC hardware, long long after your capture tool intercepted the packet from the network stack.

As this may be confusing and will prevent Wireshark from reassemble TCP segments it's a good idea to switch checksum verification off in these cases.

To disable checking of the TCP checksum validity, go to the TCP preferences and untick the box for checksum verification

3
  • I've tried disabling the firewall both through the system preferences and disabling the pf firewall, both to no avail. Any ideas here? I won't worry about the bad checksum error then, as it most likely isn't what is causing this issue then.
    – McBirdy
    Jun 30, 2016 at 13:22
  • 1
    The bad checksum "0" on the outgoing packet is common, it's because the network stack or network card does the checksumming lower down (closer to the network). However, the "wrong icmp cksum" is another beast entirely.
    – Law29
    Jun 30, 2016 at 20:53
  • 1
    @Law29 Good to know your opinion on the matter, but without explanation it's worth no value, it would be useful if you detail it, in case it help for the OP problem.
    – yagmoth555
    Jul 1, 2016 at 1:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .