[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    RE: Proposed patch: VLAN support in udhcpc
From:       "Nigel Hathaway" <Nigel.Hathaway () ubiquisys ! com>
Date:       2011-03-24 12:14:30
Message-ID: 094A73044298734FB7D58CAAA319E1D6036EC307 () UBIQ-SERV1 ! ubiquisys ! local
[Download RAW message or body]

Denys,

I found the code that handles signal and, as you say, the signal is
captured and handled later at the appropriate point.

You can send multiple signals and they get queued up, so you can send
SIGUSR2 followed by SIGTERM if you don't want to use the -R option.

Another way of handling the timing is to run udhcpc from the respawn
facility of inittab, and have it determine the ethernet interface (VLAN
or not) by some means.

I will make the VLAN option recognition conditionally compile on a new
config variable ENABLE_FEATURE_UDHCP_802_1 (unless you say otherwise).

I'll go with what you have suggested. I will submit a patch in the next
few weeks.

Nigel

-----Original Message-----
From: Denys Vlasenko 
Sent: 22 March 2011 07:52
To: busybox@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
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]