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

[Alan DeKok]

  If you're asking for help, it's a good idea to be honest about it.  Editing the hex output and *not* saying so is rude 

  The reason I asked for the hex output is because I wanted the hex output. I didn't want a butchered version of he hex output. 

On 2013-07-31, at 1:19 PM, James Leavitt <james.leavitt at corp.xplornet.com> wrote:

> Sorry Alan,
> 
> I left that part out since it is coming through ok, here's the whole
> thing (you can see the 00 00 60 b5 after the 1a 17):
> 
> 1a 17 00 00 60 b5 1c 11 00 01 04 45 b7 02 04 cf b7 03 06 cf b7 01 00
> 
> 1a 17 00 00 60 b5 1c 11 00 01 04 45 b7 02 04 d2 b7 03 06 d0 b7 00 00
> 
> Interesting theory though, I did *try* a change in the dictionaries in a
> vain attempt solve this issue (tried the included wimax and wichorus),
> but I rolled them back. I also compiled 3.0.0 and installed in a new
> location, and never touched those dictionaries at all, same bizarre problem.
> 
> If the binaries are broken, then I now have two sets of broken binaries
> (granted they are on the same platform so perhaps it's a library problem?).
> 
> Perhaps I should install a whole new system / os and test on it to see
> if a similar problem exists. What I will try now is another TLV and see
> how it behaves.
> 
> Thanks,
> 
> James
> 
> 
> 
> 
> On 07/31/2013 01:19 PM, Alan DeKok wrote:
>> Re: WiMAX TLV value correct in debug but not correct in packet capture
>> 
>>  See the hex output. The "00 00 60 b5" is the WiMAX forum vendor ID.
>> Your debug output has "00 01 04 45" in the same place.  So either the
>> dictionaries are broken, or the binaries are broken.
>> 
>>  Either way, this problem doesnt appear in a stock install with the
>> stock dictionaries.
>> 
>>  So what changes have you made, and why?
>> 
>> 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
>>>> 
>>> 
>>> --
>>> 
>>> 
>> 
>>> <1370_tlv_issue.pcap>
>>> -
>>> List info/subscribe/unsubscribe? See
>> http://www.freeradius.org/list/users.html
>> -
>> List info/subscribe/unsubscribe? See
>> http://www.freeradius.org/list/users.html
>> 
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html