Re: radius accounting proxy usage

Hi Stipe,

Yes- you are correct in your assumptions of my broken explanation of
the setup.  "with parent" is that there is a native RADIUS server.

I will do a build using the cvs versions of the radius code and test it again.

This is how our setup also looks (as you have it):
  APN <--acct pdu--> kannel <--acct pdu--> RADIUS

Please confirm for me:
- the RADIUS authentication message still go to the native RADIUS server
- only the RADIUS accounting messages are sent to my kannel server for
proxy to the real RADIUS server


On 11/22/05, Stipe Tolj <[email protected]> wrote:
> 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/
> -------------------------------------------------------------------
>