[linux] NIC doet het niet

Pagina: 1
Acties:

  • RemcoX
  • Registratie: Mei 2000
  • Laatst online: 14-02 20:05
Ik heb hier RH 7.1 op een bak geinstalleerd, met 2 NIC's erin. Een 3C900 en een 3C509b (ja hoor ;) ). Nu lijkt alles prima te werken als ik het netwerk up breng. Er hang dus niets, ifconfig en routing table zien er goed uit enzo (volgens mij dan). De 3C900 werkt ook perfect, maar die 3C509b doet niet veel. Al ik probeer te pingen krijg ik een 'Destination Host Unreachable'.

Aan het kaartje zal zal het niet liggen, want die heeft voorheen prima gewerkt. (In Windows weliswaar.) Iemand suggesties om het werkende te krijgen :?

Voor de volledigheid:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
[root@michael ~]# ifconfig
eth0    Link encap:Ethernet  HWaddr 00:60:97:80:D6:C4
        inet addr:192.168.0.3  Bcast:192.168.0.255  Mask:255.255.255.0
        UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
        RX packets:63 errors:0 dropped:0 overruns:0 frame:0
        TX packets:41 errors:0 dropped:0 overruns:0 carrier:0
        collisions:0 txqueuelen:100
        Interrupt:11 Base address:0xfe80

eth1    Link encap:Ethernet  HWaddr 00:50:04:2D:36:AF
        inet addr:192.168.1.8  Bcast:192.168.1.255  Mask:255.255.255.0
        UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
        RX packets:90 errors:0 dropped:0 overruns:0 frame:0
        TX packets:81 errors:0 dropped:0 overruns:0 carrier:0
        collisions:0 txqueuelen:100
        Interrupt:5 Base address:0x220

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:45 errors:0 dropped:0 overruns:0 frame:0
        TX packets:45 errors:0 dropped:0 overruns:0 carrier:0
        collisions:0 txqueuelen:0

[root@michael ~]# route
Kernel IP routing table
Destination     Gateway    Genmask     Flags Metric Ref    Use Iface
192.168.1.0     *          255.255.255.0   U     0  0     0 eth1
192.168.0.0     *          255.255.255.0   U     0  0     0 eth0
127.0.0.0    *         255.0.0.0     U     0    0     0 lo
default    oversight     0.0.0.0       UG    0  0     0 eth0

[root@michael ~]# ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) from 192.168.0.3 : 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=0 ttl=128 time=5.316 msec

[root@michael ~]# ping 192.168.1.6
PING 192.168.1.6 (192.168.1.6) from 192.168.1.8 : 56(84) bytes of data.
From 192.168.1.8: Destination Host Unreachable

  • Wilke
  • Registratie: December 2000
  • Laatst online: 13:11
Ik kan zo snel niet bedenken wat het is - de I/O-ranges en IRQ's zijn verschillend, dus dat zit in ieder geval wel goed.

Misschien doet de 0.*-range het wel omdat dat de default-route is?

Dus dat in plaats van de 1e route uit het lijstje de laatste wordt gekozen (ook dat verkeer gaat nl. naar eth0) - dat zou verklaren waarom pingen naar 192.168.0.* wel lukt en naar 192.168.1.* niet.

Omdat de regels verder exact gelijk zijn moet het haast wel zoiets stoms zijn, maar ik zie niet wat er mis mee kan zijn...

  • Wilke
  • Registratie: December 2000
  • Laatst online: 13:11
Mijn routing-tabel ziet er zo uit:
code:
1
2
3
4
5
Kernel IP routing table
Destination     Gateway    Genmask     Flags Metric Ref    Use Iface
130.89.0.0  0.0.0.0    255.255.0.0     U     0  0     0 eth0
127.0.0.0    0.0.0.0       255.0.0.0     U     0    0     0 lo
0.0.0.0    130.89.1.1   0.0.0.0    UG    1  0     0 eth0

[Edit: n/m er is geen enkel wezenlijk verschil te zien met jouw routing tabel behalve het aantal netwerkkaarten dan]

  • RemcoX
  • Registratie: Mei 2000
  • Laatst online: 14-02 20:05
Op donderdag 09 augustus 2001 18:34 schreef Wilke het volgende:
Misschien doet de 0.*-range het wel omdat dat de default-route is?

Dus dat in plaats van de 1e route uit het lijstje de laatste wordt gekozen (ook dat verkeer gaat nl. naar eth0) - dat zou verklaren waarom pingen naar 192.168.0.* wel lukt en naar 192.168.1.* niet.
Ik snap niet helemaal wat je bedoelt, maar volgens mij weerlegt dit feit je veronderstelling:

Ik kan vanuit een pc uit de 192.168.1.* range 192.168.1.8 ook NIET pingen.

Verwijderd

Op donderdag 09 augustus 2001 18:15 schreef RemcoX het volgende:
code:
1
2
3
4
5
6
7
[root@michael ~]# route
Kernel IP routing table
Destination     Gateway    Genmask     Flags Metric Ref    Use Iface
192.168.1.0     *          255.255.255.0   U     0  0     0 eth1
192.168.0.0     *          255.255.255.0   U     0  0     0 eth0
127.0.0.0    *         255.0.0.0     U     0    0     0 lo
default    oversight     0.0.0.0       UG    0  0     0 eth0
Zie ik het nou verkeerd of gebruiken beiden nic`s dezelfde gateway? (sterretje?) Als dat zo is dan gaat het volgens mij verkeerd.... toch :?

Het kan ook aan mijn gebrekkige netwerkkennis liggen... ;)

Verwijderd

is die eene toevallig geen isa kaartje, die dus niet pnp is onder redhat, waardoor je hem zelf moet toevoegen (dat had ik zelf namelijk met 6.2 )

/edit/


mijn routing is zo
code:
1
2
3
4
5
6
7
8
Kernel IP routing table
Destination     Gateway    Genmask     Flags Metric Ref    Use Iface
90.0.0.90    *         255.255.255.255 UH    0  0     0 eth1
qn-212-127-175- *          255.255.255.255 UH    0  0     0 eth0
90.0.0.0      *        255.255.255.0   U     0  0     0 eth1
212.127.175.0   *          255.255.255.0   U     0  0     0 eth0
127.0.0.0    *         255.0.0.0     U     0    0     0 lo
default    qn-212-127-175- 0.0.0.0     UG    0  0     0 eth0

  • Wilke
  • Registratie: December 2000
  • Laatst online: 13:11
Waarschijnlijk is het inderdaad toch iets met het kaartje zelf en is de driver niet goed geladen ofzo. Staat er niks boeiends in de log (/var/log/messages bv.) ?

Dat * bij gateway klopt wel hoor..

Voor pingen is het nodig dat de computer die je pingt antwoord geeft - als je een andere computer niet kunt pingen is dit vrijwel altijd wederzijds (anders zijn er echt HELE vage dingen aan de hand met je verbinding!).

Dus dat je niet vanaf een andere computer in de 192.168.1.* range de computer kunt pingen waar het hier om gaat zegt volgens mij niet zo erg veel.

Weet je zeker dat de IRQ/IO-adressen kloppen met eventuele jumpers op de kaart en/of dat PNP instellingen goed staan?

  • Zarc.oh
  • Registratie: November 2000
  • Laatst online: 10-05 18:52

Zarc.oh

heeft een HD van 20 YottaByte

Waarom die afwijkende ip-adressen?
Ik zou zeggen probeer ze 's allebei in hetzelfde subnet te zetten.
Voor beide kaartje is het subnetmask 255.255.255.0. Dat houdt dus in dat 192.168.0.3 in een ander netwerk ligt dan 192.168.1.8. Dus gebruik 192.168.0.1 en 192.168.0.2 oid...

Zoek wat je niet eerder vond


  • RemcoX
  • Registratie: Mei 2000
  • Laatst online: 14-02 20:05
Die 3C509b is inderdaad een ISA kaartje, maar volgens mij is 'ie wel goed geconfigd. Uit /etc/sysconfig/hwconf
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
class: NETWORK
bus: ISAPNP
detached: 0
device: eth
driver: 3c509
desc: "3Com 3C509B EtherLink III:Unknown"
deviceId: TCM5098
pdeviceId: TCM5098
compat: PNP80f7
native: 1
active: 1
cardnum: 0
logdev: 0
io: 0x220
irq: 5

Beide NIC's in hetzelfde subnetmask heb ik ook al geprobeerd, maar dat levert niets op.

In /var/log/messages staat ook niets interessants.

Bij het up brengen van het netwerk krijg ik wel hetvolgende...
code:
1
2
eth1: Setting Rx mode to 0 addresses.
eth1: Setting Rx mode to 1 addresses.

... geen idee wat het betekent...

Verwijderd

Die Rx meldingen zijn oke, da's normaal, mijn routing-table ziet er zo uit:

10.120.24.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
192.168.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth1
212.187.93.0 0.0.0.0 255.255.255.192 U 0 0 0 eth2
10.120.24.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 212.187.93.1 0.0.0.0 UG 0 0 0 eth2

Je zou verwachten dat allebei de NIC's moeten werken, vraagje, zitten ze allebei op een hub/switch? Enne, heb je een uplink?

  • RemcoX
  • Registratie: Mei 2000
  • Laatst online: 14-02 20:05
Die 3C900 zit op een hub, en die 3C509b zit met een crosscable aan een andere pc. Ik heb het hele zaakje al eens omgedraaid, (dus 2 utp kabels verwisseld en in de config alle eth0 en eth1 omgewisseld) en toen werkte nog steeds alleen de 3C900.

  • joop3
  • Registratie: April 2001
  • Laatst online: 17-01 16:52

joop3

 

je zou eens met de dosutil 3c5x9cfg.exe moeten kijken of de kaart in pnp staat. Als dat zo is moet je die eraf gooien. Dat vind linux namelijk niet leuk

  • RemcoX
  • Registratie: Mei 2000
  • Laatst online: 14-02 20:05
Het werkt!. Hij stond dus toch in PnP. Dit uitgezet en het werkt meteen. Thanks!
Pagina: 1