python unpack buffer data

Question

I am using the rlm_python module in radius and its get the DHCP location option82 from coovachilli in hex or binary format.

Catching it as a string shows as this value \001\027\002\025\001+\001\024, but looks the value which python shows is truncated, as the option82 contains suboptions encoded in TLVs-type,length,values which means the field starts with type 0x01(circuit ID, per RFC 3046), followed by a one byte length.

Any idea how I can catch this and unpack the options properly?

I have unpacked the string using struct.unpack but is not meaningful..as it does not tell about the packed suboptions in option82 field.

Python 2.4.3 (#1, May  5 2011, 16:39:10) 
[GCC 4.1.2 20080704 (Red Hat 4.1.2-50)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from struct import *
>>> unpack('=hhl',"\001\027\002\025\001+\001\024" )
(5889, 5378, 335620865)

any ideas?

UPDATE:

Coovachilli is compiled with --locationopt82 and it sends location as an attribute, something like this...

rad_recv: Accounting-Request packet from host 10.66.53.49 port 53178, id=101, length=342
        ChilliSpot-Version = "1.3.0"
        ChilliSpot-Acct-View-Point = ChilliSpot-Client-View-Point
        Event-Timestamp = "Apr 18 2013 11:59:16 BST"
        User-Name = "3C-D0-F8-4A-05-68"
        Acct-Input-Octets = 0
        Acct-Output-Octets = 22851
        Acct-Input-Gigawords = 0
        Acct-Output-Gigawords = 0
        Acct-Input-Packets = 0
        Acct-Output-Packets = 370
        Acct-Session-Time = 5401
        ChilliSpot-Session-State = Authorized
        Acct-Status-Type = Interim-Update
        Acct-Session-Id = "516fbceb00000002"
        Framed-IP-Address = 10.75.33.46
        NAS-Port-Type = Wireless-802.11
        NAS-Port = 2
        NAS-Port-Id = "00000002"
        Calling-Station-Id = "3C-D0-F8-4A-05-68"
        Called-Station-Id = "00-50-56-B7-66-00"
        NAS-IP-Address = 10.75.32.7
        ChilliSpot-Location = "\001\030\002\026\001+\001\024"
        ChilliSpot-Location-Change-Count = 15
        NAS-Identifier = "VLAN299-REGENT"
        WISPr-Location-ID = "isocc=GR,cc=44,ac=01200,network=mywifi,my_Network_regent"
        WISPr-Location-Name = "REGENT"

the freeradius has the rlm_python module which looks for accounting requests

def accounting(p):
    file = open("/tmp/test.log","a")
    username = None
    chillilocation = None
    output = StringIO.StringIO()

    for t in p:
        if t[0] == 'User-Name':
            username = t[1]
        elif t[0] == 'ChilliSpot-Location':
            chillilocation = t[1]a
             output.write(t[1])


    content = output.getvalue()


    file.write("I am being called in radius accouting section as %s and location is %s \n" % (username,content))
    file.close()
    print "---Accounting---"
    radiusd.radlog(radiusd.L_INFO, '*** radlog call in accounting (0) ***')
    print
    print p
    return radiusd.RLM_MODULE_OK

i have tried storing the ChilliSpot-Location in string and stringIO, unpacked using struct with no avail, It looks like its in TLV format...

any ideas how to strip it out?

How do you catch the value as a string using rlm_python and coovachilli? — RedBaron, Apr 18 '13 at 05:50
Not sure about the whole thing but `ChilliSpot-Location` is supposed to be a human-readable string. See [specs](http://wiki-robin.meshroot.com/@api/deki/files/220/=dictionary.chillispot) and [an example](http://coova.org/node/4170) (Browse down to somewhere in the middle where it says `RADIUS Access-Request from CoovaChilli`) — RedBaron, Apr 18 '13 at 11:25

score 0 · Answer 1 · answered May 01 '13 at 04:46

Unpack does not unpacks to "meaningful" values. It unpacks the string as a sequence of number fields, so that the size of each field is specified by each char of the format string (numbers preceding letters are multipliers).

Shouldn't the unpack use octet-sized fields?

>>> unpack('=8B',"\001\027\002\025\001+\001\024")
(1, 23, 2, 21, 1, 43, 1, 20)
# Or maybe '+' is a separator (43):
>>> unpack('=6Bh',"\001\027\002\025\001+\001\024")
(1, 23, 2, 21, 1, 43, 5121)

The first byte may be a circuit suboption code (unpack()[0]==1) with a strangelly high size of 23, meaning we didn't get the whole suboption value. But we may also have only the contained value of a suboption with size == 10, or 8 bytes of content.

I'm not so sure that an option 82 should contain a readable string, though "ChilliSpot-Location" does. RFC3046 indicates the circuit suboption is expected to contain things like "Router interface number", port numbers and other numerical values. But that property of rad_recv really came from a 82 option?

thanks for the reply, according to coova it is from the option 82 field on dhcp packet, if the unpack shows only the size, then where is the actual content, obviously it represents something... — krisdigitx, May 01 '13 at 15:46

python unpack buffer data

1 Answers1