Copy-acct-to-home-server Issue

[Ricardo Larrañaga]

Hey Alan, thank you for your help.
What do you mean by "making the system more robust"? I thought that using
tcp would do that, unless you are talking about using master-master
replication on the db?
Since we were talking about the radius protocol being intrinsically error
prone, y dont know if i understand what you mean by making the system more
robust.

For example, in an smp system, packets might get reordered on reception,
and i wouldnt see that as lack of robustness.

In my case, i have servers directly connected to switches that show clean
interfaces, so i am not sure what else i could do to increase robustness.
Thanks a lot.
Regards
On Jul 10, 2015 5:54 PM, "Alan DeKok" <aland at deployingradius.com> wrote:

> On Jul 10, 2015, at 4:06 PM, Ricardo Larrañaga <
> ricardo.larranaga at gmail.com> wrote:
> >> Or, they're received in a different order, and that causes problems.
> >
> > Could you explain a little bit more what kind of problems could this
> cause?
>
>   Account sessions go start / update / update / stop.  If the packets are
> received in a different order, things can go wrong.
>
> > Is it receiving packets in a different order for that user/session, or
> just
> > receiving packets in a different order from that server?
>
>   All of that.
>
> > I would like to see it there is a way to minimize this behaviour. I read
> > that the server has support for radius over tcp. I don't know anything
> > about it, but woud it be possible to proxy between servers over tcp?
> Would
> > that solve the reordering issue?
>
>   Maybe.  But I wouldn't bother.  Making the system robust will be better
> in the long run.
>
> >> Why?  Just run the script once, and have it write RADIUS packets to a
> > > detail file.  Those can be replicated to every server.
> >
> > This was my first idea all along, and i have the code ready. i ran into
> an
> > issue though, I started using the server with the default calculation for
> > unique accounting session:
> >
> > Acct-Unique-Session-Id :=
> >
> "%{md5:%{User-Name},%{Acct-Session-ID},%{%{NAS-IPv6-Address}:-%{NAS-IP-Address}},%{NAS-Identifier},%{NAS-Port-ID},%{NAS-Port}}"
> >
> > Now, the problem that i have is that some of my NAS send both NAS-port
> and
> > NAS-Port-ID. Nas-port is not on the accounting database, so i cannot
> really
> > add it to the attribute, and that makes the accounting session ID
> > different. I would also prefer not to add it, as i dont use it for
> anything.
>
>   If the Acct-Session-Id attribute is unique, you can just use that, and
> ignore Acct-Unique-Session-Id.
>
> > The options that i see are:
> >
> > -Force all my NAS to not sent NAS-port (I am working on this, but it is
> not
> > solved yet. I am not sure how to do it yet, or if it is possible)
>
>   Maybe.
>
> > -Change the calculation so it does not include the nas-port attribute.
> This
> > would be my preferred option, but in order to do this (since i already
> have
> > sessions opened), i also need to update my database with the new
> > calculation. How is that md5 calculated? Is it a plain md5 of the
> > concatenation of the fields?
>
>   Yes.  See the debug output. It prints out the input to the MD5, and the
> output MD5 hash.
>
>   Alan DeKok.
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html