I'm running a couple of LXC containers (Container1 and Container2) on my host, each with a veth (veth1000_1 and veth1001_1) connected through a bridge (mbr1). From Container1 I ping6 Container2 and everything is working, but I can't manage to capture the icmp6 replies if I filter by protocol on veth1000_1:
I'm interested in using veth1000_1 instead of mbr1 because when jumping to a more complex scenario, where packets can be lost, I'm interested on seeing only the packets actually received by the container and not on the network. Also having to capture in the container makes everything more complicated so I rather capture everything from the host. And I don't want huge capture files, so I'd like to filter out the other traffic. I've also tried with tcpdump with the same results. Also I tried pinging from the host to the outside world and everything worked fine. I'm using tshark 1.8.2 with libpcap 1.3.0. Any idea what I'm doing wrong and how can I manage to do it properly? asked 20 Sep '13, 03:01  Ester edited 20 Sep '13, 17:55  Guy Harris ♦♦ |
One Answer:
O.K. then I guess it's either a libpcap issue or an issue with the LXC virtual interfaces and not an issue with Wireshark. Unfortunately neither problem can be fixed by the Wireshark community. Did you ask this question in the forums of libpcap/tcpdump and/or lxc?
If you look at the reply packets in this case: Is there any VLAN tag added (I don't know if LXC uses VLANs internally)? Or do the replies look in any way 'strange'? BTW: If you cannot detect a difference, can you please post a capture file somewhere (google docs, dropbox, cloudshark, etc.)? SOLUTION see comments below. The problem seems to be related to VLAN tags and possibly a bug in libpcap in conjunction with LXC virtual interfaces. The following filter shows both, requests and responses:
Regards answered 20 Sep '13, 04:10  Kurt Knochner ♦ edited 20 Sep '13, 07:17 showing 5 of 11 show 6 more comments |
Yup, I forgot to mention that traffic carries a VLAN tag, but both request and replies. What I don't get is why (if everything seems the same on lower ayers) when filtering by protocol it will drop some packets.
A capture file (without the icmp6 filter): https://dl.dropboxusercontent.com/u/3807034/ICMP6_capture.pcap
Anyway, I'll ask too to the libpcap community. Thanks Kurt.
Can you please try this:
and/or
What do you see?
If it's a bug in the LXC veth code or the libpcap code, there is no logic you can apply ;-))
Wow,
In both cases (tcpdump and tshark) I see only the replies:
whereas
Could you explain me the rationale behind this? (I mean I know I can now use the filter "icmp6 or (vlan and icmp6)" but I cannot understand the reason why it works)
I'm sorry, but no. I believe this could be a libpcap issue (or a problem with the veth interface code).
What do you see with this filter:
Captur filter works on byte offsets and the VLAN tag adds a couple of bytes so "icmp6" does not work on the VLAN tagged packet, Most probably the outgoing request gets the VLAN tag added by the interface or after libpcap "sees" the pacaket so the filter with VLAN does not catch the packet try "vlan and icmp6"|| "icmp6"
Neither the filter '(vlan and icmp6) or icmp6' nor "vlan and icmp6"|| "icmp6" worked (they only show replies).
I guess it is because, as explained by Anders, once you write vlan it expects the packets to have a VLAN tag and then does not recognise the ones without it.
Anyway, it is confusing, because the "or" operation should be commutative.
Many thanks to you both.
Did you try this:
The BPF code is different see
versus
Yeah, that one is working :), yet I always thought that 'or' order didn't matter (much)..
I see that is not the case after seeing the code, though I couldn't decipher it, but I see that 'icmp6 or (vlan and icmp6)' seems to check more cases, or at least its longer.
I'm glad I could help.
Nevertheless, there seems to be a bug in libpcap in conjunction with LXC virtual ethernet nics, whereas it is yet unclear who is introducing the bug. See @Anders comment: I's probably related to the fact where/when the VLAN tag is added.
It's code for the BPF filtering virtual machine. See here, if you are interested in some details
For future reference, you may want to refer to the pcap-filter man page hosted on www.tcpdump.org.
Of particular note:
vlanprimitive is not the only primitive that behaves this way - bothmplsandpppoesdo as well.vlan(andmpls) primitive increments the filter offsets by 4. (Refer to the man page for more details and examples.)the pcap-filter man page would be a good source of information about the filter synatx, however the OP wanted to understand the difference in generated BPF code and thus he needs to know how the BPF virtual machine works and how to read the BPF 'machine instructions'. The pcap-filter man page does not contain that information, whereas the PDF is a pretty good tutorial for that.