Re:Radius accounting proxy thread. (need help)

Hi Vjacheslav !
Can you send me your RADIUS config, for example?

I as yet not configure the NAS-KANNEL-RADIUS scheme for this time :((
RADIUS did not autorize request from NAS (forwarding from kannel)
my logs:
...
2003-09-30 16:44:23 [1] INFO: RADIUS PDU type: Accounting_Request
2003-09-30 16:44:23 [1] INFO: RADIUS: Mapping `172.16.188.2 <-> 7xxxxxxxxxx' for session id <0033FDED> added.
/************ FORWARD DATA to RADIUS *****************************/
2003-09-30 16:44:23 [1] INFO: RADIUS: Got data from remote RADIUS <1.1.1.3:1813>
2003-09-30 16:44:23 [1] DEBUG: Octet string at 131d58:
2003-09-30 16:44:23 [1] DEBUG:   len:  20
2003-09-30 16:44:23 [1] DEBUG:   size: 21
2003-09-30 16:44:23 [1] DEBUG:   immutable: 0
2003-09-30 16:44:23 [1] DEBUG:   data: 05 d9 00 14 a1 2b 54 d0 0e f8 a1 68 95 d9 55 09   .....+T....h..U.
2003-09-30 16:44:23 [1] DEBUG:   data: c9 28 a5 f6                                       .(..
2003-09-30 16:44:23 [1] DEBUG: Octet string dump ends.
2003-09-30 16:44:23 [1] DEBUG: RADIUS: Mapping table contains 1 elements
2003-09-30 16:44:23 [1] DEBUG: RADIUS: Session table contains 1 elements
2003-09-30 16:44:23 [1] DEBUG: RADIUS: Client table contains 1 elements
...

> Hi, list.
> 
> There are some problems in current radius account proxy implementation.
> First, as I mentioned before, is that Kannel RADIUS accounting proxy
> _allways_ forward incoming packets to somewhere (default localhost).
> I don't undestand why? In many cases kannel is the end point for these packets.
> I think that if remote_host not defined, then packets must not be forwarded.
> 
> Second problem is blocking read from UDP sockets. So if you start wapbox and
> then try to stop it, it waits for for packet from RAS forever:
> 
> 2003-10-03 10:03:58 [0] DEBUG: Waiting for 1 (radius/radius_acct.c:proxy_thread) 
> to terminate
> 
> And strace show us that wapbox wait data on socket:
> 
> [wapgw@vasdevel wapgw]$ strace -p18071
> recvfrom(11,  <unfinished ...>
> 
> Attached patch solve both problems. Please look at it.
> I send two patches:
> 1) radius_accnt.patch - functionality patch
> 2) radius_accnt_style.patch with style modifications for patched radius_acct.c 
> according doc/CodingStyle document. (can be apllied only after first patch)
> 
> And I still have some questions.
> 1. Persistent storage for mapping.
> 2. Why session and client table not cleaned when accounting "stop" packet received:
> 2003-10-06 14:09:11 [1] DEBUG: RADIUS: Mapping table contains 5 elements
> 2003-10-06 14:09:11 [1] DEBUG: RADIUS: Session table contains 53 elements
> 2003-10-06 14:09:11 [1] DEBUG: RADIUS: Client table contains 53 elements
> 
> Is it a bug or planned behavior?

-- 
 
Best regards,
Yury Mikhienko.
IT ERP group head, ZAO "Mobicom-Kavkaz"


-- 
 
Best regards,
Yury Mikhienko.
IT ERP group head, ZAO "Mobicom-Kavkaz"