On Tue, Jul 26, 2005 at 04:34:16PM +0200, Gert Doering wrote: | Hi, | | I'm sure this is going to be difficult to diagnose - so I need some | help to figure out where to start. | | Setup: | NetBSD -current (3.99.7) on Sparc64. | IPv6-over-GRE-over-IPv4 tunneling | tcpdump HEAD from CVS | system libpcap | | $ ./tcpdump -V | tcpdump version 3.9-PRE-CVS | libpcap version 0.8.3 | | (this is because using libpcap-3.9-PRE-CVS makes tcpdump core dump, for | whatever reason??!)
can i have the core file for inspection, pls ? | | Sniffing on the LAN for "host <remote address of tunnel>" gives: | | tcpdump: verbose output suppressed, use -v or -vv for full protocol decode | listening on hme0, link-type EN10MB (Ethernet), capture size 65535 bytes | 16:14:04.595494 IP 172.30.1.153 > 193.149.44.208: GREv0, length 60: IP6 2001:608:8003::1 > 2001:608:4::3: ICMP6, echo request, seq 0, length 16 | 16:14:04.700420 IP 193.149.44.208 > 172.30.1.153: GREv0, length 60: IP6 2001:608:4::3 > 2001:608:8003::1: ICMP6, echo reply, seq 0, length 16 | 16:14:05.595419 IP 172.30.1.153 > 193.149.44.208: GREv0, length 60: IP6 2001:608:8003::1 > 2001:608:4::3: ICMP6, echo request, seq 1, length 16 | 16:14:05.746677 IP 193.149.44.208 > 172.30.1.153: GREv0, length 60: IP6 2001:608:4::3 > 2001:608:8003::1: ICMP6, echo reply, seq 1, length 16 | | -> perfect, this is exactly how it should be. | | | Sniffing on the tunnel interface (gre0) gives: | | [EMAIL PROTECTED]:/home/gert/cdp/tcpdump$ SU ./tcpdump -n -s0 -i gre0 | tcpdump: WARNING: gre0: no IPv4 address assigned | tcpdump: verbose output suppressed, use -v or -vv for full protocol decode | listening on gre0, link-type NULL (BSD loopback), capture size 65535 bytes | 16:16:28.835438 IP6 2001:608:8003::1 > 2001:608:4::3: ICMP6, echo request, seq 0, length 16 | 16:16:28.937041 IP6 , wrong link-layer encapsulationbad-hlen 0 | 16:16:29.835377 IP6 2001:608:8003::1 > 2001:608:4::3: ICMP6, echo request, seq 1, length 16 | 16:16:29.947910 IP6 , wrong link-layer encapsulationbad-hlen 0 | | -> which is weird. Outgoing packets are properly decoded, incoming | packets are not properly displayed. | | With "-X", the packets look like this: | | 16:32:36.925380 IP6 2001:608:8003::1 > 2001:608:4::3: ICMP6, echo request, seq 1, length 16 | 0x0000: 6000 0000 0010 3a40 2001 0608 8003 0000 `.....:@........ | 0x0010: 0000 0000 0000 0001 2001 0608 0004 0000 ................ | 0x0020: 0000 0000 0000 0003 8000 1c21 ecc8 0001 ...........!.... | 0x0030: 42e6 4984 000e 1e34 B.I....4 | 16:32:37.024946 IP6 , wrong link-layer encapsulationbad-hlen 0 | 0x0000: 6000 0000 0010 3a3d 2001 0608 0004 0000 `.....:=........ | 0x0010: 0000 0000 0000 0003 2001 0608 8003 0000 ................ | 0x0020: 0000 0000 0000 0001 8100 1b21 ecc8 0001 ...........!.... | 0x0030: 42e6 4984 000e 1e34 B.I....4 | | (The pinging itself works fine, so the issue is not "corrupted packets" | but more "corrupted signalling kernel->libpcap" or such). | | | What could be causing this effect? How can I narrow this down, and | get it fixed / fix it? can you send me the .pcap of the gre tunnel and i have a look; i am anticipating a kernel issue - typically we get this error message when the kernel tells us that the payload is IPv4 [and in reality is IPv6] - that makes the IPv4 printer bark; /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
