Proxying EAP-TTLS requests via 2.1.0 to 1.1.7

[Peter Eriksson]

>>           Vendor Specific Attribute (26), length: 59, Value: Vendor:
>> Microsoft (311)
>>             Vendor Attribute: 16, Length: 51, Value:
>> ..."D...1.RX...dt..F..x4..&}...<F...I..j..L..%O!..'
>>             0x0000:  0000 0137 1035 009d be22 4487 0b90 31ab
> 
>   The '1035 00' is odd.  The extra '00' doesn't belong.
> 
>> Dunno if it's relevant, but I notice the 51 vs 50 'Length' value
>> difference in the 'Vendor Attribute'. An off-by-one error
>> somewhere?
> 
>   No.  It's fine on my system.  And your previous post (with
> Vendor-Specific) had:
> 
>>>>         Vendor-Specific =
>>>>
> 0x0000013710348b855687f3a4ef1194289232229fe0be952c98689fb606c1e9d6ceae6a388baee98eeb292
> 
>   i.e. '1034 8b'.  So the length is correct there.
> 
>   I don't know what's going on with your system, but it looks like
> either the software is completely broken, or the dictionaries are
> broken.  Either way, it's system-specific, and I can't reproduce it here.

Any suggestions on where I should start adding debugging
printf's/debugger checkpoints in order to try to pin-point
this problem?

Am I correct in assuming the keys in question are generated in
src/modules/rlm_eap/libeap/mppe_keys.c:151 via a call to the local
function add_reply?

OS: Solaris 10
Hardware: Sun Fire T1000 (64bit UltraSPARC-T1 processor)

FreeRadius built as a 32bit process.

I've tried compiling with both Sun Studio (latest express version)
and GCC (version 4.3.1). Didn't make any difference.

Hmmm... Structure alignment issue (SPARC can be more "picky" there)?
Byte order issue? (SPARC is different from x86 here).

I'm going to build on some x86 machines too to see if it behaves
differently there.

- Peter