Re: bad tcp cksum fffe!
Dear Giorgos, Thanks for your suggestion! The problem has gone away by backing off to -O1 in kernel and -O2 in userland. Strange, because I have been using -O3 -fomit-frame-pointer for a while now (/usr/share/examples/etc/make.conf notwithstanding) with ill effects. My bad. Sorry, but I can't be more specific on which particular flag or which particular CVS update caused the problem. CPU too slow. Thanks again, -- Chris On Tuesday, Giorgos Keramidas said: > On 2002-05-14 17:39, Cristan Szmajda wrote: > > Dear freebsd-current, > > > > Any suggestions you have regarding this problem would be > > much appreciated. > > > > My laptop running -CURRENT is suddenly generating bad TCP > > checksums when talking to some IPs but not others. For > > example, 129.94.209.220 is a problem, > > > > 17:08:47.026823 129.94.233.200.1032 > 129.94.209.220.22: S > > [bad tcp cksum fffe!] 3868790363:3868790363(0) win 65535 > > > > (DF) (ttl 64, id 347, len 68) > > I've seen this only twice. The first time I was using too funky > optimizations to the CFLAGS of my kernel, and GCC was obviously doing > something wrong with the checksum generation code. If this is the > case, then rebuild your kernel and userland with the suggested > optimizations from /usr/share/examples/etc/make.conf and see if this > fixes things for you. > > The second one was when my tcpdump (and the rest of the userland) was > really VERY out of sync with the running kernel (I had managed to > upgrade only the kernel and tcpdump was probably reading random data > from bpf). But there were other more important things wrong with this > case. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bad tcp cksum fffe!
On 2002-05-14 17:39, Cristan Szmajda wrote: > Dear freebsd-current, > > Any suggestions you have regarding this problem would be > much appreciated. > > My laptop running -CURRENT is suddenly generating bad TCP > checksums when talking to some IPs but not others. For > example, 129.94.209.220 is a problem, > > 17:08:47.026823 129.94.233.200.1032 > 129.94.209.220.22: S > [bad tcp cksum fffe!] 3868790363:3868790363(0) win 65535 > > (DF) (ttl 64, id 347, len 68) I've seen this only twice. The first time I was using too funky optimizations to the CFLAGS of my kernel, and GCC was obviously doing something wrong with the checksum generation code. If this is the case, then rebuild your kernel and userland with the suggested optimizations from /usr/share/examples/etc/make.conf and see if this fixes things for you. The second one was when my tcpdump (and the rest of the userland) was really VERY out of sync with the running kernel (I had managed to upgrade only the kernel and tcpdump was probably reading random data from bpf). But there were other more important things wrong with this case. -- Giorgos Keramidas- http://www.FreeBSD.org [EMAIL PROTECTED] - The Power to Serve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bad tcp cksum fffe!
Cristan Szmajda wrote: > > Dear freebsd-current, > > Any suggestions you have regarding this problem would be > much appreciated. > > My laptop running -CURRENT is suddenly generating bad TCP > checksums when talking to some IPs but not others. For > example, 129.94.209.220 is a problem, What do you mean "suddenly"? If you downgrade, but have all the IP addresses and payloads exactly the same, you don't get the problem? The NAT code is known to use the RFC 1141 rather than RFC 1624 incremental checksum update method, which can result in checksum errors like those you are seeing, as a result of carry underflow screwing up the calculation (the calculation should accumulate the old and new checksum values in different registers, and then combine them only after dealing with carry to get them into 16 bits). I've commented on this before, with patched calculation code. If the problem happens on both the old and the new FreeBSD code, then it's probably that you are going through a NAT. If it happens only on the newer code, then it's something that's changed, and you can use CVS to binary search for the change that caused the problem (8 kernels will find any kernel in the last 8.5 months where a breaking change occurred, if you use a binary search). If it's just the compiler change alone, then it's a deeper problem. It's not like the WaveLAN driver supports checksum offloading, which is the problem du jour for the BCG570x... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
bad tcp cksum fffe!
Dear freebsd-current,
Any suggestions you have regarding this problem would be
much appreciated.
My laptop running -CURRENT is suddenly generating bad TCP
checksums when talking to some IPs but not others. For
example, 129.94.209.220 is a problem,
17:08:47.026823 129.94.233.200.1032 > 129.94.209.220.22: S
[bad tcp cksum fffe!] 3868790363:3868790363(0) win 65535
(DF) (ttl 64, id 347, len 68)
17:08:50.676968 129.94.233.200.1033 > 129.94.173.109.22: S
[bad tcp cksum fffe!] 3810151152:3810151152(0) win 65535
(DF) (ttl 64, id 348, len 68)
but 129.94.242.14 is fine.
17:08:56.686832 129.94.233.200.1034 > 129.94.242.14.22: S
[tcp sum ok] 2395865513:2395865513(0) win 65535
(DF) (ttl 64, id 349, len 68)
17:08:56.689644 129.94.242.14.22 > 129.94.233.200.1034: S
[tcp sum ok] 990076085:990076085(0) ack 2395865514 win 10136
(ttl 254, id 7165, len 60)
17:08:56.689991 129.94.233.200.1034 > 129.94.242.14.22: .
[tcp sum ok] ack 1 win 33304
(DF) (ttl 64, id 350, len 52)
It doesn't matter whether net.inet.tcp.rfc1323 and
net.inet.tcp.rfc1644 are off or on. My dmesg is below.
Thanks,
--
Chris
Copyright (c) 1992-2001 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #24: Tue May 14 15:34:56 EST 2002
cls@oedipus:/usr/src/sys/i386/compile/OEDIPUS
Timecounter "i8254" frequency 1193182 Hz
CPU: Pentium/P55C (quarter-micron) (298.42-MHz 586-class CPU)
Origin = "GenuineIntel" Id = 0x582 Stepping = 2
Features=0x8001bf
real memory = 134152192 (131008K bytes)
avail memory = 126439424 (123476K bytes)
Preloaded elf kernel "kernel" at 0xc040b000.
Intel Pentium detected, installing workaround for F00F bug
Using $PIR table, 4 entries at 0xc00fdf80
apm0: on motherboard
apm0: found APM BIOS v1.2, connected at v1.2
npx0: on motherboard
npx0: INT 16 interface
pcib0: at pcibus 0 on motherboard
pci0: on pcib0
isab0: at device 7.0 on pci0
isa0: on isab0
atapci0: port 0xfcf0-0xfcff at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
uhci0: at device 7.2 on pci0
uhci0: Could not map ports
device_probe_and_attach: uhci0 attach returned 6
pci0: at 7.3 (no driver attached)
pci0: at 8.0 (no driver attached)
pci0: at 9.0 (no driver attached)
pci_cfgintr_unique: hard-routed to irq 9
pci_cfgintr: 0:10 INTA routed to irq 9
pcic0: irq 9 at device 10.0 on pci0
pcic0: PCI Memory allocated: 0x4400
pccard0: on pcic0
orm0: at iomem 0xc-0xcbfff on isa0
atkbdc0: at port 0x60,0x64 on isa0
atkbd0: flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
psm0: irq 12 on atkbdc0
psm0: model VersaPad, device ID 0
fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
pmtimer0 on isa0
ppc0: at port 0x378-0x37f irq 7 on isa0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/8 bytes threshold
lpt0: on ppbus0
lpt0: Interrupt-driven port
ppi0: on ppbus0
sc0: at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0
unknown: can't assign resources
sbc0: at port 0x220-0x22f,0x388-0x38b,0x320-0x321 irq 5 drq 1,5 on isa0
pcm0: on sbc0
midi0: on sbc0
midi1: on sbc0
unknown: can't assign resources
unknown: can't assign resources
unknown: can't assign resources
unknown: can't assign resources
unknown: can't assign resources
IP packet filtering initialized, divert enabled, rule-based forwarding enabled,
default to deny, logging limited to 1000 packets/entry by default
IPv6 packet filtering initialized, logging limited to 1000 packets/entry
IPsec: Initialized Security Association Processing.
ad0: 6194MB [13424/15/63] at ata0-master UDMA33
Mounting root from ufs:/dev/ad0s2a
pccard: card inserted, slot 0
pcic0: Event mask 0x9
wi0 at port 0x240-0x27f irq 9 slot 0 on pccard0
wi0: Ethernet address: 00:02:2d:02:98:7e
wi0: promiscuous mode enabled
wi0: promiscuous mode disabled
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
