Jump to content

upgrade mdk9.1-10.1, now eth0 broken [solved]


thekx
 Share

Recommended Posts

I've installed 10.1 to replace my previous install of mdk9.1 (which networked fine) on a VIA EPIA/Eden box. Install runs smoothly but on reboot I can't connect eth0.

 

Looking at syslog, dhclient reports a series of: 'DHCPDISCOVER on eth0 to 255.255.255.255 port 67' messages, followed by: 'no DHCPOFFERS received...no working leases...sleeping'. This is from a LAN connection to my Linksys router, which is leasing fine via DHCP to my Windows box alongside, and was fine with mdk9.1 before.

 

Sanity checks: eth0 is UP BROADCAST RUNNING MULTICAST according to ifconfig, and link beat is detected according to dmesg. Driver is via-rhine, which was autodetected OK and is loaded without error according to lsmod and dmesg.

 

I noticed a message in syslog about no IPv6 routers found. I tried editing sysctl.conf and modprobe.conf as suggested on:

 

http://mandrakeusers.org/index.php?showtopic=23508

 

which I found through google. The ipv6 messages have stopped, but still no network. I've since tried a complete re-install from media (twice). I've also tried setting a static IP address/netmask/gateway within the correct IP class for the router, but that doesn't work either - with this the eth0 interface comes up (which is arguably progress), but `route` returns nothing. Even if I manually add nameservers to /etc/resolv.conf and `route add` a default gateway, I still can't seem to ping out.

 

I've been battling this for 3 days now :wall: Can anyone please help! I thought this should be a straightforward upgrade... :-(

 

Nick

Link to comment
Share on other sites

welcome aboard :)

 

please post the contents of your /etc/sysconfig/networkingscripts/ifcfg-eth0 file and the output of the terminal-commands "ifconfig", "ping <any site you want, e.g. www.google.com>" and "iptables -nvL". check if you have a firewall up and running, blocking your traffic.

 

about your resolv.conf: have you locked the file after changing the dns-servers? (btw: is your root-filesystem ext3? if yes, the much better it is)

 

have you disabled ipv6 in firefox, if you are using firefox? (type "about:config" in the searchbar and search for ipv6 afterwards, set disable-ipv6 from false to true)

 

good luck. :thumbs:

Link to comment
Share on other sites

Hi arctic, thanks for the welcome - I've read quite a few posts from you over the past few days, so it's reassuring to hear from you!

 

To (hopefully)eliminate a couple of things, no firewall is installed (iptables not found), no firefox installed yet, and the / partition is ext3. resolv.conf is not yet locked, but no change evident before or after trying to service network restart.

 

Without a connection, I'll have to retype the current state of the requested files. With dhcp:

 

ifcfg-eth0

DEVICE=eth0

BOOTPROTO=dhcp

NETMASK=255.255.255.0

ONBOOT=yes

METRIC=10

MII_NOT_SUPPORTED=no# or yes, I've tried with both

NEEDHOSTNAME= yes # or no, I've tried with both

 

ifconfig eth0

eth0 Link encap:Ethernet HWaddr 00:40:53:CC:33:33

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:2 errors:0 dropped:0 overruns:0 frame:0

TX packets:13 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:303 (303.0 b) TX bytes:4446 (4.3 Kb)

Interrupt:11 Base address:0xe800

 

>ping www.google.com

ping: unknown host www.google.com

 

With static IP I used exactly the settings from Chris's setup guide sticky'd on mandrakeusers.org as they're using the correct IP class for my router. Only difference is in address of nameservers, which are same as work on my Windoze box.

 

With this setup, ifconfig eth0 is same as above, with addition of:

inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0

below first line.

 

After a reboot, eth0 comes up, but ping requests return 100% packet loss.

 

Does this point to anything obvious?

 

Best,

Nick

Link to comment
Share on other sites

Just to add an aside, I wondered if it might be a problem with the via-rhine driver module itself.

 

I downloaded a fairly recent source tarball for the driver (dated november 04) and compiled it, having installed the kernel-source-2.6 package from the mdk 10.1 official DVD. Unfortunately, the module created (rhinefet.ko) won't insmod, since it has the wrong magic number.

 

No idea how to get it to have the right magic number though, so I can't even tell if that would have helped...

 

:sad: N

Link to comment
Share on other sites

Hi all,

 

One thing to add. With the static IP defined:

 

ping 192.168.1.2 (the eth0 interface)

answers fine.

 

ping 192.168.1.1 (the router/gateway)

100% packet loss.

 

My instinct is that there's nothing getting down the cable to the router. How can I test this out? LEDs are lit at both ends of the cable (I've tried different cables and ports into the router) and ifplugd seems to see a link working...

 

I'd *really* welcome any ideas from people out there :unsure:

 

Best,

Nick

Link to comment
Share on other sites

Hi

 

A couple of things to try:

 

Install iptables (urpmi iptables) - you could still have a misconfigured firewall (you don't need iptables installed to have an active firewall, as it's only a frontend). Then send us the results of iptables -nvL

 

Presumably you can ping the router from the Windows box?

 

Have you tried a crossover cable directly from the Linux box to your windows box, and pinging both ways?

 

If the driver/card is faulty (unlikely), you could always put a second NIC in the Linux box and use that one.

 

Looks most likely to be a firewall problem from here though.

 

Chris

Link to comment
Share on other sites

Can you try to explain the driver problem a little more? If the module can't be inserted how are you getting eth0 up?

 

Hi QChem,

 

First efforts were with the via-rhine.ko.gz driver module autodetected and installed by the mdk10.1 installer. This gets eth0 up (statically) but still lack connectivity to the rest of the LAN.

 

I tried to download and compile a fresh driver from VIA. This module had a different name of rhinefet.ko. Even though compiled against the kernel-source2.6 off the DVD, it wouldn't insert, as the magic number was different.

 

AFAIR, it was 2.6.8.1-12mdk in the module and 2.6.8.1-12mdk-i586-up-1GB was expected. Clearly some clever tweak required somewhere, but it's somewhere buried in the linux source hooks rather than the driver. I tried poking around in version.h but decided to back out as I'm not that great at parsing C! :o

 

So, everything since has been back to the default driver.

 

Hope that explains.

 

Thanks,

Nick

Link to comment
Share on other sites

Install iptables (urpmi iptables) - you could still have a misconfigured firewall (you don't need iptables installed to have an active firewall, as it's only a frontend). Then send us the results of iptables -nvL

Hi Chris,

 

Thanks for replying. That's news to me about iptables being frontend only. I'll install and test that out.

 

On the other things, yes, I can ping the router from the 'doze box just fine. Haven't got a crossover cable to try - may yet have to make one up!

 

Trying another NIC could be tricky; it's a Mini-ITX EPIA mobo, so there's only one PCI slot. That's occupied by a TV card as this is the family PVR that's out of action. It's OK to pull it for testing, but it would make the box redundant in practice! :lol:

 

I'll test out iptables and report back.

 

Thanks,

Nick

Link to comment
Share on other sites

OK, installed iptables and now running iptables -nvL gives:

 

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source        destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source        destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source        destination

 

Looks like no rules. Which may or may not be good news... :juggle:

 

Time to hit the man page!

 

N

Link to comment
Share on other sites

Please excuse me following myself up again, but I thought I ought to add, I've pinged the router again and still get host unreachable. After this ping though, the number of packets and bytes has gone up in both input and output chains of iptables -nvL.

 

N

Link to comment
Share on other sites

Hi again

 

No firewall rules is good news for connectivity.

 

Perhaps we should start out troubleshooting right from the beginning, even though you may have already done all the things below, weird things happen...

 

Can you ping Linux from Windows?

 

Turn off or unplug the Windows box and leave it off/unplugged while testing.

 

Replace the cable from the Linux box to the router with the one from Windows. By the way, are they directly connected with a patch lead - i.e sitting next to each other, or is there further cabling to go faulty?

 

Restart the router. Wait a couple of minutes for the lights to settle down.

 

Reboot the Linux box

 

Try pinging the router

 

Post output of route -n

 

Make sure there is a valid IP address in the output of ifconfig eth0

 

That will do for now...

 

Chris

Link to comment
Share on other sites

No firewall rules is good news for connectivity.

 

Perhaps we should start out troubleshooting right from the beginning, even though you may have already done all the things below, weird things happen...

Chris

For sure. I dread to think how many hours I've been trying different things to solve this... it'd be easy to miss something simple.

 

OK. Windows pings linux, with both connected to router via separate patch leads = nothing.

 

I swap the patch lead from Windows box to linux box. Link light on router returns.

 

Turn off router for 1/2 hour and go have a cup of tea. Power it up again, reboot linux. Check `ifconfig eth0` is up, have:

inet addr:192.168.1.2  Bcast:192.168.1.255  Mask:255.255.255.0

 

`ping 192.168.1.2` (linux NIC) - 0% packet loss, 0.01ms avg TTL

`ping 192.168.1.1` (router) - destination host unreachable, 100% packet loss

 

`route -n` gives:

Kernel IP routing table
Destination     Gateway        Genmask         Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0        255.255.255.0   U     0      0        0 eth0
0.0.0.0         192.168.1.1    0.0.0.0         UG    0      0        0 eth0

 

N

Link to comment
Share on other sites

I've been doing some other tests, and the results have me confused. I hope someone here can make sense of it.

 

I installed Packetyser onto the Windows box to monitor the LAN activity. With this, I could clearly see the Windows and Linksys router negotiating an IP address via DHCP. But I couldn't see anything to/from the linux box - the router appeared to be acting as a switch to hide activity from the linux box although they should be on the same segment.

 

Next, I inserted a hub between the router and linux box to try to see what was going on there. When I ran `ping -bf 192.168.1.255` to flood ping my LAN with broadcast packets, I got a stack of activity on the hub LEDS. The NIC answered fine (>6,200 packets/sec, with 0% packet loss). I surmise from this that the NIC hardware is getting something onto the local ethernet.

 

Next, I plug both the Windows and linux box on the hub, sharing an uplink to the router.

 

Now I can see the linux box, broadcasting ARP requests every second or so:

 

ARP: Who has 192.168.1.1? Tell 192.168.1.2

 

At the same time, the Windows box tries to re-negotiate DHCP, but now gets no answer from the Linksys router! :devil:

 

So, to summarise:

  • If the two boxes are patched direct to any two LAN ports of the router, Windows networks fine, linux sees nothing. Router shows link lights for both.
     
  • If they share a router LAN socket through the hub, neither box can see the router, but they can see each other's packets. All 3 sockets on the hub show link lights, as does the router at the end of the uplink.
     
  • If I have either box alone attached through the hub to the router, I get no answer from the router. Again, link lights fine.

The crazy thing is that this network and hardware all worked perfectly on 12 March, until I upgraded the linux box from mdk9.1. Aagh?! :wall:

 

Nick

Link to comment
Share on other sites

The Linux NIC and networking seem to be fine - look to the router

 

The router must be ignoring the Linux box - has it a setting to only allow certain MAC addresses perhaps?? My Belkin certainly does.

 

Maybe it is worth noting down/saving the router settings and then resetting it

 

What is the make/model of the router (somebody else may have knowledge of it)

 

The hub should be connected to the router through a normal socket, not the uplink socket, else it won't work.

 

You won't see anything with a packet sniffer on another machine if the router ports are switched - use the hub

Edited by streeter
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...