Re: [PATCH] [CFT] [RFC] [WIP] Next series

I also would like mention, that current radius implementetion not always 
working properly. Sometimes we get incorrect mappings and as a result clients 
get other clients MSISDN's. That situation is fatal when services are 
dependent on MSIDN, for example MMS.
From my point of view, Paul's implementetion is more cleaner. But there is 
also disadvantage: hard dependency to FreeRadius. 


On Thursday 06 May 2004 15:52, Paul P Komkoff Jr wrote:
> OK, next step
> http://stingr.net/l/kannel-stingr-20040506.tar.bz2
> and
> http://sting.net/l/stingr-20040506.patch.gz (patch to current cvs)
>
> So what's up?
> Here I tried to remove serious limitation. It is a proof-of-concept
> hack, maybe the direction is totally wrong, but it works.
>
> * Preamble
> Many of us need MSISDNs. Not only for provisioning (e.g. substituting
> into http request header), but, and most, for internal debugging
> purposes and for accounting (to be shown in access log)
>
> Many of us running many wapboxes - to protect from crashes, to protect
> from slow and blocking gethostbyname calls, to protect from
> C10K-threaded-case gliches.
>
> * Current state
> wapbox can act as blind radius accounting proxy, extracting msisdn
> information from radius accounting packets and relaying it further, to
> real accounting device.
>
> This have the following limitation:
>   We need to setup proper chain of wapbox -> radius, and ensure hat
>   wapbox is always running - unachievable at this moment
>   When one of wapboxes in chain dies for some reason, chain is broken,
>   and accounting is no longer.
>
> This was the only motivation to further work
>
> * Proposed solution
>
> Yes, again, as with curl, I'm putting an external dependency in
> kannel! Now, to freeradius package.
>
> freeradius is another proven free package for doing radius
> authentication. I am using it here. Moreover, it can be used for
> proxying.
>
> I've written a small module for freeradius, which can store
> framed-ip-address to caller-id mappings in berkeleydb CDB
> (concurrent data store, single writer-many readers) environment.
>
> I written a complementary thing in kannel, which only doing lookups in
> that environment.
>
> * Installation
> Take tarball, or original kannel patched with provided patch, and
> compile it with --enable-cdb passed to configure
>
> Take freeradius-0.9.3 and extract rlm_dbutmp.tar.gz into its
> src/modules directory, and enable it when compiling.
>
> * Configuration
> in freeradius radiusd.conf
> #in modules config
> dbutmp {
> 	dbenv = /path/to/some/dir
> 	dbname = some-dbname
> }
>
> # in accounting {
> dbutmp
>
> # --- cut here ---
>
> in kannel.conf
>
> group = radius-acct
> dbenv = "/path/to/some/dir"
> dbname = "some-dbname"
>
> # --- cut here ---
>
> directory should be writable by bothradius and wapboxes.
>
> it will write in access log (if you have access logging enabled)
> msisdns enclosed in () just after IP address, or (-) if it cannot
> determine msisdn for some reason (it's off, improperly configured,
> radius is defunct etc.)
>
> You can run multiple wapboxes with dbenv and dbname pointing to the
> same place - it will work. It is designed for such setup :)
>
> * Downloading
>
> http://stingr.net/l/kannel-stingr-20040506.tar.bz2
> -or-
> http://stingr.net/l/stingr-20040506.patch.gz (patch to current cvs)
>
> and
> http://stingr.net/l/rlm_dbutmp.tar.gz (freeradius module)

-- 
David Chkhartishvili
MagtiCom Ltd.
Tel: +995 99 182418