[tcpdump-workers] incorrect tcp checksum on Linux tun interfaces?

2012-12-04 Thread Gert Doering
Hi,

I'm a bit irritated by a byproduct of a problem hunt today, incorrect
TCP checksums on a *tun* interface...

23:17:39.862001 IP6 (hlim 64, next-header TCP (6) payload length: 40) 
fd00:abcd:194:7::1.33509 > fd00:abcd:194:7::1000.2: S, cksum 0x6502 (incorrect 
(-> 0x3962), 1541095226:1541095226(0) win 14400 
23:17:39.926409 IP6 (hlim 64, next-header TCP (6) payload length: 20) 
fd00:abcd:194:7::1000.2 > fd00:abcd:194:7::1.33509: R, cksum 0x2cff (correct), 
0:0(0) ack 1541095227 win 0

23:18:14.295000 IP (tos 0x10, ttl 64, id 4904, offset 0, flags [DF], proto TCP 
(6), length 60) 10.194.7.1.52647 > 10.194.7.6.2: S, cksum 0x23b9 (incorrect (-> 
0xd832), 2395069612:2395069612(0) win 14600 
23:18:14.322183 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto TCP 
(6), length 40) 10.194.7.6.2 > 10.194.7.1.52647: R, cksum 0x532d (correct), 
0:0(0) ack 2395069613 win 0

this is "tcpdump -v -s0 -i tun6" on a Linux 3.3.8 kernel.

I'm quite used to see "incorrect" TCP checksums on interfaces that have
hardware TCP checksum offloading (because pcap sees the packet before it's
handed to the hardware for checksumming) - but on a *tun* interface, with
no hardware to actually offload it to?

Is this something new in the way Linux tun operates?

(The tun goes into openvpn, and out of the other side's tun comes a packet
with a perfectly valid TCP checksum, so "what openvpn sees" has the correct
checksum, only "what tcpdum sees" does not)


For the fun of it, I asked "ethtool", and it tells me "no checksum 
offloading"...

gert@gentoo $ ethtool  -k tun6
Offload parameters for tun6:
rx-checksumming: off
tx-checksumming: off
scatter-gather: off
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: off
tx-vlan-offload: off
ntuple-filters: off
receive-hashing: off

... weird.

gert

-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Re: [tcpdump-workers] [Fixed] mcr/tcpdump#14 (master - 27b9548)

2012-12-04 Thread Marc Abramowitz
Ok, have a look at https://github.com/mcr/tcpdump/pull/43

-Marc
http://marc-abramowitz.com
Sent from my iPhone 4S


On Nov 28, 2012, at 2:11 PM, Michael Richardson  wrote:

> 
>> "Marc" == Marc Abramowitz  writes:
>Marc> It wouldn't be hard I think to build libpcap as well. Would
>Marc> you want to 
>Marc> build from the latest source code off GitHub
>Marc> (https://github.com/mcr/libpcap) 
> 
> Yeah. Except for glitches, it's the same anyway.
> 
> -- 
> ]   He who is tired of Weird Al is tired of life!   |  firewalls  
> [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net 
> architect[
> ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device 
> driver[
>   Kyoto Plus: watch the video 
>   then sign the petition. 
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Re: [tcpdump-workers] scan_sys_class_net bug in pcap-linux.c

2012-12-04 Thread Paul Sheer
> > !strcmp(ent->d_name, "bonding_masters")) continue;
>
> No.
>
> That wires in a particular name, and when the *next* weird file gets added
> by some future kernel revision, we won't handle it, and would end up wiring
> in another name, lather, rinse, repeat.
>
> Instead, it should ignore "." and "..", ignore all *plain files* (rather
> than directories), and check whether there's a "subsystem" item underneath
> the item (just in case there are directories, or symlinks that point to
> directories, in there that *don't* correspond to devices, either now or in
> the future).
>
>

Hmmm

i recall on some systems they are symlinks not directories

what about if they don't contain "subsystem" in the future?  or older
kernel versions that don't contain "subsystem" (do they?) ?   or future
versions that add subsystem to bonding_masters?

i agree with the impetus of what you are saying, I just don't know where
one would draw the line as to what CAN change and what CANNOT change

and your line seems just as arbitrary

actually i've had these very similar arguments a few times before --

do you see a general principle?

-paul
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Re: [tcpdump-workers] scan_sys_class_net bug in pcap-linux.c

2012-12-04 Thread Paul Sheer
works for me

-paul



On Mon, Dec 3, 2012 at 3:43 AM, Guy Harris  wrote:
>
> [...]
>
> Well:
>
> [...]
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Re: [tcpdump-workers] incorrect tcp checksum on Linux tun interfaces?

2012-12-04 Thread Michael Richardson

{sorry if I'm a bit tardy at removing the emergency moderation that I
turned on in order to keep junk off the list}

> "Gert" == Gert Doering  writes:
Gert> I'm a bit irritated by a byproduct of a problem hunt today, incorrect
Gert> TCP checksums on a *tun* interface...

Gert> 23:17:39.862001 IP6 (hlim 64, next-header TCP (6) payload length: 40) 
fd00:abcd:194:7::1.33509 > fd00:abcd:194:7::1000.2: S, cksum 0x6502 (incorrect 
(-> 0x3962), 1541095226:1541095226(0) win 14400 

What's curious to me is that the chsum is not zero. If it was being
"offloaded" into a step after the PF_PACKET interface, it would be zero,
right?

Gert> 23:18:14.295000 IP (tos 0x10, ttl 64, id 4904, offset 0, flags [DF], 
proto TCP (6), length 60) 10.194.7.1.52647 > 10.194.7.6.2: S, cksum 0x23b9 
(incorrect (-> 0xd832), 2395069612:2395069612(0) win 14600 

Both for IPv4 and IPv6?

Gert> (The tun goes into openvpn, and out of the other side's tun
Gert> comes a packet 

openvpn does IPv6 now?

I suppose the next step would be to hexdump packets from /dev/net/tun.

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Re: [tcpdump-workers] incorrect tcp checksum on Linux tun interfaces?

2012-12-04 Thread Gert Doering
Hi,

On Tue, Dec 04, 2012 at 11:09:43AM -0500, Michael Richardson wrote:
> {sorry if I'm a bit tardy at removing the emergency moderation that I
> turned on in order to keep junk off the list}

I understand that, which I wasn't bugging anyone about this :-)

> > "Gert" == Gert Doering  writes:
> Gert> I'm a bit irritated by a byproduct of a problem hunt today, 
> incorrect
> Gert> TCP checksums on a *tun* interface...
> 
> Gert> 23:17:39.862001 IP6 (hlim 64, next-header TCP (6) payload length: 
> 40) fd00:abcd:194:7::1.33509 > fd00:abcd:194:7::1000.2: S, cksum 0x6502 
> (incorrect (-> 0x3962), 1541095226:1541095226(0) win 14400  1440,sackOK,timestamp 178211075 0,nop,wscale 6>
> 
> What's curious to me is that the chsum is not zero. If it was being
> "offloaded" into a step after the PF_PACKET interface, it would be zero,
> right?

I'm not sure.  I find this highly irritating, and I'm fairly sure that
*here* are the folks that have seen all the funnies when tcpdumping on
specific interfaces...

> Gert> 23:18:14.295000 IP (tos 0x10, ttl 64, id 4904, offset 0, flags 
> [DF], proto TCP (6), length 60) 10.194.7.1.52647 > 10.194.7.6.2: S, cksum 
> 0x23b9 (incorrect (-> 0xd832), 2395069612:2395069612(0) win 14600  1460,sackOK,timestamp 178245508 0,nop,wscale 6>
> 
> Both for IPv4 and IPv6?

Yes.

> Gert> (The tun goes into openvpn, and out of the other side's tun
> Gert> comes a packet 
> 
> openvpn does IPv6 now?

For point-to-point links, it did for a long time (but you had to set it
up manually on both ends).  For multipoint setups with a "server" that
assigns IPv6 addresses etc., this is new functionality in 2.3, to be 
released "real soon now".

> I suppose the next step would be to hexdump packets from /dev/net/tun.

I can try to do that, but I'm fairly sure that the packet is fine when it
really arrives "at the tun interface" - after all, it's coming *out* of 
the server side tun with a correct checksum:

Client tun (kernel->tun->openvpn):

23:03:32.016262 IP (tos 0x10, ttl 64, id 15966, offset 0, flags [DF], proto TCP 
(6), length 60)
10.194.7.6.42707 > 10.194.7.1.2: Flags [S], cksum 0x23b9 (incorrect -> 
0x0ff4), seq 3558498516, win 14600, options [mss 1460,sackOK,TS val 2703974026 
ecr 0,nop,wscale 6], length 0
23:03:33.264096 IP6 (hlim 64, next-header TCP (6) payload length: 40) 
fd00:abcd:194:7::1000.33677 > fd00:abcd:194:7::1.2: Flags [S], cksum 0x6502 
(incorrect -> 0x4150), seq 1568376760, win 14400, options [mss 1440,sackOK,TS 
val 2703974338 ecr 0,nop,wscale 6], length 0


Server tun (openvpn->tun->kernel), same two packets:

23:07:08.409938 IP (tos 0x10, ttl 64, id 15966, offset 0, flags [DF], proto TCP 
(6), length 60) 10.194.7.6.42707 > 10.194.7.1.2: S, cksum 0x104f (correct), 
3558498516:3558498516(0) win 14600 
23:07:09.642172 IP6 (hlim 64, next-header TCP (6) payload length: 40) 
fd00:abcd:194:7::1000.33677 > fd00:abcd:194:7::1.2: S, cksum 0x4150 (correct), 
1568376760:1568376760(0) win 14400 

(for the SYN-ACK, the "incorrect" bit is on the other end, so this is 
symmetric)

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers