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 Milne                Mechanical 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.
******************************************************************

Reply via email to