Proposed patch: VLAN support in udhcpc

[Nigel Hathaway]

Denys,

Are you happy with the patch I submitted to the mailing list?

Nigel

-----Original Message-----
From: Denys Vlasenko [mailto:vda.linux at googlemail.com] 
Sent: 22 March 2011 07:52
To: busybox at busybox.net
Cc: Nigel Hathaway
Subject: Re: Proposed patch: VLAN support in udhcpc

On Friday 18 March 2011 14:19, Nigel Hathaway wrote:
> I am implementing VLAN support for a VoIP product. Typically, VLAN is
> used to tag the priority of voice packets, so that they can be given
> priority over other traffic right from the ingress point of the switch
> that the VoIP product is connected to. Typically VLAN ID 0 is used for
> this, but we are implementing a generalised VLAN solution.
> 
> Getting udhcpc to recognise and support DHCP options 132 (802.1P VLAN
> ID) and 133 (802.1Q L2 Priority) is a trivial exercise, as is passing
> the returned values as environment variables to the script.
> 
> However, the logic of handling this is not quite so simple. What
happens
> is as follows:
> 
> The DCHP client requests an IP address using a standard Ethernet port,
> say eth0. The DHCP server replies with an IP address and a VLAN ID and
> Priority. The full discover/offer/request/acknowledge sequence is then
> completed, and then the client immediately releases the address it has
> just been given. The client configures VLAN as requested and does a
> fresh DHCP sequence on the specified VLAN, this time retaining the IP
> address.
> 
> Note: all current well-know VoIP equipment that uses VLAN works this
way
> (Siemens, Mitel, etc.) Usually, the DHCP server is triggered to tell
the
> client to use VLAN because the client has provided a class identifier
> (DHCP option 60) which the DHCP server has been set up to recognise.
> 
> The proposed implementation is as follows:
> 
> On top of having udhcpc recognising the 2 VLAN DHCP options, it is
> proposed that the entire operation of switching over to VLAN should be
> handled by the script.
> 
> On recognising that VLAN is requested, the script would run vconfig to
> create the VLAN virtual interface, say eth0.0, and would then start up
a
> fresh instance of udhcpc using that interface. The script would then
> signal then calling instance of udhcpc to terminate, releasing the
lease
> for eth0.
> 
> Can anyone see any problems with this?
> 
> The potential problems that I foresee are timing related. Ideally the
> release sequence should happen before the new request sequence is
> started, but I don't think this will happen this way.

Script needs to die, allowing parent udhcpc to continue.
Something like:

# Create a child which will spawn new udhcpc shortly
(sleep N; create_vlan_and_start_new_udhcpc) &
# Ask parent udhcpc to exit
kill $PPID
# And now script exits
exit 0


> Also, I presume we have to send 2 signals from the script to the
calling
> udhcpc sequence: SIGUSR2 to get it to do the release and SIGINT to get
> it to exit, or is there a better way to do this?

Run parent udhcpc with -R (release on exit).

> Will this cause the 
> parent to kill the script before it has finished?

No, udhcpc never kills the script.

> Or would it be better 
> to have the script return a value that indicates that the calling
udhcpc
> instance should terminate and relinquish the lease?

Looks like it is not necessary.

-- 
vda