Date: Thu, 21 Dec 2006 10:45:29 -0500 From: Troy Settle <troy@psknet.com> To: Jeremy Tregunna <jtregunna@blurgle.ca> Cc: freebsd-isp@freebsd.org Subject: Re: RADIUS/PPPoE Dead Connections Message-ID: <458AAC19.3030404@psknet.com> In-Reply-To: <37692.24.122.21.214.1166656631.squirrel@secure.interplex.ca> References: <2004672F-664F-4331-A09F-D09A0C9DD99E@blurgle.ca> <56245.24.122.21.214.1166649785.squirrel@secure.interplex.ca> <6FA799B6-ED28-47A5-9A45-E90C86280A65@blurgle.ca> <37692.24.122.21.214.1166656631.squirrel@secure.interplex.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-isp >>>> To unsubscribe, send any mail to "freebsd-isp- >>>> unsubscribe@freebsd.org" >>>> >>>> >>> -- >>> Dominic Blais >>> Administrateur réseau >>> Interplex Télécom Inc. >>> http://www.interplex.ca >>> >>> >>> >>> !DSPAM:4589a963678325368818224! >>> >>> >> > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?458AAC19.3030404>