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: > > [EMAIL PROTECTED] 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"
