Re: [RADIATOR] BindAddress question
On 14/06/2011 15:21, Heikki Vatiainen wrote: > Linux also has this special file to control the system wide behaviour: > > /proc/sys/net/ipv6/bindv6only > If I do this to enable the option: > echo 1 |sudo tee /proc/sys/net/ipv6/bindv6only > > the same configuration works: > > BindAddress ipv6:::, 0.0.0.0 Works for me too! Thanks :-) -- Dyonisius Visser System & Networking Engineer TERENA Secretariat Singel 468 D, 1017 AW Amsterdam The Netherlands T +31 20 530 44 88 F +31 20 530 44 99 vis...@terena.org | www.terena.org smime.p7s Description: S/MIME Cryptographic Signature ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] BindAddress question
Awesome reply Heikki, thanks!
I recommend you add an IPv6 section to the pdf documentation including this!
Am 2011-06-14 15:21, schrieb Heikki Vatiainen:
> On 06/14/2011 11:45 AM, Alexander Hartmaier wrote:
>> Does this mean that we can't bind to IPv4 and IPv6 separately on Linux
>> to not get v6 mapped v4 addresses?
> I think the mapped addresses are only seen when a wildcard IPv6 bind is
> done. If you bind to a non-wildcard IPv4 or IPv6 address, you should
> only see traffic that arrived over IPv4 or IPv6, respectively.
>
> To control the mapped addresses, there is IPV6_V6ONLY socket option, see
> http://tools.ietf.org/html/rfc3493#section-5.3 for more
>
> Linux also has this special file to control the system wide behaviour:
>
> /proc/sys/net/ipv6/bindv6only
>
> By default this seems to be 0. When it is 0, this will not work:
>
> BindAddress ipv6:::, 0.0.0.0
>
> The result in logs is this:
>
> Tue Jun 14 16:15:07 2011: DEBUG: Creating authentication port ipv61645
> Tue Jun 14 16:15:07 2011: DEBUG: Creating accounting port ipv61646
> Tue Jun 14 16:15:07 2011: DEBUG: Creating authentication port 0.0.0.0:1645
> Tue Jun 14 16:15:07 2011: ERR: Could not bind authentication socket:
> Address already in use
> Tue Jun 14 16:15:07 2011: DEBUG: Creating accounting port 0.0.0.0:1646
> Tue Jun 14 16:15:07 2011: ERR: Could not bind accounting socket: Address
> already in use
>
> If I do this to enable the option:
> echo 1 |sudo tee /proc/sys/net/ipv6/bindv6only
>
> the same configuration works:
>
> BindAddress ipv6:::, 0.0.0.0
>
> Tue Jun 14 16:16:20 2011: DEBUG: Creating authentication port ipv61645
> Tue Jun 14 16:16:20 2011: DEBUG: Creating accounting port ipv61646
> Tue Jun 14 16:16:20 2011: DEBUG: Creating authentication port 0.0.0.0:1645
> Tue Jun 14 16:16:20 2011: DEBUG: Creating accounting port 0.0.0.0:1646
>
> When I used radpwtst to send requests to ipv6:::1 or 127.0.0.1 these
> Client clauses were matched, respectively:
>
>
> Identifier ipv6-loopback
> Secret mysecret
> DupInterval 0
>
>
> Identifier ipv4-loopback
> Secret mysecret
> DupInterval 0
>
>
> # Use this to check which Client clause matched
>
>
> Filename%D/users-%{Client:Identifier}
>
>
>
> This may be useful for controlling IPv6 behaviour.
>
> Thanks!
> Heikki
>
>
>> Am 2011-06-09 19:50, schrieb Heikki Vatiainen:
>>> On 06/09/2011 05:37 PM, Dyonisius Visser wrote:
Well, I installed a second instance on a dual stack host, and I tested
various combinations:
>>> Thanks for the summary.
>>>
BindAddress 192.87.30.31,ipv6:2001:610:148:dead::31
I.e. hardcoded addresses - this works, both IPv4 and IPv6 clients
work
BindAddress ipv6:::
IPv4 blocked (NOTICE: Request from unknown client 192.87.30.32:
ignored)
>>> This should work if you specify your client like this:
>>>
>>>
>>>
>>> Since the request arrived over IPv4 but was delivered to the application
>>> by IPv6 wildcard socket, the IPv4 address is presented as an IPv6
>>> address. See
>>>
>>> http://tools.ietf.org/html/rfc4291#section-2.5.5
>>>
>>> section "2.5.5.2. IPv4-Mapped IPv6 Address". The purpose of this mapping
>>> is to let the application to know was the message received over IPv6 or
>>> IPv4 since the socket can handle both protocols.
>>>
>>>
BindAddress 0.0.0.0
This is the default. IPv4 clients work. IPv6 clients DO NOT work,
and worse, nothing is logged by radiator, no "request from unknown
client 2001:610:blah:blah"
BindAddress ipv6:::,0.0.0.0
Startup gives some errors, and only IPv6 works:
Thu Jun 9 16:25:54 2011: DEBUG: Finished reading configuration file
'/etc/radiator/radius.cfg'
Thu Jun 9 16:25:54 2011: DEBUG: Reading dictionary file
'/etc/radiator/db/dictionary'
Thu Jun 9 16:25:54 2011: DEBUG: Creating authentication port ipv61812
Thu Jun 9 16:25:54 2011: DEBUG: Creating accounting port ipv61813
Thu Jun 9 16:25:54 2011: DEBUG: Creating authentication port 0.0.0.0:1812
Thu Jun 9 16:25:54 2011: ERR: Could not bind authentication socket:
Address already in use
Thu Jun 9 16:25:54 2011: DEBUG: Creating accounting port 0.0.0.0:1813
Thu Jun 9 16:25:54 2011: ERR: Could not bind accounting socket:
Address already in use
Thu Jun 9 16:25:54 2011: NOTICE: Server started: Radiator 4.8 on radius
Thu Jun 9 16:25:55 2011: NOTICE: Request from unknown client
145.100.98.42: ignored
BindAddress 0.0.0.0,ipv6:::
Also some errors, only IPv4 works, and also nothing logged when an
IPv6 client connects:
Thu Jun 9 16:27:42 2011: DEBUG: Finished reading configuration file
'/etc/radiator/radius.cfg'
Thu Jun 9 16:27:42 2011: DEBUG: Reading dictionary file
'/etc/radiator/db/dictionary'
Thu Jun 9 16:27:42 2011: DEBUG: Creating authentication po
Re: [RADIATOR] BindAddress question
On 06/14/2011 11:45 AM, Alexander Hartmaier wrote:
> Does this mean that we can't bind to IPv4 and IPv6 separately on Linux
> to not get v6 mapped v4 addresses?
I think the mapped addresses are only seen when a wildcard IPv6 bind is
done. If you bind to a non-wildcard IPv4 or IPv6 address, you should
only see traffic that arrived over IPv4 or IPv6, respectively.
To control the mapped addresses, there is IPV6_V6ONLY socket option, see
http://tools.ietf.org/html/rfc3493#section-5.3 for more
Linux also has this special file to control the system wide behaviour:
/proc/sys/net/ipv6/bindv6only
By default this seems to be 0. When it is 0, this will not work:
BindAddress ipv6:::, 0.0.0.0
The result in logs is this:
Tue Jun 14 16:15:07 2011: DEBUG: Creating authentication port ipv61645
Tue Jun 14 16:15:07 2011: DEBUG: Creating accounting port ipv61646
Tue Jun 14 16:15:07 2011: DEBUG: Creating authentication port 0.0.0.0:1645
Tue Jun 14 16:15:07 2011: ERR: Could not bind authentication socket:
Address already in use
Tue Jun 14 16:15:07 2011: DEBUG: Creating accounting port 0.0.0.0:1646
Tue Jun 14 16:15:07 2011: ERR: Could not bind accounting socket: Address
already in use
If I do this to enable the option:
echo 1 |sudo tee /proc/sys/net/ipv6/bindv6only
the same configuration works:
BindAddress ipv6:::, 0.0.0.0
Tue Jun 14 16:16:20 2011: DEBUG: Creating authentication port ipv61645
Tue Jun 14 16:16:20 2011: DEBUG: Creating accounting port ipv61646
Tue Jun 14 16:16:20 2011: DEBUG: Creating authentication port 0.0.0.0:1645
Tue Jun 14 16:16:20 2011: DEBUG: Creating accounting port 0.0.0.0:1646
When I used radpwtst to send requests to ipv6:::1 or 127.0.0.1 these
Client clauses were matched, respectively:
Identifier ipv6-loopback
Secret mysecret
DupInterval 0
Identifier ipv4-loopback
Secret mysecret
DupInterval 0
# Use this to check which Client clause matched
Filename%D/users-%{Client:Identifier}
This may be useful for controlling IPv6 behaviour.
Thanks!
Heikki
> Am 2011-06-09 19:50, schrieb Heikki Vatiainen:
>> On 06/09/2011 05:37 PM, Dyonisius Visser wrote:
>>> Well, I installed a second instance on a dual stack host, and I tested
>>> various combinations:
>> Thanks for the summary.
>>
>>> BindAddress 192.87.30.31,ipv6:2001:610:148:dead::31
>>> I.e. hardcoded addresses - this works, both IPv4 and IPv6 clients work
>>>
>>> BindAddress ipv6:::
>>> IPv4 blocked (NOTICE: Request from unknown client 192.87.30.32: ignored)
>> This should work if you specify your client like this:
>>
>>
>>
>> Since the request arrived over IPv4 but was delivered to the application
>> by IPv6 wildcard socket, the IPv4 address is presented as an IPv6
>> address. See
>>
>> http://tools.ietf.org/html/rfc4291#section-2.5.5
>>
>> section "2.5.5.2. IPv4-Mapped IPv6 Address". The purpose of this mapping
>> is to let the application to know was the message received over IPv6 or
>> IPv4 since the socket can handle both protocols.
>>
>>
>>> BindAddress 0.0.0.0
>>>This is the default. IPv4 clients work. IPv6 clients DO NOT work,
>>> and worse, nothing is logged by radiator, no "request from unknown
>>> client 2001:610:blah:blah"
>>>
>>> BindAddress ipv6:::,0.0.0.0
>>>Startup gives some errors, and only IPv6 works:
>>> Thu Jun 9 16:25:54 2011: DEBUG: Finished reading configuration file
>>> '/etc/radiator/radius.cfg'
>>> Thu Jun 9 16:25:54 2011: DEBUG: Reading dictionary file
>>> '/etc/radiator/db/dictionary'
>>> Thu Jun 9 16:25:54 2011: DEBUG: Creating authentication port ipv61812
>>> Thu Jun 9 16:25:54 2011: DEBUG: Creating accounting port ipv61813
>>> Thu Jun 9 16:25:54 2011: DEBUG: Creating authentication port 0.0.0.0:1812
>>> Thu Jun 9 16:25:54 2011: ERR: Could not bind authentication socket:
>>> Address already in use
>>> Thu Jun 9 16:25:54 2011: DEBUG: Creating accounting port 0.0.0.0:1813
>>> Thu Jun 9 16:25:54 2011: ERR: Could not bind accounting socket:
>>> Address already in use
>>> Thu Jun 9 16:25:54 2011: NOTICE: Server started: Radiator 4.8 on radius
>>> Thu Jun 9 16:25:55 2011: NOTICE: Request from unknown client
>>> 145.100.98.42: ignored
>>>
>>> BindAddress 0.0.0.0,ipv6:::
>>>Also some errors, only IPv4 works, and also nothing logged when an
>>> IPv6 client connects:
>>> Thu Jun 9 16:27:42 2011: DEBUG: Finished reading configuration file
>>> '/etc/radiator/radius.cfg'
>>> Thu Jun 9 16:27:42 2011: DEBUG: Reading dictionary file
>>> '/etc/radiator/db/dictionary'
>>> Thu Jun 9 16:27:42 2011: DEBUG: Creating authentication port 0.0.0.0:1812
>>> Thu Jun 9 16:27:42 2011: DEBUG: Creating accounting port 0.0.0.0:1813
>>> Thu Jun 9 16:27:42 2011: DEBUG: Creating authentication port ipv61812
>>> Thu Jun 9 16:27:42 2011: ERR: Could not bind authentication socket:
>>> Address already in use
>>> Thu Jun 9 16:27:42 2011: DEBUG: Creating accounting port ipv61813
>>> Thu
Re: [RADIATOR] BindAddress question
Does this mean that we can't bind to IPv4 and IPv6 separately on Linux
to not get v6 mapped v4 addresses?
Am 2011-06-09 19:50, schrieb Heikki Vatiainen:
> On 06/09/2011 05:37 PM, Dyonisius Visser wrote:
>> Well, I installed a second instance on a dual stack host, and I tested
>> various combinations:
> Thanks for the summary.
>
>> BindAddress 192.87.30.31,ipv6:2001:610:148:dead::31
>> I.e. hardcoded addresses - this works, both IPv4 and IPv6 clients work
>>
>> BindAddress ipv6:::
>> IPv4 blocked (NOTICE: Request from unknown client 192.87.30.32: ignored)
> This should work if you specify your client like this:
>
>
>
> Since the request arrived over IPv4 but was delivered to the application
> by IPv6 wildcard socket, the IPv4 address is presented as an IPv6
> address. See
>
> http://tools.ietf.org/html/rfc4291#section-2.5.5
>
> section "2.5.5.2. IPv4-Mapped IPv6 Address". The purpose of this mapping
> is to let the application to know was the message received over IPv6 or
> IPv4 since the socket can handle both protocols.
>
>
>> BindAddress 0.0.0.0
>>This is the default. IPv4 clients work. IPv6 clients DO NOT work,
>> and worse, nothing is logged by radiator, no "request from unknown
>> client 2001:610:blah:blah"
>>
>> BindAddress ipv6:::,0.0.0.0
>>Startup gives some errors, and only IPv6 works:
>> Thu Jun 9 16:25:54 2011: DEBUG: Finished reading configuration file
>> '/etc/radiator/radius.cfg'
>> Thu Jun 9 16:25:54 2011: DEBUG: Reading dictionary file
>> '/etc/radiator/db/dictionary'
>> Thu Jun 9 16:25:54 2011: DEBUG: Creating authentication port ipv61812
>> Thu Jun 9 16:25:54 2011: DEBUG: Creating accounting port ipv61813
>> Thu Jun 9 16:25:54 2011: DEBUG: Creating authentication port 0.0.0.0:1812
>> Thu Jun 9 16:25:54 2011: ERR: Could not bind authentication socket:
>> Address already in use
>> Thu Jun 9 16:25:54 2011: DEBUG: Creating accounting port 0.0.0.0:1813
>> Thu Jun 9 16:25:54 2011: ERR: Could not bind accounting socket:
>> Address already in use
>> Thu Jun 9 16:25:54 2011: NOTICE: Server started: Radiator 4.8 on radius
>> Thu Jun 9 16:25:55 2011: NOTICE: Request from unknown client
>> 145.100.98.42: ignored
>>
>> BindAddress 0.0.0.0,ipv6:::
>>Also some errors, only IPv4 works, and also nothing logged when an
>> IPv6 client connects:
>> Thu Jun 9 16:27:42 2011: DEBUG: Finished reading configuration file
>> '/etc/radiator/radius.cfg'
>> Thu Jun 9 16:27:42 2011: DEBUG: Reading dictionary file
>> '/etc/radiator/db/dictionary'
>> Thu Jun 9 16:27:42 2011: DEBUG: Creating authentication port 0.0.0.0:1812
>> Thu Jun 9 16:27:42 2011: DEBUG: Creating accounting port 0.0.0.0:1813
>> Thu Jun 9 16:27:42 2011: DEBUG: Creating authentication port ipv61812
>> Thu Jun 9 16:27:42 2011: ERR: Could not bind authentication socket:
>> Address already in use
>> Thu Jun 9 16:27:42 2011: DEBUG: Creating accounting port ipv61813
>> Thu Jun 9 16:27:42 2011: ERR: Could not bind accounting socket:
>> Address already in use
>> Thu Jun 9 16:27:42 2011: NOTICE: Server started: Radiator 4.8 on radius
>>
>>
>> So the only way I can radiator to accept requests from both protocols,
>> is to hardcode the interface addresses.
>>
>> Would it be possible to have radiator listen to 4+6 without hard coding?
>>
>> I think that option (whatever it looks like) should be the default.
>>
>> If possible, can the behavior of the current default ('BindAddress
>> 0.0.0.0') be changed so that it actually logs ignored incoming
>> requests?
>> I've spend quite some time figuring out what is going on, and only
>> tcpdump revealed that requests are actually reaching my box.
>>
>> Thanks :-)
>>
>
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] BindAddress question
On 06/09/2011 05:37 PM, Dyonisius Visser wrote:
> Well, I installed a second instance on a dual stack host, and I tested
> various combinations:
Thanks for the summary.
> BindAddress 192.87.30.31,ipv6:2001:610:148:dead::31
> I.e. hardcoded addresses - this works, both IPv4 and IPv6 clients work
>
> BindAddress ipv6:::
>IPv4 blocked (NOTICE: Request from unknown client 192.87.30.32: ignored)
This should work if you specify your client like this:
Since the request arrived over IPv4 but was delivered to the application
by IPv6 wildcard socket, the IPv4 address is presented as an IPv6
address. See
http://tools.ietf.org/html/rfc4291#section-2.5.5
section "2.5.5.2. IPv4-Mapped IPv6 Address". The purpose of this mapping
is to let the application to know was the message received over IPv6 or
IPv4 since the socket can handle both protocols.
> BindAddress 0.0.0.0
> This is the default. IPv4 clients work. IPv6 clients DO NOT work,
> and worse, nothing is logged by radiator, no "request from unknown
> client 2001:610:blah:blah"
>
> BindAddress ipv6:::,0.0.0.0
> Startup gives some errors, and only IPv6 works:
> Thu Jun 9 16:25:54 2011: DEBUG: Finished reading configuration file
> '/etc/radiator/radius.cfg'
> Thu Jun 9 16:25:54 2011: DEBUG: Reading dictionary file
> '/etc/radiator/db/dictionary'
> Thu Jun 9 16:25:54 2011: DEBUG: Creating authentication port ipv61812
> Thu Jun 9 16:25:54 2011: DEBUG: Creating accounting port ipv61813
> Thu Jun 9 16:25:54 2011: DEBUG: Creating authentication port 0.0.0.0:1812
> Thu Jun 9 16:25:54 2011: ERR: Could not bind authentication socket:
> Address already in use
> Thu Jun 9 16:25:54 2011: DEBUG: Creating accounting port 0.0.0.0:1813
> Thu Jun 9 16:25:54 2011: ERR: Could not bind accounting socket:
> Address already in use
> Thu Jun 9 16:25:54 2011: NOTICE: Server started: Radiator 4.8 on radius
> Thu Jun 9 16:25:55 2011: NOTICE: Request from unknown client
> 145.100.98.42: ignored
>
> BindAddress 0.0.0.0,ipv6:::
> Also some errors, only IPv4 works, and also nothing logged when an
> IPv6 client connects:
> Thu Jun 9 16:27:42 2011: DEBUG: Finished reading configuration file
> '/etc/radiator/radius.cfg'
> Thu Jun 9 16:27:42 2011: DEBUG: Reading dictionary file
> '/etc/radiator/db/dictionary'
> Thu Jun 9 16:27:42 2011: DEBUG: Creating authentication port 0.0.0.0:1812
> Thu Jun 9 16:27:42 2011: DEBUG: Creating accounting port 0.0.0.0:1813
> Thu Jun 9 16:27:42 2011: DEBUG: Creating authentication port ipv61812
> Thu Jun 9 16:27:42 2011: ERR: Could not bind authentication socket:
> Address already in use
> Thu Jun 9 16:27:42 2011: DEBUG: Creating accounting port ipv61813
> Thu Jun 9 16:27:42 2011: ERR: Could not bind accounting socket:
> Address already in use
> Thu Jun 9 16:27:42 2011: NOTICE: Server started: Radiator 4.8 on radius
>
>
> So the only way I can radiator to accept requests from both protocols,
> is to hardcode the interface addresses.
>
> Would it be possible to have radiator listen to 4+6 without hard coding?
>
> I think that option (whatever it looks like) should be the default.
>
> If possible, can the behavior of the current default ('BindAddress
> 0.0.0.0') be changed so that it actually logs ignored incoming
> requests?
> I've spend quite some time figuring out what is going on, and only
> tcpdump revealed that requests are actually reaching my box.
>
> Thanks :-)
>
--
Heikki Vatiainen
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] BindAddress question
hi, I can confirm exactly the same behaviour on Linux boxes here. hardcoded is the only way to have both working. Solaris can have both on single line and it works. a nice patch for 4.8 to arrive? :-) alan ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] BindAddress question
Well, I installed a second instance on a dual stack host, and I tested
various combinations:
BindAddress 192.87.30.31,ipv6:2001:610:148:dead::31
I.e. hardcoded addresses - this works, both IPv4 and IPv6 clients work
BindAddress ipv6:::
IPv4 blocked (NOTICE: Request from unknown client 192.87.30.32: ignored)
BindAddress 0.0.0.0
This is the default. IPv4 clients work. IPv6 clients DO NOT work,
and worse, nothing is logged by radiator, no "request from unknown
client 2001:610:blah:blah"
BindAddress ipv6:::,0.0.0.0
Startup gives some errors, and only IPv6 works:
Thu Jun 9 16:25:54 2011: DEBUG: Finished reading configuration file
'/etc/radiator/radius.cfg'
Thu Jun 9 16:25:54 2011: DEBUG: Reading dictionary file
'/etc/radiator/db/dictionary'
Thu Jun 9 16:25:54 2011: DEBUG: Creating authentication port ipv61812
Thu Jun 9 16:25:54 2011: DEBUG: Creating accounting port ipv61813
Thu Jun 9 16:25:54 2011: DEBUG: Creating authentication port 0.0.0.0:1812
Thu Jun 9 16:25:54 2011: ERR: Could not bind authentication socket:
Address already in use
Thu Jun 9 16:25:54 2011: DEBUG: Creating accounting port 0.0.0.0:1813
Thu Jun 9 16:25:54 2011: ERR: Could not bind accounting socket:
Address already in use
Thu Jun 9 16:25:54 2011: NOTICE: Server started: Radiator 4.8 on radius
Thu Jun 9 16:25:55 2011: NOTICE: Request from unknown client
145.100.98.42: ignored
BindAddress 0.0.0.0,ipv6:::
Also some errors, only IPv4 works, and also nothing logged when an
IPv6 client connects:
Thu Jun 9 16:27:42 2011: DEBUG: Finished reading configuration file
'/etc/radiator/radius.cfg'
Thu Jun 9 16:27:42 2011: DEBUG: Reading dictionary file
'/etc/radiator/db/dictionary'
Thu Jun 9 16:27:42 2011: DEBUG: Creating authentication port 0.0.0.0:1812
Thu Jun 9 16:27:42 2011: DEBUG: Creating accounting port 0.0.0.0:1813
Thu Jun 9 16:27:42 2011: DEBUG: Creating authentication port ipv61812
Thu Jun 9 16:27:42 2011: ERR: Could not bind authentication socket:
Address already in use
Thu Jun 9 16:27:42 2011: DEBUG: Creating accounting port ipv61813
Thu Jun 9 16:27:42 2011: ERR: Could not bind accounting socket:
Address already in use
Thu Jun 9 16:27:42 2011: NOTICE: Server started: Radiator 4.8 on radius
So the only way I can radiator to accept requests from both protocols,
is to hardcode the interface addresses.
Would it be possible to have radiator listen to 4+6 without hard coding?
I think that option (whatever it looks like) should be the default.
If possible, can the behavior of the current default ('BindAddress
0.0.0.0') be changed so that it actually logs ignored incoming
requests?
I've spend quite some time figuring out what is going on, and only
tcpdump revealed that requests are actually reaching my box.
Thanks :-)
--
Dyonisius Visser
System & Networking Engineer
TERENA Secretariat
Singel 468 D, 1017 AW Amsterdam
The Netherlands
T +31 20 530 44 88 F +31 20 530 44 99
vis...@terena.org | www.terena.org
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] BindAddress question
On 06/09/2011 03:03 PM, Alan Buxey wrote: >>> BindAddress 0.0.0.0,ipv6::: > > its horribly broken on Linux isnt it? on Solaris this works fine in this > incantation. Heh, I guess it can be said its broken, or this is just one posibility to do it. For those who are interested, see for example http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man4/inet6.4.html and search for "Interaction between IPv4/v6 sockets" There's also the mention about IPv4 mapped addresses, which is another nice thing about IPv6 and IPv4 interaction. -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] BindAddress question
Hi, > > BindAddress 0.0.0.0,ipv6::: its horribly broken on Linux isnt it? on Solaris this works fine in this incantation. alan ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] BindAddress question
On 06/09/2011 01:56 PM, Dyonisius Visser wrote: > On 09/06/2011 12:48, Alan Buxey wrote: >> Hi, >> >>> Could it be the same as other apps, '::' ? >>> >>> >>> I have now configured the hard coded addresses as a work aroudn. >> >> goodies/ipv6.cfg >> >> BindAddress ipv6::: >> >> (this is basically saying, use ipv6: and bind to :: - like other daemons >> do) > > > So this should make it listen for all IPv4 and IPv6: > > BindAddress 0.0.0.0,ipv6::: Try BindAddress ipv6::: At least on my Linux box, kernel 2.6.34, binding to :: covers both IPv4 and IPv6. If I specify both, IPv6 binding fails apparently because it tries to bind IPv4 again and since that's not possible anymore, it will not bind IPv6 either. > I heard that this might caused problems with Linux kernels? I do not know about problems, but if I remember correctly there has been confusion about one socket serving both protocols. Just noticed Alan's message, too: BindAddress 0.0.0.0 BindAddress ipv6::: is the same as BindAddress ipv6::: If these are reversed: BindAddress ipv6::: BindAddress 0.0.0.0 the net effect is the same as: BindAddress 0.0.0.0 In other words, BindAddress should be specified only once with all addresses as a parameter value. -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] BindAddress question
Hi, > So this should make it listen for all IPv4 and IPv6: > > BindAddress 0.0.0.0,ipv6::: on Solaris thats certainly true > I heard that this might caused problems with Linux kernels? BindAddress 0.0.0.0 BindAddress ipv6::: that works on the few Linux boxes that I've tested alan ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] BindAddress question
On 09/06/2011 12:48, Alan Buxey wrote: > Hi, > >> Could it be the same as other apps, '::' ? >> >> >> I have now configured the hard coded addresses as a work aroudn. > > goodies/ipv6.cfg > > BindAddress ipv6::: > > (this is basically saying, use ipv6: and bind to :: - like other daemons > do) So this should make it listen for all IPv4 and IPv6: BindAddress 0.0.0.0,ipv6::: I heard that this might caused problems with Linux kernels? -- Dyonisius Visser System & Networking Engineer TERENA Secretariat Singel 468 D, 1017 AW Amsterdam The Netherlands T +31 20 530 44 88 F +31 20 530 44 99 vis...@terena.org | www.terena.org smime.p7s Description: S/MIME Cryptographic Signature ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] BindAddress question
Hi, > Could it be the same as other apps, '::' ? > > > I have now configured the hard coded addresses as a work aroudn. goodies/ipv6.cfg BindAddress ipv6::: (this is basically saying, use ipv6: and bind to :: - like other daemons do) please note that you must use ipv6: as the prefix to hostnames to use the IPv6 address or it will use ipv4 by default alan ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] BindAddress question
Hi guys I've just fixed a problem where requests coming in to our Radiator instance via IPv6 were not recognized. I did not configure the BindAddress paramater, which defaults to 0.0.0.0. So, this was the error. After reading up on the docs, I could not find a way to have it listen to all IPv6. All IPv4 is '0.0.0.0', but how do I let it listen to all IPv6? Could it be the same as other apps, '::' ? I have now configured the hard coded addresses as a work aroudn. Thanks!! -- Dyonisius Visser System & Networking Engineer TERENA Secretariat Singel 468 D, 1017 AW Amsterdam The Netherlands T +31 20 530 44 88 F +31 20 530 44 99 vis...@terena.org | www.terena.org smime.p7s Description: S/MIME Cryptographic Signature ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: (RADIATOR) BindAddress multiple IPs?
Hi Jeremy, Yes from memory, only one BindAddress can currently be used, but I can see that multiple qaddresses might be usefule, and prob not too hard to implement. I will look when I am back on Nov 4. Cheers. On Tue, 29 Oct 2002 13:31, Hugh Irvine wrote: > Hello Jeremy - > > I have copied this mail to Mike, but he is travelling until next week. > > My understanding is that this is a lower-level problem than Perl can > deal with. > > Mike will be able to clarify I'm sure. > > regards > > Hugh > > On Tuesday, October 29, 2002, at 02:23 AM, Jeremy Hinton wrote: > > Hugh & crew, > > > > From reading the docs, and my own testing, it looks like the > > BindAddress parameter can only accept a single IP. As a result, > > it looks like you're limited to either having radiator respond on all > > IPs, or just on one. If this is not the case, someone please feel free > > to correct me. At any rate, i just wanted to submit a feature request > > to change this to accept multiple IPs. I for one would find this quite > > useful in our setup here. > > > > - jeremy > > > > === > > 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. === 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) BindAddress multiple IPs?
Hello Jeremy - I have copied this mail to Mike, but he is travelling until next week. My understanding is that this is a lower-level problem than Perl can deal with. Mike will be able to clarify I'm sure. regards Hugh On Tuesday, October 29, 2002, at 02:23 AM, Jeremy Hinton wrote: Hugh & crew, From reading the docs, and my own testing, it looks like the BindAddress parameter can only accept a single IP. As a result, it looks like you're limited to either having radiator respond on all IPs, or just on one. If this is not the case, someone please feel free to correct me. At any rate, i just wanted to submit a feature request to change this to accept multiple IPs. I for one would find this quite useful in our setup here. - jeremy === 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) BindAddress multiple IPs?
Hugh & crew, From reading the docs, and my own testing, it looks like the BindAddress parameter can only accept a single IP. As a result, it looks like you're limited to either having radiator respond on all IPs, or just on one. If this is not the case, someone please feel free to correct me. At any rate, i just wanted to submit a feature request to change this to accept multiple IPs. I for one would find this quite useful in our setup here. - jeremy === 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) BindAddress
Hello Harrison - Could you please send me a copy of your Radiator configuration file (no secrets) together with a complete trace 4. I would also like to see the command line that you have used to start Radiator and the command line you have used for radpwtst. thanks Hugh On Monday 20 August 2001 12:19, Harrison Ng wrote: > > Hello, > > We are using Radiator 2.18.2 on RH6.2. > The BindAddress parameter works only on radius authentication but not > accounting request. > We use tcpdump to check where has the packet gone, it said udp port radacct > unreachable. > I have no idea how to solve it, can anyone give me a hint. > > Harrison > SmarTone Mobile Communications Ltd. > > > Running radpwtst > - > There is no value named Async for attribute NAS-Port-Type. Using 0. > sending Access-Request... > OK > There is no value named Async for attribute NAS-Port-Type. Using 0. > sending Accounting-Request Start... > No reply > There is no value named Async for attribute NAS-Port-Type. Using 0. > sending Accounting-Request Stop... > No reply > time for 1 iterations: 10 s > > > > Radiator logfile > - > > Mon Aug 20 10:05:24 2001: INFO: Server started: Radiator 2.18.2 on grad1 > Mon Aug 20 10:05:24 2001: DEBUG: Packet dump: > *** Received from 127.0.0.1 port 1024 > Code: Access-Request > Identifier: 143 > Authentic: 1234567890123456 > Attributes: > User-Name = "lmds1" > Service-Type = Framed-User > NAS-IP-Address = 203.63.154.1 > NAS-Port = 1234 > Called-Station-Id = "123456789" > Calling-Station-Id = "987654321" > NAS-Port-Type = Asynchronous > User-Password = > "<200><185>l<153><154>j<4><246><188>8<9><160><216>}x<153>" > > Mon Aug 20 10:05:24 2001: DEBUG: Check if Handler Client-Id = > 202.140.74.1,NAS-Identifier = "radius" should be used to handle this > request Mon Aug 20 10:05:24 2001: DEBUG: Check if Handler Client-Id = > 10.25.155.1,NAS-Identifier = "rad" should be used to handle this request > Mon Aug 20 10:05:24 2001: DEBUG: Check if Handler Client-Id = > 10.25.157.18,NAS-Identifier = "radius" should be used to handle this > request Mon Aug 20 10:05:24 2001: DEBUG: Check if Handler Client-Id = > localhost should be used to handle this request > Mon Aug 20 10:05:24 2001: DEBUG: Handling request with Handler 'Client-Id = > localhost' > Mon Aug 20 10:05:24 2001: DEBUG: Rewrote user name to lmds1 > Mon Aug 20 10:05:24 2001: DEBUG: Deleting session for lmds1, 203.63.154.1, > 1234 > Mon Aug 20 10:05:24 2001: DEBUG: Handling with Radius::AuthFILE > Mon Aug 20 10:05:24 2001: DEBUG: Radius::AuthFILE looks for match with > lmds1 Mon Aug 20 10:05:24 2001: DEBUG: Radius::AuthFILE looks for match > with DEFAULT > Mon Aug 20 10:05:24 2001: DEBUG: Radius::AuthFILE ACCEPT: Accept explicitly > by Auth-Type=Accept > Mon Aug 20 10:05:24 2001: DEBUG: Access accepted for lmds1 > Mon Aug 20 10:05:24 2001: DEBUG: Packet dump: > *** Sending to 127.0.0.1 port 1024 > Code: Access-Accept > Identifier: 143 > Authentic: 1234567890123456 > Attributes: > > > > Running tcpdump > - > [root@grad1 /root]# tcpdump host 127.0.0.1 > Kernel filter, protocol ALL, datagram packet socket > tcpdump: listening on all devices > 10:19:34.615660 lo > localhost.radacct > localhost.radius: udp 91 > 10:19:34.615660 lo < localhost.radacct > localhost.radius: udp 91 > 10:19:34.632010 lo > localhost.radius > localhost.radacct: udp 20 > 10:19:34.632010 lo < localhost.radius > localhost.radacct: udp 20 > 10:19:34.637640 lo > localhost.radacct > localhost.radacct: udp 89 > 10:19:34.637640 lo < localhost.radacct > localhost.radacct: udp 89 > 10:19:34.637686 lo > localhost > localhost: icmp: localhost udp port > radacct unreachable [tos 0xc0] > 10:19:34.637686 lo < localhost > localhost: icmp: localhost udp port > radacct unreachable [tos 0xc0] > 10:19:39.640813 lo > localhost.radacct > localhost.radacct: udp 113 > 10:19:39.640813 lo < localhost.radacct > localhost.radacct: udp 113 > 10:19:39.640849 lo > localhost > localhost: icmp: localhost udp port > radacct unreachable [tos 0xc0] > 10:19:39.640849 lo < localhost > localhost: icmp: localhost udp port > radacct unreachable [tos 0xc0] Content-Type: text/html; charset="iso-8859-1"; name="Attachment: 1" Content-Transfer-Encoding: quoted-printable Content-Description: -- 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) BindAddress
Title: BindAddress Hello, We are using Radiator 2.18.2 on RH6.2. The BindAddress parameter works only on radius authentication but not accounting request. We use tcpdump to check where has the packet gone, it said udp port radacct unreachable. I have no idea how to solve it, can anyone give me a hint. Harrison SmarTone Mobile Communications Ltd. Running radpwtst - There is no value named Async for attribute NAS-Port-Type. Using 0. sending Access-Request... OK There is no value named Async for attribute NAS-Port-Type. Using 0. sending Accounting-Request Start... No reply There is no value named Async for attribute NAS-Port-Type. Using 0. sending Accounting-Request Stop... No reply time for 1 iterations: 10 s Radiator logfile - Mon Aug 20 10:05:24 2001: INFO: Server started: Radiator 2.18.2 on grad1 Mon Aug 20 10:05:24 2001: DEBUG: Packet dump: *** Received from 127.0.0.1 port 1024 Code: Access-Request Identifier: 143 Authentic: 1234567890123456 Attributes: User-Name = "lmds1" Service-Type = Framed-User NAS-IP-Address = 203.63.154.1 NAS-Port = 1234 Called-Station-Id = "123456789" Calling-Station-Id = "987654321" NAS-Port-Type = Asynchronous User-Password = "<200><185>l<153><154>j<4><246><188>8<9><160><216>}x<153>" Mon Aug 20 10:05:24 2001: DEBUG: Check if Handler Client-Id = 202.140.74.1,NAS-Identifier = "radius" should be used to handle this request Mon Aug 20 10:05:24 2001: DEBUG: Check if Handler Client-Id = 10.25.155.1,NAS-Identifier = "rad" should be used to handle this request Mon Aug 20 10:05:24 2001: DEBUG: Check if Handler Client-Id = 10.25.157.18,NAS-Identifier = "radius" should be used to handle this request Mon Aug 20 10:05:24 2001: DEBUG: Check if Handler Client-Id = localhost should be used to handle this request Mon Aug 20 10:05:24 2001: DEBUG: Handling request with Handler 'Client-Id = localhost' Mon Aug 20 10:05:24 2001: DEBUG: Rewrote user name to lmds1 Mon Aug 20 10:05:24 2001: DEBUG: Deleting session for lmds1, 203.63.154.1, 1234 Mon Aug 20 10:05:24 2001: DEBUG: Handling with Radius::AuthFILE Mon Aug 20 10:05:24 2001: DEBUG: Radius::AuthFILE looks for match with lmds1 Mon Aug 20 10:05:24 2001: DEBUG: Radius::AuthFILE looks for match with DEFAULT Mon Aug 20 10:05:24 2001: DEBUG: Radius::AuthFILE ACCEPT: Accept explicitly by Auth-Type=Accept Mon Aug 20 10:05:24 2001: DEBUG: Access accepted for lmds1 Mon Aug 20 10:05:24 2001: DEBUG: Packet dump: *** Sending to 127.0.0.1 port 1024 Code: Access-Accept Identifier: 143 Authentic: 1234567890123456 Attributes: Running tcpdump - [root@grad1 /root]# tcpdump host 127.0.0.1 Kernel filter, protocol ALL, datagram packet socket tcpdump: listening on all devices 10:19:34.615660 lo > localhost.radacct > localhost.radius: udp 91 10:19:34.615660 lo < localhost.radacct > localhost.radius: udp 91 10:19:34.632010 lo > localhost.radius > localhost.radacct: udp 20 10:19:34.632010 lo < localhost.radius > localhost.radacct: udp 20 10:19:34.637640 lo > localhost.radacct > localhost.radacct: udp 89 10:19:34.637640 lo < localhost.radacct > localhost.radacct: udp 89 10:19:34.637686 lo > localhost > localhost: icmp: localhost udp port radacct unreachable [tos 0xc0] 10:19:34.637686 lo < localhost > localhost: icmp: localhost udp port radacct unreachable [tos 0xc0] 10:19:39.640813 lo > localhost.radacct > localhost.radacct: udp 113 10:19:39.640813 lo < localhost.radacct > localhost.radacct: udp 113 10:19:39.640849 lo > localhost > localhost: icmp: localhost udp port radacct unreachable [tos 0xc0] 10:19:39.640849 lo < localhost > localhost: icmp: localhost udp port radacct unreachable [tos 0xc0]
Re: (RADIATOR) BindAddress
Hello Andy - This is almost always an OS issue - it decides what interface to use, not Radiator. regards Hugh At 12:49 +0200 15/5/01, Andy De Petter wrote: >Hi, > >I have a question, concerning the BindAddress to multiple >interfaces, on the same machine. When I don't bind Radiator to a >specific interface, it listens (by default) on -all- interfaces. > >Now, when I have RADIUS requests coming in from NAS, on a virtual >interface, Radiator will always respond with its primary interface >(instead of sending the reply through the interface through where it >has received the initial requests). > >My question is: Is it possible, to make Radiator respond to the >(virtual) interface on where it has received the initial requests >from NAS? > >It works, if you bind Radiator to the interface, with BindAddress, >but setting up radiusd daemons, for each (virtual) interface is not >an option in my situation, so.. > >TIA, > >-Andy > >-- > >*** DISCLAIMER *** >This e-mail and any attachments thereto may contain information, which >is confidential and/or protected by intellectual property rights and >are intended for the sole use of the recipient(s) named above. Any use >of the information contained herein (including, but not limited to, >total or partial reproduction, communication or distribution in any >form) by persons other than the designated recipient(s) is prohibited. >If you have received this e-mail in error, please notify the sender >either by telephone or by e-mail and delete the material from any >computer. Thank you for your cooperation. > > > >=== >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. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc. Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X. === 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) BindAddress
Hi, I have a question, concerning the BindAddress to multiple interfaces, on the same machine. When I don't bind Radiator to a specific interface, it listens (by default) on -all- interfaces. Now, when I have RADIUS requests coming in from NAS, on a virtual interface, Radiator will always respond with its primary interface (instead of sending the reply through the interface through where it has received the initial requests). My question is: Is it possible, to make Radiator respond to the (virtual) interface on where it has received the initial requests from NAS? It works, if you bind Radiator to the interface, with BindAddress, but setting up radiusd daemons, for each (virtual) interface is not an option in my situation, so.. TIA, -Andy -- *** DISCLAIMER *** This e-mail and any attachments thereto may contain information, which is confidential and/or protected by intellectual property rights and are intended for the sole use of the recipient(s) named above. Any use of the information contained herein (including, but not limited to, total or partial reproduction, communication or distribution in any form) by persons other than the designated recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender either by telephone or by e-mail and delete the material from any computer. Thank you for your cooperation. === 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) BindAddress for SNMPAgent
Hello, It seems that the BindAddress attribute, for SNMPAgent isn't working properly on my site. I'm running Radiator 2.17.1, and I have this in my configuration file, for my authentication radiator server: Community public BindAddress 192.168.1.97 Port162 And this for my accounting radiator server: Community public BindAddress 192.168.1.97 Port163 But when I check my netstat, it seems that it's listening on all interfaces: *.162 Idle *.163 Idle Any ideas anyone? The bind of the radius server itself, is working fine, it's just the SNMP Agent, that is not binding to its proper IP address. I'm having problems with this, as I'm running multiple radiator instances on the same machine, but multiple IP addresses. -Andy -- "For nothing can seem foul to those that win." - Henry IV, Pt1, Act 5, Sc 1 *** DISCLAIMER *** This e-mail and any attachments thereto may contain information, which is confidential and/or protected by intellectual property rights and are intended for the sole use of the recipient(s) named above. Any use of the information contained herein (including, but not limited to, total or partial reproduction, communication or distribution in any form) by persons other than the designated recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender either by telephone or by e-mail and delete the material from any computer. Thank you for your cooperation. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) BindAddress question
Hello Jason - On Fri, 04 Aug 2000, Jason J. Horton wrote: > Is it possible to bind to more than one IP address per installation? > No - but it is possible to run multiple copies of Radiator, each on a different IP address and/or port number. hth Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc. Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) BindAddress question
Is it possible to bind to more than one IP address per installation? -- -Jason J. Horton <[EMAIL PROTECTED]> Fat Man in a Little Coat Intercom Online Inc. 212.376.7440 | http://www.intercom.com === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
