Re: radius accounting proxy usage
Stipe Tolj <[email protected]>
| Newsgroups | gmane.comp.mobile.kannel.devel |
|---|---|
| Organization | The Kannel Group |
| Message-ID | <[email protected]> |
Hi Deon, the RADIUS proxy code is my work ;)... will try to assist. Deon van der Merwe wrote: > > We are running kannel 1.4.0 on FC4. Subscribers are accessing the > system over GPRS. Recently we have the need to add the subscribers > MSISDN into the HTTP headers. For this we then use the > radius-accounting configuration option. > > Have been trying to get it up and running, but has some issues with it. > - looks like it can run in one of 2 modes: > + without a "parent" > + with a "parent" not clear what you mean with the terms with/witout "parent"? Please describe in more detail. Ok, obviously you mean with "parent" a native RADIUS daemon that get's the proxied PDUs, right? > Without a parent: > - we see the packets come in > - we see kannel parse/process etc. the packet > - we see kannel send a response packet > - the APN has some problem with the response as they resend the > radius-acct packet ok, which means kannel does proxy the acct packets, but as it responds on the one side towards the APN, the APN dislikes the response and re-transmits the UDP packets (acct PDUs), right? > With a parent: > - we see the packets come into the server (with tcpdump) > - kannel does not read the packets or process it > - the receive queue of the tcp (udp) buffer just grows with every request. ??? RADIUS PDUs come via UDP datagrams. Actually if you address the RADIUS server from the APN directly, kannel will never come into play. > So, my question is this then: > - is anyone else using this feature? yep, we use/used this in our MMSC environment. Where MSISDN provisioning was required to "hard" identify the senders MSISDN. > - are we using it in the correct way? the setup is as follows: APN <--acct pdu--> kannel <--acct pdu--> RADIUS so from the point of view from APN kannel is the RADIUS server, and from the point of view of the "real" RADIUS server kannel is the APN.... hence you have a proxy chain. > - has there been updates in CVS that we should take a look at? now, this depends on what version you are using. There has been a major fix 7 months ago: 2005-04-07 Stipe Tolj <[email protected]> * radius/radius_[acct|pdu].c: fixing bug #208, which caused a wrong computing of the MD5 authenticator of the NAS acct packet. Thanks a lot to Vincenzo <[email protected]> for bug report and also fix. This was a very stupid interpretation of the RFC2866 by me. I'd suggest you update your local cvs version or better checkout a fresh one. > Anyone with experience on this feature, please advice? Please checkout a current cvs version and retry, the "with parent" version. If you still see re-transmissions of the APN, please provide us with a debug-log level logfile as attachement to have a closer view into it. Stipe mailto:stolj_{at}_wapme-group.de ------------------------------------------------------------------- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf, NRW, Germany phone: +49.211.74845.0 fax: +49.211.74845.299 mailto:info_{at}_wapme-systems.de http://www.wapme-systems.de/ -------------------------------------------------------------------