[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

DHCP: renewal when cable is plugged out/in



Arnout Vandecappelle wrote:
>  Hoi,
> 
>  I have an RTEMS-based system which normally is not connected to the
> (Ether)network, but occasionally a user comes a long and plugs in a
> cable.  I need DHCP to get a new address whenever the network cable is
> plugged in, even if it's previous lease hasn't expired yet.  I also need
> DHCP to fall back to a statically configured address if no reply comes.
> 
>  My questions:
>  * does anyone have these features already?  I expect not, so

This is not normal behavior as network drop outs can occur at anytime and this 
is just one how-ever I can see the need with an embedded box in certain 
applications. I suggest this be an application you have.

>  * any suggestions on how to implement the network cable plug-in
> detection?  My Ethernet driver detects cable (dis)connects, how should
> these be propagated to the DHCP task?
>    - By setting the struct ifnet's if_flags and have the DHCP task poll
> on them; or

Yes this would seem to be the best path. Looking on my Linux box I see the 
following behavior with the cable in:

[chris at kaka ~]$ /sbin/ifconfig
eth0      Link encap:Ethernet  HWaddr 00:1A:4D:9A:1D:11
           inet addr:172.16.100.186  Bcast:172.16.100.255  Mask:255.255.255.0
           inet6 addr: fe80::21a:4dff:fe9a:1d11/64 Scope:Link
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
                        ^^^^^^^
           RX packets:36270897 errors:6 dropped:0 overruns:0 frame:6
           TX packets:23072244 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:46103590289 (42.9 GiB)  TX bytes:5563216546 (5.1 GiB)
           Interrupt:253 Base address:0x4000

Remove cable:

[chris at kaka ~]$ /sbin/ifconfig
eth0      Link encap:Ethernet  HWaddr 00:1A:4D:9A:1D:11
           inet addr:172.16.100.186  Bcast:172.16.100.255  Mask:255.255.255.0
           inet6 addr: fe80::21a:4dff:fe9a:1d11/64 Scope:Link
           UP BROADCAST MULTICAST  MTU:1500  Metric:1
           RX packets:36270901 errors:6 dropped:0 overruns:0 frame:6
           TX packets:23072252 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:46103591057 (42.9 GiB)  TX bytes:5563217714 (5.1 GiB)
           Interrupt:253 Base address:0x4000

Return cable:

[chris at kaka ~]$ /sbin/ifconfig
eth0      Link encap:Ethernet  HWaddr 00:1A:4D:9A:1D:11
           inet addr:172.16.100.186  Bcast:172.16.100.255  Mask:255.255.255.0
           inet6 addr: fe80::21a:4dff:fe9a:1d11/64 Scope:Link
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
                        ^^^^^^^
           RX packets:36270901 errors:6 dropped:0 overruns:0 frame:6
           TX packets:23072252 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:46103591057 (42.9 GiB)  TX bytes:5563217714 (5.1 GiB)
           Interrupt:253 Base address:0x4000

Setting the running flags is what happens here.

>    - by sending an event to the DHCP task; or

No this is not a good idea.

>    - by configuring a hook similar to the network taps, and having the
> DHCP task register a function to it; or

No. I think other better ways exist.

>    - by calling BSDnet's if_down() from the driver, make the DHCP task
> listen on the routing input socket.
> 
>  I guess the last option is the best, but it requires a bit of BSDnet
> insight...
> 

I think the flags is a good solution.

>  And one final question: is it OK to make changes to BSDnet itself, or
> is that to be avoided because it makes tracking the real BSDnet
> development more difficult?

We would prefer not to how-ever we have made a number of changes so it is hard 
to argue against changes. The change needs to be really needed, cannot be 
implemented in another way, and not just specific to something you need.

Can you configure short leases ?

Regards
Chris