Hi, Vjacheslav. Can you send me your worked NAS (may be RAS in additional) configuration (approximate of course)?
> Hi, Yury. > > There are two differnet things: accounting and authorization. > There are even differnet default ports (1813 and 1812). > So accounting packets has been not used for authorization. > You must be able to configure AUTH packets at NAS to go directly to RAS. > > > Yury Mikhienko wrote: > > 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"
