I'm running 10.1 Official upgraded with Thac's KDE3.4 rpms, and a couple of days ago I updated a bunch of things (including drakxtools, which is I suspect where my problem comes from) from the official updates repository.
Since then, netprofile, which worked fine up to then, seems to be a bit buggered. My laptop won't connect to be local network (an MDK 10.0 Official machine operating as transparent proxy and dhcp server).
The wierd bit is in MCC, eth1 (my network card) is configured properly, and if I delete eth1 and add a new connection with exactly the same settings, it works!
I tried "service network restart", disabling some things and others to try to get it to work, to no avail. Switching from one profile to another and back again also doesn't work either.
Anyone have any suggestions as to how I might fix this without having to delete and re-setup a network connection every time I switch the machine on?
And see if anything changes between the working and non-working states?
Other output that would be useful to compare between the two states:
ifconfig
route _________________ Adam Williamson | http://www.happyassassin.net Fedora QA community monkey
Mandriva contributor, former community manager
You say 'service network restart' doesn't work - what actually _happens_ when you do it? Is there any mention of eth1? Do you have the little network tool in the system tray? What's showing up there? Anything in its 'profiles' menu? _________________ Adam Williamson | http://www.happyassassin.net Fedora QA community monkey
Mandriva contributor, former community manager
Shutting down loopback interface: [ OK ]
Setting network parameters: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface eth1: [FAILED]
The "Bringing up interface eth1 ...[FAILED]" is all it says during boot also, no more information than that I'm afraid.
I do (or did, I think I've gone and banished it) have the network tool in the system tray. It did note correctly whether there was or was not a network connection, but it has no "Profiles" menu, just "connect eth1", "configure network", "monitor network", "refresh", "get online help", "launch on startup" and "exit". It would change correctly to indicate a network connection as soon as I had a new one configured.
When things are *not* working, the settings in "Manage connections" in the MCC are correct for eth1, except that there is no ip address or netmask set in the greyed out TCP/IP portions (the gateway *is* set correctly though). This suggests that it's just not reaching the dhcp server, and the lack of default route would explain that problem wouldn't it?
Going to try setting a default route in a not-working setup to see what happens.
This is a bit odd, isn't it...hmm...anything in the kernel logs? _________________ Adam Williamson | http://www.happyassassin.net Fedora QA community monkey
Mandriva contributor, former community manager
It looks like it's definitely whatever the problem is with setting the default route.
I've just logged on to another network (there's three I use fairly regularly, hence my dependence on netprofile). This one uses static ip addresses, and the same problem has occured (network settings correct but no connection), with the same solution (just set up the connection again in MCC with same settings).
This has me stumped, I have to say. What could possibly be changing in the network configurations between boots? And why does it not change back for a network service restart, but does change when a connection is set up and started for the first time?
There's nothing in the kernel logs that might make any difference (there's a reference to eth0, which is my firewire port I think, as a network device, but the reference is there from everytime I've switched on the machine, as far back as it goes, so it isn't causing the problem here).
dmesg has this for eth1, presumably from when I set up when I re-add the connection in MCC.
Code:
eth1: ICS LAN PHY transceiver found at address 1.
eth1: Using transceiver found at address 1 as default
eth1: SiS 900 PCI Fast Ethernet at 0xe400, IRQ 11, 00:40:d0:48:51:91.
eth1: Media Link On 100mbps full-duplex
eth1: no IPv6 routers present
And manually setting up the network card when things aren't working (on the static ip network) doesn't work, with similar problem to before; no eth1 device found.
I'm stumped too. I will see if I can find a network expert to help out here. Sorry... _________________ Adam Williamson | http://www.happyassassin.net Fedora QA community monkey
Mandriva contributor, former community manager
Here's some suggestions from Luca Berra, a Cooker regular:
check
1) why the gateway in /etc/sysconfig/network, op is using dhcp
2) run sh -x /sbin/ifup eth1
and see what exactly fails
3) MII_NOT_SUPPORTED
4) why the 10.xxx adresses when it works it is using 192.168 ones _________________ Adam Williamson | http://www.happyassassin.net Fedora QA community monkey
Mandriva contributor, former community manager
Okay, firstly thanks for your help so far, and thanks to Luca too.
1) why the gateway in /etc/sysconfig/network, op is using dhcp
The proxy server that that network (my home network) profile uses is an MDK10.0 Official machine, which is set up as a proxy server using the MDK Wizard for the task in MCC (on the 10.0 machine) - can't say I know more than that, I'm afraid, so everything's dhcp on that network.
2) run sh -x /sbin/ifup eth1
I ran this this morning on the second network I'm on (work, the one I was using yesterday and am using today, and just to make things even more fun I'll be on an entirely different network tomorrow!).
The output from the above is rather long, and I understand none of it, but I've put it here for any to whom it might make some sense:
I'm afraid I don't know what this means (and Google hasn't been much help, everyone seems to take it for granted that people know it). Should it be set to "yes"?
4) why the 10.xxx adresses when it works it is using 192.168 ones
The 10.xxx addresses are a different network (my work network, which is an NT one with static ip addresses). route from *this* network (when it's working) gives:
Code:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.0 * 255.255.0.0 U 0 0 0 eth1
default 10.0.0.1 0.0.0.0 UG 0 0 0 eth1
And similarly, when it isn't working, there is no output beyond the headings.
And it will all be different tomorrow, when I'm on a different (unix, college) network with dynamic addressing again.
Nothing like a moving target to keep things interesting, but the problem looks the same across all of them (for the first two at least...).[/url]
bgmilne: there is an eth1 entry in /etc/modprobe.conf both when things work and when they don't (alias eth1:9 sis900), and I'm using a 2.6.8.1-12mdk kernel.
It seems there is no alias for eth1 in modprobe.conf, only for eth1:9
(zeroconf thing ?). Try to load the sis900 module, and add an
"alias eth1 sis900" line in /etc/modprobe.conf
It may be a link detection issue too (try MII_NOT_SUPPORTED=yes), it's
sometimes broken with sis900.
---------
MII_NOT_SUPPORTED is set in /etc/sysconfig/network-scripts/ifcfg-eth1 . It determines whether the network service attempts to detect whether there is actually a connection when asked to bring up eth1. We introduced this to avoid the five-minute DHCP timeout on boot problem when you don't have the network cable plugged in, or whatever, but as blino says, sometimes it doesn't work, so if you set MII_NOT_SUPPORTED=yes , it'll skip the check. Definitely try those two suggestions. I don't know how it got to be eth1:9 , either, but that's almost certainly wrong. _________________ Adam Williamson | http://www.happyassassin.net Fedora QA community monkey
Mandriva contributor, former community manager
The removal of the ":9" from my "alias eth1:9 sis900" did the trick. No more fiddling with network settings. I didn't have to alter MII_NOT_SUPPORTED either, though thanks very much for explaining it to me.
I haven't editted modprobe.conf manually at all, I don't think, so I don't know how the offending ":9" got there, but the laptop (a Packard Bell Easynote K5 - I will never buy PB again) has had a number of other quirks so it would well be something do with that.
Anyway, thanks again. Everything back to well tuned and problem free network hopping.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
Help
Search
Log in 
