udhcpc: not adding userclass to the script env (anymore...)?

Denys Vlasenko vda.linux at googlemail.com
Sat May 21 18:46:09 UTC 2011

On Friday 20 May 2011 19:38, Paul Smith wrote:
> Hi all.
> I was using busybox 1.15.3, and configured my DHCP server to send a
> userclass value of 'FOO' with the registration response.  I use dnsmasq
> and the dnsmasq config was:
> dhcp-option-force=77,"FOO"
> (option 77 decimal, or 0x4D, is the userclass option).
> With busybox 1.15.3, this value was then added to the environment in my
> udhcpc script; if I checked the "userclass" env. var. I would see it set
> to "FOO".
> Now I've upgraded to busybox 1.18.3, and using the identical DHCP server
> and configuration, the udhcpc version that comes with 1.18.3 does not
> add the "userclass" value to the environment; running "env" in the
> script udhcpc invokes shows that variable is not present (not set).  I
> have all the same settings in my busybox config as before and I've
> checked and don't see anything new in the udhcp config.
> My system kind of depends on this information (basically each network
> interface on my system can be attached to one of two different subnets
> and I use this value set by the DHCP server to tell the client what
> subnet that interface is attached to).
> Is this something that got broken or lost?  Or am I doing something
> wrong?

The problem is that option 77 has a peculiar format

4. User Class option

   This option is used by a DHCP client to optionally identify the type
   or category of user or applications it represents.  A DHCP server
   uses the User Class option to choose the address pool it allocates an
   address from and/or to select any other configuration option.

   This option is a DHCP option [1, 2].

   This option MAY carry multiple User Classes.  Servers may interpret
   the meanings of multiple class specifications in an implementation
   dependent or configuration dependent manner, and so the use of
   multiple classes by a DHCP client should be based on the specific
   server implementation and configuration which will be used to process
   that User class option.

   The format of this option is as follows:

         Code   Len   Value
        +-----+-----+---------------------  . . .  --+
        | 77  |  N  | User Class Data ('Len' octets) |
        +-----+-----+---------------------  . . .  --+

   where Value consists of one or more instances of User Class Data.
   Each instance of User Class Data is formatted as follows:

         UC_Len_i     User_Class_Data_i
        +--------+------------------------  . . .  --+
        |  L_i   | Opaque-Data ('UC_Len_i' octets)   |
        +--------+------------------------  . . .  --+

   Each User Class value (User_Class_Data_i) is indicated as an opaque
   field.  The value in UC_Len_i does not include the length field
   itself and MUST be non-zero.  Let m be the number of User Classes
   carried in the option.  The length of the option as specified in Len
   must be the sum of the lengths of each of the class names plus m:
   Len= UC_Len_1 + UC_Len_2 + ... + UC_Len_m + m.  If any instances of
   User Class Data are present, the minimum value of Len is two (Len =
   UC_Len_1 + 1 = 1 + 1 = 2).

   The Code for this option is 77.

   A server that is not equipped to interpret any given user class
   specified by a client MUST ignore it (although it may be reported).
   If a server recognizes one or more user classes specified by the
   client, but does not recognize one or more other user classes
   specified by the client, the server MAY use the user classes it

   DHCP clients implementing this option SHOULD allow users to enter one
   or more user class values.

See? According to this RFC, it's not an ASCIZ string.
At best, it may be a set of LASCII strings.
It may be even a set of something else than strings.

Can you send be an example of the DHCP packets which your server emits?


More information about the busybox mailing list