Hello Paul -
For problems like these (and most others come to that), I need to see the complete configuration file (no secrets), together with a trace 4 debug showing what happens in both cases. This is the *only* way that I can see what is going on and it is also the only way that I can accurately reproduce the problem in a test setup. Otherwise I am basically just guessing and that is of no use to you nor anyone else in all probability. BTW - it does sound like the reply from Radiator is not getting back to the client device, so you should probably check firewall rules and router filters between the Radiator host and remote client. regards Hugh On Fri, 7 Jun 2002 18:04, Paul Culmsee wrote: > Hi > > Now this is really weird. I have a happy (but relatively complex) radiator > config. One of the <client> clauses refers to a remote Radius proxy that we > receive requests from. I recently added the following config to the global > config. > > <StatsLog SQL> > Interval 900 > > DBSource dbi:ODBC:ControlCentre > DBUsername [snip] > DBAuth [snip] > > InsertQuery insert into RadiatorStatistics (Timestamp, Type, ObjectName, > accessAccepts, accessChallenges, accessRequests, \ > accessRejects, accountingRequests, accountingResponses, > badAuthAccessRequests, badAuthRequests, badAuthAccountingRequests, \ > droppedAccessRequests, droppedAccountingRequests, droppedRequests, > dupAccessRequests, dupAccountingRequests, duplicateRequests, \ > malformedAccessRequests, malformedAccountingRequests, proxiedNoReply, > proxiedRequests, requests, responseTime) \ > values (%0, '%1', '%2', %3, %4, %5, %6, %7, %8, %9, %10, %11, %12, %13, > %14, %15, %16, %17, %18, %19, %20, %21, %22, %23) > > </StatsLog> > > Now after adding this suddenly I was seeing ODBC errors in a handler but > nothing to do with the table referred to above. > > What was happening was that a valid stop record was coming from the > aforementioned radius proxy client and my logs show radiator happily > processing it. It then sends an ack reply back to this remote radius proxy. > 10 seconds later in comes another stop record for the same user (the remote > NAS has missed our reply it seems). So radiator happily processes it again, > but this time there is an ODBC problem with duplicate primary keys. (AUTHBY > EMERALD) It logs another ACK anyway back to the proxy. Then 10 seconds > later attempt 3 comes back - same stop record. Again radius sends an ack > but it seems that the remote NAS doesn't receive it. > > Now it would seem that the changes I made should have nothing to do with > the sending/processing of stop records. but once I removed the abvoe > config, everything went back to normal again. I tried it again and the same > thing happened. > > I am running Radius 3.0 with a couple of patches. > > Is this a known bug? > > cheers > > Paul > > > === > 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: 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.