Re: [suse-ppc] DHCP problem with 7.3
On Thursday, 31. October 2002 00:48, Steven Bedrick wrote:
What about a ping before and after you lose your ability to resolve URL's. Do you get packet loss?
Oh yeah. 100%.
-SB
Can you try an older kernel sth. before 2.4.7-pre3. I suspect a kernel related problem in networking on B&W G3 after 2.4.7-pre3, but I'm not quite sure it's the same in your case. Can someone else comment on that? (Olav, are you still alive?) Grüßli, Micha
On Mon, Nov 04, 2002 at 03:21:03PM +0100, Michael Engel wrote:
On Thursday, 31. October 2002 00:48, Steven Bedrick wrote:
What about a ping before and after you lose your ability to resolve URL's. Do you get packet loss?
Oh yeah. 100%.
-SB
Can you try an older kernel sth. before 2.4.7-pre3. I suspect a kernel related problem in networking on B&W G3 after 2.4.7-pre3, but I'm not quite sure it's the same in your case. Can someone else comment on that? (Olav, are you still alive?)
good suggestion to find out first whether the network as such is dead or just the name resolution or something else. Also check whether dhclient is running ('pidof dhclient') and grep in the logs ('grep dhc /var/log/messages | tail -10). Then we can look further. Peter -- Thought is limitation. Free your mind.
Can you try an older kernel sth. before 2.4.7-pre3. I suspect a kernel related problem in networking on B&W G3 after 2.4.7-pre3, but I'm not quite sure it's the same in your case. Can someone else comment on that? (Olav, are you still alive?)
I haven't tried the older kernel, is there a suggestion on which particular one I should try? I'm also not too clear about how I would go about testing a diff. kernel...
good suggestion to find out first whether the network as such is dead or just the name resolution or something else.
The network's fine, as restarting rcdhclient temporarily solves the problem.
Also check whether dhclient is running ('pidof dhclient') and grep in the logs ('grep dhc /var/log/messages | tail -10).
'pidof dhclient' didn't return anything, nor did 'pidof rcdhclient'. Even when name resolution is working fine, neither command returns anything. There's nothing in /var/log/messages about dhclient, except for the messages generated by restarting it. -SB -- "As an adolescent I aspired to lasting fame, I craved factual certainty, and I thirsted for a meaningful vision of human life -- so I became a scientist. This is like becoming an archbishop so you can meet girls." -- Matt Cartmill
On Mon, Nov 04, 2002 at 01:59:35PM -0800, Steven Bedrick wrote:
good suggestion to find out first whether the network as such is dead or just the name resolution or something else.
The network's fine, as restarting rcdhclient temporarily solves the problem.
Also check whether dhclient is running ('pidof dhclient') and grep in the logs ('grep dhc /var/log/messages | tail -10).
'pidof dhclient' didn't return anything, nor did 'pidof rcdhclient'. Even when name resolution is working fine, neither command returns anything.
Okay, let's use a different method: 'ps aufx | grep dhc'
There's nothing in /var/log/messages about dhclient, except for the messages generated by restarting it.
If it dies it should log an error. What about dhcpcd? (Is there a certain reason why you use dhclient?) Peter -- Thought is limitation. Free your mind.
'pidof dhclient' didn't return anything, nor did 'pidof rcdhclient'. Even when name resolution is working fine, neither command returns anything.
Okay, let's use a different method: 'ps aufx | grep dhc'
Yeah, that turns up dhcpcd.
There's nothing in /var/log/messages about dhclient, except for the messages generated by restarting it.
If it dies it should log an error.
Nope. No errors being logged.
What about dhcpcd? (Is there a certain reason why you use dhclient?)
Well, apparently, I'm actually using dhcpcd, according to ps. The dhclient bit came into play when I was trying to figure out how to work around this problem. I've got a more-or-less stock SuSE installation going on, nothing fancy, especially in the networking area. I don't know much about the particulars of what's going on with all of that, so I've left it alone. -SB -- "As an adolescent I aspired to lasting fame, I craved factual certainty, and I thirsted for a meaningful vision of human life -- so I became a scientist. This is like becoming an archbishop so you can meet girls." -- Matt Cartmill
On Mon, Nov 04, 2002 at 07:26:42PM -0800, Steven Bedrick wrote:
'pidof dhclient' didn't return anything, nor did 'pidof rcdhclient'. Even when name resolution is working fine, neither command returns anything.
Okay, let's use a different method: 'ps aufx | grep dhc'
Yeah, that turns up dhcpcd.
Ah! So while the DHCP client is running, the network doesn't work though.
There's nothing in /var/log/messages about dhclient, except for the messages generated by restarting it.
If it dies it should log an error.
Nope. No errors being logged.
Strange. Can you set DHCLIENT_DEBUG to "yes" in /etc/rc.config.d/dhcpcd.rc.config and restart the network? And, as I'm still not clear about what your situation is when the network is "down", can you check 'ifconfig -a' in such a case? Ping your own address? And in addition look for messages like "transmit timeout" or similar messages in /var/log/messages that might come from the driver? Do you have access to the DHCP server logfiles? They could also be helpful. To ultimately determine whether it is a DHCP or driver problem, try a static configuration instead of DHCP: rcdhclient stop ifconfig eth0 192.168.0.1 broadcast 192.168.0.255 netmask 255.255.255.0 up route add default gw 192.168.0.5 (or whatever the address is that you last got from the DHCP server) ...and see the problem turns up as well.
What about dhcpcd? (Is there a certain reason why you use dhclient?)
Well, apparently, I'm actually using dhcpcd, according to ps. The dhclient bit came into play when I was trying to figure out how to work around this problem. I've got a more-or-less stock SuSE installation going on, nothing fancy, especially in the networking area. I don't know much about the particulars of what's going on with all of that, so I've left it alone.
The names are utterly confusing, which is neither your fault, nor mine :) Peter -- Thought is limitation. Free your mind.
Nope. No errors being logged.
Strange. Can you set DHCLIENT_DEBUG to "yes" in /etc/rc.config.d/dhcpcd.rc.config and restart the network? And, as I'm still not clear about what your situation is when the network is "down", can you check 'ifconfig -a' in such a case? Ping your own address? And in addition look for messages like "transmit timeout" or similar messages in /var/log/messages that might come from the driver?
When the network is "down", it seems as though I can't resolve other hosts. For example, I can ping my own IP address all I want, and get fine results. Pinging other addresses, though, even internal ones on my own LAN, fails every time (until I restart dhcpcd, that is). I get a "Destination Host Unreachable" message after every packet attempt. One strange thing, though: take a look at the first line of ping's output, where it says, for example: "PING coloradocollege.edu (205.170.1.68) from 205.170.13.166 : 56(84) bytes of data." So, it looks like it's getting an IP addresss for the remote host, it just can't get there. What the heck is going on here? Regarding the next question, "ifconfig -a" looks normal (I've still got an IP address, and other stuff seems to be set properly). That is, it looks the same when my network is working and when it isn't. Also, I'm running dhcpcd with dhclient_debug set to yes, and so far am seeing no new messages.
Do you have access to the DHCP server logfiles? They could also be helpful.
No, I don't have access to those. :-(
To ultimately determine whether it is a DHCP or driver problem, try a static configuration instead of DHCP: rcdhclient stop ifconfig eth0 192.168.0.1 broadcast 192.168.0.255 netmask 255.255.255.0 up route add default gw 192.168.0.5 (or whatever the address is that you last got from the DHCP server) ...and see the problem turns up as well.
I'm a bit unclear- is "route add default gw 192.168.0.5" a second command after ifconfig? Also, which address should be used rather than "192.168.0.5"? My own computer's most recently assigned IP address? My broadcast address?
The names are utterly confusing, which is neither your fault, nor mine :)
Ain't that the truth... -SB -- "As an adolescent I aspired to lasting fame, I craved factual certainty, and I thirsted for a meaningful vision of human life -- so I became a scientist. This is like becoming an archbishop so you can meet girls." -- Matt Cartmill
On Tue, Nov 05, 2002 at 09:01:37PM -0800, Steven Bedrick wrote:
So, it looks like it's getting an IP addresss for the remote host, it just can't get there. What the heck is going on here?
Regarding the next question, "ifconfig -a" looks normal (I've still got an IP address, and other stuff seems to be set properly). That is, it looks the same when my network is working and when it isn't.
So the interface is up, but it doesn't work.
To ultimately determine whether it is a DHCP or driver problem, try a static configuration instead of DHCP: rcdhclient stop ifconfig eth0 192.168.0.1 broadcast 192.168.0.255 netmask 255.255.255.0 up route add default gw 192.168.0.5 (or whatever the address is that you last got from the DHCP server) ...and see the problem turns up as well.
I'm a bit unclear- is "route add default gw 192.168.0.5" a second command after ifconfig? Also, which address should be used rather than "192.168.0.5"? My own computer's most recently assigned IP address? My broadcast address?
"route ..." is a second command. The IP address would be the default route of your subnet (if there is any), check 'route -n', the line that starts with 0.0.0.0. (Another way of setting the interface up would be to rcdhclient restart and 'killall -9 dhcpcd', that leaves the interface up) But anyway, this doesn't look like a problem with the DHCP client. The DHCP client just sits there and waits. It looks more like a driver problem. It would be most promising to try a different kernel, as it was suggested earlier in this thread. Peter -- Thought is limitation. Free your mind.
participants (3)
-
Michael Engel -
Peter Poeml -
Steven Bedrick