Hello Dave -
Here is the message: Sat Mar 9 09:37:10 2002: DEBUG: Packet dump: *** Received from 127.0.0.1 port 33555 .... and yes - it is telling you the *source* IP address and UDP port number from which this request was received. I have been thinking about adding the *destination* IP address and port number to the message just to make it clearer what is going on. Thoughts? regards Hugh On Sat, 9 Mar 2002 00:37, Dave Kitabjian wrote: > Just one thought: > > I haven't been reading this thread in all its detail, but this might be > of some value. Some time back, I believe when we transitioned from USR > to Cisco NASes, we started getting log entries such as: > > *** Received from X.X.X.X on port 1645 > > when we were definitely only listening on ports 1812/1813. I posted this > to the list back then, so you might find it in the archive. I think Hugh > might have said something to the effect that the 1645 might be the > OUTGOING port from the client rather than the server's listening port, > but that doesn't sound right to me. I'm still curious about why this > happens. > > Dave > > > -----Original Message----- > > From: Jim Liebgott [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, March 07, 2002 6:33 PM > > To: [EMAIL PROTECTED] > > Cc: Ronan Eckelberry; [EMAIL PROTECTED] > > Subject: Re: (RADIATOR) unknown ports > > > > Hugh Irvine wrote: > > > Thanks for sending the configuration file. > > > > > > Each AuthBy RADIUS clause opens a port at initialisation > > > > time to send > > > > > and receive requests to the target proxy host. The portnumber is > > > allocated by the OS unless overridden with the OutPort > > > > parameter, and > > > > > the port is held open during the whole time that Radiator > > > > is running. > > > > > Have a look at the code in "Radius/AuthRADIUS.pm". > > > > I see. That makes sense to me. Thanks for explaining. I > > had assumed that each new request opened a new socket to the > > proxy host and closed it when a reply was received. I > > imagine that you have reduced per-request overhead with your > > implementation. > > > > > On Fri, 8 Mar 2002 09:58, you wrote: > > > > Hugh Irvine wrote: > > > > > The only ports that Radiator opens by default are the > > > > > authentication and accounting ports. Any other ports > > > > that you see > > > > > > > will be the result of your configuration file. > > > > > > > > > > As Ronan says, if you send me a copy of your configuration file > > > > > (no > > > > > secrets) I will take a look. > > > > > > > > I have attached my config file. It uses an "include" > > > > directive to > > > > > > run a program to generate more config, so I have attached that > > > > program as well. The config info generated by the program only > > > > contains <Client> directives. > > > > > > > > > On Fri, 8 Mar 2002 07:35, Ronan Eckelberry wrote: > > > > > > Really? What does your config look like? I'm not sure what > > > > > > time it is in Australia probably between 3-5am, but when Hugh > > > > > > gets in he will probably have the answer. Hugh > > > > usually has the > > > > > > > > answers. He will probably ask for a copy of your config (no > > > > > > secrets) and a Trace 5 debug from you log. > > > > > > > > > > > > That's weird. You may have something in your > > > > config that > > > > > > > > is opening those ports. > > > > > > > > > > > > -Ronan > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Jim Liebgott [mailto:[EMAIL PROTECTED]] > > > > > > Sent: Thursday, 07 March, 2002 15:03 > > > > > > To: Ronan Eckelberry > > > > > > Cc: [EMAIL PROTECTED] > > > > > > Subject: Re: (RADIATOR) unknown ports > > > > > > Importance: High > > > > > > > > > > > > Ronan Eckelberry wrote: > > > > > > > And you only see these ports open when you > > > > are running > > > > > > > > Radiator. > > > > > > > > > > > > > If you kill radiusd, the ports are no longer open? > > > > > > > > > > > > indeed. Furthermore, I use the "-p" option to netstat, which > > > > > > displays the process ID that has bound a given port, > > > > and those > > > > > > > > ports are conclusively bound by the radiusd daemon process. > > > > > > > > > > > > As an update, it looks like the socket bindings are more > > > > > > persistent than I thought. They don't change after a > > > > day; I was > > > > > > > > mistaken when I said that earlier. I haven't seen > > > > these sockets > > > > > > > > close and re-open like I previously indicated, I was > > > > confusing > > > > > > > > the port numbers from two different servers. On each server, > > > > > > the sockets bindings haven't changed. > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Jim Liebgott [mailto:[EMAIL PROTECTED]] > > > > > > > Sent: Thursday, 07 March, 2002 14:30 > > > > > > > To: Ronan Eckelberry > > > > > > > Cc: [EMAIL PROTECTED] > > > > > > > Subject: Re: (RADIATOR) unknown ports > > > > > > > > > > > > > > Ronan Eckelberry wrote: > > > > > > > > Most likely those ports are opened to communicate > > > > > > > > with the > > > > > > > > > > > > > > other > > > > > > > > > > > > > > > RADIUS and/or SQL servers that you are proxying to. Do a > > > > > > > > netstat to > > > > > > > > > > > > > > see > > > > > > > > > > > > > > > what addresses that they are connected to. You will > > > > > > > > probably see > > > > > > > > > > > > that > > > > > > > > > > > > > > it is the other servers. RADIUS RECEIVES > > > > Authentication and > > > > > > > > > Accounting > > > > > > > > > > > > > > > requests on 1645 and 1646 (Or whatever ports you > > > > configure > > > > > > > > > > in your > > > > > > > > > > > > cfg > > > > > > > > > > > > > > file), but for it to proxy the info, it will have > > > > to open up > > > > > > > > > > another connection on another port to connect to > > > > the other > > > > > > > > > > RADIUS servers. > > > > > > > > > > > > > > You > > > > > > > > > > > > > > > will probably see that they are connecting to another > > > > > > > > address on > > > > > > > > > > > > port > > > > > > > > > > > > > > 1645 or 1646. > > > > > > > > > > > > > > According to netstat, for each of the unusual ports > > > > that I see > > > > > > > > > open, > > > > > > > > > > > > the > > > > > > > > > > > > > Remote address is "0.0.0.0.*", which on my linux system > > > > > > > indicates that the port is bound locally and accepting > > > > > > > connections. UDP ports that > > > > > > > > > > > > are > > > > > > > > > > > > > bound on both ends rarely show up in netstat, > > > > because they are > > > > > > > > > ephemeral. These port bindings are persistent, > > > > lasting about > > > > > > > > > a day. > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: [EMAIL PROTECTED] > > > > > > > > [mailto:[EMAIL PROTECTED]] > > > > > > > > > > > > > > On > > > > > > > > > > > > > > > Behalf Of Jim Liebgott > > > > > > > > Sent: Thursday, 07 March, 2002 13:21 > > > > > > > > To: [EMAIL PROTECTED] > > > > > > > > Subject: (RADIATOR) unknown ports > > > > > > > > > > > > > > > > I use Radiator 2.18.3. I noticed that the server > > > > binds to > > > > > > > > > > three UDP ports that aren't listed in my > > > > configuration, and > > > > > > > > > > appear to have > > > > > > > > > > > > > > random > > > > > > > > > > > > > > > port numbers (all greater than 1024). I am using > > > > both the > > > > > > > > > > authentication and accounting features, and I use <AuthBy > > > > > > > > RADIUS> to proxy authentication requests. In the current > > > > > > > > incarnation of the daemon, it is bound to 1645 and 1646 > > > > > > > > (which is expected because I > > > > > > > > > > > > use > > > > > > > > > > > > > > those for authentication and accounting) and also 2837, > > > > > > > > 2789, and > > > > > > > > > > > > > > 1443. > > > > > > > > > > > > > > > It seems that there are always three ports, but the port > > > > > > > > numbers > > > > > > > > > > > > > > change > > > > > > > > > > > > > > > over time (it takes perhaps a day to notice a > > > > change). Is > > > > > > > > > > this a > > > > > > > > > > > > > > normal > > > > > > > > > > > > > > > part of a radius server and/or a normal part of > > > > Radiator? > > > > > > > > > > It seems > > > > > > > > > > > > a > > > > > > > > > > > > > > bit strange to me that the server is bound to ports that > > > > > > > > don't > > > > > > > > > > > > appear > > > > > > > > > > > > > to > > > > > > > > > > > > > > > be in use. > > > > > > > > === > > > > > > > > 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: 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. > > > > > -- > > > 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: 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.
