On Wed, 14 Aug 2002, David Woodhouse wrote:
> > 20:45:55.253738 209.45.208.4.smtp > 12.155.196.8.28253: P 229:285(56) ack
> > 80 win 5840 (DF) (ttl 64, id 49196, len 96)
> > 0x0000 4500 0060 c02c 4000 4006 0896 d12d d004 E..`.,@.@....-..
> > 0x0010 0c9b c408 0019 6e5d 75b4 ec3f 02b9 ac85 ......n]u..?....
> > 0x0020 5018 16d0 18d5 0000 3335 3420 456e 7465 P.......354.Ente
> > 0x0030 7220 6d65 7373 6167 652c 2065 6e64 696e r.message,.endin
> > 0x0040 6720 7769 7468 2022 2e22 206f 6e20 6120 g.with.".".on.a.
> > 0x0050 6c69 li
>
> Er, there ain't 56 bytes of data there. There are only 42. There _should_
> be 56 though. Note also the absence of the text '[tcp sum ok]'. Where are
> these tcpdumps taken? On the offending server box or elsewhere on the same
> network segment?
This was taken on the mail server itself.
> Network driver problems, perhaps? What OS/version/NIC etc.? (Sorry, I
> missed the beginning of the thread).
I was told this was just happening to the ISP's DSL customers (and this
weeks logs show 2557 of these timeouts for that one network vs. only 172
timeouts from elsewhere). I am assuming that the network issue is
elsewhere since these timeouts are only for a small portion of mail
activity.
This is Red Hat Linux 7.2 and 2.4.7-10enterprise #1 SMP (only one
processor used) with exim-3.22-14.1 RPM. ifconfig and /proc/net/dev show
zero collisions and zero errors for the:
8139too Fast Ethernet driver 0.9.18a
eth0: RealTek RTL8139 Fast Ethernet at 0xe08f1e00, xx:xx:xx:xx:xx:xx, IRQ 11
eth0: Identified 8139 chip type 'RTL-8139C'
eth0: Setting 100mbps full-duplex based on auto-negotiated partner ability 45e1.
Thanks again David,
Jeremy C. Reed
http://www.isp-faq.com/ -- find answers to your questions
