Re: [RADIATOR] radiator never gets to the 2nd authentication phase in PEAP - MSCHAPv2

2016-02-01 Thread Hugo Veiga
Hi,


Heikki I bow to you. :)


So the problem was this:

(Topology)

Radiator Machine/ IP: 10.253.1.12/24
--Router--wireless switch/IP:10.240.1.1/24

- The radiator machine receives requests from wireless switch.

- Wireless switch never receives the answer.

:: So Radiator machine is a virtual machine and installed by a
colleague of mine (system admin) that inserted the mask 255.0.0.0 in
the network mask. Radiator machine with the supplied mask will try to
contact 10.240.1.1 through arp discovery and will never find it
because it's on a different broadcast domain. The solution was
obvious, insert the correct netmask and it started to work perfectly.


Problem solved.

Many thanks Heikki,

Hugo Veiga




>* Code:   Access-Request
*>* Identifier: 180
*>* Authentic:  <139><3>(<143><10><139>N<158><194><163><168><135>O
*
Radiator notices this and retransmits its previous reply

>* Tue Jan 26 15:54:57 2016: INFO: Duplicate request id 180 received from
*>* 10.240.1.1(20004): retransmit reply
*>* Tue Jan 26 15:54:57 2016: DEBUG: Packet dump:
*>* *** Sending to 10.240.1.1 port 20004 
*
There are multiple retransmits back and forth and the authentication
does not proceed.

I would check the Wi-Fi controller logs and make sure it is receiving

the responses from Radiator.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] radiator never gets to the 2nd authentication phase in PEAP - MSCHAPv2

2016-01-27 Thread Hugo Veiga
ch
perl-devel-5.22.1-350.fc23.x86_64
perl-Compress-Raw-Zlib-2.068-347.fc23.x86_64
perl-HTML-Tagset-3.20-24.fc23.noarch
perl-IO-Compress-2.068-347.fc23.noarch
perl-Net-HTTP-6.09-3.fc23.noarch
perl-Authen-SASL-2.16-6.fc23.noarch
perl-Module-Metadata-1.27-3.fc23.noarch
perl-Module-Load-Conditional-0.64-346.fc23.noarch
perl-Data-Section-0.26-5.fc23.noarch
perl-Carp-1.38-1.fc23.noarch
perl-Text-Diff-1.43-1.fc23.noarch
perl-Archive-Zip-1.49-1.fc23.noarch
perl-XML-Parser-2.44-3.fc23.x86_64
perl-podlators-2.5.3-347.fc23.noarch

2- I adapted the goodies file eap_peap.cfg, with small adjusts and tried a
AuthBy FILE, with the same result gets stuck and never enters the inner
handler.

3- Tried different OS as clients (windows 10 and android) with the same
result gets stuck and never enters the inner handler.

4- Tried different certificates that were previously tested in the
production environment (version radiator-4.9) with the same result gets
stuck and never enters the inner handler.


 I'm really getting out of ideas and can't figure out what is wrong with
this. By the way the OS of the server is fedora core 23, with all upgrades
and I installed Radiator 4.16 from rpm file.


Best regards,
Hugo Veiga


2016-01-26 15:40 GMT+00:00 Christian Kratzer :

> Hi,
>
> On Tue, 26 Jan 2016, Hugo Veiga wrote:
>
> In my original message I have by mistake a AuthBy INTERNAL in the outter
>> authentication it's actually a AuthBy SQL clause.
>>
>
> which is exactly why I made you test your 4.9 case.
>
>
> AuthBy SQL supports EAP.
> AuthBy FILE also supports EAP.
>
> and as Heikki said before: AuthBy INTERNAL does not.
>
>>
>>
>> This is trace from radiator 4.9.
>>
>> Tue Jan 26 15:01:15 2016: DEBUG: Handling request with Handler
>> 'Realm=/^convidado$/i', Identifier ''
>> Tue Jan 26 15:01:15 2016: DEBUG:  Deleting session for 1745@convidado,
>> 10.240.1.1, 54482
>> Tue Jan 26 15:01:15 2016: DEBUG: Handling with Radius::AuthSQL:
>> SQLAccounting
>> Tue Jan 26 15:01:15 2016: DEBUG: AuthBy SQL result: IGNORE, Ignored due to
>> IgnoreAuthentication
>> Tue Jan 26 15:01:15 2016: DEBUG: Handling with Radius::AuthSQL:
>> PEAP_CONVIDADO
>> Tue Jan 26 15:01:15 2016: DEBUG: Handling with Radius::AuthSQL:
>> PEAP_CONVIDADO
>>
>
> this is proof that the first packet is going into an AuthSQL.  In your
> 4.16 example it was going into your AuthBy INTERNAL handler.
>
> Your old configuration should from 4.9 should run on 4.16.  Just do not
> put swap your AuthBy FILE or AuthBy SQL  for an  AuthBy INTERNAL.
>
> Greetings
> Christian
>
> --
> Christian Kratzer   CK Software GmbH
> Email:   c...@cksoft.de   Wildberger Weg 24/2
> Phone:   +49 7032 893 997 - 0   D-71126 Gaeufelden
> Fax: +49 7032 893 997 - 9   HRB 245288, Amtsgericht Stuttgart
> Mobile:  +49 171 1947 843   Geschaeftsfuehrer: Christian Kratzer
> Web: http://www.cksoft.de/
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] radiator never gets to the 2nd authentication phase in PEAP - MSCHAPv2

2016-01-26 Thread Hugo Veiga
Sorry For the waist of your time, and thanks for your point (I was
trying all possible things that I could remember and this went to the list
by mistake).

Also tried another certificate but it's doing the same, it gets stuck and
never reaches the inner handler.

Here is a trace from 4.16 with the SQL clause just like 4.9 (except for the
AuthBy SQL "Accounting" - that's in the 4.9 because its a production
eviroment) with i'm not doing right now for the 4.16.

Best regards,
Hugo Veiga


The config file for 4.16:




Identifier PEAP_CONVIDADO_INNER
DBSource dbi:mysql:radius-temp
DBUsername db_user
DBAuth db_passwd_1234
Timeout 10
SQLRetries 4
FailureBackoffTime 10
EAPType MSCHAP-V2
AuthSelect SELECT password FROM convidado WHERE
username=SUBSTRING('%u',1,LOCATE('@','%u')) AND datai<"%Y-%m-%d %H:%M:%S"
AND dataf>"%Y-%m-%d %H:%M:%S"



Identifier PEAP_CONVIDADO
   DBSource dbi:mysql:radius-temp
DBUsername db_user
DBAuth db_passwd_1234
Timeout 10
SQLRetries 4
FailureBackoffTime 10
EAPType PEAP
EAPAnonymous %u
EAPTLS_PEAPVersion 0
EAPTTLS_NoAckRequired
EAPTLS_CAFile /etc/radiator/hvcert.pem
EAPTLS_CertificateFile /etc/radiator/hvcert.pem
EAPTLS_CertificateType PEM
EAPTLS_PrivateKeyFile /etc/radiator/hvkey.pem
EAPTLS_MaxFragmentSize 1000
AutoMPPEKeys





AuthBy PEAP_CONVIDADO_INNER





AuthByPolicy ContinueAlways
#AuthBy SQLAccounting - Not in for this test used
AuthBy PEAP_CONVIDADO




Dump:

Tue Jan 26 15:54:52 2016: DEBUG: Packet dump:
*** Received from 10.240.1.1 port 20004 

Packet length = 163
01 b4 00 a3 8b 03 28 8f 0a 8b 4e 9e 3c 46 ac c2
a3 a8 87 4f 57 07 41 50 32 2f 31 1f 13 43 34 2d
38 35 2d 30 38 2d 41 36 2d 43 30 2d 32 46 1e 1b
30 30 2d 31 31 2d 38 38 2d 44 32 2d 44 39 2d 39
34 3a 63 63 74 65 73 74 65 06 06 00 00 00 02 4f
15 02 01 00 13 01 31 37 34 35 40 63 6f 6e 76 69
64 61 64 6f 01 10 31 37 34 35 40 63 6f 6e 76 69
64 61 64 6f 05 06 00 00 dc 55 3d 06 00 00 00 13
04 06 0a f0 01 01 20 0b 65 6e 74 65 72 61 73 79
73 50 12 e3 bc 56 bf 10 ec 97 f5 f8 22 c6 7e 96
a4 80 c8
Code:   Access-Request
Identifier: 180
Authentic:  <139><3>(<143><10><139>N<158><194><163><168><135>O
Attributes:
NAS-Port-Id = "AP2/1"
Calling-Station-Id = "C4-85-08-A6-C0-2F"
Called-Station-Id = "00-11-88-D2-D9-94:ccteste"
Service-Type = Framed-User
EAP-Message = <2><1><0><19><1>1745@convidado
User-Name = "1745@convidado"
NAS-Port = 56405
NAS-Port-Type = Wireless-IEEE-802-11
NAS-IP-Address = 10.240.1.1
NAS-Identifier = "enterasys"
Message-Authenticator =
<227><188>V<191><16><236><151><245><248>"<198>~<150><164><128><200>

Tue Jan 26 15:54:52 2016: DEBUG: Handling request with Handler
'Realm=/^convidado$/i', Identifier ''
Tue Jan 26 15:54:52 2016: DEBUG:  Deleting session for 1745@convidado,
10.240.1.1, 56405
Tue Jan 26 15:54:52 2016: DEBUG: Handling with Radius::AuthSQL:
PEAP_CONVIDADO
Tue Jan 26 15:54:52 2016: DEBUG: Handling with Radius::AuthSQL:
PEAP_CONVIDADO
Tue Jan 26 15:54:52 2016: DEBUG: Handling with EAP: code 2, 1, 19, 1
Tue Jan 26 15:54:52 2016: DEBUG: Response type 1
Tue Jan 26 15:54:52 2016: DEBUG: EAP result: 3, EAP PEAP Challenge
Tue Jan 26 15:54:52 2016: DEBUG: AuthBy SQL result: CHALLENGE, EAP PEAP
Challenge
Tue Jan 26 15:54:52 2016: DEBUG: Access challenged for 1745@convidado: EAP
PEAP Challenge
Tue Jan 26 15:54:52 2016: DEBUG: Packet dump:
*** Sending to 10.240.1.1 port 20004 

Packet length = 46
0b b4 00 2e fa a6 ac 2d f7 6f 14 aa 11 5c 6e 0e
a4 24 88 8e 4f 08 01 02 00 06 19 20 50 12 2d 47
b9 13 e4 7d 75 21 1b 7e 14 4b 39 67 16 5e
Code:   Access-Challenge
Identifier: 180
Authentic:  <250><166><172>-<247>o<20><170><17>\n<14><164>$<136><142>
Attributes:
EAP-Message = <1><2><0><6><25>
Message-Authenticator =
<0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>

Tue Jan 26 15:54:57 2016: DEBUG: Packet dump:
*** Received from 10.240.1.1 port 20004 

Packet length = 163
01 b4 00 a3 8b 03 28 8f 0a 8b 4e 9e 3c 46 ac c2
a3 a8 87 4f 57 07 41 50 32 2f 31 1f 13 43 34 2d
38 35 2d 30 38 2d 41 36 2d 43 30 2d 32 46 1e 1b
30 30 2d 31 31 2d 38 38 2d 44 32 2d 44 39 2d 39
34 3a 63 63 74 65 73 74 65 06 06 00 00 00 02 4f
15 02 01 00 13 01 31 37 34 35 40

Re: [RADIATOR] radiator never gets to the 2nd authentication phase in PEAP - MSCHAPv2

2016-01-26 Thread Hugo Veiga
2016: DEBUG: Access challenged for 1745@convidado: EAP
PEAP inner authentication redispatched to a Handler
Tue Jan 26 15:01:15 2016: DEBUG: Packet dump:
*** Sending to 10.240.1.1 port 20009 

Packet length = 131
0b 55 00 83 7e f2 3b 35 e4 1f c7 97 70 25 65 bb
79 5f 98 62 4f 5d 01 08 00 5b 19 00 17 03 01 00
50 bb 32 41 53 22 23 e4 1c ec 91 51 fb 1a 95 83
2a 6a 27 4c ce 62 5f 5a 30 99 d4 8c 46 ce a6 a8
ff 84 e2 64 b5 7d 3f e3 c0 11 e3 76 49 9e 10 c5
dd 82 69 75 f6 24 36 56 87 cb e7 08 70 1f 0a ab
6f d5 e2 8d b7 14 f5 17 1e 88 56 6b 93 c5 8b 11
3c 50 12 92 cb 9a 3b 40 ee aa ad e4 cb df 7a bb
25 6f d6
Code:   Access-Challenge
Identifier: 85
Authentic:  ~<242>;5<228><31><199><151>p%e<187>y_<152>b
Attributes:
EAP-Message =
<1><8><0>[<25><0><23><3><1><0>P<187>2AS"#<228><28><236><145>Q<251><26><149><131>*j'L<206>b_Z0<153><212><140>F<206><166><168><255><132><226>d<181>}?<227><192><17><227>vI<158><16><197><221><130>iu<246>$6V<135><203><231><8>p<31><10><171>o<213><226><141><183><20><245><23><30><136>Vk<147><197><139><17><
Message-Authenticator =
<0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>

Tue Jan 26 15:01:15 2016: DEBUG: Handling request with Handler
'Realm=/^convidado$/i', Identifier ''
Tue Jan 26 15:01:15 2016: DEBUG:  Deleting session for 1745@convidado,
10.240.1.1, 54482
Tue Jan 26 15:01:15 2016: DEBUG: Handling with Radius::AuthSQL:
SQLAccounting
Tue Jan 26 15:01:15 2016: DEBUG: AuthBy SQL result: IGNORE, Ignored due to
IgnoreAuthentication
Tue Jan 26 15:01:15 2016: DEBUG: Handling with Radius::AuthSQL:
PEAP_CONVIDADO
Tue Jan 26 15:01:15 2016: DEBUG: Handling with Radius::AuthSQL:
PEAP_CONVIDADO
Tue Jan 26 15:01:15 2016: DEBUG: Handling with EAP: code 2, 8, 43, 25
Tue Jan 26 15:01:15 2016: DEBUG: Response type 25
Tue Jan 26 15:01:15 2016: DEBUG: Handling request with Handler
'Realm=/^convidado$/i, TunnelledByPEAP=1', Identifier ''
Tue Jan 26 15:01:15 2016: DEBUG:  Deleting session for 1745@convidado,
10.240.1.1, 54482
Tue Jan 26 15:01:15 2016: DEBUG: Handling with Radius::AuthSQL:
PEAP_CONVIDADO_INNER
Tue Jan 26 15:01:15 2016: DEBUG: Handling with Radius::AuthSQL:
PEAP_CONVIDADO_INNER
Tue Jan 26 15:01:15 2016: DEBUG: Handling with EAP: code 2, 8, 2, 26
Tue Jan 26 15:01:15 2016: DEBUG: Response type 26
Tue Jan 26 15:01:15 2016: DEBUG: EAP result: 0,
Tue Jan 26 15:01:15 2016: DEBUG: AuthBy SQL result: ACCEPT,
Tue Jan 26 15:01:15 2016: DEBUG: Access accepted for 1745@convidado
Tue Jan 26 15:01:15 2016: DEBUG: EAP result: 3, EAP PEAP inner
authentication redispatched to a Handler
Tue Jan 26 15:01:15 2016: DEBUG: AuthBy SQL result: CHALLENGE, EAP PEAP
inner authentication redispatched to a Handler
Tue Jan 26 15:01:15 2016: DEBUG: Access challenged for 1745@convidado: EAP
PEAP inner authentication redispatched to a Handler
Tue Jan 26 15:01:15 2016: DEBUG: Packet dump:
*** Sending to 10.240.1.1 port 20009 

Packet length = 83
0b 56 00 53 20 55 c4 02 60 16 31 f2 47 31 3c 6e
8e bc 79 ca 4f 2d 01 09 00 2b 19 00 17 03 01 00
20 ba 39 99 53 4b fe c4 c3 0d 7a 82 0d ab 4b f2
0d a6 8a ed 14 90 18 3b 4c fc 1a e3 c4 f1 f5 99
46 50 12 d5 cd f7 be ce 24 19 a5 b7 f0 c7 ab 88
df 6c 3f
Code:   Access-Challenge
Identifier: 86
Authentic:   U<196><2>`<22>1<242>G1<188>y<202>
Attributes:
EAP-Message = <1><9><0>+<25><0><23><3><1><0>
<186>9<153>SK<254><196><195><13>z<130><13><171>K<242><13><166><138><237><20><144><24>;L<252><26><227><196><241><245><153>F
Message-Authenticator =
<0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>

Tue Jan 26 15:01:15 2016: DEBUG: Handling request with Handler
'Realm=/^convidado$/i', Identifier ''
Tue Jan 26 15:01:15 2016: DEBUG:  Deleting session for 1745@convidado,
10.240.1.1, 54482
Tue Jan 26 15:01:15 2016: DEBUG: Handling with Radius::AuthSQL:
SQLAccounting
Tue Jan 26 15:01:15 2016: DEBUG: AuthBy SQL result: IGNORE, Ignored due to
IgnoreAuthentication
Tue Jan 26 15:01:15 2016: DEBUG: Handling with Radius::AuthSQL:
PEAP_CONVIDADO
Tue Jan 26 15:01:15 2016: DEBUG: Handling with Radius::AuthSQL:
PEAP_CONVIDADO
Tue Jan 26 15:01:15 2016: DEBUG: Handling with EAP: code 2, 9, 43, 25
Tue Jan 26 15:01:15 2016: DEBUG: Response type 25
Tue Jan 26 15:01:15 2016: DEBUG: EAP result: 0,
Tue Jan 26 15:01:15 2016: DEBUG: AuthBy SQL result: ACCEPT,
Tue Jan 26 15:01:15 2016: DEBUG: Access accepted for 1745@convidado
Tue Jan 26 15:01:15 2016: DEBUG: Packet dump:
*** Sending to 10.240.1.1 port 20009 

Packet length = 160
02 57 00 a0 3b a0 1b bb ac b6 77 2a 38 ed c5 52
99 e5 4f 36 4f 06 03 09 00 04 50 12 eb 0d c5 07
bc ea cf 46 3f 5e df 81 d3 ff 23 84 1a 3a 00 00
01 37 10 34 a4 bf ec f5 94 3e 60 fd bc fe 20 cb
9c 79 f5 78 59 df e4 bb e0 05 ac 6a 87 2d df 5c
56 d5 ba 6d 02 0d 80 54 28 1e 04 61 08 29 08 1a
ef bf 41 65 fe 03 1a 3a 00 00 01 37 11 34 da 80
09 ca 00 29 4b a2 4a da 0c 65 e9 f9 bc 43 cf d7
9f 5c 04 36 fa 03 37 03 ec 35 dd 55 bb bc 89 5f
97 49 20 fd 37 28 b1 e2 25 f6 f4 a1 93 83 9d 51
Code:   Access-Accept
Identifier: 87
Authentic:  ;<160><27><187><172><182>w*8<237><197>R<153><229>O6
Attributes:
EAP-Message = <3><9><0><4>
Message-Authenticator =
<0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>
MS-MPPE-Send-Key =
+<29>8<28><211><200><184><12><236><207><195><153><206><227><249><244><198><232><255><226><225>;Z<23><242><146>XT<201><212>*<171>
MS-MPPE-Recv-Key = <210>M<169><160><149>
<226><236><171><217>t<139><13><209><255><246><131>i<130><211><179><249>V<135>D<178>n<243><136>a<148>@

Tue Jan 26 15:01:15 2016: DEBUG: Handling request with Handler
'Realm=/^convidado$/i', Identifier ''
Tue Jan 26 15:01:15 2016: DEBUG:  Adding session for 1745@convidado,
10.240.1.1, 54482
Tue Jan 26 15:01:15 2016: DEBUG: Handling with Radius::AuthSQL:
SQLAccounting
Tue Jan 26 15:01:15 2016: DEBUG: Handling accounting with Radius::AuthSQL
Tue Jan 26 15:01:15 2016: DEBUG: AuthBy SQL result: ACCEPT,
Tue Jan 26 15:01:15 2016: DEBUG: Handling with Radius::AuthSQL:
PEAP_CONVIDADO
Tue Jan 26 15:01:15 2016: DEBUG: Handling accounting with Radius::AuthSQL
Tue Jan 26 15:01:15 2016: DEBUG: AuthBy SQL result: ACCEPT,
Tue Jan 26 15:01:15 2016: DEBUG: Accounting accepted
Tue Jan 26 15:01:15 2016: DEBUG: Packet dump:
*** Sending to 10.240.1.1 port 20009 

Packet length = 20
05 58 00 14 aa 34 2c d5 d9 cf c0 17 dd 20 b1 ef
76 a8 88 e4
Code:   Accounting-Response
Identifier: 88
Authentic:  <170>4,<213><217><207><192><23><221> <177><239>v<168><136><228>
Attributes:

Tue Jan 26 15:01:16 2016: DEBUG: Handling request with Handler
'Realm=/^convidado$/i', Identifier ''
Tue Jan 26 15:01:16 2016: DEBUG:  Adding session for 1745@convidado,
10.240.1.1, 54482
Tue Jan 26 15:01:16 2016: DEBUG: Handling with Radius::AuthSQL:
SQLAccounting
Tue Jan 26 15:01:16 2016: DEBUG: Handling accounting with Radius::AuthSQL
Tue Jan 26 15:01:16 2016: DEBUG: AuthBy SQL result: ACCEPT,
Tue Jan 26 15:01:16 2016: DEBUG: Handling with Radius::AuthSQL:
PEAP_CONVIDADO
Tue Jan 26 15:01:16 2016: DEBUG: Handling accounting with Radius::AuthSQL
Tue Jan 26 15:01:16 2016: DEBUG: AuthBy SQL result: ACCEPT,
Tue Jan 26 15:01:16 2016: DEBUG: Accounting accepted
Tue Jan 26 15:01:16 2016: DEBUG: Packet dump:
*** Sending to 10.240.1.1 port 20009 

Packet length = 20
05 63 00 14 21 f7 25 87 55 57 dc 1d b2 ef 4d 48
3a aa 46 e2
Code:   Accounting-Response
Identifier: 99
Authentic:  !<247>%<135>UW<220><29><178><239>MH:<170>F<226>
Attributes:



2016-01-26 9:35 GMT+00:00 Christian Kratzer :

> Hi,
>
> On Tue, 26 Jan 2016, Hugo Veiga wrote:
>
>> Hi Alan,
>>
>> I have the same config on radiator 4.9 and it works perfectly.
>>
>> About the stuff order ;) , I use the Authby as "functions" and usually I
>> put them before the handlers, this is very practical to reuse code.
>>
>> As you suggested I tried to put them after the handlers and I have the
>> same
>> exact result.
>>
>
> try getting a trace 4 log from the authentication on your 4.9 radiator
> so we can see the difference.
>
> Greetings
> Christian
>
>
>
>> Best regards,
>> Hugo Veiga
>>
>>
>> 2016-01-25 19:09 GMT+00:00 Alan Buxey :
>>
>> Try putting your stuff into order - your inner stuff , handlers et al ,
>>> AFTER the realm check (where you are then asking for a particular
>>> handler).
>>>
>>> The goodies directory provides ready to go starting recipes for this
>>> stuff
>>> (so you can see how handlers/inner work)
>>>
>>> alan
>>>
>>
>>
> --
> Christian Kratzer   CK Software GmbH
> Email:   c...@cksoft.de   Wildberger Weg 24/2
> Phone:   +49 7032 893 997 - 0   D-71126 Gaeufelden
> Fax: +49 7032 893 997 - 9   HRB 245288, Amtsgericht Stuttgart
> Mobile:  +49 171 1947 843   Geschaeftsfuehrer: Christian Kratzer
> Web: http://www.cksoft.de/
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] radiator never gets to the 2nd authentication phase in PEAP - MSCHAPv2

2016-01-26 Thread Hugo Veiga
Hi Alan,

I have the same config on radiator 4.9 and it works perfectly.

About the stuff order ;) , I use the Authby as "functions" and usually I
put them before the handlers, this is very practical to reuse code.

As you suggested I tried to put them after the handlers and I have the same
exact result.

Best regards,
Hugo Veiga


2016-01-25 19:09 GMT+00:00 Alan Buxey :

> Try putting your stuff into order - your inner stuff , handlers et al ,
> AFTER the realm check (where you are then asking for a particular handler).
>
> The goodies directory provides ready to go starting recipes for this stuff
> (so you can see how handlers/inner work)
>
> alan
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] radiator never gets to the 2nd authentication phase in PEAP - MSCHAPv2

2016-01-25 Thread Hugo Veiga
Hi,

I'm upgrading from 4.9 to radiator 4.16 and I'm stuck because I can't get
radiator to get to the inner authentication phase.

It simply doesn't dispatch to the inner handler! Am I missing to install
something?

Light on this would be great.

Best regards,
Hugo Veiga


Here is my config:
-
LogDir  /var/log/radius
DbDir   /etc/radiator/
Trace   9
AuthPort 1812
AcctPort 1813



Secret test123..123



Identifier localusers
Filename %L/localusers.log
#SuccessFormat %l|%u|OK
SuccessFormat %l|%N|%{Request:Calling-Station-Id}|%u|OK|%P
FailureFormat %l|%N|%{Request:Calling-Station-Id}|%u|Reason:%1|KO
LogSuccess 1
LogFailure 1


#Inner-Request-the-real-authentication

Identifier PEAP_CONVIDADO_INNER
DBSource dbi:mysql:radius-temp
DBUsername db_user
DBAuth passwd_teste123
Timeout 10
SQLRetries 4
FailureBackoffTime 10
EAPType MSCHAP-V2
#uses the outer username no anonymous allowed
AuthSelect SELECT password FROM convidado WHERE
username=SUBSTRING('%u',1,LOCATE('@','%u'))
AND datai<"%Y-%m-%d %H:%M:%S" AND dataf>"%Y-%m-%d %H:%M:%S"
#PacketTrace


#Outer-request-to-exchange-certificate-keys

Identifier PEAP_CONVIDADO
EAPType PEAP
EAPAnonymous %u
EAPTLS_PEAPVersion 0
EAPTTLS_NoAckRequired
EAPTLS_CAFile /etc/radiator/terena_ca.pem
EAPTLS_CertificateFile /etc/radiator/dc2_2.pem
EAPTLS_CertificateType PEM
EAPTLS_PrivateKeyFile /etc/radiator/dc2key_2.pem
EAPTLS_MaxFragmentSize 1000
AutoMPPEKeys


#handler for inner

  AuthBy PEAP_CONVIDADO_INNER



#handler for outer

AuthBy PEAP_CONVIDADO



#Default

 
DefaultResult   REJECT


Filename %L/localusers.log
FailureFormat
%l|%N|%{Request:Calling-Station-Id}|%u|Reason:DEFAULT REALM|KO

AccountingHandled


---

Trace:

Mon Jan 25 17:51:59 2016: DEBUG: Finished reading configuration file
'/etc/radiator/radius.cfg'
Mon Jan 25 17:51:59 2016: DEBUG: Reading dictionary file
'/etc/radiator//dictionary'
Mon Jan 25 17:51:59 2016: DEBUG: This system is IPv6 capable. IPv6
capability provided by: core
Mon Jan 25 17:51:59 2016: INFO: Using Net::SSLeay 1.71 with SSL/TLS library
version 0x1000205f (OpenSSL 1.0.2e-fips 3 Dec 2015)
Mon Jan 25 17:51:59 2016: DEBUG: Creating authentication port 0.0.0.0:1812
Mon Jan 25 17:51:59 2016: DEBUG: Creating accounting port 0.0.0.0:1813
Mon Jan 25 17:51:59 2016: NOTICE: Server started: Radiator 4.16 on radius02.
ubi.pt
Mon Jan 25 17:52:08 2016: DEBUG: Packet dump:
*** Received from 10.240.1.1 port 20002 

Packet length = 163
01 90 00 a3 e9 8b 9f 43 90 88 16 f2 7c 53 68 0a
99 7f b3 88 57 07 41 50 33 2f 31 1f 13 43 34 2d
38 35 2d 30 38 2d 41 36 2d 43 30 2d 32 46 1e 1b
30 30 2d 31 31 2d 38 38 2d 44 32 2d 44 44 2d 30
34 3a 63 63 74 65 73 74 65 06 06 00 00 00 02 4f
15 02 01 00 13 01 31 37 34 35 40 63 6f 6e 76 69
64 61 64 6f 01 10 31 37 34 35 40 63 6f 6e 76 69
64 61 64 6f 05 06 00 00 93 d0 3d 06 00 00 00 13
04 06 0a f0 01 01 20 0b 65 6e 74 65 72 61 73 79
73 50 12 61 c8 48 b8 9a 0b 4b 42 12 7a e1 f9 cd
b1 ea 22
Code:   Access-Request
Identifier: 144
Authentic:  <233><139><159>C<144><136><22><242>|Sh<10><153><127><179><136>
Attributes:
NAS-Port-Id = "AP3/1"
Calling-Station-Id = "C4-85-08-A6-C0-2F"
Called-Station-Id = "00-11-88-D2-DD-04:ccteste"
Service-Type = Framed-User
EAP-Message = <2><1><0><19><1>1745@convidado
User-Name = "1745@convidado"
NAS-Port = 37840
NAS-Port-Type = Wireless-IEEE-802-11
NAS-IP-Address = 10.240.1.1
NAS-Identifier = "enterasys"
Message-Authenticator =
a<200>H<184><154><11>KB<18>z<225><249><205><177><234>"

Mon Jan 25 17:52:08 2016: DEBUG: Handling request with Handler 'Realm=/^
convidado$/i', Identifier ''
Mon Jan 25 17:52:08 2016: DEBUG:  Deleting session for 1745@convidado,
10.240.1.1, 37840
Mon Jan 25 17:52:08 2016: DEBUG: Handling with AuthINTERNAL: PEAP_CONVIDADO
Mon Jan 25 17:52:08 2016: DEBUG: AuthBy INTERNAL result: IGNORE, Fixed by
DefaultResult
Mon Jan 25 17:52:13 2016: DEBUG: Packet dump:
*** Received from 10.240.1.1 port 20002 

Packet length = 163
01 90 00 a3 e9 8b 9f 43 90 88 16 f2 7c 53 68 0a
99 7f b3 88 57 07 41 50 33 2f 31 1f 13 43 34 2d
38 35 2d 30 38 2d 41 36 2d 43 30 2d 32 46 1e 1b
30 30 2d 31 31 2d 38 38 2d 44 32 2d 44 44 2d 30
34 3a 63 63 74 65 73 74 65 06 06 00 00 00 02 4f
15 02 01 00 13 01 31 37 34 35 40

[RADIATOR] regex match in realm

2012-07-31 Thread Hugo Veiga
Hi,

Yes, tried with and without just to make sure.

On the double check I found that I introduced another symbol the first time
I added the quotes. :)

Thanks a lot António and Heikki

Regards,
Hugo Veiga



>Hi,
>
>Have you surrounded it with double quotes?
>
>Regards,
>António Mendes
>
>
>Em 31-07-2012 10:39, Hugo Veiga escreveu:
> Hi,
>
> Same result, if I use a coma in the regex it will not match even if it
> should.
>
> I'm using radiator 4.7.3
>
> Regards,
> Hugo Veiga
>
>
> Hi Hugo,
>
> I think that your regexp is badly formed, could you please test the
> following and post the results:
> /^([a-zA-Z0-9\.-]+@?)*[a-zA-Z0-9\.-]*\.([a-zA-Z]){2,4}$/
>
> This allows strings of type:
> user at ua.pt <http://ua.pt>
> ua.pt <http://ua.pt>
> ua.ppt
> ua.ptpt
> user at ua.pptt
>
> This not allows:
> @ua.pt <http://ua.pt>
> ""saa at ua.pt <http://ua.pt>
> 
>
>
> Regards,
> António Mendes.
>
>
>
> Em 31-07-2012 10:03, Hugo Veiga escreveu:
> > Hi,
> >
> > I tried addind the double quotes to surround the Realm but it still
> doesn't beave as expected.
> >
> >
> >
> > The realmua.pt <http://realmua.pt>  <http://ua.pt>  should be a
> match but with the ,4 it doesn't work !
> >
> > Do you have more advice? They are very welcome.
> >
> > Thanks,
> > Hugo Veiga
> >
> >
> > On 07/30/2012 05:44 PM, Hugo Veiga wrote:
> >
> > >/  I'm having trouble in a regex in realm Handler:
> > />/
> > />/   > />/  Realm=/^[a-zA-Z0-9\.-]*?\.([a-zA-Z]){2,4}$/,
> > />/  Client-Identifier=/^(?!4ProxyServer$)/>
> > /
> > Hello Hugo,
> >
> > I tried the handler and got this:
> >
> >ERR: Bad attribute=value pair: 4}$/,
> > Client-Identifier=/^(?!4ProxyServer$)/
> >
> > Try this instead:
> >
> >  > Realm="/^[a-zA-Z0-9\.-]*?\.([a-zA-Z]){2,4}$/",
> > Client-Identifier=/^(?!4ProxyServer$)/>
> >
> > I added the double quotes to surround the Realm value since the value
> > contains a comma.
> >
> > Thanks,
> > Heikki
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] regex match in realm

2012-07-31 Thread Hugo Veiga
Hi,

Same result, if I use a coma in the regex it will not match even if it
should.

I'm using radiator 4.7.3

Regards,
Hugo Veiga


Hi Hugo,

I think that your regexp is badly formed, could you please test the
following and post the results:
/^([a-zA-Z0-9\.-]+@?)*[a-zA-Z0-9\.-]*\.([a-zA-Z]){2,4}$/

This allows strings of type:
user at ua.pt
ua.pt
ua.ppt
ua.ptpt
user at ua.pptt

This not allows:
@ua.pt
""saa at ua.pt



Regards,
António Mendes.



Em 31-07-2012 10:03, Hugo Veiga escreveu:
> Hi,
>
> I tried addind the double quotes to surround the Realm but it still
doesn't beave as expected.
>
>
>
> The realmua.pt  <http://ua.pt>  should be a match but with the ,4 it
doesn't work !
>
> Do you have more advice? They are very welcome.
>
> Thanks,
> Hugo Veiga
>
>
> On 07/30/2012 05:44 PM, Hugo Veiga wrote:
>
> >/  I'm having trouble in a regex in realm Handler:
> />/
> />/   />/  Realm=/^[a-zA-Z0-9\.-]*?\.([a-zA-Z]){2,4}$/,
> />/  Client-Identifier=/^(?!4ProxyServer$)/>
> /
> Hello Hugo,
>
> I tried the handler and got this:
>
>ERR: Bad attribute=value pair: 4}$/,
> Client-Identifier=/^(?!4ProxyServer$)/
>
> Try this instead:
>
>  Realm="/^[a-zA-Z0-9\.-]*?\.([a-zA-Z]){2,4}$/",
> Client-Identifier=/^(?!4ProxyServer$)/>
>
> I added the double quotes to surround the Realm value since the value
> contains a comma.
>
> Thanks,
> Heikki
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] regex match in realm

2012-07-31 Thread Hugo Veiga
Hi,


I tried addind the double quotes to surround the Realm but it still
doesn't beave as expected.


The realm ua.pt should be a match but with the ,4 it doesn't work !


Do you have more advice? They are very welcome.


Thanks,

Hugo Veiga



On 07/30/2012 05:44 PM, Hugo Veiga wrote:

>* I'm having trouble in a regex in realm Handler:*>* *>* User-Name=/^[a-zA-Z0-9][a-zA-Z0-9._-]/,*>* 
>Realm=/^[a-zA-Z0-9\.-]*?\.([a-zA-Z]){2,4}$/,*>* 
>Client-Identifier=/^(?!4ProxyServer$)/>*
Hello Hugo,

I tried the handler and got this:

  ERR: Bad attribute=value pair: 4}$/,
Client-Identifier=/^(?!4ProxyServer$)/

Try this instead:



I added the double quotes to surround the Realm value since the value
contains a comma.

Thanks,
Heikki
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] regex match in realm

2012-07-30 Thread Hugo Veiga
Hi,

I'm having trouble in a regex in realm Handler:



The problem is in the Realm part:

If I put the regex like mentioned and test the user: t...@ua.pt the string
will never math!.

But I've tried out this regex in various regex testers and it should be
working.

If I take out maximum number of chars of 4 and just
put: Realm=/^[a-zA-Z0-9\.-]*?\.([a-zA-Z]){2}$/ it will match as expected
since pt only have 2 chars.


Is this some kind of bug or I'm I doing something really wrong.


Best regards,
Hugo Veiga
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator