On 14 Apr 2015, at 18:41, Jorge Pereira <jpereiran@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@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2