Re: [Cooker] dhcpcd cooked
On Sun, 2003-07-27 at 06:07, w9ya wrote: Hey Adam and the gang; Yes, in fact ifplugd starts and successfully determines the eth0 info (after dhclient DHCPACKS from the server). Then, as you suggest, ifplugd about a minute (or so) later brings down the interface (eth0), and then exits. If I then execute: /etc/ifplugd/ifplugd.action eth0 up (from a prompt), the interface successfully comes up and works fine from that point forward. So it appears that when your situation was remedied concerning ifplugd, mine was broken. As I followed up, it wasn't actually resolved for me - it still happens, and now I can confirm it happens on both WLAN and wired cards. Maybe the time is ripe to file a bug report. BTW, all you need to run to fix it is ifup eth0, that does the job. -- adamw
Re: [Cooker] dhcpcd cooked
Hello again; Yes agreed that this is not driver related per say as I ran test with various wired cards too. An I agree that a bug report is in order. Since you were first affected by this, I will let you do the honors of filing a report. (Besides the Mandrake bugzilla was too cranky for me to successfully file a report the last time I tried to use it.) Thanxs for the sane replies and kind attitudes during them. Best regards; Bob On Sunday 27 July 2003 05:30 am, Adam Williamson wrote: On Sun, 2003-07-27 at 06:07, w9ya wrote: Hey Adam and the gang; Yes, in fact ifplugd starts and successfully determines the eth0 info (after dhclient DHCPACKS from the server). Then, as you suggest, ifplugd about a minute (or so) later brings down the interface (eth0), and then exits. If I then execute: /etc/ifplugd/ifplugd.action eth0 up (from a prompt), the interface successfully comes up and works fine from that point forward. So it appears that when your situation was remedied concerning ifplugd, mine was broken. As I followed up, it wasn't actually resolved for me - it still happens, and now I can confirm it happens on both WLAN and wired cards. Maybe the time is ripe to file a bug report. BTW, all you need to run to fix it is ifup eth0, that does the job.
Re: [Cooker] dhcpcd cooked
Hey Adam and the gang; Yes, in fact ifplugd starts and successfully determines the eth0 info (after dhclient DHCPACKS from the server). Then, as you suggest, ifplugd about a minute (or so) later brings down the interface (eth0), and then exits. If I then execute: /etc/ifplugd/ifplugd.action eth0 up (from a prompt), the interface successfully comes up and works fine from that point forward. So it appears that when your situation was remedied concerning ifplugd, mine was broken. Anywaysit has remained broken for the past week, and the bugzilla is hosed, so I guess this amounts to the bug report. Best regards; Bob On Friday 18 July 2003 07:08 pm, Adam Williamson wrote: On Fri, 2003-07-18 at 22:37, Buchan Milne wrote: On Fri, 18 Jul 2003, w9ya wrote: O.k. Here's yet some more observations. I was premature in stating that conditions had changed. It now appears that sometimes a full dhcp lease is retreved, and THEN logging into kde via kdm is killing the interface etc. (eth0), and at other times the interface and lease never get completed. In both cases the drivers are there. Posting anecdotes about the things you were doing when something took your interface down isn't going to help. If you want to try and fix this, post the output of 'ifstatus -v eth0' at the time when the interface is up, and when it is down, and the contents of your /etc/sysconfig/networks-scripts/ifcfg-eth0, and possibly the drive your PCMCIA NIC uses. If you don't post any information that is *useful* for seeing what is happening, this is a waste of time for all of us. I wouldn't be surprised if the same thing was happening to him as happened to me with my WLAN card - ifplugd now tries to deal with it, and until this morning's updates it would launch then terminate itself a minute later and take the connection down with it. Now it doesn't seem to do that any more. Note: why the hell has Evolution just started wrapping at these ridiculously short line lengths? I didn't change anything. Fred?
Re: [Cooker] dhcpcd cooked
On Fri, 18 Jul 2003, w9ya wrote: This is exactly what went on and was fixed immediately prior to the 9.1 release (and ifstaus -v is unchanged in either condition also). No it is not. Immediately prior to 9.1, ifplugd was working fine, but the ifup script would not set the DNS servers supplied by the dhcp server in /etc/resolv.conf if the dhcp server didn't supply a domain name (you still got an IP, and kept it - totally different behaviour). Similar behaviour to what you are seeing *might* have been present during the initial integration of ifplug, but that was a bit more than immediately prior to. In my case I am using the pcnet_cs card, so it probably isn't specific to driver. AFAIK, pcnet_cs does not support ifplugd, and since you haven't posted your ifcfg-eth0 (no, I did not want to know if it was static or dhcp), figure out yourself how to turn off ifplugd. -- |Registered Linux User #182071-| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 ** Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. **
Re: [Cooker] dhcpcd cooked
On Saturday 19 July 2003 05:32 am, Buchan Milne wrote: On Fri, 18 Jul 2003, w9ya wrote: This is exactly what went on and was fixed immediately prior to the 9.1 release (and ifstaus -v is unchanged in either condition also). No it is not. Immediately prior to 9.1, ifplugd was working fine, but the ifup script would not set the DNS servers supplied by the dhcp server in /etc/resolv.conf if the dhcp server didn't supply a domain name (you still got an IP, and kept it - totally different behaviour). Similar behaviour to what you are seeing *might* have been present during the initial integration of ifplug, but that was a bit more than immediately prior to. Well, since *I* have not said it *was* ifplugd I don't doubt you might be right. Also *my* idea of immediately prior might well be different than yours, in as much as alot of pcmcia nics had problems working with the scripting across MANY versions of Mandrake, i.e. this was problem for a long time. Again, all of this I have said before in this thread. In my case I am using the pcnet_cs card, so it probably isn't specific to driver. AFAIK, pcnet_cs does not support ifplugd, and since you haven't posted your ifcfg-eth0 (no, I did not want to know if it was static or dhcp), figure out yourself how to turn off ifplugd. Well I did send it in to this list more than once, Apparently the internet is having ALOT of problems this weekend with email and you may not have seen it. I even sent it to you directly. (And my outgoing mail is just fine.) I will tell you again and specifically; DEVICE=eth0, BOOTPROTO=dhcp, NETMASK=255.255.255.0, ONBOOT=yes, NEEDHOSTNAME=yes . Um, just for the record, I am *NOT* interested in figuring this out. If that wasn't obvious, please let me be specific. This is troubleshooting info for the maintainer(s) that have been changing scripts and/or modifying packages. I was hoping that a maintainer would use the information I was turning in. Are you one of these maintainers ? If not, then please just be gracious and let me post the information I have. ANY information can be useful to a maintainer. Earlier you said this was antedotal (which is more than debatable) and of no use. I seriously doubt that. Finally if you don't want to help troubleshoot this problem, that is more than fine with me. I (again as stated in an earlier posting) can just make the need changes myself, as I did custom scripting for this before and I am content to do so again. I think unless there is something relevant to discuss further here and you are a maintainer wanting to deal with this, I would say this thread has run its course, long ago, as nothing useful has come out of it, other than my original intention to alert the relevant maintainers and some interesting input from Adam W. Sincerely and with best regards; Bob Finch
Re: [Cooker] dhcpcd cooked
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 w9ya wrote: HOWEVER: After rebooting the laptop without the pcmcia network card inserted, and then inserting it watching on a root tty.well as I suspected this mimmicks the pcmcia network card issues that plagued the 8.x releases and I think got fixed shortly before 9.1 was released. The scripts are clearly hanging. As I recall there was much discussion of this in the past. SO this must just be a case of deja-vu !! AFAIK, no PCMCIA cards can accurately tell you the status of the cable. If you aren't connected, pop the card out, if you are, pop it in, otherwise you will see things like this. If we can't tell if we are connected, we have to try dhcp, which may result in a long timeout if not connected = get a card that has support for this, most onboard NICs in new laptops do. Thanks for the attention. Bob Finch p.s. The fix for me was script in rc.local to take care of this. Prolly going to have to that again. No big deal just wanted to get this on the record. It would then also be useful to have the output of 'ifstatus -v interface' for each card, in different states (ie plugged in, not pluggged in). And you might also want to show us what you have in /etc/sysconfig/network-scripts/ifcfg-eth0, especially MII_UNSUPPORTED or whatever it is (aka the network hotplugging checkbox in drakconnect in expert mode). My cooker box with a RTL-8139 never has problems like this ;-) but then again it is always connected, and ifplugd does work well with it. Regards, Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/GC2NrJK6UGDSBKcRAj6aAJ0bjts72HfVnuG2YDEtvccZ5rjX1QCgihcK ouLDkoJgdSjNADpI86AJyTE= =I9zZ -END PGP SIGNATURE- ** Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. **
Re: [Cooker] dhcpcd cooked
Some additional info. On the kde desktop icon flashing issue. I moved some files into folders on the desktop, and that seemed to fix the flashing. Some of these files couldn't find there associated graphics (i.e a .pdf file may or may not look like a pdf icon). So this may well be a non-issue, or probably NOT a Mandrake issue. HOWEVER: After rebooting the laptop without the pcmcia network card inserted, and then inserting it watching on a root tty.well as I suspected this mimmicks the pcmcia network card issues that plagued the 8.x releases and I think got fixed shortly before 9.1 was released. The scripts are clearly hanging. As I recall there was much discussion of this in the past. SO this must just be a case of deja-vu !! Thanks for the attention. Bob Finch p.s. The fix for me was script in rc.local to take care of this. Prolly going to have to that again. No big deal just wanted to get this on the record. On Friday 18 July 2003 11:17 am, w9ya wrote: Hey Gang; Earlier this week, after a urpmi.update -a urmpi --auto-select --auto, the eth0 interface seemed to be set up just fine after a reboot. *However* logging into kde via kdm (not mdkkdm) oddly caused the routing and ifconfig for eth0 to disappear. The modules for the pcmcia card were still loaded so a simple dhcpcd from a root prompt fixed it all up. This was only for the first kdm login after a reboot as subsequent logins via kdm were fine. *NOW* (after just now running the urmpi script above) only the lo interface is being setup after a reboot. As before the pcmcia card's modules are being loaded during the reboot and running dhcpcd from a root prompt after the reboot completes works fine. Now kdm logins no longer appear to be causing any issues in this area. Additionally the kde desktop is having problems since the earlier urpmi updates. Desktop icons are flashing after kdm completes placing said icons after a (kdm) login. The operational fix is to select icon alignment, however this has to be done each time a user logs in. Obviously this may not be a Mandrake specific problem in either case (kde or dhcpcd). But in past experience with at least the dhcpcd issue (yes this is NOT the first time) it has been a Mandrake scripting error. Thanks for the attention. Bob Finch
Re: [Cooker] dhcpcd cooked
On Friday 18 July 2003 12:25 pm, Buchan Milne wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 w9ya wrote: HOWEVER: After rebooting the laptop without the pcmcia network card inserted, and then inserting it watching on a root tty.well as I suspected this mimmicks the pcmcia network card issues that plagued the 8.x releases and I think got fixed shortly before 9.1 was released. The scripts are clearly hanging. As I recall there was much discussion of this in the past. SO this must just be a case of deja-vu !! AFAIK, no PCMCIA cards can accurately tell you the status of the cable. If you aren't connected, pop the card out, if you are, pop it in, otherwise you will see things like this. If we can't tell if we are connected, we have to try dhcp, which may result in a long timeout if not connected = get a card that has support for this, most onboard NICs in new laptops do. Let me be very specific. It worked, then I updated, then it didn't work. Something must have changed in the updating I guess. Since I can get this to work from a command line, I don't see why a script cannot also work, and *again* it was working. Additionally there is no reason to go looking for the status of the cable in this case. One should just be loading drivers (which is happening) and then if your system is dhcp based, getting a lease. Perhaps I don't truly understand what you are saying. Since I am not going to be fixing this, and only reporting function that was working at one point, I am not sure it makes much difference that I know that much about it anyways. Thanks for the attention. Bob Finch p.s. The fix for me was script in rc.local to take care of this. Prolly Sigh. going to have to that again. No big deal just wanted to get this on the record. It would then also be useful to have the output of 'ifstatus -v interface' for each card, in different states (ie plugged in, not pluggged in). And you might also want to show us what you have in /etc/sysconfig/network-scripts/ifcfg-eth0, especially MII_UNSUPPORTED or whatever it is (aka the network hotplugging checkbox in drakconnect in expert mode). My cooker box with a RTL-8139 never has problems like this ;-) but then again it is always connected, and ifplugd does work well with it. That's nice. Well as I mentioned in the original post, even with the card installed prior to turning the laptop on, I get the same results. And yes I do understand it might be using the hotplugd stuff anyways. Certainly some of the same scripts are called. Regards, Buchan - -- Sure thing' Bob Finch |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/GC2NrJK6UGDSBKcRAj6aAJ0bjts72HfVnuG2YDEtvccZ5rjX1QCgihcK ouLDkoJgdSjNADpI86AJyTE= =I9zZ -END PGP SIGNATURE- ** Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. **
Re: [Cooker] dhcpcd cooked
O.k. Here's yet some more observations. I was premature in stating that conditions had changed. It now appears that sometimes a full dhcp lease is retreved, and THEN logging into kde via kdm is killing the interface etc. (eth0), and at other times the interface and lease never get completed. In both cases the drivers are there. Sorry about this confusion. Bob FInch On Friday 18 July 2003 12:16 pm, w9ya wrote: Some additional info. On the kde desktop icon flashing issue. I moved some files into folders on the desktop, and that seemed to fix the flashing. Some of these files couldn't find there associated graphics (i.e a .pdf file may or may not look like a pdf icon). So this may well be a non-issue, or probably NOT a Mandrake issue. HOWEVER: After rebooting the laptop without the pcmcia network card inserted, and then inserting it watching on a root tty.well as I suspected this mimmicks the pcmcia network card issues that plagued the 8.x releases and I think got fixed shortly before 9.1 was released. The scripts are clearly hanging. As I recall there was much discussion of this in the past. SO this must just be a case of deja-vu !! Thanks for the attention. Bob Finch p.s. The fix for me was script in rc.local to take care of this. Prolly going to have to that again. No big deal just wanted to get this on the record. On Friday 18 July 2003 11:17 am, w9ya wrote: Hey Gang; Earlier this week, after a urpmi.update -a urmpi --auto-select --auto, the eth0 interface seemed to be set up just fine after a reboot. *However* logging into kde via kdm (not mdkkdm) oddly caused the routing and ifconfig for eth0 to disappear. The modules for the pcmcia card were still loaded so a simple dhcpcd from a root prompt fixed it all up. This was only for the first kdm login after a reboot as subsequent logins via kdm were fine. *NOW* (after just now running the urmpi script above) only the lo interface is being setup after a reboot. As before the pcmcia card's modules are being loaded during the reboot and running dhcpcd from a root prompt after the reboot completes works fine. Now kdm logins no longer appear to be causing any issues in this area. Additionally the kde desktop is having problems since the earlier urpmi updates. Desktop icons are flashing after kdm completes placing said icons after a (kdm) login. The operational fix is to select icon alignment, however this has to be done each time a user logs in. Obviously this may not be a Mandrake specific problem in either case (kde or dhcpcd). But in past experience with at least the dhcpcd issue (yes this is NOT the first time) it has been a Mandrake scripting error. Thanks for the attention. Bob Finch
Re: [Cooker] dhcpcd cooked
On Fri, 18 Jul 2003, w9ya wrote: On Friday 18 July 2003 12:25 pm, Buchan Milne wrote: AFAIK, no PCMCIA cards can accurately tell you the status of the cable. If you aren't connected, pop the card out, if you are, pop it in, otherwise you will see things like this. If we can't tell if we are connected, we have to try dhcp, which may result in a long timeout if not connected = get a card that has support for this, most onboard NICs in new laptops do. Let me be very specific. It worked, then I updated, then it didn't work. Something must have changed in the updating I guess. And maybe you would like to try and help find out what it was? Since I can get this to work from a command line, I don't see why a script cannot also work, and *again* it was working. The initscrtipts do a bit more than just launch dhcpcd, and one of the other bits may have broken. Additionally there is no reason to go looking for the status of the cable in this case. One should just be loading drivers (which is happening) and then if your system is dhcp based, getting a lease. Perhaps I don't truly understand what you are saying. Why would you want to request a lease, and wait around for the reply if you know there isn't a DHCP server on the other side of your NIC (since it's not connected)? By determining whether the cable is connected, we can decide whether we should make the user wait until DHCP times out (this is what happened on 8.x and earlier if you were configured for dhcp and not connected), or if we should just keep the interface down. So, maybe it would be useful to have software that can tell us whether the cable is connected? Since I am not going to be fixing this, and only reporting function that was working at one point, I am not sure it makes much difference that I know that much about it anyways. But if you want to have it fixed (without hacking), so other people don't have the same problem, maybe you can do us all a favour and run 'ifstatus -v eth0', and post the answers back, and tell us whether your card was showing a link light at the time? p.s. The fix for me was script in rc.local to take care of this. Prolly Who wrote this? ^^^ I didn't. It would then also be useful to have the output of 'ifstatus -v interface' for each card, in different states (ie plugged in, not pluggged in). And you might also want to show us what you have in /etc/sysconfig/network-scripts/ifcfg-eth0, especially MII_UNSUPPORTED or whatever it is (aka the network hotplugging checkbox in drakconnect in expert mode). My cooker box with a RTL-8139 never has problems like this ;-) but then again it is always connected, and ifplugd does work well with it. That's nice. Well as I mentioned in the original post, even with the card installed prior to turning the laptop on, I get the same results. And yes I do understand it might be using the hotplugd stuff anyways. Certainly some of the same scripts are called. Nothing to do with hotplug. And you also did not post your ifcfg-eth0 file. How do you expect us to figure out what the problem is? Regards, Buchan -- |Registered Linux User #182071-| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 ** Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. **
Re: [Cooker] dhcpcd cooked
On Fri, 2003-07-18 at 22:37, Buchan Milne wrote: On Fri, 18 Jul 2003, w9ya wrote: O.k. Here's yet some more observations. I was premature in stating that conditions had changed. It now appears that sometimes a full dhcp lease is retreved, and THEN logging into kde via kdm is killing the interface etc. (eth0), and at other times the interface and lease never get completed. In both cases the drivers are there. Posting anecdotes about the things you were doing when something took your interface down isn't going to help. If you want to try and fix this, post the output of 'ifstatus -v eth0' at the time when the interface is up, and when it is down, and the contents of your /etc/sysconfig/networks-scripts/ifcfg-eth0, and possibly the drive your PCMCIA NIC uses. If you don't post any information that is *useful* for seeing what is happening, this is a waste of time for all of us. I wouldn't be surprised if the same thing was happening to him as happened to me with my WLAN card - ifplugd now tries to deal with it, and until this morning's updates it would launch then terminate itself a minute later and take the connection down with it. Now it doesn't seem to do that any more. Note: why the hell has Evolution just started wrapping at these ridiculously short line lengths? I didn't change anything. Fred? -- adamw
Re: [Cooker] dhcpcd cooked
Supplementary to previous - the problem I noted with ifplugd isn't actually fixed. When it starts on boot, it still exits and brings the connection down with it after about two minutes. I have to put the connection up manually with ifup eth0. This is on my laptop, with a PCMCIA WLAN card using the orinoco_cs driver. It's clearly exiting intentionally, not just crashing, according to /var/log/messages. And what the FUCK is wrong with Evolution's word wrap? Argh. -- adamw
Re: [Cooker] dhcpcd cooked
On Sat, 19 Jul 2003, Adam Williamson wrote: Supplementary to previous - the problem I noted with ifplugd isn't actually fixed. When it starts on boot, it still exits and brings the connection down with it after about two minutes. I have to put the connection up manually with ifup eth0. This is on my laptop, with a PCMCIA WLAN card using the orinoco_cs driver. It's clearly exiting intentionally, not just crashing, according to /var/log/messages. And what the FUCK is wrong with Evolution's word wrap? Argh. Log messages? ifstatus -v output before and after 'service network restart'? It might also be an idea to see if ifplugd is affected by gcc-3.3.1, dropping optimisation flags may help (just tested, samba-2.2.8a works with -Os). Regards, Buchan -- |Registered Linux User #182071-| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 ** Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. **
Re: [Cooker] dhcpcd cooked
On Sat, 2003-07-19 at 01:08, Adam Williamson wrote: I wouldn't be surprised if the same thing was happening to him as happened to me with my WLAN card - ifplugd now tries to deal with it, and until this morning's updates it would launch then terminate itself a minute later and take the connection down with it. Now it doesn't seem to do that any more. Note: why the hell has Evolution just started wrapping at these ridiculously short line lengths? I didn't change anything. Fred? Eek, sorry to reply to myself, but this just gets weirder and weirder. See, when I TYPED the above message the line breaks appeared in entirely different places. As I'm typing this, there's a line break at just, one at I, one at line, one at different and one at line again. Yet when I post they'll be somewhere else, it seems, and the message will appear normal, and you'll think I'm all on crack. I can post a screenshot if anyone's worried about my mental health. This is one weird bug. Fred, I'm sure it's your fault. :) -- adamw
Re: [Cooker] dhcpcd cooked
On Sat, 2003-07-19 at 01:25, Buchan Milne wrote: On Sat, 19 Jul 2003, Adam Williamson wrote: Supplementary to previous - the problem I noted with ifplugd isn't actually fixed. When it starts on boot, it still exits and brings the connection down with it after about two minutes. I have to put the connection up manually with ifup eth0. This is on my laptop, with a PCMCIA WLAN card using the orinoco_cs driver. It's clearly exiting intentionally, not just crashing, according to /var/log/messages. And what the FUCK is wrong with Evolution's word wrap? Argh. Log messages? ifstatus -v output before and after 'service network restart'? It might also be an idea to see if ifplugd is affected by gcc-3.3.1, dropping optimisation flags may help (just tested, samba-2.2.8a works with -Os). Log: [EMAIL PROTECTED] adamw]# cat /var/log/messages | grep ifplugd ... Jul 19 01:13:49 toy /etc/hotplug/net.agent: invoke ifplugd eth0 Jul 19 01:13:49 toy ifplugd(eth0)[902]: Using interface eth0/00:20:E0:88:43:8D with driver orinoco_cs (version: orinoco.c 0.13c (David Gibson ) Jul 19 01:13:49 toy ifplugd(eth0)[902]: Using detection mode: wireless extensionJul 19 01:13:49 toy ifplugd(eth0)[902]: ifplugd 0.15 successfully initialized, link beat not detected. Jul 19 01:13:50 toy ifplugd(eth0)[902]: Link beat detected. Jul 19 01:13:51 toy ifplugd(eth0)[902]: Executing '/etc/ifplugd/ifplugd.action eth0 up'. Jul 19 01:13:54 toy ifplugd(eth0)[902]: Program executed successfully. Jul 19 01:14:49 toy ifplugd(eth0)[902]: Executing '/etc/ifplugd/ifplugd.action eth0 down'. Jul 19 01:14:50 toy ifplugd(eth0)[902]: Program executed successfully. Jul 19 01:14:50 toy ifplugd(eth0)[902]: Exiting. 01:13 is during boot, there's nothing much going on at 01:14, it just shuts itself down. This happens reliably on every boot. ifstatus -v before and after restarting PCMCIA and network services shows the first three operations not supported, then Wireless: link beat detected. -- adamw
Re: [Cooker] dhcpcd cooked
On Friday 18 July 2003 12:25 pm, Buchan Milne wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 w9ya wrote: HOWEVER: After rebooting the laptop without the pcmcia network card inserted, and then inserting it watching on a root tty.well as I suspected this mimmicks the pcmcia network card issues that plagued the 8.x releases and I think got fixed shortly before 9.1 was released. The scripts are clearly hanging. As I recall there was much discussion of this in the past. SO this must just be a case of deja-vu !! AFAIK, no PCMCIA cards can accurately tell you the status of the cable. If you aren't connected, pop the card out, if you are, pop it in, otherwise you will see things like this. If we can't tell if we are connected, we have to try dhcp, which may result in a long timeout if not connected = get a card that has support for this, most onboard NICs in new laptops do. Let me be very specific. It worked, then I updated, then it didn't work. Something must have changed in the updating I guess. Since I can get this to work from a command line, I don't see why a script cannot also work, and *again* it was working. Additionally there is no reason to go looking for the status of the cable in this case. One should just be loading drivers (which is happening) and then if your system is dhcp based, getting a lease. Perhaps I don't truly understand what you are saying. Since I am not going to be fixing this, and only reporting function that was working at one point, I am not sure it makes much difference that I know that much about it anyways. Thanks for the attention. Bob Finch p.s. The fix for me was script in rc.local to take care of this. Prolly Sigh. going to have to that again. No big deal just wanted to get this on the record. It would then also be useful to have the output of 'ifstatus -v interface' for each card, in different states (ie plugged in, not pluggged in). And you might also want to show us what you have in /etc/sysconfig/network-scripts/ifcfg-eth0, especially MII_UNSUPPORTED or whatever it is (aka the network hotplugging checkbox in drakconnect in expert mode). My cooker box with a RTL-8139 never has problems like this ;-) but then again it is always connected, and ifplugd does work well with it. That's nice. Well as I mentioned in the original post, even with the card installed prior to turning the laptop on, I get the same results. And yes I do understand it might be using the hotplugd stuff anyways. Certainly some of the same scripts are called. Regards, Buchan - -- Sure thing' Bob Finch |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/GC2NrJK6UGDSBKcRAj6aAJ0bjts72HfVnuG2YDEtvccZ5rjX1QCgihcK ouLDkoJgdSjNADpI86AJyTE= =I9zZ -END PGP SIGNATURE- ** Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. **
Re: [Cooker] dhcpcd cooked
On Friday 18 July 2003 04:37 pm, you wrote: On Fri, 18 Jul 2003, w9ya wrote: O.k. Here's yet some more observations. I was premature in stating that conditions had changed. It now appears that sometimes a full dhcp lease is retreved, and THEN logging into kde via kdm is killing the interface etc. (eth0), and at other times the interface and lease never get completed. In both cases the drivers are there. Posting anecdotes about the things you were doing when something took your interface down isn't going to help. Not really, it can be very useful. Someone who made the changes might very well know the changes that were made. (I sure as heck don't.) If you want to try and fix this, post the output of 'ifstatus -v eth0' at the time when the interface is up, and when it is down, and the contents of your /etc/sysconfig/networks-scripts/ifcfg-eth0, and possibly the drive your PCMCIA NIC uses. No difference whatsoever with ifstatus between/during the two conditions tested. The ifcfg-eth0 is dhcp protocol and during boot (and needing the hostname) , but I mentioned or inferred all of this info before. If you don't post any information that is *useful* for seeing what is happening, this is a waste of time for all of us. Well, since the two above are not truly useful, I guess I don't have anything to report, unless you have something more specific you want me to look at. Are you by chance the maintainer of any of the associated packages ? Bob Finch
Re: [Cooker] dhcpcd cooked
This is exactly what went on and was fixed immediately prior to the 9.1 release (and ifstaus -v is unchanged in either condition also). In my case I am using the pcnet_cs card, so it probably isn't specific to driver. Bob Finch On Friday 18 July 2003 07:42 pm, Adam Williamson wrote: On Sat, 2003-07-19 at 01:25, Buchan Milne wrote: On Sat, 19 Jul 2003, Adam Williamson wrote: Supplementary to previous - the problem I noted with ifplugd isn't actually fixed. When it starts on boot, it still exits and brings the connection down with it after about two minutes. I have to put the connection up manually with ifup eth0. This is on my laptop, with a PCMCIA WLAN card using the orinoco_cs driver. It's clearly exiting intentionally, not just crashing, according to /var/log/messages. And what the FUCK is wrong with Evolution's word wrap? Argh. Log messages? ifstatus -v output before and after 'service network restart'? It might also be an idea to see if ifplugd is affected by gcc-3.3.1, dropping optimisation flags may help (just tested, samba-2.2.8a works with -Os). Log: [EMAIL PROTECTED] adamw]# cat /var/log/messages | grep ifplugd ... Jul 19 01:13:49 toy /etc/hotplug/net.agent: invoke ifplugd eth0 Jul 19 01:13:49 toy ifplugd(eth0)[902]: Using interface eth0/00:20:E0:88:43:8D with driver orinoco_cs (version: orinoco.c 0.13c (David Gibson ) Jul 19 01:13:49 toy ifplugd(eth0)[902]: Using detection mode: wireless extensionJul 19 01:13:49 toy ifplugd(eth0)[902]: ifplugd 0.15 successfully initialized, link beat not detected. Jul 19 01:13:50 toy ifplugd(eth0)[902]: Link beat detected. Jul 19 01:13:51 toy ifplugd(eth0)[902]: Executing '/etc/ifplugd/ifplugd.action eth0 up'. Jul 19 01:13:54 toy ifplugd(eth0)[902]: Program executed successfully. Jul 19 01:14:49 toy ifplugd(eth0)[902]: Executing '/etc/ifplugd/ifplugd.action eth0 down'. Jul 19 01:14:50 toy ifplugd(eth0)[902]: Program executed successfully. Jul 19 01:14:50 toy ifplugd(eth0)[902]: Exiting. 01:13 is during boot, there's nothing much going on at 01:14, it just shuts itself down. This happens reliably on every boot. ifstatus -v before and after restarting PCMCIA and network services shows the first three operations not supported, then Wireless: link beat detected.
Re: [Cooker] dhcpcd cooked
This is exactly what went on and was fixed immediately prior to the 9.1 release (and ifstaus -v is unchanged in either condition also). In my case I am using the pcnet_cs card, so it probably isn't specific to driver. Bob Finch On Friday 18 July 2003 07:42 pm, Adam Williamson wrote: On Sat, 2003-07-19 at 01:25, Buchan Milne wrote: On Sat, 19 Jul 2003, Adam Williamson wrote: Supplementary to previous - the problem I noted with ifplugd isn't actually fixed. When it starts on boot, it still exits and brings the connection down with it after about two minutes. I have to put the connection up manually with ifup eth0. This is on my laptop, with a PCMCIA WLAN card using the orinoco_cs driver. It's clearly exiting intentionally, not just crashing, according to /var/log/messages. And what the FUCK is wrong with Evolution's word wrap? Argh. Log messages? ifstatus -v output before and after 'service network restart'? It might also be an idea to see if ifplugd is affected by gcc-3.3.1, dropping optimisation flags may help (just tested, samba-2.2.8a works with -Os). Log: [EMAIL PROTECTED] adamw]# cat /var/log/messages | grep ifplugd ... Jul 19 01:13:49 toy /etc/hotplug/net.agent: invoke ifplugd eth0 Jul 19 01:13:49 toy ifplugd(eth0)[902]: Using interface eth0/00:20:E0:88:43:8D with driver orinoco_cs (version: orinoco.c 0.13c (David Gibson ) Jul 19 01:13:49 toy ifplugd(eth0)[902]: Using detection mode: wireless extensionJul 19 01:13:49 toy ifplugd(eth0)[902]: ifplugd 0.15 successfully initialized, link beat not detected. Jul 19 01:13:50 toy ifplugd(eth0)[902]: Link beat detected. Jul 19 01:13:51 toy ifplugd(eth0)[902]: Executing '/etc/ifplugd/ifplugd.action eth0 up'. Jul 19 01:13:54 toy ifplugd(eth0)[902]: Program executed successfully. Jul 19 01:14:49 toy ifplugd(eth0)[902]: Executing '/etc/ifplugd/ifplugd.action eth0 down'. Jul 19 01:14:50 toy ifplugd(eth0)[902]: Program executed successfully. Jul 19 01:14:50 toy ifplugd(eth0)[902]: Exiting. 01:13 is during boot, there's nothing much going on at 01:14, it just shuts itself down. This happens reliably on every boot. ifstatus -v before and after restarting PCMCIA and network services shows the first three operations not supported, then Wireless: link beat detected.
Re: [Cooker] dhcpcd cooked
On Friday 18 July 2003 04:37 pm, you wrote: On Fri, 18 Jul 2003, w9ya wrote: O.k. Here's yet some more observations. I was premature in stating that conditions had changed. It now appears that sometimes a full dhcp lease is retreved, and THEN logging into kde via kdm is killing the interface etc. (eth0), and at other times the interface and lease never get completed. In both cases the drivers are there. Posting anecdotes about the things you were doing when something took your interface down isn't going to help. Not really, it can be very useful. Someone who made the changes might very well know the changes that were made. (I sure as heck don't.) If you want to try and fix this, post the output of 'ifstatus -v eth0' at the time when the interface is up, and when it is down, and the contents of your /etc/sysconfig/networks-scripts/ifcfg-eth0, and possibly the drive your PCMCIA NIC uses. No difference whatsoever with ifstatus between/during the two conditions tested. The ifcfg-eth0 is dhcp protocol and during boot (and needing the hostname) , but I mentioned or inferred all of this info before. If you don't post any information that is *useful* for seeing what is happening, this is a waste of time for all of us. Well, since the two above are not truly useful, I guess I don't have anything to report, unless you have something more specific you want me to look at. Are you by chance the maintainer of any of the associated packages ? Bob Finch
Re: [Cooker] dhcpcd cooked
On Friday 18 July 2003 12:25 pm, Buchan Milne wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 w9ya wrote: HOWEVER: After rebooting the laptop without the pcmcia network card inserted, and then inserting it watching on a root tty.well as I suspected this mimmicks the pcmcia network card issues that plagued the 8.x releases and I think got fixed shortly before 9.1 was released. The scripts are clearly hanging. As I recall there was much discussion of this in the past. SO this must just be a case of deja-vu !! AFAIK, no PCMCIA cards can accurately tell you the status of the cable. If you aren't connected, pop the card out, if you are, pop it in, otherwise you will see things like this. If we can't tell if we are connected, we have to try dhcp, which may result in a long timeout if not connected = get a card that has support for this, most onboard NICs in new laptops do. Let me be very specific. It worked, then I updated, then it didn't work. Something must have changed in the updating I guess. Since I can get this to work from a command line, I don't see why a script cannot also work, and *again* it was working. Additionally there is no reason to go looking for the status of the cable in this case. One should just be loading drivers (which is happening) and then if your system is dhcp based, getting a lease. Perhaps I don't truly understand what you are saying. Since I am not going to be fixing this, and only reporting function that was working at one point, I am not sure it makes much difference that I know that much about it anyways. Thanks for the attention. Bob Finch p.s. The fix for me was script in rc.local to take care of this. Prolly Sigh. going to have to that again. No big deal just wanted to get this on the record. It would then also be useful to have the output of 'ifstatus -v interface' for each card, in different states (ie plugged in, not pluggged in). And you might also want to show us what you have in /etc/sysconfig/network-scripts/ifcfg-eth0, especially MII_UNSUPPORTED or whatever it is (aka the network hotplugging checkbox in drakconnect in expert mode). My cooker box with a RTL-8139 never has problems like this ;-) but then again it is always connected, and ifplugd does work well with it. That's nice. Well as I mentioned in the original post, even with the card installed prior to turning the laptop on, I get the same results. And yes I do understand it might be using the hotplugd stuff anyways. Certainly some of the same scripts are called. Regards, Buchan - -- Sure thing' Bob Finch |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/GC2NrJK6UGDSBKcRAj6aAJ0bjts72HfVnuG2YDEtvccZ5rjX1QCgihcK ouLDkoJgdSjNADpI86AJyTE= =I9zZ -END PGP SIGNATURE- ** Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. **
Re: [Cooker] dhcpcd cooked
On Friday 18 July 2003 04:37 pm, you wrote: On Fri, 18 Jul 2003, w9ya wrote: O.k. Here's yet some more observations. I was premature in stating that conditions had changed. It now appears that sometimes a full dhcp lease is retreved, and THEN logging into kde via kdm is killing the interface etc. (eth0), and at other times the interface and lease never get completed. In both cases the drivers are there. Posting anecdotes about the things you were doing when something took your interface down isn't going to help. Not really, it can be very useful. Someone who made the changes might very well know the changes that were made. (I sure as heck don't.) If you want to try and fix this, post the output of 'ifstatus -v eth0' at the time when the interface is up, and when it is down, and the contents of your /etc/sysconfig/networks-scripts/ifcfg-eth0, and possibly the drive your PCMCIA NIC uses. No difference whatsoever with ifstatus between/during the two conditions tested. The ifcfg-eth0 is dhcp protocol and during boot (and needing the hostname) , but I mentioned or inferred all of this info before. If you don't post any information that is *useful* for seeing what is happening, this is a waste of time for all of us. Well, since the two above are not truly useful, I guess I don't have anything to report, unless you have something more specific you want me to look at. Are you by chance the maintainer of any of the associated packages ? Bob Finch
Re: [Cooker] dhcpcd cooked
On Friday 18 July 2003 04:37 pm, you wrote: On Fri, 18 Jul 2003, w9ya wrote: O.k. Here's yet some more observations. I was premature in stating that conditions had changed. It now appears that sometimes a full dhcp lease is retreved, and THEN logging into kde via kdm is killing the interface etc. (eth0), and at other times the interface and lease never get completed. In both cases the drivers are there. Posting anecdotes about the things you were doing when something took your interface down isn't going to help. Not really, it can be very useful. Someone who made the changes might very well know the changes that were made. (I sure as heck don't.) If you want to try and fix this, post the output of 'ifstatus -v eth0' at the time when the interface is up, and when it is down, and the contents of your /etc/sysconfig/networks-scripts/ifcfg-eth0, and possibly the drive your PCMCIA NIC uses. No difference whatsoever with ifstatus between/during the two conditions tested. The ifcfg-eth0 is dhcp protocol and during boot (and needing the hostname) , but I mentioned or inferred all of this info before. If you don't post any information that is *useful* for seeing what is happening, this is a waste of time for all of us. Well, since the two above are not truly useful, I guess I don't have anything to report, unless you have something more specific you want me to look at. Are you by chance the maintainer of any of the associated packages ? Bob Finch -- |Registered Linux User #182071-| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 ** Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. **
