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/
-------------------------------------------------------------------
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.