Date: Thu, 20 Feb 2003 14:31:02 -0600 From: "Nick H. -- Technical Support Engineer" <nickh@supportteam.net> To: <freebsd-current@FreeBSD.ORG> Subject: Re: Ethernet (xl) will not transmit or receive Message-ID: <002001c2d91e$fcb546a0$0402a8c0@dotnet> References: <20030220161905.BBA6D5D04@ptavv.es.net> <Pine.NEB.3.96L.1030220113026.8683A-100000@fledge.watson.org> <20030220184417.GA3743@physik.TU-Berlin.DE>
next in thread | previous in thread | raw e-mail | index | archive | help
Ive run into the exact same problem on about 8 machines now, all running different network cards. The network will just simply not work if I have IPFILTER built into the kernel. On some of the machines, I started getting "No route to host". This has happened on the following network cards: 3COM 3C905C 3COM 3C450 *yes, 450* Linksys LNE100TX v4 Linksys LNE100TX v5 NETGEAR Fast 100 Intel Pro 10/100+ Intel Pro 10/100/1000 (gigabit over copper) Im going to assume that since it's not on a specific card, it's not something with the drivers for that card. The only thing I could do was deinstall IPFILTER. I tried wiping the ARP tables (showed incomplete arp entries for all hosts) and even redoing the routing table. The only thing that I could get that would fix it was removing ipfiter. I have another 5.0-CURRENT machine (FreeBSD 5.0-CURRENT #2: Wed Jan 29 17:55:34 CST 2003 root@edge:/usr/obj/usr/src/sys/edge i386) that is NOT having this problem. It's something done fairly recently that has caused this. Im going to go through and see if I cant find some differences between the source for that version and this one: 5.0-CURRENT #1: Wed Feb 19 10:28:49 GMT 2003 root@ender:/usr/obj/usr/src/sys/ender i386 The second one (last one I gave uname for) is the most recent to have the problems. As you can see, it's source from earlier this week. There's no errors on dmesg nor are there any errors anywhere. It just seems that if IPFILTER is enabled, the network devices are completely inoperable. I know you're going to ask how I have the rules setup, and I have tried many variations. The first I tried is a DEFAULT_BLOCK using a working ruleset from a 4.7-R-p3 machine. After that failed, I tried doing a default allow, and it still did it. The only feasible way to get the machine online with that source is to rip out IPFILTER. Anyone having similiar issues? Any comments/suggestions would be more than welcome, as having boxes on the network with no firewall is just asking for trouble ;) Regards, Nick H. nickh@supportteam.net ----- Original Message ----- From: "Jan Schlesner" <jschlesn@physik.TU-Berlin.DE> To: <freebsd-current@FreeBSD.ORG> Sent: Thursday, February 20, 2003 12:44 PM Subject: Re: Ethernet (xl) will not transmit or receive : Hi, : : On Thu, Feb 20, 2003 at 11:32:04AM -0500, Andrew R. Reiter wrote: : > I experienced similar issues yesterday when just installing release 5 from : > ftp (floppy boot). I essentially had to ifconfig the device down and then : > back up and it then seemed to continue ok... but I think there most likely : > something odd going on :/ : > : > On Thu, 20 Feb 2003, Kevin Oberman wrote: : > :I updated my 5.0 system built in late January to RELENG_5_0 on Sunday : > :and the Ethernet was not working. I tried again last night with no : > :change in behavior. : > : : > :The system is an AMD K6-2 on an ASUS P5A mobo. I have a 3Com 3c905B : > :Ethernet which had been working fine on a kernel built in late : > :January. : > : : > :The dmesg is not too meaningful, but the system shows no errors. It : > :simply never receives a packet. ARPs are all incomplete and no packets : > :are transmitted although netstat -in indicates that they are. The : > :packets never actually reach the wire, though. : > : : > :I can't believe that no one else has this card, but I didn't find : > :anything in the archives on it. : > : : > :Any idea what needs to be rolled back and how far? I'm suspicious that : > :it might be an mii problem. Maybe even an interrupt issue. I an : > :suspicious of the second, empty xlphy0: line in the dmesg, but the : > :reported MAC is right and my old kernel that works seems to generate a : > :similar empty line. : : I have had the same problem with a "3Com 3c905B-COMBO". But the system : was a 4.7-RELEASE. If you used the the media-Option in /etc/rc.conf it : doesn't work. It was necessary to boot the system with a wrong media : type, mark the interface down and mark the interface up with the correct : media type. Than it works. But at that time I had no time to analyse : this behaviour. : : Jan : : Here are the old boot messages (no errors): : : FreeBSD 4.7-RELEASE #0: Wed Oct 9 15:08:34 GMT 2002 : Copyright (c) 1992-2002 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 4.7-RELEASE #0: Wed Oct 9 15:08:34 GMT 2002 : root@builder.freebsdmall.com:/usr/obj/usr/src/sys/GENERIC : Timecounter "i8254" frequency 1193182 Hz : CPU: AMD Duron(tm) Processor (756.74-MHz 686-class CPU) : Origin = "AuthenticAMD" Id = 0x631 Stepping = 1 : Features=0x183f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV, PAT,PSE36,MMX,FXSR> : AMD Features=0xc0440000<<b18>,AMIE,DSP,3DNow!> : real memory = 134135808 (130992K bytes) : avail memory = 125349888 (122412K bytes) : Preloaded elf kernel "kernel" at 0xc050f000. : Preloaded userconfig_script "/boot/kernel.conf" at 0xc050f09c. : Pentium Pro MTRR support enabled : md0: Malloc disk : Using $PIR table, 9 entries at 0xc00f1720 : npx0: <math processor> on motherboard : npx0: INT 16 interface : pcib0: <Host to PCI bridge> on motherboard : pci0: <PCI bus> on pcib0 : pcib2: <VIA 8363 (Apollo KT133) PCI-PCI (AGP) bridge> at device 1.0 on pci0 : pci1: <PCI bus> on pcib2 : pci1: <ATI Mach64-GM graphics accelerator> at 0.0 irq 11 : isab0: <VIA 82C686 PCI-ISA brid/ge> at device 4.0 on pci0 : isa0: <ISA bus> on isab0 : atapci0: <VIA 82C686 ATA66 controller> port 0xb800-0xb80f at device 4.1 on pci0 : ata0: at 0x1f0 irq 14 on atapci0 : ata1: at 0x170 irq 15 on atapci0 : uhci0: <VIA 83C572 USB controller> port 0xb400-0xb41f irq 9 at device 4.2 on pci0 : usb0: <VIA 83C572 USB controller> on uhci0 : usb0: USB revision 1.0 : uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 : uhub0: 2 ports with 2 removable, self powered : uhci1: <VIA 83C572 USB controller> port 0xb000-0xb01f irq 9 at device 4.3 on pci0 : usb1: <VIA 83C572 USB controller> on uhci1 : usb1: USB revision 1.0 : uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 : uhub1: 2 ports with 2 removable, self powered : uhub2: ALCOR Generic USB Hub, class 9/0, rev 1.10/1.00, addr 2 : uhub2: 4 ports with 4 removable, self powered : pci0: <unknown card> (vendor=0x1106, dev=0x3057) at 4.4 : xl0: <3Com 3c905B-COMBO Fast Etherlink XL> port 0x9400-0x947f mem 0xdd000000-0xdd00007f irq 5 at device 10.0 on pci0 : xl0: Ethernet address: 00:01:02:2f:42:0a : miibus0: <MII bus> on xl0 : xlphy0: <3Com internal media interface> on miibus0 : xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto : atapci1: <Promise ATA100 controller> port 0x7800-0x783f,0x8000-0x8003,0x8400-0x8407,0x8800-0x8803,0x9000-0x9007 mem 0xdc800000-0xdc81ffff irq 10 at device 17.0 on pci0 : ata2: at 0x9000 on atapci1 : ata3: at 0x8400 on atapci1 : pcib1: <Host to PCI bridge> on motherboard : pci2: <PCI bus> on pcib1 : orm0: <Option ROMs> at iomem 0xc0000-0xc97ff,0xcc000-0xcffff,0xd0000-0xd1fff on isa0 : fdc0: <NEC 72065B or clone> 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 : atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0 : atkbd0: <AT Keyboard> flags 0x1 irq 1 on atkbdc0 : kbd0 at atkbd0 : psm0: <PS/2 Mouse> irq 12 on atkbdc0 : psm0: model Generic PS/2 mouse, device ID 0 : vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 : sc0: <System console> 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 : ... : : : -- : [ gpg key: http://nl3.physik.tu-berlin.de/~jan/jschlesn.gpg ] : [ key fingerprint: 4236 3497 C4CF 4F3A 274F B6E2 C4F6 B639 1DF4 CF0A ] : -- : It's better to reign in hell, : than to serve in heaven... : : To Unsubscribe: send mail to majordomo@FreeBSD.org : with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?002001c2d91e$fcb546a0$0402a8c0>