lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 13 Nov 2008 13:48:14 +0200
From:	Sami Farin <safari-kernel@...ari.iki.fi>
To:	Linux Networking Mailing List <netdev@...r.kernel.org>
Subject: Re: Linux 2.6.27.5 / SFQ/HTB scheduling problems

On Thu, Nov 13, 2008 at 07:15:43 +0000, Jarek Poplawski wrote:
> On 11-11-2008 22:47, Sami Farin wrote:
> ...
> > When 2.6.27.5 was sending:
> > 
> > 2008-11-11T21:16:13.488287Z IP (tos 0x0, ttl 255, id 10323, offset 0, flags [none], proto TCP (6), length 7152) 80.223.84.180.40449 > 74.54.226.166.80: ., cksum 0xee52 (incorrect (-> 0x96a4), 4123538094:4123545194(7100) ack 1017886112 win 710 <nop,nop,timestamp 418352 372760162>
> > 2008-11-11T21:16:13.620018Z IP (tos 0x0, ttl 255, id 10328, offset 0, flags [none], proto TCP (6), length 7152) 80.223.84.180.40449 > 74.54.226.166.80: ., cksum 0xee52 (incorrect (-> 0xf1d0), 4123545194:4123552294(7100) ack 1017886112 win 710 <nop,nop,timestamp 418458 372760270>
> > 2008-11-11T21:16:13.751751Z IP (tos 0x0, ttl 255, id 10333, offset 0, flags [none], proto TCP (6), length 7152) 80.223.84.180.40449 > 74.54.226.166.80: ., cksum 0xee52 (incorrect (-> 0xc685), 4123552294:4123559394(7100) ack 1017886112 win 710 <nop,nop,timestamp 418562 372760374>
> > 
> > I noticed it's 7152 bytes a packet!
> > Is this a new trick in 2.6.27 or 2.6.26?
> > But:
> > <3>[ 1583.914947] 0000:00:19.0: eth0: Jumbo Frames not supported.
> > 
> 
> Could you check for TSO (and maybe turn this off) with ethtool?

It was off:

# ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: off
tx-checksumming: off
scatter-gather: off
tcp segmentation offload: off

Sometimes I am also sending over 15000 byte packets according to
tcpdump.  What I'd like to know is:
1) How can I get tcpdump to show the actual packets I am sending,
   without needing to buy another computer for sniffing the packets?
2) What does it really mean when 15000 byte packet is sent?
   Can other packets be queued normally "in between" or am I doomed
   to 250 ms latency, if I happen to e.g. ping one microsecond after
   the first of these packets is being sent?
   Or are many packets of the same stream just coalesced into one
   bigger, if there are no other packets from other streams in
   between, so that is looks neater when tcpdump is used?

P.S. google does not add References header field so scoring does
not work very well :(

-- 
Do what you love because life is too short for anything else.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists