You've done something to the dictionaries. What is it? Alan DeKok.
On 2013-07-31, at 10:57 AM, James Leavitt <[email protected]> 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: [email protected] <mailto: > [email protected]> > > 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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
