Summary: | 2.4.20-gentoo-r5 never sees SYN/ACK for SYN it sent | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | seatec-astronomy |
Component: | [OLD] Core system | Assignee: | x86-kernel (DEPRECATED) <x86-kernel> |
Status: | VERIFIED WORKSFORME | ||
Severity: | blocker | CC: | steel300 |
Priority: | Highest | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
linux-2.4.20-gentoo-r5 config
linux-2.4.20-gentoo-r5 config Even MORE simple link detection. |
Description
seatec-astronomy
2003-07-30 17:29:13 UTC
Do you get this with -r6? Are you using any netfilter software/firewall/blah, is anything like that enabled/built as modules in your kernel? I know it sounds like, but there was no firewall of any sort in between. The only thing I know is that the machine sent out syns, and never saw the syn/acks that actually came back. I still have that kernel config+src. Right now I'm still using a 2.4.20, but will update these days. So I didn't test -r6 yet. CONFIG_NETFILTER and CONFIG_FILTER was not enabled in the config. My NIC is an onboard gbit ethernet. Maybe there's a problem with the driver implementation? which nic are you using? how about a kernel .config and relevant system info. Thanks, Jay Created attachment 17480 [details]
linux-2.4.20-gentoo-r5 config
Created attachment 17481 [details]
linux-2.4.20-gentoo-r5 config
Argh. Had problems attaching the file. Bugzilla gave me an error msg. :} The nic is an onboard chip, a 3com 3c940. It's a gbit ethernet chip. The system is an iP4-2.8 ghz northwood. The board is an Asus P4C800 Deluxe. The machine has 512 MB Infineon RAM. bash-2.05b$ uname -a Linux IceDragon 2.4.20-gentoo-r7 #1 Fri Sep 19 15:11:45 CEST 2003 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz GenuineIntel GNU/Linux I recompiled my kernel tonight, after running a vanilla 2.4.18 for weeks. I'm experiencing the same problems as with gentoo-r5 with gentoo-r7 now, only that it's even more bizarre. While I'm able to connect to most hosts, www.heise.de, www.google.com and many others just don't work. The symptoms are the same. I see the syn from my host, I sniff the router(some suse) and see the syn/ack coming back from the host(f.ex. www.google.com), but the sniffer running on gentoo-r7 never sees that syn/ack coming in. This is _not_ an application problem. I tried it with different browsers and the telnet client. They work fine. They do what they're supposed to do: send out a syn and wait for the reply to complete the handshake. The reply just never reaches them. My MTU is 1500. So whats wrong? Do you want that Kernel config too? the gigE driver you are using is the sk98lin? have you been able to reproduce this with another nic or with a different kernel version? I'd be interested to see how a vanilla 2.4.22 treats you. yes I'm using the sk98lin driver that came with the kernel(I didn't patch myself). I'll try a vanilla 2.4.22 as soon as I find time, prolly sunday, else monday. I do not have any otehr nic in that machine. As I said vanilla 2.4.18 worked without any problems. Okay: This probably is a gentoo-sources problem and it looks like somebody did a messy backport in <= -r5... Can you: modify the patches-.... archive for the gentoo-sources, get rid of the "sk98lin" file, run "ebuild /usr/portage/sys-kernel/gentoo-sources/gentoo-sources-2.4.20-r7.ebuild digest" and remerge gentoo-sources... * ping * -> see comment #10 sorry was pretty busy lately. did you see that I had the same problem with r7? r7 was not patched by me(iirc, may be wrong). I think it already contained that sk98lin driver. so now what? Yes, -r7 contains the driver, so does -r8. I asked whether you could rip it out of the patches-... tarball [it's called sk98lin] and run 'patch' with it, telling it to reverse the patch when asked. Created attachment 20444 [details]
Even MORE simple link detection.
Instead of using mii-tool to get link state, we can re-use the link state
"RUNNING" from ifconfig (which comes from the ioctl SIOCGIFFLAGS, which equates
to the netif_carrier_ok (netdevice.h) from the kernel's net_device struct).
This patch simply augments setup_env() with one more variable.
ahh shit, sorry, I got confused by bugzilla. apologies. Is this still valid? Is the error there anymore? If it's not I'm marking this closed. I can not access the machine till september, and I'm still not running a gentoo kernel on it. So honestly I do not know wether it's fixed or not. Apparently I was the only one reporting this issue? I'd close this case if I were you. Closing. Marking works for me, since this is an isolated incident that noone else could reproduce. Closed. |