Re: ANNOUNCE: new DHCP client for linux 2.6.x

2006-02-26 Thread Stefan Rompf
Hi,

Am Freitag 17 Februar 2006 20:39 schrieb Simon Barber:

 In 802.11 networks when connecting to a new AP on the same networks
 (same SSID  security settings) you typically don't have to do DHCP
 again - but with some networks setups you do. In order to detect this,
 when connecting to a new AP always issue an ARP request for the default
 gateway - if you don't get a response, then kick off a dhcp request.

I've just implemented the feature. As the client does not know the specific 
wireless settings, I've chosen this approach to verify the IP address:

-downtime must be lower than 60 seconds
-T1 (RENEWal time) has not passed yet
-IP address of default gateway is ARP probed and must answer with the known 
MAC address of the default gateway. Maximum 3 (is configurable) tries with .5 
sec delay.

If any of this fails, the client tries to verify the IP address via DHCP for 
four seconds, then drops IP configuration and restarts if it is NAKed or not 
answered.

Got to do more tests of course, but this sounds like a workable solution to 
me.

Jamal: Your idea of influencing the statemachine from the called scripts 
hasn't been forgotten, but a communication channel from script to daemon must 
be well designed and there is still too much other stuff on my todo list.

Stefan

shameless readvertisement
http://www.flamewarmaster.de/software/dhcpclient/
/shameless readvertisement
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: ANNOUNCE: new DHCP client for linux 2.6.x

2006-02-17 Thread Jean Tourrilhes
Stefan Rompf wrote :
 
  dhcpclient
 
A DHCP client for linux 2.6, using modern kernel features, (c) 2006
Stefan Rompf.
 
 Motivation
 
Using a notebook, I'm often traveling between different networks.
After replugging, I always needed to issue a ifdown/ifup sequence
because the DHCP client did not realize the temporary disconnection.
This is an unneeded limitation because since 2.6, the kernel notifies
userspace of these disconnection/reconnection events. Actually is was
me who implemented this feature.
 
Beginning with 2.6.17, the linux kernel will allow userspace to
influence this signalling, so that for example a wpa supplicant can
tell the dhcpclient that an association has finished and the client
should try to get an IP address.
 
Of course, you need software that support this feature. Unfortunately,
most existing DHCP clients implemented their statemachine using
siglongjmp() or one huge function, so there was no easy way extending
them. So I wrote a new one.

I congratulate you on your good work.
I will share with you my personal gripe on most DHCP clients :
they depend too much on those link signalling. I hope you appreciate
the irony ;-)

I'm personally setup with a WLAN in Ad-Hoc mode. I've got so
many WLAN cards left over from previous projects that I don't really
need an Access Point. One of the PC in Ad-Hoc mode act as a DHCP
server (trivial to configure on most distro).
In Ad-Hoc mode, you can't have any link notification. Think
about it, an Ad-Hoc network with only a single node is valid, because
you need to start somewhere. The PC with the DHCP server doesn't have
any specific meaning at the link layer, and might actually go down
sometimes (reboot to update kernel).
After 'ifup', the DHCP client tries a few time to connect to
the DHCP server, and if not in range, will give up and never
retry. When I bring my laptop within range of my DHCP server, nothing
happens. I have to manually restart the interface.

If you are not familiar with WLAN Ad-Hoc mode, I'll give you a
conceptual equivalent with Ethernet.
Let suppose you have a Ethernet switch on your desk (or under
your desk), and the uplink is *NOT* connected to the rest of the
network. You plug your PC into the switch. You get a netlink event
saying that you have a valid Ethernet link, but your DHCP will fail.
At the point when you will connect the uplink to the switch,
the PC will not notice it and DHCP will not get an address.
In essence, in WLAN Ad-Hoc mode the link to the switch is
always valid but the uplink may or may not be connected.

Have fun...

Jean
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: ANNOUNCE: new DHCP client for linux 2.6.x

2006-02-17 Thread Simon Barber
A quick suggestion for a feature improvement...

In 802.11 networks when connecting to a new AP on the same networks
(same SSID  security settings) you typically don't have to do DHCP
again - but with some networks setups you do. In order to detect this,
when connecting to a new AP always issue an ARP request for the default
gateway - if you don't get a response, then kick off a dhcp request.

Simon
 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Stefan Rompf
Sent: Friday, February 17, 2006 6:37 AM
To: netdev@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: ANNOUNCE: new DHCP client for linux 2.6.x


  dhcpclient

   A DHCP client for linux 2.6, using modern kernel features, (c) 2006
   Stefan Rompf.

Motivation

   Using a notebook, I'm often traveling between different networks.
   After replugging, I always needed to issue a ifdown/ifup sequence
   because the DHCP client did not realize the temporary disconnection.
   This is an unneeded limitation because since 2.6, the kernel notifies
   userspace of these disconnection/reconnection events. Actually is was
   me who implemented this feature.

   Beginning with 2.6.17, the linux kernel will allow userspace to
   influence this signalling, so that for example a wpa supplicant can
   tell the dhcpclient that an association has finished and the client
   should try to get an IP address.

   Of course, you need software that support this feature.
Unfortunately,
   most existing DHCP clients implemented their statemachine using
   siglongjmp() or one huge function, so there was no easy way extending
   them. So I wrote a new one.

Features

 * RFC2131 compatible DHCP client, tested with ISC dhcpd directly
and
   via a Cisco IOS relay agent, Cisco IOS DHCP server and dnsmasq.
 * uses netlink for interface configuration
 * does act on link state messages
 * calls a script on every state change to allow updating
resolv.conf
   etc
 * small, compiles with [1]uclibc

Status

   Currently, this is alpha software. It shouldn't be used in production
   environment, but I'm looking forward for people who like to test it
in
   different environments and for (reasonable ;-) feature suggestions!

Support

   The webpage is at
[2]http://www.flamewarmaster.de/software/dhcpclient/

   There is a mailing list available on
   [3]http://www.flamewarmaster.de/mailman/listinfo/dhcpclient/

References

   1. http://www.uclibc.org/
   2. http://www.flamewarmaster.de/software/dhcpclient/
   3. http://www.flamewarmaster.de/mailman/listinfo/dhcpclient/
-
To unsubscribe from this list: send the line unsubscribe netdev in the
body of a message to [EMAIL PROTECTED] More majordomo info at
http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: ANNOUNCE: new DHCP client for linux 2.6.x

2006-02-17 Thread Stefan Rompf
Am Freitag 17 Februar 2006 19:39 schrieb Jean Tourrilhes:

   I congratulate you on your good work.

Thanks!

   I will share with you my personal gripe on most DHCP clients :
 they depend too much on those link signalling. I hope you appreciate
 the irony ;-)

Someone needs a feature, another one hates it ;-)

   After 'ifup', the DHCP client tries a few time to connect to
 the DHCP server, and if not in range, will give up and never
 retry. When I bring my laptop within range of my DHCP server, nothing
 happens. I have to manually restart the interface.

... but still, my client may be interesting for you because it doesn't give 
up. If it cannot get an IP address, the backoff between DHCP discovers goes 
up to the RFC 2131 mandated 64 seconds, but it will keep trying.

Stefan
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: ANNOUNCE: new DHCP client for linux 2.6.x

2006-02-17 Thread Stefan Rompf
Am Freitag 17 Februar 2006 20:39 schrieb Simon Barber:

 In 802.11 networks when connecting to a new AP on the same networks
 (same SSID  security settings) you typically don't have to do DHCP
 again - but with some networks setups you do. In order to detect this,
 when connecting to a new AP always issue an ARP request for the default
 gateway - if you don't get a response, then kick off a dhcp request.

good idea, I'll revisit this after if have ARP probing implemented. Right now, 
my client goes to INIT_REBOOT and tries to verify the address for four 
seconds without giving up IP configuration. This puts more load onto the DHCP 
server, but should lead to the same result.

Stefan
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: ANNOUNCE: new DHCP client for linux 2.6.x

2006-02-17 Thread jamal
On Fri, 2006-17-02 at 21:49 +0100, Stefan Rompf wrote:
 Am Freitag 17 Februar 2006 20:39 schrieb Simon Barber:
 
  In 802.11 networks when connecting to a new AP on the same networks
  (same SSID  security settings) you typically don't have to do DHCP
  again - but with some networks setups you do. In order to detect this,
  when connecting to a new AP always issue an ARP request for the default
  gateway - if you don't get a response, then kick off a dhcp request.
 
 good idea, I'll revisit this after if have ARP probing implemented. Right 
 now, 
 my client goes to INIT_REBOOT and tries to verify the address for four 
 seconds without giving up IP configuration. This puts more load onto the DHCP 
 server, but should lead to the same result.
 

A nice feature is to have scripts invoked at different DHCP
states/hooks.
This way you let people who want to do ARP probing do it from a user
space script before transitioning for example to INIT_REBOOT.

cheers,
jamal

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: ANNOUNCE: new DHCP client for linux 2.6.x

2006-02-17 Thread Jean Tourrilhes
On Fri, Feb 17, 2006 at 09:44:39PM +0100, Stefan Rompf wrote:
 Am Freitag 17 Februar 2006 19:39 schrieb Jean Tourrilhes:
 
  I congratulate you on your good work.
 
 Thanks!
 
  I will share with you my personal gripe on most DHCP clients :
  they depend too much on those link signalling. I hope you appreciate
  the irony ;-)
 
 Someone needs a feature, another one hates it ;-)
 
  After 'ifup', the DHCP client tries a few time to connect to
  the DHCP server, and if not in range, will give up and never
  retry. When I bring my laptop within range of my DHCP server, nothing
  happens. I have to manually restart the interface.
 
 ... but still, my client may be interesting for you because it doesn't give 
 up. If it cannot get an IP address, the backoff between DHCP discovers goes 
 up to the RFC 2131 mandated 64 seconds, but it will keep trying.

Yep, that seems to be the proper behaviour.
The only other thing missing is setting the DHCP lease time to
some reasonable value in the server so that when I go out of range it
goes back to searching, but that's clearly not a client issue...
So, it seems that your new client would address the need of
Ad-Hoc mode users. Pretty cool.

 Stefan

Thanks !

Jean
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html