I have found the following problem with 2.6.0-test9-bk13 on sparc64: We do traceroute6 to 3ffe:80ee:3bd:0:a00:20ff:fec7:a192 (IP of that sparc64). We get the following corrupted answer: 13:17:47.191
This may be related to the problem (on sparc64): traceroute to 3ffe:80ee:3bd:0:a00:20ff:fec7:a192 (3ffe:80ee:3bd:0:a00:20ff:fec7:a192) from ::1, 30 hops max, 24 byte packets Bus error 3ffe:80ee:3bd:0
And another observation is that on 2.6.0-test9-bk4 on Opteron x86_64 when I The kernel crashs. I will have kernel OOPS output tommorow (the box is located in office)
A colleague of mine has Opteron at home, he tried traceroute6 ::1 on 2.6.0-test9-bk4, here is the kernel output: RDX: 0000000000000048 RSI: 000001001ec06048 RDI: 000001011ec06218 RBP: 000000000000004
What specifically about this packet makes you think it is corrupted? Let's look at the ICMP header you say is "correct" from the x86 box: type = ICMPV6_DEST_UNREACH code = ICMPV6_PORT_UNREACH In the
0x0030- should be the copy of the original packet. it is corrupted. -- Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@xxxxxxxxxxxxxx> GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
The ICMP reply should contain the original packet. 3.3.2 I am running 64-bit-only userspace and there is no gdb/strace for sparc64 yet :(. But I think I have found the problem: icmpv6_send() can get
Yes there is a gdb, here is a prebuilt 64-bit gdb for you. It is even statically linked so there are no shared library dependencies. It can debug 32-bit processes as well: ftp://pizda.ninka.net/pub/f
All of the __skb_{push,pull}() modifications made by icmpv6_send() are illegal. The SKB could be cloned and being inspected by other entities in the networking, therefore moving the pointers around c
OK, I like your patch more. You have forgot to decrease 'len' by msg.offset here: I've fixed that and tested, here is a working patch: -- linux/net/ipv6/icmp.c.orig 2003-11-12 16:02:23.000000000 +01
Hello, I have found the following problem with 2.6.0-test9-bk13 on sparc64: We do traceroute6 to 3ffe:80ee:3bd:0:a00:20ff:fec7:a192 (IP of that sparc64). We get the following corrupted answer: 13:17:
This may be related to the problem (on sparc64): traceroute to 3ffe:80ee:3bd:0:a00:20ff:fec7:a192 (3ffe:80ee:3bd:0:a00:20ff:fec7:a192) from ::1, 30 hops max, 24 byte packets Bus error 3ffe:80ee:3bd:0
And another observation is that on 2.6.0-test9-bk4 on Opteron x86_64 when I do: The kernel crashs. I will have kernel OOPS output tommorow (the box is located in office)
A colleague of mine has Opteron at home, he tried traceroute6 ::1 on 2.6.0-test9-bk4, here is the kernel output: RDX: 0000000000000048 RSI: 000001001ec06048 RDI: 000001011ec06218 RBP: 000000000000004
What specifically about this packet makes you think it is corrupted? Let's look at the ICMP header you say is "correct" from the x86 box: type = ICMPV6_DEST_UNREACH code = ICMPV6_PORT_UNREACH In the
0x0030- should be the copy of the original packet. it is corrupted. -- Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@xxxxxxxxxxxxxx> GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
The ICMP reply should contain the original packet. 3.3.2 I am running 64-bit-only userspace and there is no gdb/strace for sparc64 yet :(. But I think I have found the problem: icmpv6_send() can get
Yes there is a gdb, here is a prebuilt 64-bit gdb for you. It is even statically linked so there are no shared library dependencies. It can debug 32-bit processes as well: ftp://pizda.ninka.net/pub/f