WiMAX TLV value correct in debug but not correct in packet capture

[Alan DeKok]

  You've done something to the dictionaries. What is it?  

  Alan DeKok.

On 2013-07-31, at 10:57 AM, James Leavitt <james.leavitt at corp.xplornet.com> wrote:

> HI Alan,
> 
> Still no dice. I've disabled the database and used the file as suggested
> (which is something that I had yet to try, but as you recommended I've
> done so). I have tried with and without the Session-Timeout and
> Acct-Interim-Interval without any effect.
> 
> Here's the hex output (from the attached pcap):
> 
> 1c 11 00 01 04 45 b7 02 04 cf b7 03 06 cf b7 01 00
> 
> 1c 11 00 01 04 45 b7 02 04 d2 b7 03 06 d0 b7 00 00
> 
> And the debug snip (this is from a time I removed the other two
> *working* values):
> 
> [ttls] Got tunneled reply code 2
>        WiMAX-Packet-Data-Flow-Id := 14
>        WiMAX-Service-Data-Flow-Id := 14
>        WiMAX-Service-Profile-Id := 14
>        WiMAX-Packet-Data-Flow-Id += 17
>        WiMAX-Service-Data-Flow-Id += 17
>        WiMAX-Service-Profile-Id += 17
> 
> Attached is a pcap of the transaction indicating the TLVs are not
> consistent with the DB or the file. It has been consistent with
> radsniff, although I use tcpdump / wireshark when comparing with the
> working systems.
> 
> One thing to note is that I am using TTLS and copying the values to the
> outer tunnel, are you performing the same in your test? I wonder if it's
> a library somewhere on the OS that's making it go awry. I keep thinking
> I've set something that would make this happen, but I cannot get over
> the fact that other values are working fine.
> 
> Thanks,
> 
> James
> 
> 
> 
> On 07/31/2013 10:06 AM, Alan DeKok wrote:
>> Re: WiMAX TLV value correct in debug but not correct in packet capture
>> 
>> James Leavitt wrote:
>>> After some compiling and configuring, I've managed to get version 3.0.0
>>> up and running, and I seem to be having a similar issue:
>> 
>>  I don't see that on my systems.  radsniff, radclient, and pcap all
>> show that the WiMAX attributes are correct.
>> 
>> Data:          1a  17  00 00 60 b5 1c 11 00 01 04 00 0e 02 04 00 0e 03
>>                        06 00 00 00 0e
>>                1a  17  00 00 60 b5 1c 11 00 01 04 00 11 02 04 00 11 03
>>                        06 00 00 00 11
>> 
>>  Please post a hex dump of the packets.  i.e. put this into the "users"
>> file:
>> 
>> bob     Cleartext-Password := "bob"
>>        WiMAX-Packet-Data-Flow-Id  := 14,
>>        WiMAX-Service-Data-Flow-Id := 14,
>>        WiMAX-Service-Profile-Id   := 14,
>>        WiMAX-Packet-Data-Flow-Id  += 17,
>>        WiMAX-Service-Data-Flow-Id += 17,
>>        WiMAX-Service-Profile-Id   += 17
>> 
>>  And run "radclient -xxxx <args>
>> 
>>  to do the test.  You will get a hex dump like I posted above.  It
>> should be identical.
>> 
>>  My guess is that you have FreeRADIUS using one WiMAX dictionary, and
>> radsniff, etc. using another.  Some vendors made their own,
>> incompatible, version of the WiMAX dictionaries.  Which is a stupid
>> idea, but that's what vendors do.
>> 
>>  Alan DeKok.
>> -
>> List info/subscribe/unsubscribe? See
>> http://www.freeradius.org/list/users.html
>> 
>> --
>> This message has been scanned by MailScanner
>> 
> 
> -- 
> 
> 
> James Leavitt
> Network Systems Architect
> 
> Xplornet Communications Inc.
> 300 Lockhart Mill Road
> Woodstock, NB
> E7M 5C3
> 
> Phone: (506) 324-8659
> Fax: (506) 328-1582
> Cell: (506) 324-4960
> Helpdesk: (888) 439-6511
> 
> Email: james.leavitt at corp.xplornet.com <mailto: james.leavitt at corp.xplornet.com> 
> 
> Xplornet - Broadband Everywhere.
> 
> GPG / SSH Public Keys in V-Card Notes
> 
> <1370_tlv_issue.pcap>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html