Re: RADIUS/PPPoE Dead Connections

Jeremy,

I have the same problem with Mikrotik's implementation of pppoe on RouterOS. For whatever reason, I miss more STOP records than I receive. I overcame this by having the MT box send update records every 5 minutes, and since all my accounting data is written to SQL in real time, I can use a view to see who's online. With a little logic, I was able to weed out the stale sessions by excluding records that hadn't been updated within the last 10 minutes. I then use this view to figure out if a user is connected or not for concurrency control.

Worst case for me, is that I lose a few minutes of bandwidth data. Worst case for my users, is that they can't log back in for up to 10 minutes. Haven't had any complaints yet.

I wish I had some the time and skill to dig into the code for PPP to ensure that a stop record gets sent no matter what. I was going to blame this on the UDP packet getting lost, but after 10 years of using radius, I'm fairly confident that it's the implementation, not the protocol that's to blame for this.

--
Troy Settle
Pulaski Networks
http://www.psknet.com
866.477.5638



Dominic Blais wrote:
If your radius server has an sql backend, change the sql request so that
it accepts the person if it's the same mac address as the last person that
was connected with the same account. This is a good behaviour to avoid
problems but you should keep on finding your solution... this is just a
workaround..



On 20-Dec-06, at 4:23 PM, Dominic Blais wrote:

Try mpd instead of ppp, great performances... we're using it as a
pppoe
concentrator for more than 100 simultaneous connections..
That's fine and dandy, but I've already got this box deployed, and I
don't like making major changes mid-stream. Unless I can guarantee
that mpd won't suffer this same issue, I'm not interested in even
considering changing, I'm more interested in fixing my problem.

Regards;

Jeremy Tregunna

See /usr/ports/net/mpd

mpd4 is beta, don't try it for production.



I've got a FreeBSD NAS and a FreeBSD RADIUS server (both running 6.1)
serving up access to a wireless network. In any event, everything
seems to work peachy when a user logs in and disconnects manually.
But if for instance, someone closes the lid on their laptop and their
wireless card powers off due to standby mode, the connection to the
NAS is broken and the disconnect request never makes it from the NAS
to the RADIUS server to inform it that the client went offline.

Now then, I'm not so much worried about that stale entry staying on
the RADIUS server until the user tries to log in again (I don't care
much about time used, only bandwidth numbers); but ultimately it
would be nice to have one of two solutions:

(1) A user tries to log in when he's already logged in, have it
disconnect that user and then log in; or
(2) Have the NAS send a Disconnect-Request to the RADIUS server
when--
as in the above example--someone closes the lid on their laptop.

An idle timeout isn't a workable solution for me, neither is a
session timeout; I need both to have no fixed limit for all clients.

My ppp.conf file is basically defined as:

### ppp.conf begin

default:
set log Chat Command Phase
enable pap
allow mode direct
enable proxy
disable ipv6cp
set radius /etc/radius.conf
set mru 1492
set mtu 1492
accept dns

### end ppp.conf

The relevant users portion is like:

DEFAULT Auth-Type := System
Service-Type := Framed-User,
Framed-Protocol := PPP,
Framed-IP-Address := 192.168.8.50,
Framed-IP-Netmask := 255.255.255.0,
Framed-Routing := Broadcast-Listen,
Framed-MTU := 1492

And the relevant portions of attrs is like:

DEFAULT
Service-Type == Framed-User,
Framed-Protocol == PPP,
Framed-MTU == 1492,
Framed-Filter-ID =* ANY,
Reply-Message =* ANY,
Session-Timeout == 0,
Idle-Timeout == 0,
Port-Limit <= 2

Any assistance would be greatly appreciated.

Regards,

Jeremy Tregunna



_______________________________________________
freebsd-isp@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isp
To unsubscribe, send any mail to "freebsd-isp-
unsubscribe@xxxxxxxxxxx"

--
Dominic Blais
Administrateur réseau
Interplex Télécom Inc.
http://www.interplex.ca



!DSPAM:4589a963678325368818224!



_______________________________________________
freebsd-isp@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isp
To unsubscribe, send any mail to "freebsd-isp-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: RADIUS/PPPoE Dead Connections
    ... concentrator for more than 100 simultaneous connections.. ... NAS is broken and the disconnect request never makes it from the NAS ... to the RADIUS server to inform it that the client went offline. ... Framed-Protocol:= PPP, ...
    (freebsd-isp)
  • Re: RADIUS/PPPoE Dead Connections
    ... But if for instance, someone closes the lid on their laptop and their wireless card powers off due to standby mode, the connection to the NAS is broken and the disconnect request never makes it from the NAS to the RADIUS server to inform it that the client went offline. ... Framed-Protocol:= PPP, ...
    (freebsd-isp)
  • Re: RADIUS/PPPoE Dead Connections
    ... My apologies, I just did some local testing here at home using it, and although the setup isn't exactly the same, it's close enough for testing purposes. ... NAS is broken and the disconnect request never makes it from the NAS ... to the RADIUS server to inform it that the client went offline. ... Framed-Protocol:= PPP, ...
    (freebsd-isp)
  • Re: RADIUS/PPPoE Dead Connections
    ... I've got a FreeBSD NAS and a FreeBSD RADIUS server ... NAS is broken and the disconnect request never makes it from the NAS ... Framed-Protocol:= PPP, ...
    (freebsd-isp)
  • Re: RADIUS/PPPoE Dead Connections
    ... You should be getting your accounting data regardless, when the session expires. ... But if for instance, someone closes the lid on their laptop and their wireless card powers off due to standby mode, the connection to the NAS is broken and the disconnect request never makes it from the NAS to the RADIUS server to inform it that the client went offline. ... Framed-Protocol:= PPP, ...
    (freebsd-isp)