DHCP-Hostname + module/dhcp

[Arran Cudbard-Bell]

> On 14 Apr 2015, at 18:41, Jorge Pereira <jpereiran at gmail.com> wrote:
> 
> Hi,
> 
>    I have searched about the modules/dhcp and i know that don't have many
> information about that... only
> the example in [1] wasn't enough for understand and uses it.
> 
> btw, in my env i receive during "Access-Request" all packets sent from the
> UE to my BRAS (Alcatel 7750) like
> the packet below.
> 
>        Alc-ToServer-Dhcp-Options = 0x350103
>        Alc-ToServer-Dhcp-Options = 0x37090103060f775ffc2c2e
>        Alc-ToServer-Dhcp-Options = 0x390205dc
>        Alc-ToServer-Dhcp-Options = 0x3d0701facafaca0002
>        Alc-ToServer-Dhcp-Options = 0x3204c0a87b0b
>        Alc-ToServer-Dhcp-Options = 0x3604c0a87bfe
>        Alc-ToServer-Dhcp-Options = 0x0c0d4a6f7267652d50657265697261

FFS Are they really split out into separate attributes now? They used to be a contiguous blob... I hate Alcatel.

Theoretically you should be able to add the 'concat' flag to the dictionary entry, but when I tried, the server threw an error.

Errors reading dictionary: dict_init: /usr/local/freeradius/share/freeradius/dictionary.alcatel.sr[191]: VSAs cannot have the "concat" flag set

I don't know if Alan D wants to allow concatenation of VSAs? It seems like vendors may want to break an value across several attributes?

I've pushed a fix to the dhcp_options xlat so that it deals with the multi-value attribute reference syntax correctly, before it'd only use the first instance.

if (&Alc-ToServer-Dhcp-Options && ("%{dhcp_options:&Alc-ToServer-Dhcp-Options[*]}" == 0)) {
	update reply {
		Reply-Message := 'Failed decoding DHCP options'
	}
	invalid
}

(0)   authorize {
(0)     update request {
(0)       Alc-ToServer-Dhcp-Options := 0x350103
(0)       Alc-ToServer-Dhcp-Options += 0x37090103060f775ffc2c2e
(0)       Alc-ToServer-Dhcp-Options += 0x390205dc
(0)       Alc-ToServer-Dhcp-Options += 0x3d0701facafaca0002
(0)       Alc-ToServer-Dhcp-Options += 0x3204c0a87b0b
(0)       Alc-ToServer-Dhcp-Options += 0x3604c0a87bfe
(0)       Alc-ToServer-Dhcp-Options += 0x0c0d4a6f7267652d50657265697261
(0)     } # update request = noop
(0)     if (&Alc-ToServer-Dhcp-Options && ("%{dhcp_options:&Alc-ToServer-Dhcp-Options[*]}" == 0)) {
	DHCP-Message-Type += DHCP-Request
	DHCP-Parameter-Request-List += DHCP-Subnet-Mask
	DHCP-Parameter-Request-List += DHCP-Router-Address
	DHCP-Parameter-Request-List += DHCP-Domain-Name-Server
	DHCP-Parameter-Request-List += DHCP-Domain-Name
	DHCP-Parameter-Request-List += DHCP-Domain-Search
	DHCP-Parameter-Request-List += DHCP-LDAP
	DHCP-Parameter-Request-List += DHCP-Site-specific-28
	DHCP-Parameter-Request-List += DHCP-NETBIOS-Name-Servers
	DHCP-Parameter-Request-List += DHCP-NETBIOS-Node-Type
	DHCP-DHCP-Maximum-Msg-Size += 1500
	DHCP-Client-Identifier += 0x01facafaca0002
	DHCP-Requested-IP-Address += 192.168.123.11
	DHCP-DHCP-Server-Identifier += 192.168.123.254
	DHCP-Hostname += 'Jorge-Pereira'
(0)     EXPAND %{dhcp_options:&Alc-ToServer-Dhcp-Options[*]}
(0)        --> 15
(0)     if (&Alc-ToServer-Dhcp-Options && ("%{dhcp_options:&Alc-ToServer-Dhcp-Options[*]}" == 0))  -> FALSE
(0)   } # authorize = noop

In your case, if you only wanted to decode the last option (which appears to contain DHCP-Hostname), you could do:

if (&Alc-ToServer-Dhcp-Options && ("%{dhcp_options:&Alc-ToServer-Dhcp-Options[n]}" == 0)) {
	update reply {
		Reply-Message := 'Failed decoding DHCP options'
	}
	invalid
}

But order of values isn't guaranteed, so it might be fragile.

To use the above you'll need to build from v3.0.x head or wait until 3.0.8 is released.

-Arran

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS development team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 872 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20150414/1e846d5d/attachment.sig>