Proxying EAP-TTLS requests via 2.1.0 to 1.1.7
Sorry about this long first mail, but I figured I'd try to include as much information as possible. right away.. I'm trying to set up a rather complicated RADIUS structure that I hope will be able to support a number of different needs. Anyway, some bit of background information. Things I need to support: EDUROAM for my roaming users at other sites around Europe. EDUROAM for roaming users at my site via WLAN access points (SSID "EDUROAM"). Normal 802.1x for our local users via WLAN (another SSID) Normal 802.1x-enabled ethernet ports on switches. Modem pool access (Ascend MAX4000 - olde faithful still going strong :-) for out users and two neighboring departments (separate user databases) VPN gateway access (Nortel Contivity and OpenVPN) for out users and one other neighboring department. + More stuff (web services)... "Access" Hardware/Software: D-Link DWL-3200AP and DWL-8200AP WLAN access points HP ProCurve ethernet switches Ascend MAX4000 modem pool Nortel Contivity IPSEC VPN gateway OpenVPN server Anyway, I have set up our access points to successfully do EAP-TTLS authentication via RADIUS to a FreeRadius 1.1.7 server since this spring. (The VPN and modem pool is handled by another very old RADIUS server for the moment but I'm planning on moving those to the new FreeRadius structure when things are working smoothly). But now in our quest for implementing EDUROAM I starting looking at using FreeRadius 2.1 and do some intelligent proxying based on various criterias which gets complicated pretty quickly... :-) 1) Users connecting to the WLAN SSID "EDUROAM" should be handled as EDUROAM authentication requests and routed thru those RADIUS servers, and if successful should end up on our "EDUROAM" VLAN. 2) Users connecting to our "PERSONAL" WLAN SSID should be handled as local users only and if successfully authenticated should end up on our "TWILIGHT ZONE" VLAN. It seems I should be able to distinguish at the RADIUS server side between #1 and #2 via the "Called-Station-Id" attribute since the D-Link AP's we are using sets that to something like: Called-Station-Id = "00-17-9A-D3-9A-BA:EDUROAM" (where the last part is the WLAN SSID). 3) Users connecting to the 802.1x enabled physical ethernet ports should if authenticating as USER@ifm.liu.se be handled like #2 above, else be handled like #1 above, and if completely unsuccessful should be conencted to a third special VLAN. (This should be doable via the a RADIUS attribute telling the switch which VLAN to switch a successfully authenticated user's port to). 4) Modem pool users should accept request from three different realms USER@ifm.liu.se USER@dept2.liu.se USER@dept3.liu.se Route those to the correct RADIUS server responsible for authenticating those users, and in the response set the Ascend-special attributes to 'give' the user the right IP# from the departments special IP pools 5) VPN pool users should do something similar to #4 but using the Nortel-specific attributes. (We do #4 and #5 already today with the stoneage RADIUS server, sans the RADIUS-proxying stuff I want to do). Anyway - what I'm curious about is if there are others 'out there' that have done similar stuff before? Any cookbooks for setting up a FreeRadius 2 server in an EDUROAM environment? Anyone with experience talking to D-Link DWL-3200AP or 8200AP with EAP-TTLs and FreeRadius 2? I ran into a problem directly - for some unknown reason when I redirect my APs to talk to a proxying-only FreeRadius 2.1.0 server that forwards requests to our old FreeRadius 1.1.7 server the access points doesn't seem to correctly understand or mishandles (sort of - it looks like things are going OK, but the Window and MacOS X clients just goes into a loop with reretrying the authentication sequence and never finishing) the 'Access-Accept' sent to them after having successfully authenticated the user... And I'm at a loss as to why. I tried running the radiusd servers with -X to see what the difference in the responses are and I can't really see any big differences: FreeRadius 1.1.7 directly to the Access Point: First request: rad_recv: Access-Request packet from host 192.168.160.158:1115, id=0, length=181 Message-Authenticator = 0x377dba909d00b36f5edacd2d732b8cc6 Service-Type = Framed-User User-Name = "testson" Framed-MTU = 1488 Called-Station-Id = "00-17-9A-D3-9A-BA:EDUROAM" Calling-Station-Id = "00-30-65-18-72-61" NAS-Identifier = "ap13434" NAS-Port-Type = Wireless-802.11 Connect-Info = "CONNECT 54Mbps 802.11g" EAP-Message = 0x0200000c0174657374736f6e NAS-IP-Address = 192.168.160.158 NAS-Port = 2 NAS-Port-Id = "STA port # 2" Last response: Sending Access-Accept of id 6 to 192.168.160.158 port 1096 MS-MPPE-Recv-Key = 0xd95114ac0ba4ea2f18815d9d713bcc09730dce74705a24e87c1b3ff1e59bb391 MS-MPPE-Send-Key = 0x59bdb8c81b2d31916a50dbd43079f019616468618cd956c2bb8db99b29436b22 EAP-Message = 0x03060004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = "testson" Finished request 6 FreeRadius 2.1.0 directly to the Access Point (with a response received via Proxying to the same 1.1.7 server): First request: rad_recv: Access-Request packet from host 192.168.160.158 port 1036, id=0, length=181 Message-Authenticator = 0x54e5c5b797c55e4cf49655edfa140e05 Service-Type = Framed-User User-Name = "testson\000" Framed-MTU = 1488 Called-Station-Id = "00-17-9A-D3-9A-BA:EDUROAM" Calling-Station-Id = "00-30-65-18-72-61" NAS-Identifier = "ap13434" NAS-Port-Type = Wireless-802.11 Connect-Info = "CONNECT 54Mbps 802.11g" EAP-Message = 0x0200000c0174657374736f6e NAS-IP-Address = 192.168.160.158 NAS-Port = 2 NAS-Port-Id = "STA port # 2" Last response: Sending Access-Accept of id 6 to 192.168.160.158 port 1036 Vendor-Specific = 0x0000013711348565439b6986f71bfa7425319eac8dd791f24936bc66a8cdd928a91c9c4343958ef040212 4dd4f552726302e356b878e6474 Vendor-Specific = 0x0000013710348b855687f3a4ef1194289232229fe0be952c98689fb606c1e9d6ceae6a388baee98eeb292 be2d41ae58efa7f67737dec758c EAP-Message = 0x03060004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = "testson" Finished request 6. (I assume that 'Vendor-Specific' stuff is the MS-MPPE-Recv-Key stuff that the 1.1.7 talks about). Any suggestions? - Peter
Peter Eriksson wrote:
I'm trying to set up a rather complicated RADIUS structure that I hope will be able to support a number of different needs.
2.1 should be *much* easier than 1.1.x. See the virtual server configuration. It means that one server can do all of this, while still keeping each configuration separate.
It seems I should be able to distinguish at the RADIUS server side between #1 and #2 via the "Called-Station-Id" attribute since the D-Link AP's we are using sets that to something like:
Yes.
Users connecting to the 802.1x enabled physical ethernet ports should
First, write down how those requests are different from (1) and (2). Then, use that information to create policies.
Modem pool users should accept request from three different realms
Again, first decide how these requests are different from the previous ones. Then, create policies.
VPN pool users should do something similar to #4 but using the Nortel-specific attributes.
And how are these requests distinguished from others?
Anyway - what I'm curious about is if there are others 'out there' that have done similar stuff before?
Yes. Lots.
Any cookbooks for setting up a FreeRadius 2 server in an EDUROAM environment?
I don't have links handy, but yes...
FreeRadius 2.1.0 directly to the Access Point (with a response received via Proxying to the same 1.1.7 server): ... Sending Access-Accept of id 6 to 192.168.160.158 port 1036 Vendor-Specific = 0x0000013711348565439b6986f71bfa7425319eac8dd791f24936bc66a8cdd928a91c9c4343958ef040212 4dd4f552726302e356b878e6474 Vendor-Specific = 0x0000013710348b855687f3a4ef1194289232229fe0be952c98689fb606c1e9d6ceae6a388baee98eeb292 be2d41ae58efa7f67737dec758c EAP-Message = 0x03060004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = "testson" Finished request 6.
(I assume that 'Vendor-Specific' stuff is the MS-MPPE-Recv-Key stuff that the 1.1.7 talks about).
Yes. But it's *not* being printed as MS-MPPE-Recv-Key, which means you've broken the dictionaries somehow. Alan DeKok.
FreeRadius 2.1.0 directly to the Access Point (with a response received via Proxying to the same 1.1.7 server): ... Sending Access-Accept of id 6 to 192.168.160.158 port 1036 Vendor-Specific = 0x0000013711348565439b6986f71bfa7425319eac8dd791f24936bc66a8cdd928a91c9c4343958ef040212 4dd4f552726302e356b878e6474 Vendor-Specific = 0x0000013710348b855687f3a4ef1194289232229fe0be952c98689fb606c1e9d6ceae6a388baee98eeb292 be2d41ae58efa7f67737dec758c EAP-Message = 0x03060004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = "testson" Finished request 6.
(I assume that 'Vendor-Specific' stuff is the MS-MPPE-Recv-Key stuff that the 1.1.7 talks about).
Yes. But it's *not* being printed as MS-MPPE-Recv-Key, which means you've broken the dictionaries somehow.
Hmm.. Strange. Since I haven't touched the dictionaries at all. I've been investigating this issue a bit more and it gets really strange. The Access Points in question is D-Link DWL-8200AP and D-Link DWL-3200AP (most of the tests being done with the 8200AP). I simplified the setup a bit and (added a local user "test" with Cleartext-Password "test" and stopped trying to proxy requests) to both the RADIUS servers and tested some more (including packet logs). Here's the tcpdump output from the last packet of the RADIUS negotiation between the AP and the RADIUS servers: 'users' file part relevant to this from both servers: test Cleartext-Password := "test" Reply-Message = "Welcome, Test user" ------------------ FreeRADIUS 1.1.7 (works!) --------------------------- 'radiusd -X' output: Sending Access-Accept of id 6 to 192.168.160.158 port 1036 Reply-Message = "Welcome, Test user" MS-MPPE-Recv-Key = 0x9eecf7bdc47ee54fda52c99bc019fcf5bcf0f752e8b2d876a86c2cba7e979241 MS-MPPE-Send-Key = 0x402f46f3c3532e96c10a4842d351ed4650e9a490d2d69ff81c4aff290cf6d29d EAP-Message = 0x03060004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = "test" 'tcpdump -vvv' output: 14:50:38.860866 IP (tos 0x0, ttl 255, id 34273, offset 0, flags [DF], proto UDP (17), length 214) radius-2.mgmt.1812 > ap13434.mgmt.1036: [udp sum ok] RADIUS, length: 186 Access Accept (2), id: 0x06, Authenticator: f2ad4202d4ae49131e3e8609d74b0f3e Reply Attribute (18), length: 20, Value: Welcome, Test user 0x0000: 5765 6c63 6f6d 652c 2054 6573 7420 7573 0x0010: 6572 Vendor Specific Attribute (26), length: 58, Value: Vendor: Microsoft (311) Vendor Attribute: 17, Length: 50, Value: ../..I.gL.b.. ....Q..Z....[./"c..c..8....ZE./(36. 0x0000: 0000 0137 1134 86fb 2f99 0849 a867 4cbf 0x0010: 62fc 0820 fd9c 09b6 512e bd5a 06d6 1e13 0x0020: 5bc3 2f22 7f63 be98 63d0 e838 01ed 05b8 0x0030: 5a45 f62f 2833 36b2 Vendor Specific Attribute (26), length: 58, Value: Vendor: Microsoft (311) Vendor Attribute: 16, Length: 50, Value: ...ct.i...s........)....~qY..2....@....6..C..ukw 0x0000: 0000 0137 1034 8a9e 9763 7411 69d5 ed9b 0x0010: 7315 7f0e a816 f916 ee2e 290a b8eb 1f7e 0x0020: 7159 949b 327f e99d d8a9 40e5 d6e3 0436 0x0030: ad04 43bc b075 6b77 EAP Message Attribute (79), length: 6, Value: .. 0x0000: 0306 0004 Message Authentication Attribute (80), length: 18, Value: ?.5..2../..E.l.. 0x0000: 3fea 35dc ea32 cdce 2fbb 1b45 a06c f391 Username Attribute (1), length: 6, Value: test 0x0000: 7465 7374 ---------------- FreeRADIUS 2.1.1 (does not work) ---------------------- 'radiusd -X' output: Sending Access-Accept of id 5 to 192.168.160.158 port 1038 MS-MPPE-Recv-Key = 0x2ddccad014a85d9efb3cfaf3a9a1e384ec4db611ba1330cce565ada55a295b2c MS-MPPE-Send-Key = 0x7fe1889799b75faae8e9dca9378586fc3e576020d04744f46a79a39e9997d977 EAP-Message = 0x03050004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = "test" 'tcpdump -vvv' output: 14:55:53.580876 IP (tos 0x0, ttl 255, id 55088, offset 0, flags [DF], proto UDP (17), length 196) radius-1.mgmt.1812 > ap13434.mgmt.1038: [udp sum ok] RADIUS, length: 168 Access Accept (2), id: 0x05, Authenticator: 0c7b40f4cc86a27f63c0e3c71e73aae0 Vendor Specific Attribute (26), length: 59, Value: Vendor: Microsoft (311) Vendor Attribute: 17, Length: 51, Value: ..5.{._....U....(..#w?9...I.T..jn.N...........i... 0x0000: 0000 0137 1135 0093 35f4 7be2 5fdc d7cd 0x0010: da55 fa18 dcb5 28da ca23 773f 39a6 9ad1 0x0020: 49c4 54f6 9c6a 6e98 4eb7 1a1f 0a01 a304 0x0030: 2e7f da00 d869 0cc0 f2 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 0x0010: 5258 cc13 aa64 748a 1946 ccc7 7834 e2f3 0x0020: 267d a309 e43c 46b3 a1f0 49e0 c06a a0bb 0x0030: 4cde 0c25 4f21 e0c4 27 EAP Message Attribute (79), length: 6, Value: .. 0x0000: 0305 0004 Message Authentication Attribute (80), length: 18, Value: .Y..........#~k. 0x0000: 1b59 e3fd 01bd 9dfe e8f8 b1b9 237e 6b86 Username Attribute (1), length: 6, Value: test 0x0000: 7465 7374 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? - Peter
Peter Eriksson wrote:
Yes. But it's *not* being printed as MS-MPPE-Recv-Key, which means you've broken the dictionaries somehow.
Hmm.. Strange. Since I haven't touched the dictionaries at all.
Well, the only way that the MS attributes are printed as "Vendor-Specific" is if the MS dictionary isn't being used.
I've been investigating this issue a bit more and it gets really strange.
Well, yes. Suddenly it's printing the MS attributes with their full name, and not as Vendor-Specific. And the TCP dump output shows:
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. Alan DeKok.
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
Peter Eriksson wrote:
Any suggestions on where I should start adding debugging printf's/debugger checkpoints in order to try to pin-point this problem?
src/lib/radius.c, rad_encode, and the attr2vp functions.
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?
Yes. But the MPPE keys are the correct length. The problem comes when they are encoded in the packet. There's an extra "0" byte added to the start. Maybe because it thinks the attribute is tagged?
OS: Solaris 10 Hardware: Sun Fire T1000 (64bit UltraSPARC-T1 processor)
FreeRadius built as a 32bit process.
Hmm... It should be 64-bit clean. I'll try it on the 64-bit system I have access to.
Hmmm... Structure alignment issue (SPARC can be more "picky" there)? Byte order issue? (SPARC is different from x86 here).
The server is 64-bit clean, and works on big/little-endian machines.
I'm going to build on some x86 machines too to see if it behaves differently there.
It it does, it's likely a 64-bit issue. Alan DeKok.
Alan DeKok wrote:
Peter Eriksson wrote:
Any suggestions on where I should start adding debugging printf's/debugger checkpoints in order to try to pin-point this problem?
src/lib/radius.c, rad_encode, and the attr2vp functions.
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?
Yes. But the MPPE keys are the correct length. The problem comes when they are encoded in the packet. There's an extra "0" byte added to the start. Maybe because it thinks the attribute is tagged?
I've been adding debugging DEBUG() calls to various parts of the code in order to try to pinpoint this problem. Here's a status report of what I've found so far. The interesting part is from the output below I think. Notice the following that I feel are a bit 'suspect' that happens in the rad_vp2attr() function: 1. dv->flags=808989706 2. vp->attribute=20381713 This is printed in the code around: /* * This must be an RFC-format attribute. If it * wasn't, then the "decode" function would have * made a Vendor-Specific attribute (i.e. type * 26), and we would have "vendorcode == 0" here. */ if (dv) { vsa_tlen = dv->type; vsa_llen = dv->length; if (dv->flags) vsa_offset = 1; DEBUG("PETER: dv->flags=%d\n", dv->flags); } DEBUG("PETER: rad_vp2attr: vendorcode=%d, vsa_tlen=%d, vsa_llen=%d, vsa_offset=%d, vp->attribute=%d\n", vendorcode, vsa_tlen, vsa_llen, vsa_offset, vp->attribute); With dv->flags set to '808989706' then vsa_offset is set to 1, and then a bit down in the code this happens (notice the 'ptr[0] = 0x00;' - could this be where the mysterious 0x00-byte gets added?): if (vsa_offset) { /* * Allow TLV's to be encoded, if someone * manages to somehow encode the sub-tlv's. * * FIXME: Keep track of room in the packet! */ if (vp->length > (254 - (ptr - start))) { DEBUG("PETER: rad_vp2attr: Calling rad_vp2continuation\n"); return rad_vp2continuation(vp, start, ptr); } ptr[0] = 0x00; ptr++; /* * sub-TLV's can only be in one format. */ if (vp->flags.is_tlv) { DEBUG("PETER: rad_vp2attr: vp->flags.is_tlv=%d\n", vp->flags.is_tlv); *(ptr++) = (vp->attribute & 0xff00) >> 8; tlv_length_ptr = ptr; *(ptr++) = 2; vsa_offset += 2; Output from the server when running with my DEBUG() calls added: Sending Access-Accept of id 5 to 192.168.160.158 port 2299 MS-MPPE-Recv-Key = 0x3b7338c7c2942aa068f6b52ba9616e0b6daf553595483804575f70c3910b49e4 PETER: rad_vp2attr: start=ffffffff7fffc344 PETER: dv->flags=808989706 PETER: rad_vp2attr: vendorcode=311, vsa_tlen=1, vsa_llen=1, vsa_offset=1, vp->attribute=20381713 PETER: rad_vp2attr: vp->flags.has_tag=0, vp->flags.tag=0 PETER: vp2data: offset=0, room=246, vp->length=32, vp->flags.encrypt=2 PETER: make_tunnel_passwd: inlen=32, room=246 PETER: make_tunnel_passwd: adjusted len=48 MS-MPPE-Send-Key = 0x6a238a9b2f97d43cfef37c80bc88309fc843d571dd97316b3754d0dee7c8754a PETER: rad_vp2attr: start=ffffffff7fffc37f PETER: dv->flags=808989706 PETER: rad_vp2attr: vendorcode=311, vsa_tlen=1, vsa_llen=1, vsa_offset=1, vp->attribute=20381712 PETER: rad_vp2attr: vp->flags.has_tag=0, vp->flags.tag=0 PETER: vp2data: offset=0, room=246, vp->length=32, vp->flags.encrypt=2 PETER: make_tunnel_passwd: inlen=32, room=246 PETER: make_tunnel_passwd: adjusted len=48 EAP-Message = 0x03050004 PETER: rad_vp2attr: start=ffffffff7fffc3ba PETER: rad_vp2attr: vendorcode=0 PETER: rad_vp2attr: vp->flags.has_tag=0, vp->flags.tag=0 PETER: vp2data: offset=0, room=253, vp->length=4, vp->flags.encrypt=0 Message-Authenticator = 0x00000000000000000000000000000000 PETER: rad_vp2attr: start=ffffffff7fffc3c0 PETER: rad_vp2attr: vendorcode=0 PETER: rad_vp2attr: vp->flags.has_tag=0, vp->flags.tag=0 PETER: vp2data: offset=0, room=253, vp->length=16, vp->flags.encrypt=0 User-Name = "" PETER: rad_vp2attr: start=ffffffff7fffc3d2 PETER: rad_vp2attr: vendorcode=0 PETER: rad_vp2attr: vp->flags.has_tag=0, vp->flags.tag=0 PETER: vp2data: offset=0, room=253, vp->length=0, vp->flags.encrypt=0 PETER: rad_encode, packet data (162 bytes): 020500a26ac716ea68df22aa04b11b19748b4cd41a3b00000137113500812965b0fd4eab49fe3130 a05e5c23ba80f7165b2f81fab9a798cdd4d42ec06e85496fe978b1ece15c4eb60342e59fca50781a3b000001371035008edb28255c56fbc717358e4599af b0ea6e99a802da0445c3d2ee12387d2ad9d31ce168bfeee5e3222881fd1d659ff1dcd3234f0603050004501200000000000000000000000000000000 Tue Sep 30 11:20:36 2008 : Debug: Finished request 5. Ah well. Back to adding mot DEBUG() calls to locate what's going on... - Peter
BINGO! Found it. The bug is that function dict_addvendor() in src/lib/dict.c, around line 440 is missing an initialization of dv->flags: dv->flags = 0; If I add that then the Windows PC client successfully connects to the WLAN station and authenticates correctly... - Peter INGO!
Notice the following that I feel are a bit 'suspect' that happens in the rad_vp2attr() function:
1. dv->flags=808989706 2. vp->attribute=20381713
This is printed in the code around:
/* * This must be an RFC-format attribute. If it * wasn't, then the "decode" function would have * made a Vendor-Specific attribute (i.e. type * 26), and we would have "vendorcode == 0" here. */ if (dv) { vsa_tlen = dv->type; vsa_llen = dv->length; if (dv->flags) vsa_offset = 1; DEBUG("PETER: dv->flags=%d\n", dv->flags); }
DEBUG("PETER: rad_vp2attr: vendorcode=%d, vsa_tlen=%d, vsa_llen=%d, vsa_offset=%d, vp->attribute=%d\n", vendorcode, vsa_tlen, vsa_llen, vsa_offset, vp->attribute);
With dv->flags set to '808989706' then vsa_offset is set to 1, and then a bit down in the code this happens (notice the 'ptr[0] = 0x00;' - could this be where the mysterious 0x00-byte gets added?):
if (vsa_offset) { /* * Allow TLV's to be encoded, if someone * manages to somehow encode the sub-tlv's. * * FIXME: Keep track of room in the packet! */ if (vp->length > (254 - (ptr - start))) { DEBUG("PETER: rad_vp2attr: Calling rad_vp2continuation\n"); return rad_vp2continuation(vp, start, ptr); }
ptr[0] = 0x00; ptr++;
/* * sub-TLV's can only be in one format. */ if (vp->flags.is_tlv) { DEBUG("PETER: rad_vp2attr: vp->flags.is_tlv=%d\n", vp->flags.is_tlv);
*(ptr++) = (vp->attribute & 0xff00) >> 8; tlv_length_ptr = ptr; *(ptr++) = 2; vsa_offset += 2;
Output from the server when running with my DEBUG() calls added:
Sending Access-Accept of id 5 to 192.168.160.158 port 2299 MS-MPPE-Recv-Key = 0x3b7338c7c2942aa068f6b52ba9616e0b6daf553595483804575f70c3910b49e4 PETER: rad_vp2attr: start=ffffffff7fffc344 PETER: dv->flags=808989706 PETER: rad_vp2attr: vendorcode=311, vsa_tlen=1, vsa_llen=1, vsa_offset=1, vp->attribute=20381713 PETER: rad_vp2attr: vp->flags.has_tag=0, vp->flags.tag=0 PETER: vp2data: offset=0, room=246, vp->length=32, vp->flags.encrypt=2 PETER: make_tunnel_passwd: inlen=32, room=246 PETER: make_tunnel_passwd: adjusted len=48 MS-MPPE-Send-Key = 0x6a238a9b2f97d43cfef37c80bc88309fc843d571dd97316b3754d0dee7c8754a PETER: rad_vp2attr: start=ffffffff7fffc37f PETER: dv->flags=808989706 PETER: rad_vp2attr: vendorcode=311, vsa_tlen=1, vsa_llen=1, vsa_offset=1, vp->attribute=20381712 PETER: rad_vp2attr: vp->flags.has_tag=0, vp->flags.tag=0 PETER: vp2data: offset=0, room=246, vp->length=32, vp->flags.encrypt=2 PETER: make_tunnel_passwd: inlen=32, room=246 PETER: make_tunnel_passwd: adjusted len=48 EAP-Message = 0x03050004 PETER: rad_vp2attr: start=ffffffff7fffc3ba PETER: rad_vp2attr: vendorcode=0 PETER: rad_vp2attr: vp->flags.has_tag=0, vp->flags.tag=0 PETER: vp2data: offset=0, room=253, vp->length=4, vp->flags.encrypt=0 Message-Authenticator = 0x00000000000000000000000000000000 PETER: rad_vp2attr: start=ffffffff7fffc3c0 PETER: rad_vp2attr: vendorcode=0 PETER: rad_vp2attr: vp->flags.has_tag=0, vp->flags.tag=0 PETER: vp2data: offset=0, room=253, vp->length=16, vp->flags.encrypt=0 User-Name = "" PETER: rad_vp2attr: start=ffffffff7fffc3d2 PETER: rad_vp2attr: vendorcode=0 PETER: rad_vp2attr: vp->flags.has_tag=0, vp->flags.tag=0 PETER: vp2data: offset=0, room=253, vp->length=0, vp->flags.encrypt=0 PETER: rad_encode, packet data (162 bytes): 020500a26ac716ea68df22aa04b11b19748b4cd41a3b00000137113500812965b0fd4eab49fe3130 a05e5c23ba80f7165b2f81fab9a798cdd4d42ec06e85496fe978b1ece15c4eb60342e59fca50781a3b000001371035008edb28255c56fbc717358e4599af b0ea6e99a802da0445c3d2ee12387d2ad9d31ce168bfeee5e3222881fd1d659ff1dcd3234f0603050004501200000000000000000000000000000000 Tue Sep 30 11:20:36 2008 : Debug: Finished request 5.
Ah well. Back to adding mot DEBUG() calls to locate what's going on...
- Peter - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Peter Eriksson wrote:
Found it. The bug is that function dict_addvendor() in src/lib/dict.c, around line 440 is missing an initialization of dv->flags:
dv->flags = 0;
Hmm... OK. I'll add the fix in a slightly different place, as there are other areas which may get hit with this. Alan DeKok.
participants (2)
-
Alan DeKok -
Peter Eriksson