python decomprimere i dati del buffer

Question

Sto utilizzando il modulo rlm_python in radius e si ottiene la posizione DHCP option82 da coovachilli in formato esadecimale o binario.

Facendo come una stringa mostra come questo valore \001\027\002\025\001+\001\024, ma sembra che il valore spettacoli pitone è troncato, come option82 contiene suboptions codificati in TLVs-type,length,values che significa che il campo inizia con il tipo 0x01(circuit ID, per RFC 3046), seguita da una lunghezza byte.

Qualche idea su come sia possibile rilevare e decomprimere correttamente le opzioni?

ho scompattato la stringa utilizzando struct.unpack ma non è meaningful..as non raccontano la imballato suboptions nel option82 campo.

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) 

qualche idea?

UPDATE:

CoovaChilli è compilato con --locationopt82 e trasmette la posizione come un attributo, qualcosa di simile ...

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" 

il freeradius ha il modulo rlm_python che guarda per la contabilità richiede

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 

ho provato a memorizzare il ChilliSpot-Locati on in string e stringIO, scompattato usando struct senza alcun risultato, Sembra che sia in formato TLV ...

qualche idea su come spogliarlo?

Answer 1

Unpack non decomprime valori "significativi". Spacchetta la stringa come una sequenza di campi numerici, in modo che la dimensione di ogni campo sia specificata da ciascun carattere della stringa di formato (i numeri che precedono le lettere sono moltiplicatori).

In caso di decompressione, non utilizzare campi di dimensioni pari a ottetto?

>>> unpack ('= 8B', "\ 001 \ 027 \ 002 \ 025 \ 001+ \ 001 \ 024")
(1, 23, 2, 21, 1, 43, 1 , 20)
# O forse '+' è un separatore (43):
>>> decomprimere ('= 6Bh', "\ 001 \ 027 \ 002 \ 025 \ 001+ \ 001 \ 024")
(1, 23, 2, 21, 1, 43, 5121)

Il primo byte può essere un circuito codice opzione secondaria (unpack() [0] == 1) con un strangelly elevata dimensione di 23 significato non abbiamo ottenuto l'intero valore di sub-opzione. Ma potremmo anche avere solo il valore contenuto di una sotto opzione con dimensioni == 10 o 8 byte di contenuto.

Non sono sicuro che un'opzione 82 debba contenere una stringa leggibile, sebbene "ChilliSpot-Location" lo faccia. RFC3046 indica che l'opzione secondaria del circuito dovrebbe contenere cose come "Numero di interfaccia del router", numeri di porta e altri valori numerici. Ma quella proprietà di rad_recv proveniva davvero da un'opzione 82?