EEPRO100 geladen und konfiguriert, aber kein Netz

[hacman]

Moin,
ich hab hier ne Kiste mir nem interessanten Fehler:
Ich will den Rechner auf 2.6.8.1 updaten. Aber nach dem Reboot laufen die Netzwerkkarten nicht mehr.
Der alte Kernel ist ein selbstkompilierter 2.4.22, der neue wie gesagt ein 2.6.8.1.
Die Karten sind Intel EE Pro 100

Code: Alles auswählen

lspci
0000:01:00.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08)
0000:01:02.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08)

Geladene Module: mii und eepro100, sonst nix.
Keine Iptables Regeln.

Nach einem Reboot in den neuen Kernel scheint alles richtig zu sein, dmesg gibt auch nix her:

Code: Alles auswählen

Sep  3 12:57:24 altf4 kernel: eepro100.c:v1.09j-t 9/29/99 Donald Becker http://www.scyld.com/network/eepro100.html
Sep  3 12:57:24 altf4 kernel: eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin <saw@saw.sw.
com.sg> and others
Sep  3 12:57:24 altf4 kernel: PCI: Found IRQ 11 for device 0000:01:00.0
Sep  3 12:57:24 altf4 kernel: PCI: Sharing IRQ 11 with 0000:00:02.0
Sep  3 12:57:24 altf4 kernel: eth0: 0000:01:00.0, 00:02:B3:21:07:6C, IRQ 11.
Sep  3 12:57:24 altf4 kernel:   Board assembly 721383-016, Physical connectors present: RJ45
Sep  3 12:57:24 altf4 kernel:   Primary interface chip i82555 PHY #1.
Sep  3 12:57:24 altf4 kernel:   General self-test: passed.
Sep  3 12:57:24 altf4 kernel:   Serial sub-system self-test: passed.
Sep  3 12:57:24 altf4 kernel:   Internal registers self-test: passed.
Sep  3 12:57:24 altf4 kernel:   ROM checksum self-test: passed (0x04f4518b).
Sep  3 12:57:24 altf4 kernel: PCI: Found IRQ 5 for device 0000:01:02.0
Sep  3 12:57:24 altf4 kernel: eth1: 0000:01:02.0, 00:02:B3:21:09:AC, IRQ 5.
Sep  3 12:57:24 altf4 kernel:   Board assembly 721383-016, Physical connectors present: RJ45
Sep  3 12:57:24 altf4 kernel:   Primary interface chip i82555 PHY #1.
Sep  3 12:57:24 altf4 kernel:   General self-test: passed.
Sep  3 12:57:24 altf4 kernel:   Serial sub-system self-test: passed.
Sep  3 12:57:24 altf4 kernel:   Internal registers self-test: passed.
Sep  3 12:57:24 altf4 kernel:   ROM checksum self-test: passed (0x04f4518b).

ifconfig gibt die Interfaces ganz normal an, route ist völlig ok, nur es kommen halt keine Packete durch.

Hat irgendwer schonmal davon gehört? Ich bin dankbar für jeden Tip.

[b a r t]

wie ist deine Anbindung ins internet, eigener router? oder dhcp vom ISP?

wenn du eine fixe adresse hast ist alles ok oder (nach deinem beschreib)?

ich habe andere probleme teilweise mit ISPs wenn ich releases hollen will.

b a r t

[hacman]

Ist ne fixe Adresse. Aber es geht trotzdem nicht...

[b a r t]

kannst du dir keine adresse geben?

wird die nicht übernommen / wird sie nicht angezeigt?

hast du eine, doch sie geht nicht?

kannst du den localhost pingen?

hast du traffic auf der karte? (siehe ifconfig)

oder kommt die karte erst gar nicht hoch?

poste doch mal dein ifconfig hier her

gruss

b a r t

[hacman]

Werd ich machen. Das geht aber erst, wenn ich am Montag in der Firma vor der Kiste sitze. Sonst reboote ich den von hier und komm nicht mehr drauf...
gruß, hacman

[hacman]

Hier also das Ergebnis von ifconfig:

Code: Alles auswählen

eth0      Link encap:Ethernet  HWaddr 00:02:B3:21:07:6C
          inet addr:172.16.100.24  Bcast:172.16.100.127  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:120 (120.0 b)  TX bytes:630 (630.0 b)
          Interrupt:11 Base address:0xa000

eth1      Link encap:Ethernet  HWaddr 00:02:B3:21:09:AC
          inet addr:192.168.199.11  Bcast:192.168.199.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:42 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:3558 (3.4 KiB)  TX bytes:0 (0.0 b)
          Interrupt:5 Base address:0xc000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:9 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:950 (950.0 b)  TX bytes:950 (950.0 b)

Und dann nochmal lsmod

Code: Alles auswählen

Module                  Size  Used by
iptable_filter          2144  0
ip_tables              14976  1 iptable_filter
eepro100               26252  0
mii                     3968  1 eepro100

Und zur Sicherheit auch noch das Ergebnis von iptables -L:

Code: Alles auswählen

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Vielleicht kommt Ihr jetzt ja auf ne gute Idee. Bin langsam echt am verzweifeln...

[ckihm.deb]

Erkannt werden deine Karten ja, und sie sind up. Ich gehe mal davon aus das du über eth0 nach draussen willst? Vielleicht liegt es am Routing, denn die eth1 empfängt mehr Pakete. Hast du vielleicht die default route auf eth1 gesetzt?

edit
____
Nachdenk ..., habe das glaube ich gerade falsch gesehen, du sendest beim pingen ja an die Karte, und da kommt bei eth0 ja anscheinend was an. Das scheint also doch ok zu sein

[hacman]

route -n

Code: Alles auswählen

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
172.16.100.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.199.0   0.0.0.0         255.255.255.0   U     0      0        0 eth1
0.0.0.0         172.16.100.126  0.0.0.0         UG    0      0        0 eth0

Nö, nicht wirklich. Ich frag mich langsam, ob es vielleicht am Switch dahinter liegt. Kann aber eigentlich nicht sein, denn dann sollte es ja auchmit dem alten 2.4 nicht gehen. Tut es aber...

[b a r t]

wenn du 2 Karten hast, ist das etwas anderes.
poste dein route file, weil das festlegt, wo was durch geht.

b a r t

[Savar]

also ich hab

lspci

02:0a.0 Network controller: Intel Corp. 82801BD PRO/100 VE (MOB) Ethernet Controller (rev 83)

und seit dem 2.6er kann ich nicht mehr den eepro100 verwenden, sondern muss/kann den "Intel(R) PRO/100+ support" benutzen (Modulname: "e100")

vielleicht ists bei dir ähnlich?

[b a r t]

was für eine funktion hat denn der PC, wie sieht sonst dein Netz aus?

b a r t

[hacman]

Steh gerade auf dem Schlauch. Welches route file?

[hacman]

An Savar:
Laut Kerneldoku ist der Intel 82557 (welcher auf meinen beiden Karten ist) nicht im e100 Modul drin. Glaub ich zwar nicht wirklich, aber der Chip wird nicht explizit gelistet. Während der gute alte Donal Becker Treiber es ja eigentlich tun sollte.
Aber ich werde den e100 doch mal testen müssen...

An bart:
Der PC ist ein Webserver. Steht in ner DMZ mit dem 172. Netz. Das 192. Netz ist ein Backup-Backbone. Nach draußen ist da nur noch ne Nokia Firewall, die auch das NAT macht.

[Savar]

ja aber dein lspic gibt doch:

lspci
0000:01:00.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08)
0000:01:02.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08)

aus... und da sehe ich 82557/8/9... als wüsste lspci nicht genau ob es eine 7 8 oder 9 ist?
oder seh ich das jetzt falsch?

[hacman]

Savar: Stimmt, so könnte man das auch lesen


Also, ich hab es eben mal mit dem e100 Modul getestet. Leider kein Erfolg. Immer noch die gleiche Symptomatik. Es sieht alles richtig aus, nur tun tut er nix...

PS:

[Savar]

hmm.. wenn du beiden Netzwerkkarten IPs im gleichen Netz gibst (ist jetzt mal egal welches), kannst du dann von der einen zu anderen pingen?

was hälst du davon mal per ethereal oder tcpdump nachzuschauen was so übers Netz läuft?

[b a r t]

so viel ich gehört habe, muss man im grub file angeben, das man zwei Karten benutzt.
ich denke nicht das du ein Problem mit de, Chip hast, weil beide konfiguriert sind, und laufen (traffice auf der Karte). Es muss also woanders liegen.

b a r t

[hacman]

Ich hab mit tcpdump schon ein paar mal mitgehört.. Auf dem Rechner selbst scheinen alle Pakete normal abzugehen und nix anzukommen. Auf den anderen Rechnern im Netz ist allerdings überhaupt nix davon zu sehen.

[b a r t]

gibt mal route ein, dann siehst du was rauskommt,
das meine ich.

b a r t