Re: (RADIATOR) Port-Error
On Wed, 16 Oct 2002, Mohammed AbdusSami wrote: Following is the stop record of my accounting configuration. The cause of termination of this is PORT-ERROR. Can you please me what does it means. As Hugh sugested, this is really a NAS-specific issue. But... Mon Oct 14 04:12:16 2002 NAS-IP-Address = 212.26.73.240 NAS-Port = 132 NAS-Port-Type = Async User-Name = [EMAIL PROTECTED] Called-Station-Id = 3602428 Calling-Station-Id = 33610711 Acct-Status-Type = Stop Acct-Authentic = RADIUS Service-Type = Framed-User Acct-Session-Id = 000DDA8A Framed-Protocol = PPP Framed-IP-Address = 212.24.231.64 Acct-Terminate-Cause = Port-Error Acct-Input-Octets = 980238 Acct-Output-Octets = 9946394 Acct-Input-Packets = 11304 Acct-Output-Packets = 10777 Acct-Session-Time = 8201 Acct-Delay-Time = 0 Timestamp = 1034557936 Is this from a Cisco? If so, these snippages are probably relevant: ===8=== Date: Mon, 2 Apr 2001 08:35:24 -0700 From: Dennis Peng [EMAIL PROTECTED] To: Neale Banks [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Acct-Terminate-Cause = Port-Error ? Port Error indicates that there was a failure in PPP keepalives, ie we were sending out LCP echo requests, and didn't receive a LCP echo reply response 5 times in a row. Perhaps the lower layer already went away and this wasn't signalled properly? Or modem was retraining for a long time? It's hard to say. Is this is on an async interface? Keepalives are turned off by default on async interfaces, so I assume you have it enabled? Dennis ===8=== ===8=== Date: Mon, 02 Apr 2001 16:49:56 -0800 (PST) From: Aaron Leonard [EMAIL PROTECTED] To: Neale Banks [EMAIL PROTECTED] Cc: Dennis Peng [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Acct-Terminate-Cause = Port-Error ? On Mon, 2 Apr 2001, Dennis Peng wrote: Neale Banks [[EMAIL PROTECTED]] wrote: Definitely Async, it's even logged by RADIUS as NAS-Port-Type = Async. FWIW, the NAS is configured with virtual profiles enabled and is part of a stack. Oh, ok, it is enabled on vaccess interfaces by default. Since you are using virtual-profiles, everyone gets a vaccess interface, which means keepalives are enabled. You can turn it off with the no keepalive command on the vtemplate. Of course if you do so, you might mask a lower layer problem. But you might also be working around a buggy client. It's hard to say. Assuming that (a) everything is virtualised and (b) keepalives are a Good Thing for ISDN callers then the balance probably falls to leaving keepalive enabled? Alternatively, is there a compromise possible by relaxing the keepalive parameters? Yes, I think it's reasonable enough to relax the keepalive interval. Say, with an interval of 30s, then the call will drop after 3 minutes of nonresponsiveness from the peer. It's very unlikely that a modem link that hasn't responded for 3 minutes will ever recover. One downside of keepalives is that they may reset some idle timers. Hopefully (in current code) we've fixed all the places where IOS does this, but I believe that Windows will always reset its idle timer when it gets an LCP ECHOREQ. So you may be defeating your clients' idle timer settings (which could be an issue for them if they're paying per-minute charges.) And, yes I also suspect it's a buggy client (possibly a dodgy modem, possibly a marginal local-loop It's even possible that Windows has hung (perish the thought). Aaron ===8=== Further discussion of this should probably be directed to a NAS-oriented forum (e.g. http://www.cisco.com/warp/public/471/cisco-nas.html ). HTH, Neale. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) SQL Timeout?
Hello Griff -
The first thing to check is the MySQL logs to see what is happening
with the database.
Then you should probably turn on LogMicroseconds (requires Time-HiRes
from CPAN) to see how long the queries are taking and what is happening
when the problem occurs. It sounds like there is some large processing
job that is tying up the database server every 3 hours.
And as usual, a complete copy of the configuration file (no secrets)
and a trace 4 debug are needed to say any more.
regards
Hugh
On Wednesday, October 23, 2002, at 02:08 AM, Griff Hamlin wrote:
Hello,
I've noticed that about every 3 hours, I get an error message in my
logfile:
Tue Oct 22 02:03:03 2002: ERR: do failed for 'insert into dialupusage
(username, session_id, router_ip, date, session_time, ip_address,
phone)
values
('level3', '123410-22', '209.244.125.132', '2002-10-22
2:2:53', '0', '65.56.213.14', '9876543210')': SQL Timeout
and whenever I get this message, my server stops authenticating fast
enough. What's odd, is that if I run radpwtst and try to do a test
authentication, I'll get no reply after seeing this message until I
restart the radius server. But if I 'tail -f' my logfile, I see people
being authenticated, it's just getting to them maybe a minute or more
after the request comes in. Basically, the server gets behind in the
event it gets one of the SQL Timeout errors. My first question is, what
would cause that error, and secondly, why does it hang up Radiator?
The part of my radius.cfg file that handles accounting is as follows:
Handler Request-Type=Accounting-Request
RewriteUsername s/^([^@]+).*/$1/
# Hook for using correct termination field and some logging
PreAuthHook file:/etc/raddb/accounting.hook
AuthBy GROUP
AuthByPolicy ContinueUntilIgnore
AuthBy SQL
DBSourcedbi:mysql:localdialup
DBUsername %{GlobalVar:DbUser}
DBAuth %{GlobalVar:DbPass}
AccountingTable dialupusage
AccountingStopsOnly
Timeout 5
FailureBackoffTime 20
AcctColumnDef username, %U, formatted
AcctColumnDef session_id, %{Acct-Session-Id}%m-%d, formatted
AcctColumnDef router_ip, %c, formatted
AcctColumnDef date, %f-%g-%i %j:%k:%p, formatted
AcctColumnDef session_time, %{Acct-Session-Time}, formatted
AcctColumnDef ip_address, %{Framed-IP-Address}, formatted
AcctColumnDef phone, %{Calling-Station-Id}, formatted
AcctColumnDef terminate_cause, %{Term-Cause}, formatted
/AuthBy
AuthBy SQL
DBSource%{GlobalVar:DbServer}
DBUsername %{GlobalVar:DbUser}
DBAuth %{GlobalVar:DbPass}
AccountingStopsOnly
Timeout 5
FailureBackoffTime 20
AcctSQLStatement update users set
prepaid_timeleft=prepaid_timeleft-0%{Acct-Session-Time} where
(prepay='true')(username='%U')
AcctSQLStatement delete from online where
(((nasidentifier='%c')(nasport='%{NAS-
Port}'))||((username='%n')(callingid='%{Calling-Station-Id}')))
/AuthBy # SQL
/AuthBy # Group
AccountingHandled
/Handler
Griff Hamlin, III
Quik Internet
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
NB: I am travelling this week, so there may be delays in our
correspondence.
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
(RADIATOR) (Fwd) Last Call: Diameter Base Protocol to Proposed Standard
FYI, according to this message, the diameter protocol (the expected successor to radius) is being issued as a Proposed Standard RFC... The RFC should be available in a few days, anyway, it should't differ from the draft in http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-15.txt I've read a very early version of the draft (months ago) and it's a totally different beast... supposedly more flexible confiable, but time will tell... we also have to see what kind of support it gets from the NAS vendors... Regards --- Forwarded message follows --- To: IETF-Announce:; CC: [EMAIL PROTECTED] From: The IESG [EMAIL PROTECTED] Subject:Last Call: Diameter Base Protocol to Proposed Standard Reply-to: [EMAIL PROTECTED] Date: Tue, 22 Oct 2002 13:57:47 -0400 Sender: [EMAIL PROTECTED] The IESG has received a request from the Authentication, Authorization and Accounting Working Group to consider Diameter Base Protocol draft-ietf-aaa-diameter-15.txt as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2002-11-5. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-15.txt --- End of forwarded message --- -- Mariano Absatz El Baby -- I thought I wanted a career, turns out I just wanted pay checks. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Add IP from SQL table to AuthBy Radius Reply packet
Hi all, I'm trying to solve the following problem. Our radiator proxies authentication requests. Upon receiving the response from the remote radius server, we want to add an user-specific IP-address from our own SQL table. I'm considering the following approach: AuthBy Group Identifier proxy AuthByPolicy ContinueWhileAccept AuthBy Radius Host ... /AuthBy AuthBy SQL DBSource dbi:mysql:radius DBUsername ... DBAuth ... AuthSelect select ipaddress from tblAccess where username='%u' AuthColumnDef 0, GENERIC, reply /AuthBy /AuthBy However, due to the asynchronous behavior of AuthBy Radius this won't work. See also: http://www.open.com.au/archives/radiator/2001-04/msg00192.html http://www.open.com.au/archives/radiator/2002-08/msg00107.html I'm a bit reluctant to use the Synchronous parameter, since we cannot really trust the remote radius server. Another solution could be using a ReplyHook. However, this seems a bit cumbersome to me; writing a failure-back-off-fall-back procedure to multiple SQL-servers myself, while it is so nicely implemented in Radiators AuthBy SQL. Does anybody has a suggestion to overcome this problem? Cheers, Alexander dr. Alexander P. de Boer KPN Royal Dutch Telecom Room L C7, P.O.Box 421, 2260 AK Leidschendam The Netherlands === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
RE: (RADIATOR) Add IP from SQL table to AuthBy Radius Reply packet
You can call your AuthBy SQL from a ReplyHook making the whole thing easier than you might think. Examples are in goodies/hooks.txt. -Original Message- From: [EMAIL PROTECTED] [mailto:alexander.deboer;kpn.com] Sent: Wednesday, October 23, 2002 11:59 AM To: [EMAIL PROTECTED] Subject: (RADIATOR) Add IP from SQL table to AuthBy Radius Reply packet Hi all, I'm trying to solve the following problem. Our radiator proxies authentication requests. Upon receiving the response from the remote radius server, we want to add an user-specific IP-address from our own SQL table. I'm considering the following approach: AuthBy Group Identifier proxy AuthByPolicy ContinueWhileAccept AuthBy Radius Host ... /AuthBy AuthBy SQL DBSource dbi:mysql:radius DBUsername ... DBAuth ... AuthSelect select ipaddress from tblAccess where username='%u' AuthColumnDef 0, GENERIC, reply /AuthBy /AuthBy However, due to the asynchronous behavior of AuthBy Radius this won't work. See also: http://www.open.com.au/archives/radiator/2001-04/msg00192.html http://www.open.com.au/archives/radiator/2002-08/msg00107.html I'm a bit reluctant to use the Synchronous parameter, since we cannot really trust the remote radius server. Another solution could be using a ReplyHook. However, this seems a bit cumbersome to me; writing a failure-back-off-fall-back procedure to multiple SQL-servers myself, while it is so nicely implemented in Radiators AuthBy SQL. Does anybody has a suggestion to overcome this problem? Cheers, Alexander dr. Alexander P. de Boer KPN Royal Dutch Telecom Room L C7, P.O.Box 421, 2260 AK Leidschendam The Netherlands === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Bug
Hey Guys, Believe I have tripped across somewhere which could do with a bit more error checking I am able to reproduce it, but I'd prefer not to ;-) A previous configuration file that I upgraded to the new version of radiator was using formatted-date in an AcctColumnDef We use Oracle, and therefore have a to_date function that we call on Oracle, in order to conform to the Oracle date standards. The issue was, once running this on the new version of Radiator (because we were lacking the TimeDate perl module), the authentications were successful, and the accounting packets caused the Radiator server to restart (even on Trace5) by displaying: Wed Oct 23 09:57:02 2002: DEBUG: Handling with Radius::AuthSQL Wed Oct 23 09:57:02 2002: DEBUG: Reading users file /usr/local/etc/radiator//reject.users Wed Oct 23 09:57:02 2002: INFO: Server started: Radiator 3.3.1 on radius01 Just a note as there is no debugging to hint at what the problem was. As soon as TimeDate was installed, it was successful. Regards, Martin Edge Software/Network Engineer KBS Internet Phone: 1300 727 205 Web: http://www.kbs.net.au/ Extranet: http://xray.kbs.net.au/ eMail: [EMAIL PROTECTED] -=-=-=- === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) proxy radius
Hi I'm trying to setup proxy radius so it sends start/stop/acct records to downstream whilst retaing a copy for myself the relevent config lines are AuthBy RADIUS Host otherisp.net.au AcctPort 1646 AuthPort 1645 Identifier otherisp Retries 3 RetryTimeout 5 Secret xxx /AuthBy Handler Realm=otherisp.net.au AuthBy pap AuthBy otherisp AuthByPolicy ContinueAlways /Handler I'm seeing the correct details but the downstream isn't seeing anything. Would anyone have a clue what I have done wrong? _ (_)___ _ __ Mark Russell | / __| '_ \[EMAIL PROTECTED] | \__ \ |_) | http://www.isp.net.au |_|___/ .__/ph: 1300 304 288 |_| Broadband from $55 p/m (NSW Only) Dialup from $5.50 p/m (National) === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Session database
How would I modify my radwho.cgi / session database (dbm format), to show calledstationid and callingstationid? Rgds TDN === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Session database
Hello TDN - You should add the relevant columns to the session database table, and specify your own SQL queries. Have a look at section 6.7 in the Radiator 3.3.1 reference manual. regards Hugh On Wednesday, October 23, 2002, at 05:12 PM, [EMAIL PROTECTED] wrote: How would I modify my radwho.cgi / session database (dbm format), to show calledstationid and callingstationid? Rgds TDN === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. NB: I am travelling this week, so there may be delays in our correspondence. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) proxy radius
Hello Mark - This is because the AuthBy pap clause is accepting the accounting request before it is proxied. Try this: Handler Realm=otherisp.net.au AuthBy otherisp AuthBy pap AuthByPolicy ContinueAlways /Handler regards Hugh On Thursday, October 24, 2002, at 12:35 PM, Mark Russell wrote: Hi I'm trying to setup proxy radius so it sends start/stop/acct records to downstream whilst retaing a copy for myself the relevent config lines are AuthBy RADIUS Host otherisp.net.au AcctPort 1646 AuthPort 1645 Identifier otherisp Retries 3 RetryTimeout 5 Secret xxx /AuthBy Handler Realm=otherisp.net.au AuthBy pap AuthBy otherisp AuthByPolicy ContinueAlways /Handler I'm seeing the correct details but the downstream isn't seeing anything. Would anyone have a clue what I have done wrong? _ (_)___ _ __ Mark Russell | / __| '_ \[EMAIL PROTECTED] | \__ \ |_) | http://www.isp.net.au |_|___/ .__/ph: 1300 304 288 |_| Broadband from $55 p/m (NSW Only) Dialup from $5.50 p/m (National) === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. NB: I am travelling this week, so there may be delays in our correspondence. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
