Re: Failure with "TLS authentication" and "Freeradius on Fefora-17"
I tried attaching the debug log-file, but the mail-message was rejected by the mailing list for exceeding 100KB How am I supposed to attach the complete logs? On Mon, Jan 7, 2013 at 11:35 AM, Ajay Garg <ajaygargnsit@gmail.com> wrote:
On Sun, Jan 6, 2013 at 8:00 PM, Alan DeKok <aland@deployingradius.com>wrote:
Ajay Garg wrote:
I just realised that I can put the issue in a simpler realm (not requiring any externally written client-code files ) ::
I am unable to get "TLS-authentication" working, when a "Fedora-17-client" tries to connect to a "WPA/WPA2-Enterprise network" through "gnome-shell-applet", via Freeradius-running-on-Fedora-17".
Look at the debug logs on the server. And on the client. Without that, your message is content-free.
Thanks Alan for the reply.
a) Alan, I am attaching the logs of "sudo /usr/sbin/radiusd -X". These logs show failure-decryption errors.
b) Also, I tried taking up the "/var/log/messages" for only the trying-to-connect duration (via "sudo rm /var/log/messages"; "sudo touch /var/log/messages"), but the file then showed empty :( Please let me know if this is indeed required; if yes, I will post this file too.
c) Also, I am attaching a snapshot of the settings entered for connecting to the network.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Regards, Ajay
-- Regards, Ajay
On 07/01/13 13:18, Ajay Garg wrote:
I tried attaching the debug log-file, but the mail-message was rejected by the mailing list for exceeding 100KB
How am I supposed to attach the complete logs?
You're supposed to *look* at them first; I'd give strong odds the answer you seek is in there. Is a debug log for 1 EAP session really >100kb these days? Maybe stick them on a pastebin somewhere.
Ajay Garg wrote:
I tried attaching the debug log-file, but the mail-message was rejected by the mailing list for exceeding 100KB
How am I supposed to attach the complete logs?
Shorten it. Much of the conf file output can be deleted. Or, READ IT. Odds are that the answers to your questions are in the debug output. Alan DeKok.
Ok, here are the logs that should identify the problem :: ############################################################################################# Listening on authentication address * port 1812 Listening on accounting address * port 1813 Listening on command file /var/run/radiusd/radiusd.sock Listening on authentication address 127.0.0.1 port 18120 as server inner-tunnel Listening on proxy address * port 1814 Ready to process requests. rad_recv: Access-Request packet from host 192.168.1.1 port 2050, id=2, length=135 User-Name = "anonymous" NAS-IP-Address = 192.168.1.1 NAS-Identifier = "NasId1" NAS-Port = 0 Called-Station-Id = "80-A1-D7-19-BC-CC" Calling-Station-Id = "8C-A9-82-0A-72-C2" Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x0201000e01616e6f6e796d6f7573 Message-Authenticator = 0x75ec2aaf6e4ff4d556074d228a772faa # 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 [suffix] No '@' in User-Name = "anonymous", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] EAP packet type response id 1 length 14 [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated ++[files] returns noop ++[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 2 to 192.168.1.1 port 2050 EAP-Message = 0x010200160410d85d9080f8377ffbd43fcd11902d0849 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xca27a4c8ca25a0d1b0def0b7ea3684b7 Finished request 0. Going to the next request Waking up in 4.9 seconds. Cleaning up request 0 ID 2 with timestamp +2 Ready to process requests. rad_recv: Access-Request packet from host 192.168.1.1 port 2050, id=1, length=135 User-Name = "anonymous" NAS-IP-Address = 192.168.1.1 NAS-Identifier = "NasId1" NAS-Port = 0 Called-Station-Id = "80-A1-D7-19-BC-CC" Calling-Station-Id = "8C-A9-82-0A-72-C2" Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x0201000e01616e6f6e796d6f7573 Message-Authenticator = 0x9bd9b052f78877d9825931a00861c9bb # 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 [suffix] No '@' in User-Name = "anonymous", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] EAP packet type response id 1 length 14 [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated ++[files] returns noop ++[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 1 to 192.168.1.1 port 2050 EAP-Message = 0x010200160410c80696960e9200663db1880b98547d70 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xc4e4c720c4e6c3e7c1639dca0ec5602b Finished request 1. Going to the next request Waking up in 4.9 seconds. Cleaning up request 1 ID 1 with timestamp +36 Ready to process requests. rad_recv: Access-Request packet from host 192.168.1.1 port 2050, id=3, length=135 User-Name = "anonymous" NAS-IP-Address = 192.168.1.1 NAS-Identifier = "NasId1" NAS-Port = 0 Called-Station-Id = "80-A1-D7-19-BC-CC" Calling-Station-Id = "8C-A9-82-0A-72-C2" Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x0201000e01616e6f6e796d6f7573 Message-Authenticator = 0xda721dc9da1bf772e873ef7dd3c3118e # 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 [suffix] No '@' in User-Name = "anonymous", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] EAP packet type response id 1 length 14 [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated ++[files] returns noop ++[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 3 to 192.168.1.1 port 2050 EAP-Message = 0x0102001604103d35620c02dfe385b8e85d29be12cbe6 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xae0bee3aae09ea25398daf498c4b8a60 Finished request 2. Going to the next request Waking up in 4.9 seconds. rad_recv: Access-Request packet from host 192.168.1.1 port 2050, id=4, length=145 User-Name = "anonymous" NAS-IP-Address = 192.168.1.1 NAS-Identifier = "NasId1" NAS-Port = 0 Called-Station-Id = "80-A1-D7-19-BC-CC" Calling-Station-Id = "8C-A9-82-0A-72-C2" Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x02020006030d State = 0xae0bee3aae09ea25398daf498c4b8a60 Message-Authenticator = 0x4a12c5fe1710ce5b4cd16e03e20a3dff # 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 [suffix] No '@' in User-Name = "anonymous", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] EAP packet type response id 2 length 6 [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated ++[files] returns noop ++[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/tls [eap] processing type tls [tls] Requiring client certificate [tls] Initiate [tls] Start returned 1 ++[eap] returns handled Sending Access-Challenge of id 4 to 192.168.1.1 port 2050 EAP-Message = 0x010300060d20 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xae0bee3aaf08e325398daf498c4b8a60 Finished request 3. Going to the next request Waking up in 4.9 seconds. rad_recv: Access-Request packet from host 192.168.1.1 port 2050, id=5, length=257 User-Name = "anonymous" NAS-IP-Address = 192.168.1.1 NAS-Identifier = "NasId1" NAS-Port = 0 Called-Station-Id = "80-A1-D7-19-BC-CC" Calling-Station-Id = "8C-A9-82-0A-72-C2" Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x020300760d00160301006b01000067030150ea6299ec45ad966ebbb9ea9b1bf4543ef4d67c15e63acdd86d348a01f3c5e400003a00390038008800870035008400160013000a00330032009a009900450044002f00960041000500040015001200090014001100080006000300ff0100000400230000 State = 0xae0bee3aaf08e325398daf498c4b8a60 Message-Authenticator = 0x9a29080d67d6c2d43cf9902dc5657a5a # 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 [suffix] No '@' in User-Name = "anonymous", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] EAP packet type response id 3 length 118 [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated ++[files] returns noop ++[expiration] returns noop ++[logintime] returns noop ++[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/tls [eap] processing type tls [tls] Authenticate [tls] processing EAP-TLS [tls] eaptls_verify returned 7 [tls] Done initial handshake [tls] (other): before/accept initialization [tls] TLS_accept: before/accept initialization [tls] <<< TLS 1.0 Handshake [length 006b], ClientHello [tls] TLS_accept: SSLv3 read client hello A [tls] >>> TLS 1.0 Handshake [length 0031], ServerHello [tls] TLS_accept: SSLv3 write server hello A [tls] >>> TLS 1.0 Handshake [length 085e], Certificate [tls] TLS_accept: SSLv3 write certificate A [tls] >>> TLS 1.0 Handshake [length 020d], ServerKeyExchange [tls] TLS_accept: SSLv3 write key exchange A [tls] >>> TLS 1.0 Handshake [length 00a7], CertificateRequest [tls] TLS_accept: SSLv3 write certificate request A [tls] TLS_accept: SSLv3 flush data [tls] TLS_accept: Need to read more data: SSLv3 read client certificate A In SSL Handshake Phase In SSL Accept mode [tls] eaptls_process returned 13 ++[eap] returns handled Sending Access-Challenge of id 5 to 192.168.1.1 port 2050 EAP-Message = 0x010404000dc000000b5716030100310200002d030150ea62998db3927a94e8e3958d4a0718aba9c8fe83861e325933d52ace7337eb000039000005ff01000100160301085e0b00085a0008570003a6308203a23082028aa003020102020101300d06092a864886f70d0101050500308193310b3009060355040613024652310f300d060355040813065261646975733112301006035504071309536f6d65776865726531153013060355040a130c4578616d706c6520496e632e3120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d312630240603550403131d4578616d706c65204365727469666963617465204175 EAP-Message = 0x74686f72697479301e170d3133303130323230343931335a170d3133303330333230343931335a307c310b3009060355040613024652310f300d0603550408130652616469757331153013060355040a130c4578616d706c6520496e632e312330210603550403131a4578616d706c65205365727665722043657274696669636174653120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d30820122300d06092a864886f70d01010105000382010f003082010a0282010100a964d88984f11cf2e098e9d5067ed817b2fb753629751159a8fd20593b91b2e13ed90ee1a40af0d5a20c954c361d534de87499ddfc01fb EAP-Message = 0xdd17e668da7580b889bb76cd99e5a15fe170528fd99c344736d96ef562984a8aaaf3d7fe88c62a5ee4ce361905a185b8c7f4e4f4707e7c33fbaf720bf67c46a9d1b340b82fc9e5f614bdc9b0b72d4fcf3994a37178db025b37cc4e96b27f5d5e1826e5368610faff2a5029d662206d25c0a9490a50293df2569910f46beb4f46f67087b917a3b45a0a5a5ccc7fba5f7c9b9eaf86a07f8b994e8116b5665126c91d25a54c2c48fae0b8e3fce245773f2a4a1aafb97edb4399aa76b31b29752f9794f08176d189399f210203010001a317301530130603551d25040c300a06082b06010505070301300d06092a864886f70d010105050003820101009619 EAP-Message = 0x95251b10a7381486cc6ced9dd00aacdc4338a5564cf99ea96e489e35a561cf242342ce6661d35d3d9d87173698e530ecb82484b1ea3b5dd1cd9a4a1b2daefe3e6c1042f85d50692a4e012ac026a25a9bd9cc21d530eba40f8ea6b328518ccfa33a5cfac384e95981f5675bc2c01c5ef9809de95cfbf9aabc0df194efe65160d4b2967857897c1468afcba2718db7c15004847f729e757b26f6ff4a0b2e48b0cbb9eabd3d405497c87d7fc6f0872c5390fd9a791aff329be726d67ae2198e01ea1c8b49719bf3e8245db56f4574bb82ed02ed8eb7cfb7a0ee44b4fb350856e50c641720eb9edeab47a7d5a65ab64505ae4c4bec18d8bacedd3883fd72b9 EAP-Message = 0x5d0004ab308204a73082038f Message-Authenticator = 0x00000000000000000000000000000000 State = 0xae0bee3aac0fe325398daf498c4b8a60 Finished request 4. Going to the next request Waking up in 4.9 seconds. rad_recv: Access-Request packet from host 192.168.1.1 port 2050, id=6, length=145 User-Name = "anonymous" NAS-IP-Address = 192.168.1.1 NAS-Identifier = "NasId1" NAS-Port = 0 Called-Station-Id = "80-A1-D7-19-BC-CC" Calling-Station-Id = "8C-A9-82-0A-72-C2" Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x020400060d00 State = 0xae0bee3aac0fe325398daf498c4b8a60 Message-Authenticator = 0x193913d4ff0d73cc840b624497a2f03d # 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 [suffix] No '@' in User-Name = "anonymous", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] EAP packet type response id 4 length 6 [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated ++[files] returns noop ++[expiration] returns noop ++[logintime] returns noop ++[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/tls [eap] processing type tls [tls] Authenticate [tls] processing EAP-TLS [tls] Received TLS ACK [tls] ACK handshake fragment handler [tls] eaptls_verify returned 1 [tls] eaptls_process returned 13 ++[eap] returns handled Sending Access-Challenge of id 6 to 192.168.1.1 port 2050 EAP-Message = 0x010504000dc000000b57a003020102020900893e0a05a634a356300d06092a864886f70d0101050500308193310b3009060355040613024652310f300d060355040813065261646975733112301006035504071309536f6d65776865726531153013060355040a130c4578616d706c6520496e632e3120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d312630240603550403131d4578616d706c6520436572746966696361746520417574686f72697479301e170d3133303130363133333635375a170d3133303330373133333635375a308193310b3009060355040613024652310f300d06035504081306526164 EAP-Message = 0x6975733112301006035504071309536f6d65776865726531153013060355040a130c4578616d706c6520496e632e3120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d312630240603550403131d4578616d706c6520436572746966696361746520417574686f7269747930820122300d06092a864886f70d01010105000382010f003082010a0282010100ebdd02fa2a5b2b43e5806d41656bda51cfa2bca2936fbe168be1781f14ca7d2c608976fcfc45fd63bb44a21fa1a4b4e2a9d00a3603b9504d21d9d9120723846c660602372539c687c2e24ee4cfe4f6b433f3c4c6d4397e1eb079dd08872cb3eef18e35a5 EAP-Message = 0x9a77761396f8666694336040a446e40374b306d1057aeb78b6a6296aee0f8930819b987adf8412bf6f4455b8c67f5c92bbae6bfbed30ecbd38fb7ee015a7d260e8ef80f47d8eba63dca2f2014fdc8fcd4db4d898e56388e3b4963c338ed11d9dfacae18e64573f17b72383d9ae9fa96d76fb9b47ee6e6ce7e2c5be485abada0feb5c4a9aa83297af2623cf931c3b88335fa3e781ab3dadfd3b62a2a10203010001a381fb3081f8301d0603551d0e04160414afc3a72620ddd02d5a37ee2fb8876c1793d4190d3081c80603551d230481c03081bd8014afc3a72620ddd02d5a37ee2fb8876c1793d4190da18199a48196308193310b3009060355040613 EAP-Message = 0x024652310f300d060355040813065261646975733112301006035504071309536f6d65776865726531153013060355040a130c4578616d706c6520496e632e3120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d312630240603550403131d4578616d706c6520436572746966696361746520417574686f72697479820900893e0a05a634a356300c0603551d13040530030101ff300d06092a864886f70d010105050003820101000bed6913d854c30ff8c5a9ae3f706e8cc97d5ee63ae8857b16297b38ab43b2562000e4f345dca706cf4c54156a134573a4b811751a43985545972e8807b60673979031538e7c5b EAP-Message = 0xc4643173fc8b9e067abaa332 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xae0bee3aad0ee325398daf498c4b8a60 Finished request 5. Going to the next request Waking up in 4.9 seconds. rad_recv: Access-Request packet from host 192.168.1.1 port 2050, id=7, length=145 User-Name = "anonymous" NAS-IP-Address = 192.168.1.1 NAS-Identifier = "NasId1" NAS-Port = 0 Called-Station-Id = "80-A1-D7-19-BC-CC" Calling-Station-Id = "8C-A9-82-0A-72-C2" Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x020500060d00 State = 0xae0bee3aad0ee325398daf498c4b8a60 Message-Authenticator = 0xe493fc1cbfbd7a59dbbf0ccc9f8390f2 # 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 [suffix] No '@' in User-Name = "anonymous", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] EAP packet type response id 5 length 6 [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated ++[files] returns noop ++[expiration] returns noop ++[logintime] returns noop ++[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/tls [eap] processing type tls [tls] Authenticate [tls] processing EAP-TLS [tls] Received TLS ACK [tls] ACK handshake fragment handler [tls] eaptls_verify returned 1 [tls] eaptls_process returned 13 ++[eap] returns handled Sending Access-Challenge of id 7 to 192.168.1.1 port 2050 EAP-Message = 0x010603750d8000000b57c5525516ee08169c65c0605ff1cd8cb8875d23e93b6eae5bf6190e00fa5d09244e6d6df1fd4b721fa3e32b197ee2a3c2093c79b83fd8c8390d01480fe5e0f7a933d0d91217a6b989b36c62dadd8f1580d2316cfde9b2db5c8cb8767c614cdd722810fcd7aa086eebb0de60a915eee1c3bf3399aabd4e727e08a333010b0f34fefe6cf58fee5df022c2b1372272987c4c86fd91937e61f881b45d238101eda2d6705291d4ba43ee237f1dfec55a160301020d0c0002090080f1516afb0dd4bfb40ee4121b45f29c3e6e01b2997948fa411b9459c47d5cc1c7c94f69338de1c704610c3ecc7bb948de7838e51cf5c4bd11d9dac2 EAP-Message = 0x657619ad86970871a77831bfe882d146839667309241f4d237e6996317113f458282372ac089f43c84e5f9cbbf5cf5af469ab7b0a7a3cc98363638dbcb57e41338d196f17b0001020080bd8697560cbf77c14813e123c7b7c9ce79f5645fda561240ea65bddb36cf520baa2b174879be8a091bda39af0bb7659d832944672aaffdf76002a21a9ada45e22323803f2a76002f302a8c69ae11a3d78c3d9f5c485a2ca8bf94e8232892a78b0e023df8325cbbf8d0b5b24576ab1e194ecd8a33eb5105e0cd0c9d81909d756a010009d4606d20f3134e39eb37d5947e4b32b7e5bc842cd052623c8a0e69d5cdfd1ff13b405e08a5672fa3e9780078b182967d EAP-Message = 0x4ae6ca5c02cb2d3f67b49f7cc5b015eb6cd69466e6dbd761792e04f8eb009ffea8c9d833fcc9a790874fe694dce4ef32104f42417a8574f0e4e13580d49ec0664b9325a707ae7ccef2ff8e652b0a4d428a2dc81b1878a9a0b1656cd60d7210a533bfdb6c6c324f0edcdfd73e46fd273275f0450558a36bdc79f6ed879c5d237f3efb8e33d023dae952d2a63acb45fc8415ab961b212a0b03e3de16ba0a13fa2f8082d4a4614d83978a5ada9528ec0e7d638586339a7f1f51c7baefb53a2f8187c67bc40344bfd53dd35ffcf2c13bee16030100a70d00009f040304010200980096308193310b3009060355040613024652310f300d0603550408130652 EAP-Message = 0x61646975733112301006035504071309536f6d65776865726531153013060355040a130c4578616d706c6520496e632e3120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d312630240603550403131d4578616d706c6520436572746966696361746520417574686f726974790e000000 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xae0bee3aaa0de325398daf498c4b8a60 Finished request 6. Going to the next request Waking up in 4.9 seconds. rad_recv: Access-Request packet from host 192.168.1.1 port 2050, id=8, length=152 User-Name = "anonymous" NAS-IP-Address = 192.168.1.1 NAS-Identifier = "NasId1" NAS-Port = 0 Called-Station-Id = "80-A1-D7-19-BC-CC" Calling-Station-Id = "8C-A9-82-0A-72-C2" Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x0206000d0d0015030100020233 State = 0xae0bee3aaa0de325398daf498c4b8a60 Message-Authenticator = 0x1bca69d903deee46c3b0e357c59ec8f9 # 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 [suffix] No '@' in User-Name = "anonymous", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] EAP packet type response id 6 length 13 [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated ++[files] returns noop ++[expiration] returns noop ++[logintime] returns noop ++[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/tls [eap] processing type tls [tls] Authenticate [tls] processing EAP-TLS [tls] eaptls_verify returned 7 [tls] Done initial handshake [tls] <<< TLS 1.0 Alert [length 0002], fatal decrypt_error TLS Alert read:fatal:decrypt error TLS_accept: failed in SSLv3 read client certificate A rlm_eap: SSL error error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1 alert decrypt error SSL: SSL_read failed inside of TLS (-1), TLS session fails. TLS receive handshake failed during operation [tls] eaptls_process returned 4 [eap] Handler failed in EAP/tls [eap] Failed in EAP select ++[eap] returns invalid Failed to authenticate the user. Using Post-Auth-Type REJECT # Executing group from file /etc/raddb/sites-enabled/default +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> anonymous attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Delaying reject of request 7 for 1 seconds Going to the next request Waking up in 0.9 seconds. Sending delayed reject for request 7 Sending Access-Reject of id 8 to 192.168.1.1 port 2050 EAP-Message = 0x04060004 Message-Authenticator = 0x00000000000000000000000000000000 Waking up in 3.9 seconds. rad_recv: Access-Request packet from host 192.168.1.1 port 2050, id=9, length=135 User-Name = "anonymous" NAS-IP-Address = 192.168.1.1 NAS-Identifier = "NasId1" NAS-Port = 0 Called-Station-Id = "80-A1-D7-19-BC-CC" Calling-Station-Id = "8C-A9-82-0A-72-C2" Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x0201000e01616e6f6e796d6f7573 Message-Authenticator = 0xecd41729c398e8d7cb3aeffa77620477 # 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 [suffix] No '@' in User-Name = "anonymous", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] EAP packet type response id 1 length 14 [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated ++[files] returns noop ++[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 9 to 192.168.1.1 port 2050 EAP-Message = 0x010200160410ab1098f6acd219d7dc4d99ea0eb9e76e Message-Authenticator = 0x00000000000000000000000000000000 State = 0xabe3eedaabe1ea79298f3c2e2b2155c8 Finished request 8. Going to the next request Waking up in 0.4 seconds. rad_recv: Access-Request packet from host 192.168.1.1 port 2050, id=10, length=145 User-Name = "anonymous" NAS-IP-Address = 192.168.1.1 NAS-Identifier = "NasId1" NAS-Port = 0 Called-Station-Id = "80-A1-D7-19-BC-CC" Calling-Station-Id = "8C-A9-82-0A-72-C2" Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x02020006030d State = 0xabe3eedaabe1ea79298f3c2e2b2155c8 Message-Authenticator = 0xfcbbdc4bf7bde2c3d05ad53e4245fc28 # 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 [suffix] No '@' in User-Name = "anonymous", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] EAP packet type response id 2 length 6 [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated ++[files] returns noop ++[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/tls [eap] processing type tls [tls] Requiring client certificate [tls] Initiate [tls] Start returned 1 ++[eap] returns handled Sending Access-Challenge of id 10 to 192.168.1.1 port 2050 EAP-Message = 0x010300060d20 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xabe3eedaaae0e379298f3c2e2b2155c8 Finished request 9. Going to the next request Waking up in 0.4 seconds. rad_recv: Access-Request packet from host 192.168.1.1 port 2050, id=11, length=257 User-Name = "anonymous" NAS-IP-Address = 192.168.1.1 NAS-Identifier = "NasId1" NAS-Port = 0 Called-Station-Id = "80-A1-D7-19-BC-CC" Calling-Station-Id = "8C-A9-82-0A-72-C2" Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x020300760d00160301006b01000067030150ea629e121e3f40f9cea283dd9bf6358c1c3b7c81b59d598c2d5963f2d8304e00003a00390038008800870035008400160013000a00330032009a009900450044002f00960041000500040015001200090014001100080006000300ff0100000400230000 State = 0xabe3eedaaae0e379298f3c2e2b2155c8 Message-Authenticator = 0x30e1a5af5af01fd1733a414414155c8e # 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 [suffix] No '@' in User-Name = "anonymous", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] EAP packet type response id 3 length 118 [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated ++[files] returns noop ++[expiration] returns noop ++[logintime] returns noop ++[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/tls [eap] processing type tls [tls] Authenticate [tls] processing EAP-TLS [tls] eaptls_verify returned 7 [tls] Done initial handshake [tls] (other): before/accept initialization [tls] TLS_accept: before/accept initialization [tls] <<< TLS 1.0 Handshake [length 006b], ClientHello [tls] TLS_accept: SSLv3 read client hello A [tls] >>> TLS 1.0 Handshake [length 0031], ServerHello [tls] TLS_accept: SSLv3 write server hello A [tls] >>> TLS 1.0 Handshake [length 085e], Certificate [tls] TLS_accept: SSLv3 write certificate A [tls] >>> TLS 1.0 Handshake [length 020d], ServerKeyExchange [tls] TLS_accept: SSLv3 write key exchange A [tls] >>> TLS 1.0 Handshake [length 00a7], CertificateRequest [tls] TLS_accept: SSLv3 write certificate request A [tls] TLS_accept: SSLv3 flush data [tls] TLS_accept: Need to read more data: SSLv3 read client certificate A In SSL Handshake Phase In SSL Accept mode [tls] eaptls_process returned 13 ++[eap] returns handled Sending Access-Challenge of id 11 to 192.168.1.1 port 2050 EAP-Message = 0x010404000dc000000b5716030100310200002d030150ea629edade68b29196650a02e89a0bbc7a678f82b96a462b76efd75699c84d000039000005ff01000100160301085e0b00085a0008570003a6308203a23082028aa003020102020101300d06092a864886f70d0101050500308193310b3009060355040613024652310f300d060355040813065261646975733112301006035504071309536f6d65776865726531153013060355040a130c4578616d706c6520496e632e3120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d312630240603550403131d4578616d706c65204365727469666963617465204175 EAP-Message = 0x74686f72697479301e170d3133303130323230343931335a170d3133303330333230343931335a307c310b3009060355040613024652310f300d0603550408130652616469757331153013060355040a130c4578616d706c6520496e632e312330210603550403131a4578616d706c65205365727665722043657274696669636174653120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d30820122300d06092a864886f70d01010105000382010f003082010a0282010100a964d88984f11cf2e098e9d5067ed817b2fb753629751159a8fd20593b91b2e13ed90ee1a40af0d5a20c954c361d534de87499ddfc01fb EAP-Message = 0xdd17e668da7580b889bb76cd99e5a15fe170528fd99c344736d96ef562984a8aaaf3d7fe88c62a5ee4ce361905a185b8c7f4e4f4707e7c33fbaf720bf67c46a9d1b340b82fc9e5f614bdc9b0b72d4fcf3994a37178db025b37cc4e96b27f5d5e1826e5368610faff2a5029d662206d25c0a9490a50293df2569910f46beb4f46f67087b917a3b45a0a5a5ccc7fba5f7c9b9eaf86a07f8b994e8116b5665126c91d25a54c2c48fae0b8e3fce245773f2a4a1aafb97edb4399aa76b31b29752f9794f08176d189399f210203010001a317301530130603551d25040c300a06082b06010505070301300d06092a864886f70d010105050003820101009619 EAP-Message = 0x95251b10a7381486cc6ced9dd00aacdc4338a5564cf99ea96e489e35a561cf242342ce6661d35d3d9d87173698e530ecb82484b1ea3b5dd1cd9a4a1b2daefe3e6c1042f85d50692a4e012ac026a25a9bd9cc21d530eba40f8ea6b328518ccfa33a5cfac384e95981f5675bc2c01c5ef9809de95cfbf9aabc0df194efe65160d4b2967857897c1468afcba2718db7c15004847f729e757b26f6ff4a0b2e48b0cbb9eabd3d405497c87d7fc6f0872c5390fd9a791aff329be726d67ae2198e01ea1c8b49719bf3e8245db56f4574bb82ed02ed8eb7cfb7a0ee44b4fb350856e50c641720eb9edeab47a7d5a65ab64505ae4c4bec18d8bacedd3883fd72b9 EAP-Message = 0x5d0004ab308204a73082038f Message-Authenticator = 0x00000000000000000000000000000000 State = 0xabe3eedaa9e7e379298f3c2e2b2155c8 Finished request 10. Going to the next request Waking up in 0.4 seconds. rad_recv: Access-Request packet from host 192.168.1.1 port 2050, id=12, length=145 User-Name = "anonymous" NAS-IP-Address = 192.168.1.1 NAS-Identifier = "NasId1" NAS-Port = 0 Called-Station-Id = "80-A1-D7-19-BC-CC" Calling-Station-Id = "8C-A9-82-0A-72-C2" Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x020400060d00 State = 0xabe3eedaa9e7e379298f3c2e2b2155c8 Message-Authenticator = 0x149a9c87d709b9bf0e0365f5ac248e7f # 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 [suffix] No '@' in User-Name = "anonymous", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] EAP packet type response id 4 length 6 [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated ++[files] returns noop ++[expiration] returns noop ++[logintime] returns noop ++[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/tls [eap] processing type tls [tls] Authenticate [tls] processing EAP-TLS [tls] Received TLS ACK [tls] ACK handshake fragment handler [tls] eaptls_verify returned 1 [tls] eaptls_process returned 13 ++[eap] returns handled Sending Access-Challenge of id 12 to 192.168.1.1 port 2050 EAP-Message = 0x010504000dc000000b57a003020102020900893e0a05a634a356300d06092a864886f70d0101050500308193310b3009060355040613024652310f300d060355040813065261646975733112301006035504071309536f6d65776865726531153013060355040a130c4578616d706c6520496e632e3120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d312630240603550403131d4578616d706c6520436572746966696361746520417574686f72697479301e170d3133303130363133333635375a170d3133303330373133333635375a308193310b3009060355040613024652310f300d06035504081306526164 EAP-Message = 0x6975733112301006035504071309536f6d65776865726531153013060355040a130c4578616d706c6520496e632e3120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d312630240603550403131d4578616d706c6520436572746966696361746520417574686f7269747930820122300d06092a864886f70d01010105000382010f003082010a0282010100ebdd02fa2a5b2b43e5806d41656bda51cfa2bca2936fbe168be1781f14ca7d2c608976fcfc45fd63bb44a21fa1a4b4e2a9d00a3603b9504d21d9d9120723846c660602372539c687c2e24ee4cfe4f6b433f3c4c6d4397e1eb079dd08872cb3eef18e35a5 EAP-Message = 0x9a77761396f8666694336040a446e40374b306d1057aeb78b6a6296aee0f8930819b987adf8412bf6f4455b8c67f5c92bbae6bfbed30ecbd38fb7ee015a7d260e8ef80f47d8eba63dca2f2014fdc8fcd4db4d898e56388e3b4963c338ed11d9dfacae18e64573f17b72383d9ae9fa96d76fb9b47ee6e6ce7e2c5be485abada0feb5c4a9aa83297af2623cf931c3b88335fa3e781ab3dadfd3b62a2a10203010001a381fb3081f8301d0603551d0e04160414afc3a72620ddd02d5a37ee2fb8876c1793d4190d3081c80603551d230481c03081bd8014afc3a72620ddd02d5a37ee2fb8876c1793d4190da18199a48196308193310b3009060355040613 EAP-Message = 0x024652310f300d060355040813065261646975733112301006035504071309536f6d65776865726531153013060355040a130c4578616d706c6520496e632e3120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d312630240603550403131d4578616d706c6520436572746966696361746520417574686f72697479820900893e0a05a634a356300c0603551d13040530030101ff300d06092a864886f70d010105050003820101000bed6913d854c30ff8c5a9ae3f706e8cc97d5ee63ae8857b16297b38ab43b2562000e4f345dca706cf4c54156a134573a4b811751a43985545972e8807b60673979031538e7c5b EAP-Message = 0xc4643173fc8b9e067abaa332 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xabe3eedaa8e6e379298f3c2e2b2155c8 Finished request 11. Going to the next request Waking up in 0.3 seconds. rad_recv: Access-Request packet from host 192.168.1.1 port 2050, id=13, length=145 User-Name = "anonymous" NAS-IP-Address = 192.168.1.1 NAS-Identifier = "NasId1" NAS-Port = 0 Called-Station-Id = "80-A1-D7-19-BC-CC" Calling-Station-Id = "8C-A9-82-0A-72-C2" Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x020500060d00 State = 0xabe3eedaa8e6e379298f3c2e2b2155c8 Message-Authenticator = 0x9e8a73edbb4a3672f9accd02064288f1 # 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 [suffix] No '@' in User-Name = "anonymous", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] EAP packet type response id 5 length 6 [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated ++[files] returns noop ++[expiration] returns noop ++[logintime] returns noop ++[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/tls [eap] processing type tls [tls] Authenticate [tls] processing EAP-TLS [tls] Received TLS ACK [tls] ACK handshake fragment handler [tls] eaptls_verify returned 1 [tls] eaptls_process returned 13 ++[eap] returns handled Sending Access-Challenge of id 13 to 192.168.1.1 port 2050 EAP-Message = 0x010603750d8000000b57c5525516ee08169c65c0605ff1cd8cb8875d23e93b6eae5bf6190e00fa5d09244e6d6df1fd4b721fa3e32b197ee2a3c2093c79b83fd8c8390d01480fe5e0f7a933d0d91217a6b989b36c62dadd8f1580d2316cfde9b2db5c8cb8767c614cdd722810fcd7aa086eebb0de60a915eee1c3bf3399aabd4e727e08a333010b0f34fefe6cf58fee5df022c2b1372272987c4c86fd91937e61f881b45d238101eda2d6705291d4ba43ee237f1dfec55a160301020d0c0002090080f1516afb0dd4bfb40ee4121b45f29c3e6e01b2997948fa411b9459c47d5cc1c7c94f69338de1c704610c3ecc7bb948de7838e51cf5c4bd11d9dac2 EAP-Message = 0x657619ad86970871a77831bfe882d146839667309241f4d237e6996317113f458282372ac089f43c84e5f9cbbf5cf5af469ab7b0a7a3cc98363638dbcb57e41338d196f17b00010200802bd94c4be6d7bd6f520fe91b8cac697adaa8dc3240308d9f0b3f04f749c302cd5ec39ca8a931db592bf7d778e99e0291b46eb3cebb18db892b4c666f462cfa60b7fe2313902f570d413f3785ab8d9f5fd96ae5cec61d56254d16c5ecac43c81351dc8c3ff4780369d517f47258db7888ad6e7040bdf898e29c040a3cfcd4e394010013c6ca68e4913b46fc45bc2d0b38ab82f836a74e8de968a48a821dc9e93f2675d39fc47d3435ef78cf9ae12b1eef02426a EAP-Message = 0xa9e4932f46cd64a13d8e939a2e5814c9eb0c2336486ec1e414821fd7c6a1339f417c33ab2bd0fbd6ff4cecf8f97f6fe5c55c3c37af2d240c71988a9a4eedd099f278bd3d696f31581352ca435d450ed5e4a758d9cd74d3f9664d713636e3c23ba7ab21816ac344e5e5bb88e6eafa4fe3719ce5c7eab5f2fdd5a7815725a7e46982177439fca1b3c7dacd5a0a6b1212a72d45ed28b492eaeb19d4fc4656a032577c35e4d2774564a90fc45bff8329778bd3eff4592061287bebf209bc278adf498b695f4bfc0ee251e500be5b62f81a16030100a70d00009f040304010200980096308193310b3009060355040613024652310f300d0603550408130652 EAP-Message = 0x61646975733112301006035504071309536f6d65776865726531153013060355040a130c4578616d706c6520496e632e3120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d312630240603550403131d4578616d706c6520436572746966696361746520417574686f726974790e000000 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xabe3eedaafe5e379298f3c2e2b2155c8 Finished request 12. Going to the next request Waking up in 0.3 seconds. rad_recv: Access-Request packet from host 192.168.1.1 port 2050, id=14, length=152 User-Name = "anonymous" NAS-IP-Address = 192.168.1.1 NAS-Identifier = "NasId1" NAS-Port = 0 Called-Station-Id = "80-A1-D7-19-BC-CC" Calling-Station-Id = "8C-A9-82-0A-72-C2" Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x0206000d0d0015030100020233 State = 0xabe3eedaafe5e379298f3c2e2b2155c8 Message-Authenticator = 0xedb4fd5e95ead9066cd40b0e9436166f # 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 [suffix] No '@' in User-Name = "anonymous", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] EAP packet type response id 6 length 13 [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated ++[files] returns noop ++[expiration] returns noop ++[logintime] returns noop ++[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/tls [eap] processing type tls [tls] Authenticate [tls] processing EAP-TLS [tls] eaptls_verify returned 7 [tls] Done initial handshake [tls] <<< TLS 1.0 Alert [length 0002], fatal decrypt_error TLS Alert read:fatal:decrypt error TLS_accept: failed in SSLv3 read client certificate A rlm_eap: SSL error error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1 alert decrypt error SSL: SSL_read failed inside of TLS (-1), TLS session fails. TLS receive handshake failed during operation [tls] eaptls_process returned 4 [eap] Handler failed in EAP/tls [eap] Failed in EAP select ++[eap] returns invalid Failed to authenticate the user. Using Post-Auth-Type REJECT # Executing group from file /etc/raddb/sites-enabled/default +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> anonymous attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Delaying reject of request 13 for 1 seconds Going to the next request Waking up in 0.3 seconds. Cleaning up request 2 ID 3 with timestamp +53 Cleaning up request 3 ID 4 with timestamp +53 Cleaning up request 4 ID 5 with timestamp +53 Cleaning up request 5 ID 6 with timestamp +53 Cleaning up request 6 ID 7 with timestamp +53 Waking up in 0.5 seconds. Sending delayed reject for request 13 Sending Access-Reject of id 14 to 192.168.1.1 port 2050 EAP-Message = 0x04060004 Message-Authenticator = 0x00000000000000000000000000000000 Waking up in 0.4 seconds. ############################################################################################# On Mon, Jan 7, 2013 at 7:30 PM, Alan DeKok <aland@deployingradius.com>wrote:
Ajay Garg wrote:
I tried attaching the debug log-file, but the mail-message was rejected by the mailing list for exceeding 100KB
How am I supposed to attach the complete logs?
Shorten it. Much of the conf file output can be deleted.
Or, READ IT. Odds are that the answers to your questions are in the debug output.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Regards, Ajay
Ajay Garg wrote:
here are the logs that should identify the problem :: ... [tls] <<< TLS 1.0 Alert [length 0002], fatal decrypt_error TLS Alert read:fatal:decrypt error TLS_accept: failed in SSLv3 read client certificate A rlm_eap: SSL error error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1 alert decrypt error SSL: SSL_read failed inside of TLS (-1), TLS session fails.
The client is refusing to continue the SSL session. And sends a message to the server saying so. So... either the client is misconfigured, or is buggy. Ensure that you have the correct configuration on the client. Alan DeKok.
Hi, the client sent a cert that your server didnt like. correct cert configured on the client? alan
Thanks Alan, and A.L.M. I too thought the same looking at the "decrypt failure messages". As I told in my startup-mail on this thread, the procedure :: su - cd /etc/raddb/certs make clean make client.pem makes TLS-authentication works perfectly fine for Fedora-14-freeradius, but not for Fedora-17-freeradius (and I am talking of the vanilla "gnome-way" of connecting, as is evident from the snapshot). Do certs need to be generated differently in Fedora-17 freeradius? On Mon, Jan 7, 2013 at 9:16 PM, <A.L.M.Buxey@lboro.ac.uk> wrote:
Hi,
the client sent a cert that your server didnt like. correct cert configured on the client?
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Regards, Ajay
On 01/07/2013 12:18 PM, Ajay Garg wrote:
Thanks Alan, and A.L.M.
I too thought the same looking at the "decrypt failure messages".
As I told in my startup-mail on this thread, the procedure ::
su - cd /etc/raddb/certs make clean make client.pem
makes TLS-authentication works perfectly fine for Fedora-14-freeradius, but not for Fedora-17-freeradius (and I am talking of the vanilla "gnome-way" of connecting, as is evident from the snapshot).
First of all there is no such version as Fedora-XX-freeradius, there is however the version of freeradius which happens to be installed. At different points in time Fedora releases will have had different versions of freeradius available. You can find out which version you have installed via either rpm -q freeradius or yum innfo freeradius It's a little hard to tell from you're series of steps but I suspect you're not using a client cert signed by the CA you've configured. Or the issuing signer (the CA) cert has expired. We deliberately set the validity period to a very short value (60 days) on the *temporary* certs which get created during the freeradius server install to force you to pay attention to the fact these are temporary certs created during install to play around with and are not appropriate for deployment (at least not without editing the configuration files to set the values to your organization). Thus I would check the following: 1) Is the CA cert still valid? 2) Is the CA cert used to sign the client cert the same one in the CA cert bundle the server is using. You could go back to square one if the above does not help you. 1) Clean all the certs in /etc/raddb/certs by cd'ing to that directory and running "make destroycerts" 2) Then run "make client", that should recreate the *both* the CA cert and the server cert first, then it will create the client cert signed by the new CA. 3) restart the server and and redeploy the client cert.
Do certs need to be generated differently in Fedora-17 freeradius?
-- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
Thanks John I am indeed looking for a ground-zero-solution :) On Tue, Jan 8, 2013 at 12:14 AM, John Dennis <jdennis@redhat.com> wrote:
On 01/07/2013 12:18 PM, Ajay Garg wrote:
Thanks Alan, and A.L.M.
I too thought the same looking at the "decrypt failure messages".
As I told in my startup-mail on this thread, the procedure ::
su - cd /etc/raddb/certs make clean make client.pem
makes TLS-authentication works perfectly fine for Fedora-14-freeradius, but not for Fedora-17-freeradius (and I am talking of the vanilla "gnome-way" of connecting, as is evident from the snapshot).
First of all there is no such version as Fedora-XX-freeradius, there is however the version of freeradius which happens to be installed. At different points in time Fedora releases will have had different versions of freeradius available. You can find out which version you have installed via either
rpm -q freeradius
or
yum innfo freeradius
It's a little hard to tell from you're series of steps but I suspect you're not using a client cert signed by the CA you've configured.
Or the issuing signer (the CA) cert has expired. We deliberately set the validity period to a very short value (60 days) on the *temporary* certs which get created during the freeradius server install to force you to pay attention to the fact these are temporary certs created during install to play around with and are not appropriate for deployment (at least not without editing the configuration files to set the values to your organization).
Thus I would check the following:
1) Is the CA cert still valid?
2) Is the CA cert used to sign the client cert the same one in the CA cert bundle the server is using.
You could go back to square one if the above does not help you.
1) Clean all the certs in /etc/raddb/certs by cd'ing to that directory and running "make destroycerts"
Done.
2) Then run "make client", that should recreate the *both* the CA cert and the server cert first, then it will create the client cert signed by the new CA.
Done.
3) restart the server and and redeploy the client cert.
Upon restarting, it shows a "missing server.pem" error. I reckon that we need to run "make server" too at some point of time (so that "server.pem" gets generated after "make destroycerts"). HOWEVER, I am now confused which "ca.pem" to consider, the one generated via "make server", or the one generated via "make client"?
Do certs need to be generated differently in Fedora-17 freeradius?
-- John Dennis <jdennis@redhat.com>
Looking to carve out IT costs? www.redhat.com/carveoutcosts/
-- Regards, Ajay
On 01/07/2013 02:41 PM, Ajay Garg wrote:
Upon restarting, it shows a "missing server.pem" error. I reckon that we need to run "make server" too at some point of time (so that "server.pem" gets generated after "make destroycerts").
make destroycerts should have removed all the pem files and keys. After running make again it will generate all new files. client has a dependency on ca and server files so it should have created a new ca, new server key and cert, a new client cert. Did it? Just to be clear, your client needs to trust the CA that signed your server cert and the server needs to trust the CA that signed your client cert. Typically those are located on two different machines. Make sure those line up or you're doomed. It's not clear to me which machines you're running these commands on and where you're copying the resulting files, but that's critical to get right. You can use the same CA to sign both the server cert and the client cert, but that's not a requirement, it just helps simplify the deployment a tad bit.
HOWEVER, I am now confused which "ca.pem" to consider, the one generated via "make server", or the one generated via "make client"?
Argh... you really need to be much more clear with what you're doing. If you're running the cert creation commands on different machines and leaving the results on that machine this will never work. Make sure you understand the RELATIONSHIP BETWEEN A CERTIFICATE AND IT'S SIGNER (issuing CA) and how that translates to the configuration parameters for each software component (see above). -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
John, I am confused. I will be grateful if you could specify the sequence of commands to be run after "make destroycerts". Note that :: a) Running JUST "make client" generates "client.pem" and "ca.pem", but no "server.pem". b) Running JUST "make" generates "server.pem" and "ca.pem", but no "client.pem". On Tue, Jan 8, 2013 at 1:44 AM, John Dennis <jdennis@redhat.com> wrote:
On 01/07/2013 02:41 PM, Ajay Garg wrote:
Upon restarting, it shows a "missing server.pem" error. I reckon that we need to run "make server" too at some point of time (so that "server.pem" gets generated after "make destroycerts").
make destroycerts should have removed all the pem files and keys. After running make again it will generate all new files. client has a dependency on ca and server files so it should have created a new ca, new server key and cert, a new client cert. Did it?
Just to be clear, your client needs to trust the CA that signed your server cert and the server needs to trust the CA that signed your client cert. Typically those are located on two different machines. Make sure those line up or you're doomed. It's not clear to me which machines you're running these commands on and where you're copying the resulting files, but that's critical to get right. You can use the same CA to sign both the server cert and the client cert, but that's not a requirement, it just helps simplify the deployment a tad bit.
HOWEVER, I am now confused which "ca.pem" to consider, the one generated
via "make server", or the one generated via "make client"?
Argh... you really need to be much more clear with what you're doing. If you're running the cert creation commands on different machines and leaving the results on that machine this will never work.
Make sure you understand the RELATIONSHIP BETWEEN A CERTIFICATE AND IT'S SIGNER (issuing CA) and how that translates to the configuration parameters for each software component (see above).
-- John Dennis <jdennis@redhat.com>
Looking to carve out IT costs? www.redhat.com/carveoutcosts/
-- Regards, Ajay
On 01/07/2013 03:32 PM, Ajay Garg wrote:
John, I am confused.
I will be grateful if you could specify the sequence of commands to be run after "make destroycerts".
Note that ::
a) Running JUST "make client" generates "client.pem" and "ca.pem", but no "server.pem".
b) Running JUST "make" generates "server.pem" and "ca.pem", but no "client.pem".
My apologies, I thought there was a dependency on server.pem. % make destroycerts % make % make client should do the trick -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
Thanks John. I am still getting the exact same error (as pasted in 3-4 mails earlier). I am doubting that this has got to do something with two "ca.pem" being generated in the calls to "make" and "make client". My freeradius version is freeradius-2.2.0-0.fc17.i686 Does TLS work at your end? On Tue, Jan 8, 2013 at 2:20 AM, John Dennis <jdennis@redhat.com> wrote:
On 01/07/2013 03:32 PM, Ajay Garg wrote:
John, I am confused.
I will be grateful if you could specify the sequence of commands to be run after "make destroycerts".
Note that ::
a) Running JUST "make client" generates "client.pem" and "ca.pem", but no "server.pem".
b) Running JUST "make" generates "server.pem" and "ca.pem", but no "client.pem".
My apologies, I thought there was a dependency on server.pem.
% make destroycerts % make % make client
should do the trick
-- John Dennis <jdennis@redhat.com>
Looking to carve out IT costs? www.redhat.com/carveoutcosts/
-- Regards, Ajay
Thanks A.L.M. On Tue, Jan 8, 2013 at 3:26 PM, <A.L.M.Buxey@lboro.ac.uk> wrote:
Hi,
Does TLS work at your end?
yes. using it quite fine. using the scripts supplied by the FreeRADIUS package with some local changes due to our security requirements and naming schemas etc.
Could you please specify the order of scripts to be run, so that proper certificates may be generated - both for the server, and the client? :P
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Regards, Ajay
On 01/08/2013 05:10 AM, Ajay Garg wrote:
Could you please specify the order of scripts to be run, so that proper certificates may be generated - both for the server, and the client? :P
You were given the answer. It's not just a matter of running the scripts it also requires knowing what the scripts output and how to configure *both* the client and the server with the script output. You've never explained what you're doing in any detail, especially with regard to where you're generating the client cert. In a previous email I explained what the server needs and what the client needs. Now you're going to have to put that information to use. You really do have to invest the energy into learning how the pieces fit together. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
On Tue, Jan 8, 2013 at 6:45 PM, John Dennis <jdennis@redhat.com> wrote:
On 01/08/2013 05:10 AM, Ajay Garg wrote:
Could you please specify the order of scripts to be run, so that proper certificates may be generated - both for the server, and the client? :P
You were given the answer. It's not just a matter of running the scripts it also requires knowing what the scripts output and how to configure *both* the client and the server with the script output.
You've never explained what you're doing in any detail, especially with regard to where you're generating the client cert. In a previous email I explained what the server needs and what the client needs. Now you're going to have to put that information to use. You really do have to invest the energy into learning how the pieces fit together.
Ok.. so here goes what I have been wanting to accomplish :P ROUTER-SIDE :: =========== a) Configure the router to do WPA/WPA2-Enterprise authentication. b) The authentication is to be done via a freeradius-server. c) I connect a wired-cable between the router and the freeradius-server-machine, to have a physical medium via which the router and the server may talk. SERVER-SIDE :: =========== a) Freeradius-server is running on Fedora-17 (freeradius-2.2.0-0.fc17.i686) b) After installing freeradius, the certificates are generated via (on Fedora-17 machine) :: su - rm /etc/raddb/modules/dhcp_sqlippool cd /etc/raddb/certs make destroycerts make make client chmod 0644 client.p12 chmod 0644 ca.pem c) Now, the freeradius is started on the Fedora-17 machine as :: sudo /usr/sbin/radiusd -X & Server runs fine. CLIENT-SIDE :: =========== a) THE SAME FEDORA-17 MACHINE ACTS AS THE CLIENT TOO :) b) Now, from the gnome-panel applet, I try connecting to the WPA/WPA-2 Enterprise network, by setting the following settings :: Wireless Security : WPA/WPA2-Enterprise Authentication : TLS Identity : Anonymous User Certificate : /etc/raddb/certs/client.p12 CA Certificate : /etc/raddb/certs/ca.pem Private Key : /etc/raddb/certs/client.p12 Private Key Password : whatever c) I click the "Connect" button..... and then the dreaded logs happen :(
-- John Dennis <jdennis@redhat.com>
Looking to carve out IT costs? www.redhat.com/carveoutcosts/
-- Regards, Ajay
On 01/08/2013 03:53 PM, Ajay Garg wrote:
On Tue, Jan 8, 2013 at 6:45 PM, John Dennis <jdennis@redhat.com <mailto:jdennis@redhat.com>> wrote:
On 01/08/2013 05:10 AM, Ajay Garg wrote:
Could you please specify the order of scripts to be run, so that proper certificates may be generated - both for the server, and the client? :P
You were given the answer. It's not just a matter of running the scripts it also requires knowing what the scripts output and how to configure *both* the client and the server with the script output.
You've never explained what you're doing in any detail, especially with regard to where you're generating the client cert. In a previous email I explained what the server needs and what the client needs. Now you're going to have to put that information to use. You really do have to invest the energy into learning how the pieces fit together.
Ok.. so here goes what I have been wanting to accomplish :P
ROUTER-SIDE :: ===========
a) Configure the router to do WPA/WPA2-Enterprise authentication.
b) The authentication is to be done via a freeradius-server.
c) I connect a wired-cable between the router and the freeradius-server-machine, to have a physical medium via which the router and the server may talk.
SERVER-SIDE :: ===========
a) Freeradius-server is running on Fedora-17 (freeradius-2.2.0-0.fc17.i686)
b) After installing freeradius, the certificates are generated via (on Fedora-17 machine) ::
su - rm /etc/raddb/modules/dhcp_sqlippool cd /etc/raddb/certs make destroycerts make make client chmod 0644 client.p12 chmod 0644 ca.pem
c) Now, the freeradius is started on the Fedora-17 machine as ::
sudo /usr/sbin/radiusd -X &
Server runs fine.
CLIENT-SIDE :: ===========
a) THE SAME FEDORA-17 MACHINE ACTS AS THE CLIENT TOO :)
b) Now, from the gnome-panel applet, I try connecting to the WPA/WPA-2 Enterprise network, by setting the following settings ::
Wireless Security : WPA/WPA2-Enterprise Authentication : TLS Identity : Anonymous User Certificate : /etc/raddb/certs/client.p12 CA Certificate : /etc/raddb/certs/ca.pem Private Key : /etc/raddb/certs/client.p12 Private Key Password : whatever
c) I click the "Connect" button.....
and then the dreaded logs happen :(
Thank you, that is a much clearer explanation. The first thing I notice is you're pointing the client to files in a directory owned by the server. Everything from /etc/raddb and below is readable only by root:radiusd for security reasons (you don't want to expose the configuration of an authentication server to the world). I suspect the code which reads the client cert files is running under your uid and is not a process with root privileges thus it can't read the cert files. I would try copying the client cert files to an alternate location, reset their permissions and try again. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
John, I changed the sequence in step b) of "SERVER-SIDE" as :: su - rm /etc/raddb/modules/dhcp_sqlippool cd /etc/raddb/certs make destroycerts make make client cp client.p12 /home/ajay cp ca.pem /home/ajay chmod 0644 /home/ajay/client.p12 chmod 0644 /home/ajay/ca.pem chown ajay.ajay /home/ajay/client.p12 chown ajay.ajay /home/ajay/ca.pem However, I get the exact same earlier dreaded logs :( On Wed, Jan 9, 2013 at 8:29 AM, John Dennis <jdennis@redhat.com> wrote:
On 01/08/2013 03:53 PM, Ajay Garg wrote:
On Tue, Jan 8, 2013 at 6:45 PM, John Dennis <jdennis@redhat.com <mailto:jdennis@redhat.com>> wrote:
On 01/08/2013 05:10 AM, Ajay Garg wrote:
Could you please specify the order of scripts to be run, so that proper certificates may be generated - both for the server, and the client? :P
You were given the answer. It's not just a matter of running the scripts it also requires knowing what the scripts output and how to configure *both* the client and the server with the script output.
You've never explained what you're doing in any detail, especially with regard to where you're generating the client cert. In a previous email I explained what the server needs and what the client needs. Now you're going to have to put that information to use. You really do have to invest the energy into learning how the pieces fit together.
Ok.. so here goes what I have been wanting to accomplish :P
ROUTER-SIDE :: ===========
a) Configure the router to do WPA/WPA2-Enterprise authentication.
b) The authentication is to be done via a freeradius-server.
c) I connect a wired-cable between the router and the freeradius-server-machine, to have a physical medium via which the router and the server may talk.
SERVER-SIDE :: ===========
a) Freeradius-server is running on Fedora-17 (freeradius-2.2.0-0.fc17.i686)
b) After installing freeradius, the certificates are generated via (on Fedora-17 machine) ::
su - rm /etc/raddb/modules/dhcp_** sqlippool cd /etc/raddb/certs make destroycerts make make client chmod 0644 client.p12 chmod 0644 ca.pem
c) Now, the freeradius is started on the Fedora-17 machine as ::
sudo /usr/sbin/radiusd -X &
Server runs fine.
CLIENT-SIDE :: ===========
a) THE SAME FEDORA-17 MACHINE ACTS AS THE CLIENT TOO :)
b) Now, from the gnome-panel applet, I try connecting to the WPA/WPA-2 Enterprise network, by setting the following settings ::
Wireless Security : WPA/WPA2-Enterprise Authentication : TLS Identity : Anonymous User Certificate : /etc/raddb/certs/client.p12 CA Certificate : /etc/raddb/certs/ca.pem Private Key : /etc/raddb/certs/client.p12 Private Key Password : whatever
c) I click the "Connect" button.....
and then the dreaded logs happen :(
Thank you, that is a much clearer explanation.
The first thing I notice is you're pointing the client to files in a directory owned by the server. Everything from /etc/raddb and below is readable only by root:radiusd for security reasons (you don't want to expose the configuration of an authentication server to the world).
I suspect the code which reads the client cert files is running under your uid and is not a process with root privileges thus it can't read the cert files. I would try copying the client cert files to an alternate location, reset their permissions and try again.
-- John Dennis <jdennis@redhat.com>
Looking to carve out IT costs? www.redhat.com/carveoutcosts/
-- Regards, Ajay
On 01/09/2013 06:15 AM, Ajay Garg wrote:
However, I get the exact same earlier dreaded logs :(
Sigh. This really is the thread of doom. Find a working CA/server cert (from another machine, generated with the same steps) and your failing ones. Then compare the output of: openssl x509 -noout -text -in ca.pem openssl x509 -noout -text -in server.pem If the certs differ substantially (applying common sense to fields that must differ, like key hashes, dates, serial numbers, etc.) then there might be an issue with cert generation. If no, you're doing something wrong - much more likely IMO.
On Wed, Jan 9, 2013 at 4:55 PM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 01/09/2013 06:15 AM, Ajay Garg wrote:
However, I get the exact same earlier dreaded logs :(
Sigh. This really is the thread of doom.
Find a working CA/server cert (from another machine, generated with the same steps) and your failing ones.
Then compare the output of:
openssl x509 -noout -text -in ca.pem openssl x509 -noout -text -in server.pem
Followed the above, and compared the structures of certs generated on Fedora-17 and Fedora-14. The structures were identical.
If the certs differ substantially (applying common sense to fields that must differ, like key hashes, dates, serial numbers, etc.) then there might be an issue with cert generation.
If no, you're doing something wrong - much more likely IMO.
Would it be possible for you (or someone) to have a WORKING-ON-FEDORA-17-FREERADIUS-SERVER "/etc/raddb/certs" directory shared with me? I could then try using those certs.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/** list/users.html <http://www.freeradius.org/list/users.html>
-- Regards, Ajay
On 09/01/13 13:41, Ajay Garg wrote:
Followed the above, and compared the structures of certs generated on Fedora-17 and Fedora-14. The structures were identical.
Then you're doing something wrong on the client I'm afraid.
On Wed, Jan 9, 2013 at 7:59 PM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 09/01/13 13:41, Ajay Garg wrote:
Followed the above, and compared the structures of certs generated on
Fedora-17 and Fedora-14. The structures were identical.
Then you're doing something wrong on the client I'm afraid.
Could you please let me know (preferably via a screenshot) what settings to use in gnome-panel for "TLS authentication"?
- List info/subscribe/unsubscribe? See http://www.freeradius.org/** list/users.html <http://www.freeradius.org/list/users.html>
-- Regards, Ajay
Hi,
b) Now, from the gnome-panel applet, I try connecting to the WPA/WPA-2 Enterprise network, by setting the following settings ::
Wireless Security : WPA/WPA2-Enterprise Authentication : TLS Identity : Anonymous User Certificate : /etc/raddb/certs/client.p12 CA Certificate : /etc/raddb/certs/ca.pem Private Key : /etc/raddb/certs/client.p12 Private Key Password : whatever
I use wpa_supplicant for wireless on Linux. nice easy config. however, I believe that on the newer NM applet you DO NOT specify the User certificate ie just do Wireless Security: WPA/WPA2-Enterprise Authentication: TLS Identity: anonymous User certificate: <leave blank> CA Certificate: /etc/raddb/certs/ca.pem Private Key: /etc/raddb/certs/client.p12 Private Key Password: whatever alan
On Thu, Jan 10, 2013 at 3:32 AM, <A.L.M.Buxey@lboro.ac.uk> wrote:
Hi,
b) Now, from the gnome-panel applet, I try connecting to the WPA/WPA-2 Enterprise network, by setting the following settings ::
Wireless Security : WPA/WPA2-Enterprise Authentication : TLS Identity : Anonymous User Certificate : /etc/raddb/certs/client.p12 CA Certificate : /etc/raddb/certs/ca.pem Private Key : /etc/raddb/certs/client.p12 Private Key Password : whatever
I use wpa_supplicant for wireless on Linux. nice easy config. however, I believe that on the newer NM applet you DO NOT specify the User certificate ie just do
Wireless Security: WPA/WPA2-Enterprise Authentication: TLS Identity: anonymous User certificate: <leave blank> CA Certificate: /etc/raddb/certs/ca.pem Private Key: /etc/raddb/certs/client.p12 Private Key Password: whatever
Same dreaded logs as before :( A.L.M., could you please try once with the gnome-applet once for a change ? :P
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Regards, Ajay
Same dreaded logs as before :( A.L.M., could you please try once with the gnome-applet once for a change ? :P -- Regards, Ajay
Ping :) Anyone managed to get this working on gnome-applet? :) On Sat, Jan 12, 2013 at 3:37 PM, Ajay Garg <ajaygargnsit@gmail.com> wrote:
Same dreaded logs as before :(
A.L.M., could you please try once with the gnome-applet once for a change ? :P
-- Regards, Ajay
-- Regards, Ajay
Hi,
Ping :)
Anyone managed to get this working on gnome-applet? :)
On Sat, Jan 12, 2013 at 3:37 PM, Ajay Garg <ajaygargnsit@gmail.com> wrote:
Same dreaded logs as before :(
A.L.M., could you please try once with the gnome-applet once for a change ? :P
what you are asking is for someone to install Fedora Core 17, install a default freeradius server, then get an AP talking RADIUS to that server and configure a WPA enterprise SSID pointing to that server then associate. all of this is pretty basic and all of this works (server stuff) works from a straight install...however, creating YOUR little test scenario isnt a quick process and is something most of us here would charge for, if I have some time over the next weeks I might do so just to show you where you went badly wrong (read up on PKI and certs yet as per some other previous responses)? but its REALLY REALLY low priority on my free support schedule alan
On 16/01/13 13:34, Ajay Garg wrote:
Ping :)
Anyone managed to get this working on gnome-applet? :)
$ gnome-applet bash: gnome-applet: command not found... You're being way too vague, inconsistent and hand-wavy for me to want to spend any time on this. If you can be *specific* about what you want someone to try, I *might* be willing to give it a go. No promises.
Hmm.. I am not exactly sure what package contains the gnome "handle" to edit network-settings (in Fedora-14, it was called "nm-applet"). Thanks !!! On Thu, Jan 17, 2013 at 5:03 PM, Phil Mayers <p.mayers@imperial.ac.uk>wrote:
-- Regards, Ajay
On 17/01/13 11:52, Ajay Garg wrote:
Hmm.. I am not exactly sure what package contains the gnome "handle" to edit network-settings (in Fedora-14, it was called "nm-applet").
Ok, then I give up. Maybe someone else is willing to spend time deciphering vagueness, but I'm not. Best of luck.
participants (5)
-
A.L.M.Buxey@lboro.ac.uk -
Ajay Garg -
Alan DeKok -
John Dennis -
Phil Mayers