No, not "radius-acct" section. with RADIUS config I'm mean the radius server config. My problem detail: 1. Kannel get account request from NAS properlly. 2. Kannel succesfully forward that request to radius server 3. Kannel got responce from radius server. but radius server do not autorize accounting request. May be I need configure radius server for forwarding autorization responce to NAS directly? (but how?)
> Hi, Yury. > I didn't undestand your problem. > And what you mean "RADIUS config"? > Is it kannel "radius-acct" section? > Yury Mikhienko wrote: > > 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"
