[Soekris] net4521 Phy Link

[Joseph Barstow]

Hi all,
    Short version: Is there a way to make 'ifconfig <dev> down' break phy
link on the net4521's onboard Ethernet ports?

    Long version: I'm working with a net4521 for a school project and have a
small obstacle.  I have a Windows PC connected to each of the two Ethernet
ports which are using DHCP for their IP address configurations.  The demo
setup is such that the Windows PCs are fully booted before the net4521
powers on.  Herein lies the problem.
    My setup of Busybox Linux with kernel 2.6.19 takes approximately 90
seconds to boot from the CF card, but the Windows PCs begin sending DHCP
requests as soon as the net4521 powers on and phy link comes up.  By the
time dnsmasq is running to respond to the DHCP requests, the Windows PCs
have given up and backed off to a slow retry.  All-in-all, despite the fact
the net4521 only takes 90 seconds to boot, they don't receive usable IP
configurations for approximately 5 minutes.
    The best solution to this problem I can think of is to break phy link on
both ports with an 'ifconfig <dev> down' command early in the boot sequence,
and then bring it back up after dnsmasq is ready for DHCP requests, thus
triggering the Windows PCs to ask for an address config.  However, ifconfig
seems unable to break phy link on either Ethernet port.  Is there anything I
can do about this?  Should I be using a specific driver module rather than
the standard Ethernet support compiled into the 2.6.19 kernel?  Will Capone
and his boys rule the streets of Chicago forever?

Other vital information:
The context of the project is such that client PCs are expected to be
varying and random.  I cannot use static configurations or alter the Windows
DHCP timer -- I must attempt to fix this from the net4521's side.
Suggestions for accomplishing this without trying to break phy link are
welcomed.

Thanks guys,
Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.soekris.com/pipermail/soekris-tech/attachments/20061228/8ae13409/attachment.html