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/
-------------------------------------------------------------------
