(RADIATOR) unknown ports

[Ronan Eckelberry]

	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:jliebgot at eni.net] 
Sent: Thursday, 07 March, 2002 15:03
To: Ronan Eckelberry
Cc: radiator at open.com.au
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:jliebgot at eni.net]
> Sent: Thursday, 07 March, 2002 14:30
> To: Ronan Eckelberry
> Cc: radiator at open.com.au
> 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: owner-radiator at open.com.au [mailto:owner-radiator at open.com.au]
> On
> > Behalf Of Jim Liebgott
> > Sent: Thursday, 07 March, 2002 13:21
> > To: radiator at open.com.au
> > 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 radiator-announce at open.com.au
> > To unsubscribe, email 'majordomo at open.com.au' with
> > 'unsubscribe radiator' in the body of the message.

===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.