Re: problem with proxying using fail_over setup

2004-07-08 Thread Alan DeKok 
"Htin Hlaing" <[EMAIL PROTECTED]> wrote:
> Now this time with round robin setup.  What I am seeing is that each
> access request are being sent out in round robin even within the same
> authentication session.  So, server1 gets the first access-request and
> sends access-challenge out and the access-request in response to the
> challenge gets sent to server2.  Now, server1 waits for the
> access-request while the server2 does not know about the access-request
> it gets and drops.  So, authentication never finishes.

  Yup.  The server SHOULD keep track of the State attribute in
Access-Challenges, and proxy the new Access-Request back to the home
server.

  This isn't in 1.0.0, and may go in 1.1.0.

  Alan DeKok.

- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: problem with proxying using fail_over setup

2004-07-08 Thread Alan DeKok 
"Htin Hlaing" <[EMAIL PROTECTED]> wrote:
> Thanks for that info Alan.  That makes sense.  Also,  what I was looking
> for is that the second server set up will be tried automatically as the
> first one is marked death.

  By the time FreeRADIUS realizes that the home server is dead, the
NAS has probably given up on the request.  So it's generally not a
good idea to send the request to a different home server.

  There are limited cases where I can see it being useful, but there's
no code in the server to support that functionality.

  Alan DeKok.

- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

RE: problem with proxying using fail_over setup

2004-07-07 Thread Htin Hlaing 
Hi,

Now this time with round robin setup.  What I am seeing is that each
access request are being sent out in round robin even within the same
authentication session.  So, server1 gets the first access-request and
sends access-challenge out and the access-request in response to the
challenge gets sent to server2.  Now, server1 waits for the
access-request while the server2 does not know about the access-request
it gets and drops.  So, authentication never finishes.

The attached files are the debug output from home server1 and server 2
and the proxy.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:freeradius-
> [EMAIL PROTECTED] On Behalf Of Htin Hlaing
> Sent: Wednesday, July 07, 2004 2:32 PM
> To: [EMAIL PROTECTED]
> Subject: RE: problem with proxying using fail_over setup
> 
> Thanks for that info Alan.  That makes sense.  Also,  what I was
looking
> for is that the second server set up will be tried automatically as
the
> first one is marked death.  But, it returns access-reject and the
client
> has to initiate authentication again while the first one is marked
dead
> for the dead time.  Any way for me to achieve what I am looking for?
> 
> Thanks,
> Htin
> 

rad_recv: Access-Request packet from host 192.168.10.118:1814, id=5, length=206
--- Walking the entire request list ---
Waking up in 31 seconds...
Thread 5 got semaphore
Thread 5 handling request 39, (8 handled so far)
Framed-MTU = 1466
NAS-IP-Address = 192.168.10.113
NAS-Identifier = "D-link Corp. Access Point"
User-Name = "user_1"
Service-Type = Framed-User
NAS-Port = 65
NAS-Port-Type = Wireless-802.11
NAS-Port-Id = "ether2_65"
Called-Station-Id = "00-05-5d-99-5f-3a"
Calling-Station-Id = "00-30-65-24-4c-5b"
Connect-Info = "CONNECT Ethernet 0Mbps Full duplex"
EAP-Message = 0x0202000b01757365725f31
Message-Authenticator = 0xf99be789d247177bdd244c5bc5f62a20
Proxy-State = 0x313635
  Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 39
  modcall[authorize]: module "preprocess" returns ok for request 39
radius_xlat:  
'/home/hhlaing/Install/radius-June-21-configs/log/radius/radacct/192.168.10.118/auth-detail-20040707'
rlm_detail: 
/home/hhlaing/Install/radius-June-21-configs/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d
 expands to 
/home/hhlaing/Install/radius-June-21-configs/log/radius/radacct/192.168.10.118/auth-detail-20040707
  modcall[authorize]: module "auth_log" returns ok for request 39
  modcall[authorize]: module "chap" returns noop for request 39
  modcall[authorize]: module "mschap" returns noop for request 39
rlm_realm: No '@' in User-Name = "user_1", looking up realm NULL
rlm_realm: No such realm "NULL"
  modcall[authorize]: module "suffix" returns noop for request 39
  rlm_eap: EAP packet type response id 2 length 11
  rlm_eap: No EAP Start, assuming it's an on-going EAP conversation
  modcall[authorize]: module "eap" returns updated for request 39
users: Matched user_1 at 104
  modcall[authorize]: module "files" returns ok for request 39
modcall: group authorize returns updated for request 39
  rad_check_password:  Found Auth-Type EAP
auth: type "EAP"
  Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 39
  rlm_eap: EAP Identity
  rlm_eap: processing type tls
  rlm_eap_tls: Initiate
  rlm_eap_tls: Start returned 1
  modcall[authenticate]: module "eap" returns handled for request 39
modcall: group authenticate returns handled for request 39
Sending Access-Challenge of id 5 to 192.168.10.118:1814
EAP-Message = 0x010300061920
Message-Authenticator = 0x
State = 0xbffaa2e18c3fe0a78e5183ee7aee01ac
Proxy-State = 0x313635
Finished request 39
Going to the next request
Thread 5 waiting to be assigned a request
--- Walking the entire request list ---
Cleaning up request 39 ID 5 with timestamp 40ec8b45
Nothing to do.  Sleeping until we see a request.

rad_recv: Access-Request packet from host 192.168.10.118:1814, id=4, length=315
--- Walking the entire request list ---
Waking up in 31 seconds...
Thread 3 got semaphore
Thread 3 handling request 7, (2 handled so far)
Framed-MTU = 1466
NAS-IP-Address = 192.168.10.113
NAS-Identifier = "D-link Corp. Access Point"
User-Name = "user_1"
Service-Type = Framed-User
NAS-Port = 65
NAS-Port-Type = Wireless-802.1

RE: problem with proxying using fail_over setup

2004-07-07 Thread Htin Hlaing 
Thanks for that info Alan.  That makes sense.  Also,  what I was looking
for is that the second server set up will be tried automatically as the
first one is marked death.  But, it returns access-reject and the client
has to initiate authentication again while the first one is marked dead
for the dead time.  Any way for me to achieve what I am looking for?

Thanks,
Htin

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:freeradius-
> [EMAIL PROTECTED] On Behalf Of Alan DeKok
> Sent: Wednesday, July 07, 2004 2:04 PM
> To: [EMAIL PROTECTED]
> Subject: Re: problem with proxying using fail_over setup
> 
> "Htin Hlaing" <[EMAIL PROTECTED]> wrote:
> > However, the behavior that I see is it first marks the host
> > from a totally unrelated realm as dead first and then the one that
did
> > not answer as dead.
> 
>   It's not a totally unrelated realm.  It's a realm at the same IP
> address and port.
> 
>   The issue is that you have the same IP & port listed in two realms:
> engineering.verniernetworks.com and NULL.  This is not a supported
> configuration.
> 
>   Alan DeKok.
> 
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: problem with proxying using fail_over setup

2004-07-07 Thread Alan DeKok 
"Htin Hlaing" <[EMAIL PROTECTED]> wrote:
> However, the behavior that I see is it first marks the host
> from a totally unrelated realm as dead first and then the one that did
> not answer as dead.

  It's not a totally unrelated realm.  It's a realm at the same IP
address and port.

  The issue is that you have the same IP & port listed in two realms:
engineering.verniernetworks.com and NULL.  This is not a supported
configuration.

  Alan DeKok.

- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html