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.leav...@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.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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html