Yeah. I tried tcpdump and I could see fragmented packets on the other side
also. Please look at the log below.
-----------------------------------------------------------
[root@nttlab12 linux-2.4.19]# ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:D0:B7:49:DB:63
inet addr:192.168.253.10 Bcast:192.168.253.255 Mask:255.255.255.0
inet6 addr: fec0::2d0:b7ff:fe49:db63/73 Scope:Site
inet6 addr: fe80::2d0:b7ff:fe49:db63/10 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7040 errors:0 dropped:0 overruns:0 frame:0
TX packets:10190 errors:0 dropped:0 overruns:14 carrier:0
collisions:0 txqueuelen:100
Interrupt:10 Base address:0x6000
[root@nttlab12 init.d]# ping6 -I eth1 fec0::280:6dff:fe51:356b
PING fec0::280:6dff:fe51:356b(fec0::280:6dff:fe51:356b) from fec0::2d0:b7ff:fe49:db63 eth1: 56 data bytes
64 bytes from fec0::280:6dff:fe51:356b: icmp_seq=0 hops=64 time=0.3 ms
64 bytes from fec0::280:6dff:fe51:356b: icmp_seq=1 hops=64 time=0.2 ms
--- fec0::280:6dff:fe51:356b ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.2/0.2/0.3 ms
[root@nttlab12 init.d]# ping6 -s 2000 -I eth1 fec0::280:6dff:fe51:356b
PING fec0::280:6dff:fe51:356b(fec0::280:6dff:fe51:356b) from fec0::2d0:b7ff:fe49:db63 eth1: 2000 data bytes
ping: recvmsg: No route to host
ping: recvmsg: No route to host
--- fec0::280:6dff:fe51:356b ping statistics ---
2 packets transmitted, 0 received, 100% loss, time 1009ms
[root@nttlab12 init.d]#
**************************************************
[root@obss]# ip -6 addr show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
inet6 ::1/128 scope host
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
inet6 fec0::280:6dff:fe51:356b/73 scope site
inet6 fe80::280:6dff:fe51:356b/64 scope link
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
inet6 fe80::280:6dff:fe51:356c/64 scope link
[root@obss]# ping6 -s 2000 -I eth0 fec0::2d0:b7ff:fe49:db63
PING fec0::2d0:b7ff:fe49:db63(fec0::2d0:b7ff:fe49:db63) from fec0::280:6dff:fe5s2008 bytes from fec0::2d0:b7ff:fe49:db63: icmp_seq=1 ttl=64 time=0.730 ms
2008 bytes from fec0::2d0:b7ff:fe49:db63: icmp_seq=2 ttl=64 time=0.591 ms
--- fec0::2d0:b7ff:fe49:db63 ping statistics ---
2 packets transmitted, 2 received, 0% loss, time 1010ms
rtt min/avg/max/mdev = 0.591/0.660/0.730/0.074 ms
[root@obss]# /usr/sbin/tcpdump -nvvxi eth0 ether proto 0x86dd
device eth0 entered promiscuous mode
tcpdump: listening on eth0
14:20:24.465183 fec0::2d0:b7ff:fe49:db63 > fec0::280:6dff:fe51:356b: frag
(0x00000019:0|1448) icmp6: echo request (len 1456, hlim 64)
6000 0000 05b0 2c40 fec0 0000 0000 0000
02d0 b7ff fe49 db63 fec0 0000 0000 0000
0280 6dff fe51 356b 3a00 0001 0000 0019
8000 7c24 9110 0000 8976 643d 06b0 0800
0809 0a0b 0c0d 0e0f 1011 1213 1415 1617
1819
14:20:24.465220 fec0::2d0:b7ff:fe49:db63 > fec0::280:6dff:fe51:356b: frag
(0x00000019:1448|560) (len 568, hlim 64)
6000 0000 0238 2c40 fec0 0000 0000 0000
02d0 b7ff fe49 db63 fec0 0000 0000 0000
0280 6dff fe51 356b 3a00 05a8 0000 0019
a0a1 a2a3 a4a5 a6a7 a8a9 aaab acad aeaf
b0b1 b2b3 b4b5 b6b7 b8b9 babb bcbd bebf
c0c1
14:20:24.465522 fec0::280:6dff:fe51:356b > fec0::2d0:b7ff:fe49:db63: frag
(0x00000013:0|1448) icmp6: echo reply (len 1456, hlim 64)
6000 0000 05b0 2c40 fec0 0000 0000 0000
0280 6dff fe51 356b fec0 0000 0000 0000
02d0 b7ff fe49 db63 3a00 0001 0000 0013
8100 7b24 9110 0000 8976 643d 06b0 0800
0809 0a0b 0c0d 0e0f 1011 1213 1415 1617
1819
14:20:24.465588 fec0::280:6dff:fe51:356b > fec0::2d0:b7ff:fe49:db63: frag
(0x00000013:1448|560) (len 568, hlim 64)
6000 0000 0238 2c40 fec0 0000 0000 0000
0280 6dff fe51 356b fec0 0000 0000 0000
02d0 b7ff fe49 db63 3a00 05a8 0000 0013
a0a1 a2a3 a4a5 a6a7 a8a9 aaab acad aeaf
b0b1 b2b3 b4b5 b6b7 b8b9 babb bcbd bebf
c0c1
14:20:25.459549 fec0::2d0:b7ff:fe49:db63 > fec0::280:6dff:fe51:356b: frag
(0x0000001a:0|1448) icmp6: echo request (len 1456, hlim 64)
6000 0000 05b0 2c40 fec0 0000 0000 0000
02d0 b7ff fe49 db63 fec0 0000 0000 0000
0280 6dff fe51 356b 3a00 0001 0000 001a
8000 383c 9110 0100 8a76 643d 4898 0800
0809 0a0b 0c0d 0e0f 1011 1213 1415 1617
1819
[root@obss]#
-------------------------------------------------------------------------
Any clues? Just a wild guess.... Could it be some problem with the device
driver support?
regards
Madhavi.
On Thu, 22 Aug 2002, Matthew Luckie wrote:
> > When ping6 works perfectly fine for small packets, why does it fail for
> > large packets. And why does it fail in only one direction?
> >
> > The interface types I have been using are EtherExpressPro/100 (This is on
> > the machine on which ping6 for large packets is failing) and DECchip Tulip
> > (dc21x4x).
> >
> > Am I missing some configuration or something? Could someone help?
>
> hosts have to do path-MTU discovery and fragment their packets to the
> correct size before they are sent. one host is probably doing it
> correctly while the other one isn't.
>
> what does tcpdump tell you?
>
> $ sudo tcpdump -i fxp0 host fec0::1
> tcpdump: listening on fxp0
> 16:42:33.894601 fec0::2 > fec0::1: frag (0|1448) icmp6: echo request
> 16:42:33.894609 fec0::2 > fec0::1: frag (1448|60)
> 16:42:33.895259 fec0::1 > fec0::2: frag (0|1448) icmp6: echo reply
> 16:42:33.895266 fec0::1 > fec0::2: frag (1448|60)
>
> replace fxp0 with the name of your interface on both machines and see
> what you can see. note that this output is on a freebsd machine, you
> should see something similar with linux
>
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
