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@deployingradius.com> wrote:
On Jul 10, 2015, at 4:06 PM, Ricardo Larrañaga < ricardo.larranaga@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