WiMAX TLV value correct in debug but not correct in packet capture
Version info: radiusd: FreeRADIUS Version 2.2.0, for host i686-redhat-linux-gnu, built on Oct 9 2012 at 17:47:30 Copyright (C) 1999-2011 The FreeRADIUS server project and contributors. Hello Everyone, I've probably missed something or buggered an option, but I've searched and searched and cannot find an answer to this. This is for a WiMAX deployment and am using the built in dictionaries. The issue is with the WiMAX-Packet-Flow-Descriptor tlv . Below is what's configured in my DB: id | groupname | attribute | op | value -----+-----------+----------------------------+----+------- 100 | Business | Session-Timeout | := | 86400 101 | Business | Acct-Interim-Interval | := | 60 110 | Business | WiMAX-Packet-Data-Flow-Id | := | 14 111 | Business | WiMAX-Service-Data-Flow-Id | := | 14 112 | Business | WiMAX-Service-Profile-Id | := | 14 120 | Business | WiMAX-Packet-Data-Flow-Id | += | 17 121 | Business | WiMAX-Service-Data-Flow-Id | += | 17 122 | Business | WiMAX-Service-Profile-Id | += | 17
From a debug I get this (relevant section):
Found Auth-Type = EAP # Executing group from file /etc/raddb/sites-enabled/default +- entering group authenticate {...} [eap] Request found, released from the list [eap] EAP/ttls [eap] processing type ttls [ttls] Authenticate [ttls] processing EAP-TLS [ttls] Received TLS ACK [ttls] ACK handshake is finished [ttls] eaptls_verify returned 3 [ttls] eaptls_process returned 3 [ttls] Using saved attributes from the original Access-Accept Session-Timeout := 86400 Acct-Interim-Interval := 60 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 [eap] Freeing handler ++[eap] returns ok # Executing section post-auth from file /etc/raddb/sites-enabled/default +- entering group post-auth {...} ++[exec] returns noop [wimax] MIP-RK = 0x00b0ce41e978a30ec9b196bdea7bd74def743761ddc81add6cb19ca577056e59ea814c5b54891482a045773e861657260658939502a9babd7c0a59a92a99cf87 [wimax] MIP-SPI = 42f4fa35 [wimax] WARNING: WiMAX-MN-NAI was not found in the request or in the reply. [wimax] WARNING: We cannot calculate MN-HA keys. [wimax] WARNING: WiMAX-IP-Technology not found in reply. [wimax] WARNING: Not calculating MN-HA keys ++[wimax] returns updated Sending Access-Accept of id 2 to 10.199.20.240 port 6219 Session-Timeout := 86400 Acct-Interim-Interval := 60 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 MS-MPPE-Recv-Key = 0x6b033615247e78ea0e225bea745bba8c33634e0bf28ea0388174965a980b1642 MS-MPPE-Send-Key = 0x1a21679697b923cc88f4b4ba4fa37ded7f00c035811cd6ff18b4fb4e64956077 EAP-Message = 0x03070004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = "1320CD7377DCB1AA6BACBBAD1A23AEE5@undisclosed.com" Finished request 14. Everything looks good but on a pcap / radsniff I get this: Access-Accept Id 2 10.199.10.14:1812 -> 10.199.20.240:6219 +31.411 Session-Timeout = 86400 Acct-Interim-Interval = 60 WiMAX-Packet-Data-Flow-Id = 17079 <--???? WiMAX-Service-Data-Flow-Id = 13496 <--???? WiMAX-Service-Profile-Id = 918034516 <--???? WiMAX-Packet-Data-Flow-Id = 17079 <--???? WiMAX-Service-Data-Flow-Id = 17079 <--???? WiMAX-Service-Profile-Id = 884473856 <--???? Microsoft-Attr-17 = 0x812038c3de66aec29f91928f3e5346f5911aa110d4c33dfd5556b1aebeb7c637b53c2420b3cd73763eb7c06f5386e6cef612 MS-MPPE-Send-Key = 0x1be2107278 EAP-Message = 0x03070004 Message-Authenticator = 0x70f2a2f9037b10be87a6ad954a205159 User-Name = "1320CD7377DCB1AA6BACBBAD1A23AEE5@undisclosed.com" As can be seen, Session-Timeout and Acct-Interim-Interval all match up, but the others don't, and even change from time to time without anything other than a restart of radiusd. I see the definition in the wimax dictionary is "short" Anyhow, if there's a bug / solution / setting that I've blatantly missed, please let me know. I am attaching more debug below. Thanks, James Going to the next request Ready to process requests. rad_recv: Access-Request packet from host 10.199.20.240 port 6216, id=0, length=274 User-Name = "1320CD7377DCB1AA6BACBBAD1A23AEE5@undisclosed.com" Chargeable-User-Identity = "null" NAS-IP-Address = 10.199.20.240 NAS-Port = 5 NAS-Port-Type = Wireless-802.16 Framed-MTU = 1400 NAS-Identifier = "test" Calling-Station-Id = "\000&\202g\023p" Service-Type = Framed-User WiMAX-GMT-Timezone-offset = 0 WiMAX-BS-Id = 0x000083010102 WiMAX-Release = "1.2" WiMAX-Accounting-Capabilities = 3 WiMAX-Hotlining-Capabilities = Hotline-Profile-Id WiMAX-Idle-Mode-Notification-Cap = Supported WiMAX-Attr-1281 = 0x01 WiMAX-Attr-1537 = 0x0000006a WiMAX-Available-In-Client = 67 WiMAX-Attr-36 = 0x000001 EAP-Message = 0x020000320131333230434437333737444342314141364241434242414431413233414545354078706c6f726e65742e636f6d Message-Authenticator = 0x624b00fa55a8e8df65355066f4257c1a # Executing section authorize from file /etc/raddb/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop rlm_wimax: Fixing WiMAX binary Calling-Station-Id to 00-26-82-67-13-70 ++[wimax] returns ok [suffix] Looking up realm "undisclosed.com" for User-Name = "1320CD7377DCB1AA6BACBBAD1A23AEE5@undisclosed.com" [suffix] No such realm "undisclosed.com" ++[suffix] returns noop [eap] EAP packet type response id 0 length 50 [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated ++[files] returns noop [sql] expand: %{User-Name} -> 1320CD7377DCB1AA6BACBBAD1A23AEE5@undisclosed.com [sql] sql_set_user escaped user --> '1320CD7377DCB1AA6BACBBAD1A23AEE5@undisclosed.com' rlm_sql (sql): Reserving sql socket id: 1 [sql] expand: SELECT id, UserName, Attribute, Value, Op FROM radcheck WHERE Username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, UserName, Attribute, Value, Op FROM radcheck WHERE Username = '1320CD7377DCB1AA6BACBBAD1A23AEE5@undisclosed.com' ORDER BY id rlm_sql_postgresql: Status: PGRES_TUPLES_OK rlm_sql_postgresql: query affected rows = 0 , fields = 5 [sql] expand: SELECT GroupName FROM radusergroup WHERE UserName='%{SQL-User-Name}' ORDER BY priority -> SELECT GroupName FROM radusergroup WHERE UserName='1320CD7377DCB1AA6BACBBAD1A23AEE5@undisclosed.com' ORDER BY priority rlm_sql_postgresql: Status: PGRES_TUPLES_OK rlm_sql_postgresql: query affected rows = 0 , fields = 1 rlm_sql (sql): Released sql socket id: 1 [sql] User 1320CD7377DCB1AA6BACBBAD1A23AEE5@undisclosed.com not found ++[sql] returns notfound ++[expiration] returns noop ++[logintime] returns noop [pap] WARNING! No "known good" password found for the user. Authentication may fail because of this. ++[pap] returns noop Found Auth-Type = EAP # Executing group from file /etc/raddb/sites-enabled/default +- entering group authenticate {...} [eap] EAP Identity [eap] processing type md5 rlm_eap_md5: Issuing Challenge ++[eap] returns handled Sending Access-Challenge of id 0 to 10.199.20.240 port 6216 EAP-Message = 0x010100160410c8f730871835d03c590829b8055f149a Message-Authenticator = 0x00000000000000000000000000000000 State = 0x3d1b22fe3d1a26c4e21bc6380caaf462 Finished request 7. Going to the next request Waking up in 4.9 seconds. rad_recv: Access-Request packet from host 10.199.20.240 port 6217, id=0, length=248 User-Name = "1320CD7377DCB1AA6BACBBAD1A23AEE5@undisclosed.com" State = 0x3d1b22fe3d1a26c4e21bc6380caaf462 Chargeable-User-Identity = "null" NAS-IP-Address = 10.199.20.240 NAS-Port = 5 NAS-Port-Type = Wireless-802.16 Framed-MTU = 1400 NAS-Identifier = "test" Calling-Station-Id = "\000&\202g\023p" Service-Type = Framed-User WiMAX-GMT-Timezone-offset = 0 WiMAX-BS-Id = 0x000083010102 WiMAX-Release = "1.2" WiMAX-Accounting-Capabilities = 3 WiMAX-Hotlining-Capabilities = Hotline-Profile-Id WiMAX-Idle-Mode-Notification-Cap = Supported WiMAX-Attr-1281 = 0x01 WiMAX-Attr-1537 = 0x0000006a WiMAX-Available-In-Client = 67 WiMAX-Attr-36 = 0x000001 EAP-Message = 0x020100060315 Message-Authenticator = 0xc216081e84e230c02e8da5c94ef5f567 # Executing section authorize from file /etc/raddb/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop rlm_wimax: Fixing WiMAX binary Calling-Station-Id to 00-26-82-67-13-70 ++[wimax] returns ok [suffix] Looking up realm "undisclosed.com" for User-Name = "1320CD7377DCB1AA6BACBBAD1A23AEE5@undisclosed.com" [suffix] No such realm "undisclosed.com" ++[suffix] returns noop [eap] EAP packet type response id 1 length 6 [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated ++[files] returns noop [sql] expand: %{User-Name} -> 1320CD7377DCB1AA6BACBBAD1A23AEE5@undisclosed.com [sql] sql_set_user escaped user --> '1320CD7377DCB1AA6BACBBAD1A23AEE5@undisclosed.com' rlm_sql (sql): Reserving sql socket id: 0 [sql] expand: SELECT id, UserName, Attribute, Value, Op FROM radcheck WHERE Username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, UserName, Attribute, Value, Op FROM radcheck WHERE Username = '1320CD7377DCB1AA6BACBBAD1A23AEE5@undisclosed.com' ORDER BY id rlm_sql_postgresql: Status: PGRES_TUPLES_OK rlm_sql_postgresql: query affected rows = 0 , fields = 5 [sql] expand: SELECT GroupName FROM radusergroup WHERE UserName='%{SQL-User-Name}' ORDER BY priority -> SELECT GroupName FROM radusergroup WHERE UserName='1320CD7377DCB1AA6BACBBAD1A23AEE5@undisclosed.com' ORDER BY priority rlm_sql_postgresql: Status: PGRES_TUPLES_OK rlm_sql_postgresql: query affected rows = 0 , fields = 1 rlm_sql (sql): Released sql socket id: 0 [sql] User 1320CD7377DCB1AA6BACBBAD1A23AEE5@undisclosed.com not found ++[sql] returns notfound ++[expiration] returns noop ++[logintime] returns noop [pap] WARNING! No "known good" password found for the user. Authentication may fail because of this. ++[pap] returns noop Found Auth-Type = EAP # Executing group from file /etc/raddb/sites-enabled/default +- entering group authenticate {...} [eap] Request found, released from the list [eap] EAP NAK [eap] EAP-NAK asked for EAP-Type/ttls [eap] processing type tls [tls] Initiate [tls] Start returned 1 ++[eap] returns handled Sending Access-Challenge of id 0 to 10.199.20.240 port 6217 EAP-Message = 0x010200061520 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x3d1b22fe3c1937c4e21bc6380caaf462 Finished request 8. Going to the next request Waking up in 4.9 seconds. rad_recv: Access-Request packet from host 10.199.20.240 port 6218, id=0, length=336 User-Name = "1320CD7377DCB1AA6BACBBAD1A23AEE5@undisclosed.com" State = 0x3d1b22fe3c1937c4e21bc6380caaf462 Chargeable-User-Identity = "null" NAS-IP-Address = 10.199.20.240 NAS-Port = 5 NAS-Port-Type = Wireless-802.16 Framed-MTU = 1400 NAS-Identifier = "test" Calling-Station-Id = "\000&\202g\023p" Service-Type = Framed-User WiMAX-GMT-Timezone-offset = 0 WiMAX-BS-Id = 0x000083010102 WiMAX-Release = "1.2" WiMAX-Accounting-Capabilities = 3 WiMAX-Hotlining-Capabilities = Hotline-Profile-Id WiMAX-Idle-Mode-Notification-Cap = Supported WiMAX-Attr-1281 = 0x01 WiMAX-Attr-1537 = 0x0000006a WiMAX-Available-In-Client = 67 WiMAX-Attr-36 = 0x000001 EAP-Message = 0x0202005e150016030100530100004f030151f6843e3ba9c0e04d448b5995f9376ddeeb021c600b2c88fd4c4f067d8472e200002800390038003500160013000a00330032002f000700050004001500120009001400110008000600030100 Message-Authenticator = 0x8d3b616e15c812e5046a994903eb4c55 # Executing section authorize from file /etc/raddb/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop rlm_wimax: Fixing WiMAX binary Calling-Station-Id to 00-26-82-67-13-70 ++[wimax] returns ok [suffix] Looking up realm "undisclosed.com" for User-Name = "1320CD7377DCB1AA6BACBBAD1A23AEE5@undisclosed.com" [suffix] No such realm "undisclosed.com" ++[suffix] returns noop [eap] EAP packet type response id 2 length 94 [eap] Continuing tunnel setup. ++[eap] returns ok Found Auth-Type = EAP # Executing group from file /etc/raddb/sites-enabled/default +- entering group authenticate {...} [eap] Request found, released from the list [eap] EAP/ttls [eap] processing type ttls [ttls] Authenticate [ttls] processing EAP-TLS [ttls] eaptls_verify returned 7 [ttls] Done initial handshake [ttls] (other): before/accept initialization [ttls] TLS_accept: before/accept initialization [ttls] <<< TLS 1.0 Handshake [length 0053], ClientHello [ttls] TLS_accept: SSLv3 read client hello A [ttls] >>> TLS 1.0 Handshake [length 002a], ServerHello [ttls] TLS_accept: SSLv3 write server hello A [ttls] >>> TLS 1.0 Handshake [length 085e], Certificate [ttls] TLS_accept: SSLv3 write certificate A [ttls] >>> TLS 1.0 Handshake [length 020d], ServerKeyExchange [ttls] TLS_accept: SSLv3 write key exchange A [ttls] >>> TLS 1.0 Handshake [length 0004], ServerHelloDone [ttls] TLS_accept: SSLv3 write server done A [ttls] TLS_accept: SSLv3 flush data [ttls] TLS_accept: Need to read more data: SSLv3 read client certificate A In SSL Handshake Phase In SSL Accept mode [ttls] eaptls_process returned 13 ++[eap] returns handled Sending Access-Challenge of id 0 to 10.199.20.240 port 6218 EAP-Message = 0x0103040015c000000aad160301002a02000026030151f6843ea7a068fcf005cd02ab7c253e507ec85b627c50a9dbbb09dad980eb8800003900160301085e0b00085a0008570003a6308203a23082028aa003020102020101300d06092a864886f70d0101050500308193310b3009060355040613024652310f300d060355040813065261646975733112301006035504071309536f6d65776865726531153013060355040a130c4578616d706c6520496e632e3120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d312630240603550403131d4578616d706c6520436572746966696361746520417574686f72697479 EAP-Message = 0x301e170d3132303932373230323931365a170d3132313132363230323931365a307c310b3009060355040613024652310f300d0603550408130652616469757331153013060355040a130c4578616d706c6520496e632e312330210603550403131a4578616d706c65205365727665722043657274696669636174653120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d30820122300d06092a864886f70d01010105000382010f003082010a0282010100c4c5b27c8989fbe23730ed64c341b3eec198c4f61c849694879bb5682e817a3bd36ee0f288703cdd2d01afad09eaa3094a530fd50b1c3051f1578f89033e EAP-Message = 0x9294b51efc7988e06054e1b2db74c33354f26e32d65a208a4f2919a133bf9f1ab8b210deb180f16ebce470e38bd51865630e59fa15fedb01d3b58dcbf3029a01b2e3c21f2ebd3d2e410824d1a8655bfc171fa834c0f4e4ceaf1d9f0aa76f3fd2349fda57a65d785b106a5faecb3520b3fa5b32b07785d466b1f91e2d695126b043b804f5326f55981922a1eeaf4d6565ade837cf4fbe86f276f0d0913f0a5878a1f0f45202cd32bbbae72c923b6b171e81ab9b03c4713ad95c6aba20e61764214b4f0203010001a317301530130603551d25040c300a06082b06010505070301300d06092a864886f70d01010505000382010100adecc8bc38709cc6cb EAP-Message = 0x650791e1531ca63c113770c53ab08e0da3decd3e2807b4ab1c602bbc3e04a4259e50dcc583170bf0cfa7720cd57a8e6982017deb231253b4d7de4497af9cee50dd48e34db2af5a318f9969319313b488af1e6576f18000b26f146cf3fa5fb434cd9f5657feb79ca0c46eb156d2f797b6e4325015052adcc7dde58b8ef9f8d8f2e9695d3e26d7802a2c5f69ca1106a082c8b4f6b5cd84873db14e847b2e95a711658d8477c4a53e3531778a09f7feac12b58bd19836b619cbc454920e3c17550eaa47b2986758c41a5059dfe4dbc3eac5653b84b4978da6fb0de56d2bee0a79bbabe09f3c79441bd198d2fd87aa1f21b47cae4add220e9b0004ab308204 EAP-Message = 0xa73082038fa0030201020209 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x3d1b22fe3f1837c4e21bc6380caaf462 Finished request 9. Going to the next request Waking up in 4.7 seconds. rad_recv: Access-Request packet from host 10.199.20.240 port 6219, id=1, length=248 User-Name = "1320CD7377DCB1AA6BACBBAD1A23AEE5@undisclosed.com" State = 0x3d1b22fe3f1837c4e21bc6380caaf462 Chargeable-User-Identity = "null" NAS-IP-Address = 10.199.20.240 NAS-Port = 5 NAS-Port-Type = Wireless-802.16 Framed-MTU = 1400 NAS-Identifier = "test" Calling-Station-Id = "\000&\202g\023p" Service-Type = Framed-User WiMAX-GMT-Timezone-offset = 0 WiMAX-BS-Id = 0x000083010102 WiMAX-Release = "1.2" WiMAX-Accounting-Capabilities = 3 WiMAX-Hotlining-Capabilities = Hotline-Profile-Id WiMAX-Idle-Mode-Notification-Cap = Supported WiMAX-Attr-1281 = 0x01 WiMAX-Attr-1537 = 0x0000006a WiMAX-Available-In-Client = 67 WiMAX-Attr-36 = 0x000001 EAP-Message = 0x020300061500 Message-Authenticator = 0xb874df56087b707cfc085595cef29766 # Executing section authorize from file /etc/raddb/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop rlm_wimax: Fixing WiMAX binary Calling-Station-Id to 00-26-82-67-13-70 ++[wimax] returns ok [suffix] Looking up realm "undisclosed.com" for User-Name = "1320CD7377DCB1AA6BACBBAD1A23AEE5@undisclosed.com" [suffix] No such realm "undisclosed.com" ++[suffix] returns noop [eap] EAP packet type response id 3 length 6 [eap] Continuing tunnel setup. ++[eap] returns ok Found Auth-Type = EAP # Executing group from file /etc/raddb/sites-enabled/default +- entering group authenticate {...} [eap] Request found, released from the list [eap] EAP/ttls [eap] processing type ttls [ttls] Authenticate [ttls] processing EAP-TLS [ttls] Received TLS ACK [ttls] ACK handshake fragment handler [ttls] eaptls_verify returned 1 [ttls] eaptls_process returned 13 ++[eap] returns handled Sending Access-Challenge of id 1 to 10.199.20.240 port 6219 EAP-Message = 0x0104040015c000000aad00f69a36800c93c0e9300d06092a864886f70d0101050500308193310b3009060355040613024652310f300d060355040813065261646975733112301006035504071309536f6d65776865726531153013060355040a130c4578616d706c6520496e632e3120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d312630240603550403131d4578616d706c6520436572746966696361746520417574686f72697479301e170d3132303932373230323931365a170d3132313132363230323931365a308193310b3009060355040613024652310f300d0603550408130652616469757331123010 EAP-Message = 0x06035504071309536f6d65776865726531153013060355040a130c4578616d706c6520496e632e3120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d312630240603550403131d4578616d706c6520436572746966696361746520417574686f7269747930820122300d06092a864886f70d01010105000382010f003082010a0282010100d9416f4a53fae50a7026bb1ca7127d27924843f1f61433e89abd8c00a1d41a4eb95ae44df2c49ac28c3a5492d9f751e91e4648b3fc28130d65e57a6ed7b4c9da2c094f55c7dabafef975d013112a4b4b335aac29fd325d7befc35ecc083e4d914e83043699b04add11ec8e EAP-Message = 0xb285b7c47c0cf057bd6fea3fab8c2b184489a5bf8ace00b216ce27c01a066f92c28bb1688cd7a085b2ef1e548cbc7f07fdb8d37b65ede2a6b39d2e5c28010fa22220ac4148277f2c183851c02c4b93d719ddc25b764fc2dd3230f11c24bd8a5d82e25129b7758ea6ed17fd3b0f748a2c56c5b30ea43e64642b850bf791c833d9de05445bceb00bf78c12f21a6eba2a333cca0c7ad90203010001a381fb3081f8301d0603551d0e04160414fae95dc6e57d9997440f8c45a9360970a8a5c2843081c80603551d230481c03081bd8014fae95dc6e57d9997440f8c45a9360970a8a5c284a18199a48196308193310b3009060355040613024652310f300d EAP-Message = 0x060355040813065261646975733112301006035504071309536f6d65776865726531153013060355040a130c4578616d706c6520496e632e3120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d312630240603550403131d4578616d706c6520436572746966696361746520417574686f72697479820900f69a36800c93c0e9300c0603551d13040530030101ff300d06092a864886f70d010105050003820101007abe5079ce7fc50a7960020c5ee7e33191e24c14d469f00ce6b22c16ab8d9e6cb16e3add64e352094e45ffda438e92a39d47ef639b6594240ab3a0e101138e279660c1083d7cffef6f01923fb674 EAP-Message = 0x51cc96f02f1763e5388aaa08 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x3d1b22fe3e1f37c4e21bc6380caaf462 Finished request 10. Going to the next request Waking up in 4.6 seconds. rad_recv: Access-Request packet from host 10.199.20.240 port 6216, id=1, length=248 User-Name = "1320CD7377DCB1AA6BACBBAD1A23AEE5@undisclosed.com" State = 0x3d1b22fe3e1f37c4e21bc6380caaf462 Chargeable-User-Identity = "null" NAS-IP-Address = 10.199.20.240 NAS-Port = 5 NAS-Port-Type = Wireless-802.16 Framed-MTU = 1400 NAS-Identifier = "test" Calling-Station-Id = "\000&\202g\023p" Service-Type = Framed-User WiMAX-GMT-Timezone-offset = 0 WiMAX-BS-Id = 0x000083010102 WiMAX-Release = "1.2" WiMAX-Accounting-Capabilities = 3 WiMAX-Hotlining-Capabilities = Hotline-Profile-Id WiMAX-Idle-Mode-Notification-Cap = Supported WiMAX-Attr-1281 = 0x01 WiMAX-Attr-1537 = 0x0000006a WiMAX-Available-In-Client = 67 WiMAX-Attr-36 = 0x000001 EAP-Message = 0x020400061500 Message-Authenticator = 0x4b4a3e988fdc78cb60e7fc872f0291ec # Executing section authorize from file /etc/raddb/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop rlm_wimax: Fixing WiMAX binary Calling-Station-Id to 00-26-82-67-13-70 ++[wimax] returns ok [suffix] Looking up realm "undisclosed.com" for User-Name = "1320CD7377DCB1AA6BACBBAD1A23AEE5@undisclosed.com" [suffix] No such realm "undisclosed.com" ++[suffix] returns noop [eap] EAP packet type response id 4 length 6 [eap] Continuing tunnel setup. ++[eap] returns ok Found Auth-Type = EAP # Executing group from file /etc/raddb/sites-enabled/default +- entering group authenticate {...} [eap] Request found, released from the list [eap] EAP/ttls [eap] processing type ttls [ttls] Authenticate [ttls] processing EAP-TLS [ttls] Received TLS ACK [ttls] ACK handshake fragment handler [ttls] eaptls_verify returned 1 [ttls] eaptls_process returned 13 ++[eap] returns handled Sending Access-Challenge of id 1 to 10.199.20.240 port 6216 EAP-Message = 0x010502cb158000000aad921ee4f1071e8d4860225e19af0554bde1421a6647aa33e46d9f9691aff69c875e8229e1baac4394bc1e1f2e857e474b5d181ae344d260691d845bcad5a4ee58b2bdfe0cb103335c0a642b6ecf4ea630836a22c41dd506a930b32544e00486d264bfdb49fc26cf00e96598911d2569ad3d7d10f9a1be2941bb56f8b684d6f08fc5cd3834cf8006f80638cb34fc65f38811592256d8b7fcfaa87301f958e056d943f621ec10b7160301020d0c0002090080ab08979de861c27c1e0ddf489d2a715a6362fdcabac2ba673e46a96be8209efaa298dff3532c0ca4fc593a6fa0cf7eb6959fcc17447028de57788e84644ec5e4d6ad EAP-Message = 0xd7ed1c67c5006738d3b00aa2bd6921a2dacda4dba0eb2cfe668b7eb60dde719053f7b92f55f8bda32784dc0a5cec065fb3e233969cbfc47662576a44c8e300010200802e479e29f0f795052aff8a81b01b5673343d287e439aad873fe9ee0133262c123e48fdc4344c9fa2f5e169609796a1e180f34aa0e932b4e69ae7cbee22362a3a0704b515774883d97dc9723c9e9e08fed3f2658abe681f51e0ce14bac33284fdfe0910295155c6c145e9b3d1495c19fa8d3ff7176a1c08fb5dd63b2d119b0229010052587f03ecb2cf51f55b0bdf8aaff7d7140b19f79ee6fe27e7f971c63c99902625587503d9f7f5f21f7cfb71ec9befa7336d290840c0a8d1 EAP-Message = 0x3d04b449eb53f890f1939d6d270d30742f3a6c98c4562b2f9f982838b358cf520d24ed6925026050f0621c930e766d0669965ba2dde17673b9cae7931ff7cca15f85c8ab6f7973b70db1bb3f548d7eea7994f9332f333bdd29e12b5ae7667abdf94c95bbf5a56df10714938ae43e9f34c1fbe9f5628fa0455f6f7883ad0cc7d2f8b75c6c9572a814ededb5158c9435a8ff47240696cc155788f8d5397aa5388867d3f08cc9fcb9c62d9d368658a8c0b71774055bd23ff3f0d50b03422f5dec055516afce6b16d31516030100040e000000 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x3d1b22fe391e37c4e21bc6380caaf462 Finished request 11. Going to the next request Waking up in 4.5 seconds. rad_recv: Access-Request packet from host 10.199.20.240 port 6217, id=1, length=446 User-Name = "1320CD7377DCB1AA6BACBBAD1A23AEE5@undisclosed.com" State = 0x3d1b22fe391e37c4e21bc6380caaf462 Chargeable-User-Identity = "null" NAS-IP-Address = 10.199.20.240 NAS-Port = 5 NAS-Port-Type = Wireless-802.16 Framed-MTU = 1400 NAS-Identifier = "test" Calling-Station-Id = "\000&\202g\023p" Service-Type = Framed-User WiMAX-GMT-Timezone-offset = 0 WiMAX-BS-Id = 0x000083010102 WiMAX-Release = "1.2" WiMAX-Accounting-Capabilities = 3 WiMAX-Hotlining-Capabilities = Hotline-Profile-Id WiMAX-Idle-Mode-Notification-Cap = Supported WiMAX-Attr-1281 = 0x01 WiMAX-Attr-1537 = 0x0000006a WiMAX-Available-In-Client = 67 WiMAX-Attr-36 = 0x000001 EAP-Message = 0x020500cc150016030100861000008200805bf0ee4eff60c428c48178565c479d314285d7e56b92715d94000a39febd071764f7d993ad7bf536e6045d9c7d939e5a7ca26db24ae358123b274a762bebb91398543c9696fb166c37e4acc90ece7156e2e785c35792ac2497a2275d79816c54f420fb0b0ef368ceaa6ff732dc7ab700d1594a4f53eb722fd670c324c2f74b7814030100010116030100303fb2196d56b8c5db3a8d286d13a3e7be1525c540e847b03753ff8dcd44b722a22eaebbfdae4733e348234f2c79332fa6 Message-Authenticator = 0xd9c5455c464de79980b501e138efcbc3 # Executing section authorize from file /etc/raddb/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop rlm_wimax: Fixing WiMAX binary Calling-Station-Id to 00-26-82-67-13-70 ++[wimax] returns ok [suffix] Looking up realm "undisclosed.com" for User-Name = "1320CD7377DCB1AA6BACBBAD1A23AEE5@undisclosed.com" [suffix] No such realm "undisclosed.com" ++[suffix] returns noop [eap] EAP packet type response id 5 length 204 [eap] Continuing tunnel setup. ++[eap] returns ok Found Auth-Type = EAP # Executing group from file /etc/raddb/sites-enabled/default +- entering group authenticate {...} [eap] Request found, released from the list [eap] EAP/ttls [eap] processing type ttls [ttls] Authenticate [ttls] processing EAP-TLS [ttls] eaptls_verify returned 7 [ttls] Done initial handshake [ttls] <<< TLS 1.0 Handshake [length 0086], ClientKeyExchange [ttls] TLS_accept: SSLv3 read client key exchange A [ttls] <<< TLS 1.0 ChangeCipherSpec [length 0001] [ttls] <<< TLS 1.0 Handshake [length 0010], Finished [ttls] TLS_accept: SSLv3 read finished A [ttls] >>> TLS 1.0 ChangeCipherSpec [length 0001] [ttls] TLS_accept: SSLv3 write change cipher spec A [ttls] >>> TLS 1.0 Handshake [length 0010], Finished [ttls] TLS_accept: SSLv3 write finished A [ttls] TLS_accept: SSLv3 flush data [ttls] (other): SSL negotiation finished successfully SSL Connection Established [ttls] eaptls_process returned 13 ++[eap] returns handled Sending Access-Challenge of id 1 to 10.199.20.240 port 6217 EAP-Message = 0x0106004515800000003b14030100010116030100300d420f69ee784d90337c123e3ad17333f33afd4785266a8495af2cd5bd00c57f9b5250ab81d6abacad9f0a3b06a6a76a Message-Authenticator = 0x00000000000000000000000000000000 State = 0x3d1b22fe381d37c4e21bc6380caaf462 Finished request 12. Going to the next request Waking up in 3.6 seconds. rad_recv: Access-Request packet from host 10.199.20.240 port 6218, id=1, length=450 User-Name = "1320CD7377DCB1AA6BACBBAD1A23AEE5@undisclosed.com" State = 0x3d1b22fe381d37c4e21bc6380caaf462 Chargeable-User-Identity = "null" NAS-IP-Address = 10.199.20.240 NAS-Port = 5 NAS-Port-Type = Wireless-802.16 Framed-MTU = 1400 NAS-Identifier = "test" Calling-Station-Id = "\000&\202g\023p" Service-Type = Framed-User WiMAX-GMT-Timezone-offset = 0 WiMAX-BS-Id = 0x000083010102 WiMAX-Release = "1.2" WiMAX-Accounting-Capabilities = 3 WiMAX-Hotlining-Capabilities = Hotline-Profile-Id WiMAX-Idle-Mode-Notification-Cap = Supported WiMAX-Attr-1281 = 0x01 WiMAX-Attr-1537 = 0x0000006a WiMAX-Available-In-Client = 67 WiMAX-Attr-36 = 0x000001 EAP-Message = 0x020600d0150017030100202efd8b68040fc99d7215fc82ddb19fcc9d5d7db5d6bf00feab83065c3c66904e17030100a08d9c6735ac0f310c1a1b40fc8b8b830001ad22a156e365fb7c7a3a172bb37b2936605498f2249045b9e90b8d078a50b9308ccc874344e52912a6ef295c7ab21e6a110effee3fe5fdb09aa3340455e22b5c29903d4cbc38b91756b75e551f21f71b9a3f73655188839f65cc8d01ed3fa072b892d664b5a82caed9fd110f88727b00321d304fe9f0d62ff61bb07eacde6670bc8f3fe688820431254c4fe8ca8493 Message-Authenticator = 0xba312fe00908947881503e3743208d95 # Executing section authorize from file /etc/raddb/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop rlm_wimax: Fixing WiMAX binary Calling-Station-Id to 00-26-82-67-13-70 ++[wimax] returns ok [suffix] Looking up realm "undisclosed.com" for User-Name = "1320CD7377DCB1AA6BACBBAD1A23AEE5@undisclosed.com" [suffix] No such realm "undisclosed.com" ++[suffix] returns noop [eap] EAP packet type response id 6 length 208 [eap] Continuing tunnel setup. ++[eap] returns ok Found Auth-Type = EAP # Executing group from file /etc/raddb/sites-enabled/default +- entering group authenticate {...} [eap] Request found, released from the list [eap] EAP/ttls [eap] processing type ttls [ttls] Authenticate [ttls] processing EAP-TLS [ttls] eaptls_verify returned 7 [ttls] Done initial handshake [ttls] eaptls_process returned 7 [ttls] Session established. Proceeding to decode tunneled attributes. [ttls] Got tunneled request User-Name = "002682671370@undisclosed.com" MS-CHAP-Challenge = 0xc919ad25030747b5b148f0012fe58cb6 MS-CHAP2-Response = 0x4a004b1aed39e592b691d44948ff62f2e0af00000000000000005c32a2d43a9b7763656058b7685e4fff541653c66a69e82c FreeRADIUS-Proxied-To = 127.0.0.1 [ttls] Sending tunneled request User-Name = "002682671370@undisclosed.com" MS-CHAP-Challenge = 0xc919ad25030747b5b148f0012fe58cb6 MS-CHAP2-Response = 0x4a004b1aed39e592b691d44948ff62f2e0af00000000000000005c32a2d43a9b7763656058b7685e4fff541653c66a69e82c FreeRADIUS-Proxied-To = 127.0.0.1 Chargeable-User-Identity = "null" NAS-IP-Address = 10.199.20.240 NAS-Port = 5 NAS-Port-Type = Wireless-802.16 Framed-MTU = 1400 NAS-Identifier = "test" Calling-Station-Id = "00-26-82-67-13-70" Service-Type = Framed-User WiMAX-GMT-Timezone-offset = 0 WiMAX-BS-Id = 0x000083010102 WiMAX-Release = "1.2" WiMAX-Accounting-Capabilities = 3 WiMAX-Hotlining-Capabilities = Hotline-Profile-Id WiMAX-Idle-Mode-Notification-Cap = Supported WiMAX-Attr-1281 = 0x01 WiMAX-Attr-1537 = 0x0000006a WiMAX-Available-In-Client = 67 WiMAX-Attr-36 = 0x000001 server inner-tunnel { # Executing section authorize from file /etc/raddb/sites-enabled/inner-tunnel +- entering group authorize {...} ++[chap] returns noop [mschap] Found MS-CHAP attributes. Setting 'Auth-Type = mschap' ++[mschap] returns ok [suffix] Looking up realm "undisclosed.com" for User-Name = "002682671370@undisclosed.com" [suffix] No such realm "undisclosed.com" ++[suffix] returns noop ++[control] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop ++[files] returns noop [sql] expand: %{User-Name} -> 002682671370@undisclosed.com [sql] sql_set_user escaped user --> '002682671370@undisclosed.com' rlm_sql (sql): Reserving sql socket id: 4 [sql] expand: SELECT id, UserName, Attribute, Value, Op FROM radcheck WHERE Username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, UserName, Attribute, Value, Op FROM radcheck WHERE Username = '002682671370@undisclosed.com' ORDER BY id rlm_sql_postgresql: Status: PGRES_TUPLES_OK rlm_sql_postgresql: query affected rows = 1 , fields = 5 [sql] User found in radcheck table [sql] expand: SELECT id, UserName, Attribute, Value, Op FROM radreply WHERE Username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, UserName, Attribute, Value, Op FROM radreply WHERE Username = '002682671370@undisclosed.com' ORDER BY id rlm_sql_postgresql: Status: PGRES_TUPLES_OK rlm_sql_postgresql: query affected rows = 0 , fields = 5 [sql] expand: SELECT GroupName FROM radusergroup WHERE UserName='%{SQL-User-Name}' ORDER BY priority -> SELECT GroupName FROM radusergroup WHERE UserName='002682671370@undisclosed.com' ORDER BY priority rlm_sql_postgresql: Status: PGRES_TUPLES_OK rlm_sql_postgresql: query affected rows = 1 , fields = 1 [sql] expand: SELECT id, GroupName, Attribute, Value, op FROM radgroupcheck WHERE GroupName = '%{Sql-Group}' ORDER BY id -> SELECT id, GroupName, Attribute, Value, op FROM radgroupcheck WHERE GroupName = 'Business' ORDER BY id rlm_sql_postgresql: Status: PGRES_TUPLES_OK rlm_sql_postgresql: query affected rows = 0 , fields = 5 [sql] User found in group Business [sql] expand: SELECT id, GroupName, Attribute, Value, op FROM radgroupreply WHERE GroupName = '%{Sql-Group}' ORDER BY id -> SELECT id, GroupName, Attribute, Value, op FROM radgroupreply WHERE GroupName = 'Business' ORDER BY id rlm_sql_postgresql: Status: PGRES_TUPLES_OK rlm_sql_postgresql: query affected rows = 8 , fields = 5 rlm_sql (sql): Released sql socket id: 4 ++[sql] returns ok ++[expiration] returns noop ++[logintime] returns noop [pap] WARNING: Auth-Type already set. Not setting to PAP ++[pap] returns noop Found Auth-Type = MSCHAP # Executing group from file /etc/raddb/sites-enabled/inner-tunnel +- entering group MS-CHAP {...} [mschap] Creating challenge hash with username: 002682671370@undisclosed.com [mschap] Client is using MS-CHAPv2 for 002682671370@undisclosed.com, we need NT-Password [mschap] adding MS-CHAPv2 MPPE keys ++[mschap] returns ok WARNING: Empty post-auth section. Using default return values. # Executing section post-auth from file /etc/raddb/sites-enabled/inner-tunnel } # server inner-tunnel [ttls] Got tunneled reply code 2 Session-Timeout := 86400 Acct-Interim-Interval := 60 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 MS-CHAP2-Success = 0x4a533d30353933303244453938323444463545414642463738433642313742443639433239343131363541 MS-MPPE-Recv-Key = 0xe47e60276cf546b4d154c7a4312fed43 MS-MPPE-Send-Key = 0xae6450ff89cc6be810f6663c9c64877f MS-MPPE-Encryption-Policy = 0x00000001 MS-MPPE-Encryption-Types = 0x00000006 [ttls] Got tunneled Access-Accept [ttls] Got MS-CHAP2-Success, tunneling it to the client in a challenge. ++[eap] returns handled Sending Access-Challenge of id 1 to 10.199.20.240 port 6218 EAP-Message = 0x0107005f158000000055170301005077724abe9bda2c3ab4c2a5b6e9133fff07ae7a253430c9ffe1670894562729f17314560024cb5e27684002a9cb7ac3d92f5ffed2a5a86acd16452736910513e429e1107846c729aa7475e84238443733 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x3d1b22fe3b1c37c4e21bc6380caaf462 Finished request 13. Going to the next request Waking up in 3.5 seconds. rad_recv: Access-Request packet from host 10.199.20.240 port 6219, id=2, length=248 User-Name = "1320CD7377DCB1AA6BACBBAD1A23AEE5@undisclosed.com" State = 0x3d1b22fe3b1c37c4e21bc6380caaf462 Chargeable-User-Identity = "null" NAS-IP-Address = 10.199.20.240 NAS-Port = 5 NAS-Port-Type = Wireless-802.16 Framed-MTU = 1400 NAS-Identifier = "test" Calling-Station-Id = "\000&\202g\023p" Service-Type = Framed-User WiMAX-GMT-Timezone-offset = 0 WiMAX-BS-Id = 0x000083010102 WiMAX-Release = "1.2" WiMAX-Accounting-Capabilities = 3 WiMAX-Hotlining-Capabilities = Hotline-Profile-Id WiMAX-Idle-Mode-Notification-Cap = Supported WiMAX-Attr-1281 = 0x01 WiMAX-Attr-1537 = 0x0000006a WiMAX-Available-In-Client = 67 WiMAX-Attr-36 = 0x000001 EAP-Message = 0x020700061500 Message-Authenticator = 0x59a914ec4b16deb92b5f027659f5c712 # Executing section authorize from file /etc/raddb/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop rlm_wimax: Fixing WiMAX binary Calling-Station-Id to 00-26-82-67-13-70 ++[wimax] returns ok [suffix] Looking up realm "undisclosed.com" for User-Name = "1320CD7377DCB1AA6BACBBAD1A23AEE5@undisclosed.com" [suffix] No such realm "undisclosed.com" ++[suffix] returns noop [eap] EAP packet type response id 7 length 6 [eap] Continuing tunnel setup. ++[eap] returns ok Found Auth-Type = EAP # Executing group from file /etc/raddb/sites-enabled/default +- entering group authenticate {...} [eap] Request found, released from the list [eap] EAP/ttls [eap] processing type ttls [ttls] Authenticate [ttls] processing EAP-TLS [ttls] Received TLS ACK [ttls] ACK handshake is finished [ttls] eaptls_verify returned 3 [ttls] eaptls_process returned 3 [ttls] Using saved attributes from the original Access-Accept Session-Timeout := 86400 Acct-Interim-Interval := 60 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 [eap] Freeing handler ++[eap] returns ok # Executing section post-auth from file /etc/raddb/sites-enabled/default +- entering group post-auth {...} ++[exec] returns noop [wimax] MIP-RK = 0x00b0ce41e978a30ec9b196bdea7bd74def743761ddc81add6cb19ca577056e59ea814c5b54891482a045773e861657260658939502a9babd7c0a59a92a99cf87 [wimax] MIP-SPI = 42f4fa35 [wimax] WARNING: WiMAX-MN-NAI was not found in the request or in the reply. [wimax] WARNING: We cannot calculate MN-HA keys. [wimax] WARNING: WiMAX-IP-Technology not found in reply. [wimax] WARNING: Not calculating MN-HA keys ++[wimax] returns updated Sending Access-Accept of id 2 to 10.199.20.240 port 6219 Session-Timeout := 86400 Acct-Interim-Interval := 60 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 MS-MPPE-Recv-Key = 0x6b033615247e78ea0e225bea745bba8c33634e0bf28ea0388174965a980b1642 MS-MPPE-Send-Key = 0x1a21679697b923cc88f4b4ba4fa37ded7f00c035811cd6ff18b4fb4e64956077 EAP-Message = 0x03070004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = "1320CD7377DCB1AA6BACBBAD1A23AEE5@undisclosed.com" Finished request 14. Going to the next request Waking up in 3.4 seconds.
James Leavitt wrote:
I've probably missed something or buggered an option, but I've searched and searched and cannot find an answer to this. This is for a WiMAX deployment and am using the built in dictionaries. The issue is with the WiMAX-Packet-Flow-Descriptor tlv . ... Everything looks good but on a pcap / radsniff I get this:
Put the raw "pcap" file somewhere. Maybe the issue is the server, maybe it's radsniff. You could also try the git branch "release_branch_3.0.0". It has a re-written WiMAX encoder / decoder, which now works everywhere. Alan DeKok.
Don't forget if the hardware is Alvarion or Runcom you cannot use the standard dictionaries. Alvarion (now Telrad) is proprietary but similar to the standard dictionary and Runcom only uses their own. David -----Original Message----- From: freeradius-users-bounces+davidp=wirelessconnections.net@lists.freeradius.org [mailto:freeradius-users-bounces+davidp=wirelessconnections.net@lists.freera dius.org] On Behalf Of Alan DeKok Sent: Tuesday, July 30, 2013 8:02 AM To: FreeRadius users mailing list Subject: Re: WiMAX TLV value correct in debug but not correct in packet capture James Leavitt wrote:
I've probably missed something or buggered an option, but I've searched and searched and cannot find an answer to this. This is for a WiMAX deployment and am using the built in dictionaries. The issue is with the WiMAX-Packet-Flow-Descriptor tlv . ... Everything looks good but on a pcap / radsniff I get this:
Put the raw "pcap" file somewhere. Maybe the issue is the server, maybe it's radsniff. You could also try the git branch "release_branch_3.0.0". It has a re-written WiMAX encoder / decoder, which now works everywhere. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Thank you Gentlemen, I am working with Alvarion CPEs but a WiChorus ASN, which I have setup on a commercial AAA without issues. I also have Freeradius working with WiChorus on another instance also but not for receiving these particular TLVs. I initially performed a tcpdump and this was where I was seeing the different values (which match radsniff btw) than what was programmed. I then compared the capture to our working solution (a commercial radius platform) and confirmed that the values radsniff / tcpdump were what I was expecting, which in turn do not match the output from Freeradius. I feel the problem is when the values are copied to the outer tunnel, but just these TLVs get corrupted. I'll take a look at 3.0.0 and see if I can work with that and post back my findings. Thanks again, James On 07/30/2013 11:13 AM, David Peterson wrote:
RE: WiMAX TLV value correct in debug but not correct in packet capture
Don't forget if the hardware is Alvarion or Runcom you cannot use the standard dictionaries.
Alvarion (now Telrad) is proprietary but similar to the standard dictionary and Runcom only uses their own.
David
-----Original Message----- From: freeradius-users-bounces+davidp=wirelessconnections.net@lists.freeradius.org [mailto:freeradius-users-bounces+davidp=wirelessconnections.net@lists.freera dius.org] On Behalf Of Alan DeKok Sent: Tuesday, July 30, 2013 8:02 AM To: FreeRadius users mailing list Subject: Re: WiMAX TLV value correct in debug but not correct in packet capture
James Leavitt wrote:
I've probably missed something or buggered an option, but I've searched and searched and cannot find an answer to this. This is for a WiMAX deployment and am using the built in dictionaries. The issue is with the WiMAX-Packet-Flow-Descriptor tlv . ... Everything looks good but on a pcap / radsniff I get this:
Put the raw "pcap" file somewhere. Maybe the issue is the server, maybe it's radsniff.
You could also try the git branch "release_branch_3.0.0". It has a re-written WiMAX encoder / decoder, which now works everywhere.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- This message has been scanned by MailScanner
Ok, 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: Radsniff on the wire (verified that it is the same in tcpdump and wireshark): Access-Accept Id 204 10.199.10.14:1812 -> 10.199.20.240:6217 +3.541 Session-Timeout = 86400 Acct-Interim-Interval = 60 WiMAX-Packet-Data-Flow-Id = 18359 WiMAX-Service-Data-Flow-Id = 3513 WiMAX-Service-Profile-Id = 263782400 WiMAX-Packet-Data-Flow-Id = 18359 WiMAX-Service-Data-Flow-Id = 18359 WiMAX-Service-Profile-Id = 0 Microsoft-Attr-17 = 0x86c4d95414f6aecd8f16cc5ef0aa1ff8b5354e553cb724bc9f103636741cdef35a57f89db1afca3711c57d5d900a06b2578b Microsoft-Attr-16 = 0x8812b94254b5c21e2be59bd62927f045f5536b1844f79f45ca7d9442db106f538f8b960b61bb483f61bad39442975af58612 EAP-Message = 0x03070004 Message-Authenticator = 0xd4654370830d4a11371d217714ee7b4f User-Name = "1B2D2F35483D3BEF7D8827EA61F8EEA5@undisclosed.com" Debug on the radius server process shows things as they are in the DB: Sending Access-Accept of id 204 to 10.199.20.240 port 6217 Session-Timeout := 86400 Acct-Interim-Interval := 60 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 MS-MPPE-Recv-Key = 0xc5232594526fb99097311c861a49671710a2d6db7c0068788ef0122c9b551ae1 MS-MPPE-Send-Key = 0xed6c9de58fabf8519b09d2900849d611142ece093a7a6973869761872d9c9bc6 EAP-Message = 0x03070004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = "1B2D2F35483D3BEF7D8827EA61F8EEA5@undisclosed.com" I am trying to get a tcp capture but the system is now not letting me re-auth (I was working on fixing the CSID in the accounting and must have changed something it doesn't like) so not sure what's up, but I don't believe v3 is the solution. I will get a tcpdump if it's worth while. Thanks, James On 07/30/2013 12:01 PM, James Leavitt wrote:
Re: WiMAX TLV value correct in debug but not correct in packet capture
Thank you Gentlemen,
I am working with Alvarion CPEs but a WiChorus ASN, which I have setup on a commercial AAA without issues. I also have Freeradius working with WiChorus on another instance also but not for receiving these particular TLVs.
I initially performed a tcpdump and this was where I was seeing the different values (which match radsniff btw) than what was programmed. I then compared the capture to our working solution (a commercial radius platform) and confirmed that the values radsniff / tcpdump were what I was expecting, which in turn do not match the output from Freeradius. I feel the problem is when the values are copied to the outer tunnel, but just these TLVs get corrupted.
I'll take a look at 3.0.0 and see if I can work with that and post back my findings.
Thanks again,
James
On 07/30/2013 11:13 AM, David Peterson wrote:
RE: WiMAX TLV value correct in debug but not correct in packet capture
Don't forget if the hardware is Alvarion or Runcom you cannot use the standard dictionaries.
Alvarion (now Telrad) is proprietary but similar to the standard dictionary and Runcom only uses their own.
David
-----Original Message----- From:
freeradius-users-bounces+davidp=wirelessconnections.net@lists.freeradius.org
[mailto:freeradius-users-bounces+davidp=wirelessconnections.net@lists.freera
dius.org] On Behalf Of Alan DeKok Sent: Tuesday, July 30, 2013 8:02 AM To: FreeRadius users mailing list Subject: Re: WiMAX TLV value correct in debug but not correct in packet capture
James Leavitt wrote:
I've probably missed something or buggered an option, but I've searched and searched and cannot find an answer to this. This is for a WiMAX deployment and am using the built in dictionaries. The issue is with the WiMAX-Packet-Flow-Descriptor tlv . ... Everything looks good but on a pcap / radsniff I get this:
Put the raw "pcap" file somewhere. Maybe the issue is the server, maybe it's radsniff.
You could also try the git branch "release_branch_3.0.0". It has a re-written WiMAX encoder / decoder, which now works everywhere.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- This message has been scanned by MailScanner
- 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: james.leavitt@corp.xplornet.com <mailto: james.leavitt@corp.xplornet.com> Xplornet - Broadband Everywhere. GPG / SSH Public Keys in V-Card Notes
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.
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: james.leavitt@corp.xplornet.com <mailto: james.leavitt@corp.xplornet.com> Xplornet - Broadband Everywhere. GPG / SSH Public Keys in V-Card Notes
You've done something to the dictionaries. What is it? Alan DeKok. On 2013-07-31, at 10:57 AM, James Leavitt <james.leavitt@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
--
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: james.leavitt@corp.xplornet.com <mailto: james.leavitt@corp.xplornet.com>
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
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.leavitt@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
--
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: james.leavitt@corp.xplornet.com <mailto: james.leavitt@corp.xplornet.com>
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
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.leavitt@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 >
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.leavitt@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.leavitt@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
Understood Alan, As I admitted I should have followed your example and copied the whole VSA, not just the TLV section, again mea culpa. I did however include the PCAP as you had requested, which has the works. James On 07/31/2013 02:34 PM, Alan DeKok wrote: > Re: WiMAX TLV value correct in debug but not correct in packet capture > > 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.leavitt@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.leavitt@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 > > -- > This message has been scanned by MailScanner >
I havent looked at the pcap file, but I'm sure it says the same thing. The WiMAX VSA is wrong. I don't know why. It works for me, using the default configuration.
Strange indeed. I just rebuilt a new server on a newer os (and 64 bit vs 32), and I am still seeing the same issue. I must have something messed up somewhere. Only thing is order of the whole structure is different from my prod, but that shouldn't matter. Here's my eap.conf just in case there is something worth looking at, most significant changes that I've done here is "copy_request_to_tunnel = yes" and "use_tunneled_reply = yes": # -*- text -*- ## ## eap.conf -- Configuration for EAP types (PEAP, TTLS, etc.) ## ## $Id$ ####################################################################### # # Whatever you do, do NOT set 'Auth-Type := EAP'. The server # is smart enough to figure this out on its own. The most # common side effect of setting 'Auth-Type := EAP' is that the # users then cannot use ANY other authentication method. # # EAP types NOT listed here may be supported via the "eap2" module. # See experimental.conf for documentation. # eap { # Invoke the default supported EAP type when # EAP-Identity response is received. # # The incoming EAP messages DO NOT specify which EAP # type they will be using, so it MUST be set here. # # For now, only one default EAP type may be used at a time. # # If the EAP-Type attribute is set by another module, # then that EAP type takes precedence over the # default type configured here. # default_eap_type = md5 # A list is maintained to correlate EAP-Response # packets with EAP-Request packets. After a # configurable length of time, entries in the list # expire, and are deleted. # timer_expire = 60 # There are many EAP types, but the server has support # for only a limited subset. If the server receives # a request for an EAP type it does not support, then # it normally rejects the request. By setting this # configuration to "yes", you can tell the server to # instead keep processing the request. Another module # MUST then be configured to proxy the request to # another RADIUS server which supports that EAP type. # # If another module is NOT configured to handle the # request, then the request will still end up being # rejected. ignore_unknown_eap_types = no # Cisco AP1230B firmware 12.2(13)JA1 has a bug. When given # a User-Name attribute in an Access-Accept, it copies one # more byte than it should. # # We can work around it by configurably adding an extra # zero byte. cisco_accounting_username_bug = no # # Help prevent DoS attacks by limiting the number of # sessions that the server is tracking. Most systems # can handle ~30 EAP sessions/s, so the default limit # of 4096 should be OK. max_sessions = 4096 # Supported EAP-types # # We do NOT recommend using EAP-MD5 authentication # for wireless connections. It is insecure, and does # not provide for dynamic WEP keys. # md5 { } # Cisco LEAP # # We do not recommend using LEAP in new deployments. See: # http://www.securiteam.com/tools/5TP012ACKE.html # # Cisco LEAP uses the MS-CHAP algorithm (but not # the MS-CHAP attributes) to perform it's authentication. # # As a result, LEAP *requires* access to the plain-text # User-Password, or the NT-Password attributes. # 'System' authentication is impossible with LEAP. # leap { } # Generic Token Card. # # Currently, this is only permitted inside of EAP-TTLS, # or EAP-PEAP. The module "challenges" the user with # text, and the response from the user is taken to be # the User-Password. # # Proxying the tunneled EAP-GTC session is a bad idea, # the users password will go over the wire in plain-text, # for anyone to see. # gtc { # The default challenge, which many clients # ignore.. #challenge = "Password: " # The plain-text response which comes back # is put into a User-Password attribute, # and passed to another module for # authentication. This allows the EAP-GTC # response to be checked against plain-text, # or crypt'd passwords. # # If you say "Local" instead of "PAP", then # the module will look for a User-Password # configured for the request, and do the # authentication itself. # auth_type = PAP } ## EAP-TLS # # See raddb/certs/README for additional comments # on certificates. # # If OpenSSL was not found at the time the server was # built, the "tls", "ttls", and "peap" sections will # be ignored. # # Otherwise, when the server first starts in debugging # mode, test certificates will be created. See the # "make_cert_command" below for details, and the README # file in raddb/certs # # These test certificates SHOULD NOT be used in a normal # deployment. They are created only to make it easier # to install the server, and to perform some simple # tests with EAP-TLS, TTLS, or PEAP. # # See also: # # http://www.dslreports.com/forum/remark,9286052~mode=flat # # Note that you should NOT use a globally known CA here! # e.g. using a Verisign cert as a "known CA" means that # ANYONE who has a certificate signed by them can # authenticate via EAP-TLS! This is likely not what you want. tls { # # These is used to simplify later configurations. # certdir = ${confdir}/certs cadir = ${confdir}/certs private_key_password = whatever private_key_file = ${certdir}/server.pem # If Private key & Certificate are located in # the same file, then private_key_file & # certificate_file must contain the same file # name. # # If CA_file (below) is not used, then the # certificate_file below MUST include not # only the server certificate, but ALSO all # of the CA certificates used to sign the # server certificate. certificate_file = ${certdir}/server.pem # Trusted Root CA list # # ALL of the CA's in this list will be trusted # to issue client certificates for authentication. # # In general, you should use self-signed # certificates for 802.1x (EAP) authentication. # In that case, this CA file should contain # *one* CA certificate. # # This parameter is used only for EAP-TLS, # when you issue client certificates. If you do # not use client certificates, and you do not want # to permit EAP-TLS authentication, then delete # this configuration item. CA_file = ${cadir}/ca.pem # # For DH cipher suites to work, you have to # run OpenSSL to create the DH file first: # # openssl dhparam -out certs/dh 1024 # dh_file = ${certdir}/dh random_file = ${certdir}/random # # This can never exceed the size of a RADIUS # packet (4096 bytes), and is preferably half # that, to accomodate other attributes in # RADIUS packet. On most APs the MAX packet # length is configured between 1500 - 1600 # In these cases, fragment size should be # 1024 or less. # # fragment_size = 1024 # include_length is a flag which is # by default set to yes If set to # yes, Total Length of the message is # included in EVERY packet we send. # If set to no, Total Length of the # message is included ONLY in the # First packet of a fragment series. # # include_length = yes # Check the Certificate Revocation List # # 1) Copy CA certificates and CRLs to same directory. # 2) Execute 'c_rehash <CA certs&CRLs Directory>'. # 'c_rehash' is OpenSSL's command. # 3) uncomment the line below. # 5) Restart radiusd # check_crl = yes CA_path = ${cadir} # # If check_cert_issuer is set, the value will # be checked against the DN of the issuer in # the client certificate. If the values do not # match, the cerficate verification will fail, # rejecting the user. # # In 2.1.10 and later, this check can be done # more generally by checking the value of the # TLS-Client-Cert-Issuer attribute. This check # can be done via any mechanism you choose. # # check_cert_issuer = "/C=GB/ST=Berkshire/L=Newbury/O=My Company Ltd" # # If check_cert_cn is set, the value will # be xlat'ed and checked against the CN # in the client certificate. If the values # do not match, the certificate verification # will fail rejecting the user. # # This check is done only if the previous # "check_cert_issuer" is not set, or if # the check succeeds. # # In 2.1.10 and later, this check can be done # more generally by checking the value of the # TLS-Client-Cert-CN attribute. This check # can be done via any mechanism you choose. # # check_cert_cn = %{User-Name} # # Set this option to specify the allowed # TLS cipher suites. The format is listed # in "man 1 ciphers". cipher_list = "DEFAULT" # # This command creates the initial "snake oil" # certificates when the server is run as root, # and via "radiusd -X". # # As of 2.1.11, it *also* checks the server # certificate for validity, including expiration. # This means that radiusd will refuse to start # when the certificate has expired. The alternative # is to have the 802.1X clients refuse to connect # when they discover the certificate has expired. # # Debugging client issues is hard, so it's better # for the server to print out an error message, # and refuse to start. # # Redhat RPM's run the bootstrap certificate creation # as part of the RPM install (not upgrade), therefore # the make_cert_command is commented out. # #make_cert_command = "${certdir}/bootstrap" # # Elliptical cryptography configuration # # Only for OpenSSL >= 0.9.8.f # ecdh_curve = "prime256v1" # # Session resumption / fast reauthentication # cache. # # The cache contains the following information: # # session Id - unique identifier, managed by SSL # User-Name - from the Access-Accept # Stripped-User-Name - from the Access-Request # Cached-Session-Policy - from the Access-Accept # # The "Cached-Session-Policy" is the name of a # policy which should be applied to the cached # session. This policy can be used to assign # VLANs, IP addresses, etc. It serves as a useful # way to re-apply the policy from the original # Access-Accept to the subsequent Access-Accept # for the cached session. # # On session resumption, these attributes are # copied from the cache, and placed into the # reply list. # # You probably also want "use_tunneled_reply = yes" # when using fast session resumption. # cache { # # Enable it. The default is "no". # Deleting the entire "cache" subsection # Also disables caching. # # You can disallow resumption for a # particular user by adding the following # attribute to the control item list: # # Allow-Session-Resumption = No # # If "enable = no" below, you CANNOT # enable resumption for just one user # by setting the above attribute to "yes". # enable = no # # Lifetime of the cached entries, in hours. # The sessions will be deleted after this # time. # lifetime = 24 # hours # # The maximum number of entries in the # cache. Set to "0" for "infinite". # # This could be set to the number of users # who are logged in... which can be a LOT. # max_entries = 255 } # # As of version 2.1.10, client certificates can be # validated via an external command. This allows # dynamic CRLs or OCSP to be used. # # This configuration is commented out in the # default configuration. Uncomment it, and configure # the correct paths below to enable it. # verify { # A temporary directory where the client # certificates are stored. This directory # MUST be owned by the UID of the server, # and MUST not be accessible by any other # users. When the server starts, it will do # "chmod go-rwx" on the directory, for # security reasons. The directory MUST # exist when the server starts. # # You should also delete all of the files # in the directory when the server starts. # tmpdir = /tmp/radiusd # The command used to verify the client cert. # We recommend using the OpenSSL command-line # tool. # # The ${..CA_path} text is a reference to # the CA_path variable defined above. # # The %{TLS-Client-Cert-Filename} is the name # of the temporary file containing the cert # in PEM format. This file is automatically # deleted by the server when the command # returns. # client = "/path/to/openssl verify -CApath ${..CA_path} %{TLS-Client-Cert-Filename}" } # # OCSP Configuration # Certificates can be verified against an OCSP # Responder. This makes it possible to immediately # revoke certificates without the distribution of # new Certificate Revokation Lists (CRLs). # ocsp { # # Enable it. The default is "no". # Deleting the entire "ocsp" subsection # Also disables ocsp checking # enable = no # # The OCSP Responder URL can be automatically # extracted from the certificate in question. # To override the OCSP Responder URL set # "override_cert_url = yes". # override_cert_url = yes # # If the OCSP Responder address is not # extracted from the certificate, the # URL can be defined here. # # Limitation: Currently the HTTP # Request is not sending the "Host: " # information to the web-server. This # can be a problem if the OCSP # Responder is running as a vhost. # url = "http://127.0.0.1/ocsp/" # # If the OCSP Responder can not cope with nonce # in the request, then it can be disabled here. # # For security reasons, disabling this option # is not recommended as nonce protects against # replay attacks. # # Note that Microsoft AD Certificate Services OCSP # Responder does not enable nonce by default. It is # more secure to enable nonce on the responder than # to disable it in the query here. # See http://technet.microsoft.com/en-us/library/cc770413%28WS.10%29.aspx # # use_nonce = yes # # Number of seconds before giving up waiting # for OCSP response. 0 uses system default. # # timeout = 0 # # Normally an error in querying the OCSP # responder (no response from server, server did # not understand the request, etc) will result in # a validation failure. # # To treat these errors as 'soft' failures and # still accept the certificate, enable this # option. # # Warning: this may enable clients with revoked # certificates to connect if the OCSP responder # is not available. Use with caution. # # softfail = no } } # The TTLS module implements the EAP-TTLS protocol, # which can be described as EAP inside of Diameter, # inside of TLS, inside of EAP, inside of RADIUS... # # Surprisingly, it works quite well. # # The TTLS module needs the TLS module to be installed # and configured, in order to use the TLS tunnel # inside of the EAP packet. You will still need to # configure the TLS module, even if you do not want # to deploy EAP-TLS in your network. Users will not # be able to request EAP-TLS, as it requires them to # have a client certificate. EAP-TTLS does not # require a client certificate. # # You can make TTLS require a client cert by setting # # EAP-TLS-Require-Client-Cert = Yes # # in the control items for a request. # ttls { # The tunneled EAP session needs a default # EAP type which is separate from the one for # the non-tunneled EAP module. Inside of the # TTLS tunnel, we recommend using EAP-MD5. # If the request does not contain an EAP # conversation, then this configuration entry # is ignored. default_eap_type = md5 # The tunneled authentication request does # not usually contain useful attributes # like 'Calling-Station-Id', etc. These # attributes are outside of the tunnel, # and normally unavailable to the tunneled # authentication request. # # By setting this configuration entry to # 'yes', any attribute which NOT in the # tunneled authentication request, but # which IS available outside of the tunnel, # is copied to the tunneled request. # # allowed values: {no, yes} copy_request_to_tunnel = yes # The reply attributes sent to the NAS are # usually based on the name of the user # 'outside' of the tunnel (usually # 'anonymous'). If you want to send the # reply attributes based on the user name # inside of the tunnel, then set this # configuration entry to 'yes', and the reply # to the NAS will be taken from the reply to # the tunneled request. # # allowed values: {no, yes} use_tunneled_reply = yes # # The inner tunneled request can be sent # through a virtual server constructed # specifically for this purpose. # # If this entry is commented out, the inner # tunneled request will be sent through # the virtual server that processed the # outer requests. # virtual_server = "inner-tunnel" # This has the same meaning as the # same field in the "tls" module, above. # The default value here is "yes". # include_length = yes } ################################################## # # !!!!! WARNINGS for Windows compatibility !!!!! # ################################################## # # If you see the server send an Access-Challenge, # and the client never sends another Access-Request, # then # # STOP! # # The server certificate has to have special OID's # in it, or else the Microsoft clients will silently # fail. See the "scripts/xpextensions" file for # details, and the following page: # # http://support.microsoft.com/kb/814394/en-us # # For additional Windows XP SP2 issues, see: # # http://support.microsoft.com/kb/885453/en-us # # # If is still doesn't work, and you're using Samba, # you may be encountering a Samba bug. See: # # https://bugzilla.samba.org/show_bug.cgi?id=6563 # # Note that we do not necessarily agree with their # explanation... but the fix does appear to work. # ################################################## # # The tunneled EAP session needs a default EAP type # which is separate from the one for the non-tunneled # EAP module. Inside of the TLS/PEAP tunnel, we # recommend using EAP-MS-CHAPv2. # # The PEAP module needs the TLS module to be installed # and configured, in order to use the TLS tunnel # inside of the EAP packet. You will still need to # configure the TLS module, even if you do not want # to deploy EAP-TLS in your network. Users will not # be able to request EAP-TLS, as it requires them to # have a client certificate. EAP-PEAP does not # require a client certificate. # # # You can make PEAP require a client cert by setting # # EAP-TLS-Require-Client-Cert = Yes # # in the control items for a request. # peap { # The tunneled EAP session needs a default # EAP type which is separate from the one for # the non-tunneled EAP module. Inside of the # PEAP tunnel, we recommend using MS-CHAPv2, # as that is the default type supported by # Windows clients. default_eap_type = mschapv2 # the PEAP module also has these configuration # items, which are the same as for TTLS. copy_request_to_tunnel = no use_tunneled_reply = no # When the tunneled session is proxied, the # home server may not understand EAP-MSCHAP-V2. # Set this entry to "no" to proxy the tunneled # EAP-MSCHAP-V2 as normal MSCHAPv2. # proxy_tunneled_request_as_eap = yes # # The inner tunneled request can be sent # through a virtual server constructed # specifically for this purpose. # # If this entry is commented out, the inner # tunneled request will be sent through # the virtual server that processed the # outer requests. # virtual_server = "inner-tunnel" # This option enables support for MS-SoH # see doc/SoH.txt for more info. # It is disabled by default. # # soh = yes # # The SoH reply will be turned into a request which # can be sent to a specific virtual server: # # soh_virtual_server = "soh-server" } # # This takes no configuration. # # Note that it is the EAP MS-CHAPv2 sub-module, not # the main 'mschap' module. # # Note also that in order for this sub-module to work, # the main 'mschap' module MUST ALSO be configured. # # This module is the *Microsoft* implementation of MS-CHAPv2 # in EAP. There is another (incompatible) implementation # of MS-CHAPv2 in EAP by Cisco, which FreeRADIUS does not # currently support. # mschapv2 { # Prior to version 2.1.11, the module never # sent the MS-CHAP-Error message to the # client. This worked, but it had issues # when the cached password was wrong. The # server *should* send "E=691 R=0" to the # client, which tells it to prompt the user # for a new password. # # The default is to behave as in 2.1.10 and # earlier, which is known to work. If you # set "send_error = yes", then the error # message will be sent back to the client. # This *may* help some clients work better, # but *may* also cause other clients to stop # working. # # send_error = no } } On 07/31/2013 04:04 PM, Alan DeKok wrote:
Re: WiMAX TLV value correct in debug but not correct in packet capture
I havent looked at the pcap file, but I'm sure it says the same thing. The WiMAX VSA is wrong. I don't know why. It works for me, using the default configuration. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- This message has been scanned by MailScanner
I've just tried other TLVs and the same problem, meanwhile everything that is not a TLV works. Thanks, James On 07/31/2013 05:10 PM, James Leavitt wrote:
Re: WiMAX TLV value correct in debug but not correct in packet capture
Strange indeed.
I just rebuilt a new server on a newer os (and 64 bit vs 32), and I am still seeing the same issue.
I must have something messed up somewhere. Only thing is order of the whole structure is different from my prod, but that shouldn't matter.
Here's my eap.conf just in case there is something worth looking at, most significant changes that I've done here is "copy_request_to_tunnel = yes" and "use_tunneled_reply = yes":
# -*- text -*- ## ## eap.conf -- Configuration for EAP types (PEAP, TTLS, etc.) ## ## $Id$ ...
James Leavitt wrote:
I just rebuilt a new server on a newer os (and 64 bit vs 32), and I am still seeing the same issue.
Weird...
I must have something messed up somewhere. Only thing is order of the whole structure is different from my prod, but that shouldn't matter.
It's hard to mess up basic RADIUS packet encoding. The whole point of the server design is that you *can't* mess it up. You deal with "Attribute = value", not with hex bytes in a packet.
Here's my eap.conf just in case there is something worth looking at, most significant changes that I've done here is "copy_request_to_tunnel = yes" and "use_tunneled_reply = yes":
Nothing there is relevant. What happens when you put the sample entry into the "users" file, and run "radclient" with a fixed name / password? If the encoding is still broken, then the problem is definitely not EAP. I fail to see how the encoding can be broken... especially on v2 and v3, which have completely different packet encoders. Are you sure that nothing else in the network is breaking the packets? i.e. is your network card OK? What happens when you try to run it on different physical hardware? I've seen issues like this before when a network card was broken. Change the card (or entire machine), and the problem goes away. Alan DeKok.
The last attempt was on a dedicated piece of hardware, not a VM. I also switched the OS to 64bit. As for the network card, since I get this in the VM system (v2 rpm and V3 compiled), and on the dedicated hardware (Fedora 19 rpm), and I am performing the capture on the radius server itself (before it hits the card) this shouldn't be the problem (or if it is I'm going to buy a lottery ticket). The config on the latest system is all in file, made it as basic as I could. Radclient is a good suggestion, I will try it and see what happens, perhaps it will yield something interesting, perhaps a strange interaction that the client itself is causing. Thanks, James On 08/01/2013 12:02 AM, Alan DeKok wrote:
Re: WiMAX TLV value correct in debug but not correct in packet capture
James Leavitt wrote:
I just rebuilt a new server on a newer os (and 64 bit vs 32), and I am still seeing the same issue.
Weird...
I must have something messed up somewhere. Only thing is order of the whole structure is different from my prod, but that shouldn't matter.
It's hard to mess up basic RADIUS packet encoding. The whole point of the server design is that you *can't* mess it up. You deal with "Attribute = value", not with hex bytes in a packet.
Here's my eap.conf just in case there is something worth looking at, most significant changes that I've done here is "copy_request_to_tunnel = yes" and "use_tunneled_reply = yes":
Nothing there is relevant.
What happens when you put the sample entry into the "users" file, and run "radclient" with a fixed name / password? If the encoding is still broken, then the problem is definitely not EAP.
I fail to see how the encoding can be broken... especially on v2 and v3, which have completely different packet encoders. Are you sure that nothing else in the network is breaking the packets?
i.e. is your network card OK?
What happens when you try to run it on different physical hardware?
I've seen issues like this before when a network card was broken. Change the card (or entire machine), and the problem goes away.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- This message has been scanned by MailScanner
James Leavitt wrote:
Radclient is a good suggestion, I will try it and see what happens, perhaps it will yield something interesting, perhaps a strange interaction that the client itself is causing.
There is no possible client interaction which will cause the server to encode the packets incorrectly. Alan DeKok.
James Leavitt wrote:
Radclient is a good suggestion, I will try it and see what happens, perhaps it will yield something interesting, perhaps a strange interaction that the client itself is causing.
I tried with eapol_test, TTLS / PAP, and radclient, on Linux and Mac. It works everywhere. I'd suggest running with valgrind. The extra bytes are usually "b7", which is itself suspicious. Alan DeKok.
participants (3)
-
Alan DeKok -
David Peterson -
James Leavitt