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.leav...@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