FreeRADIUS 2 not listening on right port
I just upgraded by FreeRADIUS server from the version 1 to version 2 family. I have the listen {} statements configured as follows: radiusd: #### Opening IP addresses and Ports #### listen { type = "auth" ipaddr = * port = 1812 } listen { type = "acct" ipaddr = * port = 1813 } main { snmp = no smux_password = "" snmp_write_access = no } Listening on authentication address * port 41045 Listening on accounting address * port 54893 Listening on proxy address * port 38374 Ready to process requests. However as you can see if always listens on random ports. What am I doing wrong? I am using version 2.0.2 which was distributed with Fedora 9. Thomas E. Casartello, Jr. Infrastructure Technician Linux Specialist Department of Information Technology Westfield State College Wilson 105-A (413) 572-8245 E-Mail: tcasartello@wsc.ma.edu Red Hat Certified Technician (RHCT)
Compiling from source did NOT solve the problem. Thomas E. Casartello, Jr. Infrastructure Technician Linux Specialist Department of Information Technology Westfield State College Wilson 105-A (413) 572-8245 E-Mail: tcasartello@wsc.ma.edu Red Hat Certified Technician (RHCT) From: freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius.org [mailto:freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius .org] On Behalf Of Casartello, Thomas Sent: Thursday, May 15, 2008 1:16 PM To: freeradius-users@lists.freeradius.org Subject: FreeRADIUS 2 not listening on right port I just upgraded by FreeRADIUS server from the version 1 to version 2 family. I have the listen {} statements configured as follows: radiusd: #### Opening IP addresses and Ports #### listen { type = "auth" ipaddr = * port = 1812 } listen { type = "acct" ipaddr = * port = 1813 } main { snmp = no smux_password = "" snmp_write_access = no } Listening on authentication address * port 41045 Listening on accounting address * port 54893 Listening on proxy address * port 38374 Ready to process requests. However as you can see if always listens on random ports. What am I doing wrong? I am using version 2.0.2 which was distributed with Fedora 9. Thomas E. Casartello, Jr. Infrastructure Technician Linux Specialist Department of Information Technology Westfield State College Wilson 105-A (413) 572-8245 E-Mail: tcasartello@wsc.ma.edu Red Hat Certified Technician (RHCT)
You're not running NAT/PAT through iptables are you? It'll translate 1812/1813 inside to <some high port>/<some high port> outside. Not sure how the server will pick that up. Maybe the port after translation. If so you'll need to not port translate the radius ports. I can do it in a Pix, but haven't used iptables for translation in a long while. Mearl From: freeradius-users-bounces+jmdanner=samford.edu@lists.freeradius.org [mailto:freeradius-users-bounces+jmdanner=samford.edu@lists.freeradius.org] On Behalf Of Casartello, Thomas Sent: Thursday, May 15, 2008 12:31 PM To: FreeRadius users mailing list Subject: RE: FreeRADIUS 2 not listening on right port Compiling from source did NOT solve the problem. Thomas E. Casartello, Jr. Infrastructure Technician Linux Specialist Department of Information Technology Westfield State College Wilson 105-A (413) 572-8245 E-Mail: tcasartello@wsc.ma.edu Red Hat Certified Technician (RHCT) From: freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius.org [mailto:freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius.org] On Behalf Of Casartello, Thomas Sent: Thursday, May 15, 2008 1:16 PM To: freeradius-users@lists.freeradius.org Subject: FreeRADIUS 2 not listening on right port I just upgraded by FreeRADIUS server from the version 1 to version 2 family. I have the listen {} statements configured as follows: radiusd: #### Opening IP addresses and Ports #### listen { type = "auth" ipaddr = * port = 1812 } listen { type = "acct" ipaddr = * port = 1813 } main { snmp = no smux_password = "" snmp_write_access = no } Listening on authentication address * port 41045 Listening on accounting address * port 54893 Listening on proxy address * port 38374 Ready to process requests. However as you can see if always listens on random ports. What am I doing wrong? I am using version 2.0.2 which was distributed with Fedora 9. Thomas E. Casartello, Jr. Infrastructure Technician Linux Specialist Department of Information Technology Westfield State College Wilson 105-A (413) 572-8245 E-Mail: tcasartello@wsc.ma.edu Red Hat Certified Technician (RHCT)
No I am not doing any kind of NAT. I actually have IPTables disabled right now. Thomas E. Casartello, Jr. Infrastructure Technician Linux Specialist Department of Information Technology Westfield State College Wilson 105-A (413) 572-8245 E-Mail: tcasartello@wsc.ma.edu Red Hat Certified Technician (RHCT) -----Original Message----- From: freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius.org [mailto:freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius.org] On Behalf Of Danner, Mearl Sent: Thursday, May 15, 2008 1:42 PM To: FreeRadius users mailing list Subject: RE: FreeRADIUS 2 not listening on right port You're not running NAT/PAT through iptables are you? It'll translate 1812/1813 inside to <some high port>/<some high port> outside. Not sure how the server will pick that up. Maybe the port after translation. If so you'll need to not port translate the radius ports. I can do it in a Pix, but haven't used iptables for translation in a long while. Mearl From: freeradius-users-bounces+jmdanner=samford.edu@lists.freeradius.org [mailto:freeradius-users-bounces+jmdanner=samford.edu@lists.freeradius.org] On Behalf Of Casartello, Thomas Sent: Thursday, May 15, 2008 12:31 PM To: FreeRadius users mailing list Subject: RE: FreeRADIUS 2 not listening on right port Compiling from source did NOT solve the problem. Thomas E. Casartello, Jr. Infrastructure Technician Linux Specialist Department of Information Technology Westfield State College Wilson 105-A (413) 572-8245 E-Mail: tcasartello@wsc.ma.edu Red Hat Certified Technician (RHCT) From: freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius.org [mailto:freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius.org] On Behalf Of Casartello, Thomas Sent: Thursday, May 15, 2008 1:16 PM To: freeradius-users@lists.freeradius.org Subject: FreeRADIUS 2 not listening on right port I just upgraded by FreeRADIUS server from the version 1 to version 2 family. I have the listen {} statements configured as follows: radiusd: #### Opening IP addresses and Ports #### listen { type = "auth" ipaddr = * port = 1812 } listen { type = "acct" ipaddr = * port = 1813 } main { snmp = no smux_password = "" snmp_write_access = no } Listening on authentication address * port 41045 Listening on accounting address * port 54893 Listening on proxy address * port 38374 Ready to process requests. However as you can see if always listens on random ports. What am I doing wrong? I am using version 2.0.2 which was distributed with Fedora 9. Thomas E. Casartello, Jr. Infrastructure Technician Linux Specialist Department of Information Technology Westfield State College Wilson 105-A (413) 572-8245 E-Mail: tcasartello@wsc.ma.edu Red Hat Certified Technician (RHCT) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Have you tried binding to a specific IP address rather than *?
-----Original Message----- From: freeradius-users- bounces+jmdanner=samford.edu@lists.freeradius.org [mailto:freeradius- users-bounces+jmdanner=samford.edu@lists.freeradius.org] On Behalf Of Casartello, Thomas Sent: Thursday, May 15, 2008 12:44 PM To: FreeRadius users mailing list Subject: RE: FreeRADIUS 2 not listening on right port
No I am not doing any kind of NAT. I actually have IPTables disabled right now.
Thomas E. Casartello, Jr. Infrastructure Technician Linux Specialist Department of Information Technology Westfield State College Wilson 105-A (413) 572-8245 E-Mail: tcasartello@wsc.ma.edu
Red Hat Certified Technician (RHCT)
-----Original Message----- From: freeradius-users- bounces+tcasartello=wsc.ma.edu@lists.freeradius.org [mailto:freeradius- users-bounces+tcasartello=wsc.ma.edu@lists.freeradius.org] On Behalf Of Danner, Mearl Sent: Thursday, May 15, 2008 1:42 PM To: FreeRadius users mailing list Subject: RE: FreeRADIUS 2 not listening on right port
You're not running NAT/PAT through iptables are you?
It'll translate 1812/1813 inside to <some high port>/<some high port> outside.
Not sure how the server will pick that up. Maybe the port after translation.
If so you'll need to not port translate the radius ports. I can do it in a Pix, but haven't used iptables for translation in a long while.
Mearl
From: freeradius-users- bounces+jmdanner=samford.edu@lists.freeradius.org [mailto:freeradius- users-bounces+jmdanner=samford.edu@lists.freeradius.org] On Behalf Of Casartello, Thomas Sent: Thursday, May 15, 2008 12:31 PM To: FreeRadius users mailing list Subject: RE: FreeRADIUS 2 not listening on right port
Compiling from source did NOT solve the problem.
Thomas E. Casartello, Jr. Infrastructure Technician Linux Specialist Department of Information Technology Westfield State College Wilson 105-A (413) 572-8245 E-Mail: tcasartello@wsc.ma.edu
Red Hat Certified Technician (RHCT)
From: freeradius-users- bounces+tcasartello=wsc.ma.edu@lists.freeradius.org [mailto:freeradius- users-bounces+tcasartello=wsc.ma.edu@lists.freeradius.org] On Behalf Of Casartello, Thomas Sent: Thursday, May 15, 2008 1:16 PM To: freeradius-users@lists.freeradius.org Subject: FreeRADIUS 2 not listening on right port
I just upgraded by FreeRADIUS server from the version 1 to version 2 family. I have the listen {} statements configured as follows: radiusd: #### Opening IP addresses and Ports #### listen { type = "auth" ipaddr = * port = 1812 } listen { type = "acct" ipaddr = * port = 1813 } main { snmp = no smux_password = "" snmp_write_access = no } Listening on authentication address * port 41045 Listening on accounting address * port 54893 Listening on proxy address * port 38374 Ready to process requests.
However as you can see if always listens on random ports. What am I doing wrong? I am using version 2.0.2 which was distributed with Fedora 9.
Thomas E. Casartello, Jr. Infrastructure Technician Linux Specialist Department of Information Technology Westfield State College Wilson 105-A (413) 572-8245 E-Mail: tcasartello@wsc.ma.edu
Red Hat Certified Technician (RHCT)
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Yes. Same result. I went back to 1.1.7 on the same box and its working fine now. Thomas E. Casartello, Jr. Infrastructure Technician Linux Specialist Department of Information Technology Westfield State College Wilson 105-A (413) 572-8245 E-Mail: tcasartello@wsc.ma.edu Red Hat Certified Technician (RHCT) -----Original Message----- From: freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius.org [mailto:freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius.org] On Behalf Of Danner, Mearl Sent: Thursday, May 15, 2008 2:01 PM To: FreeRadius users mailing list Subject: RE: FreeRADIUS 2 not listening on right port Have you tried binding to a specific IP address rather than *?
-----Original Message----- From: freeradius-users- bounces+jmdanner=samford.edu@lists.freeradius.org [mailto:freeradius- users-bounces+jmdanner=samford.edu@lists.freeradius.org] On Behalf Of Casartello, Thomas Sent: Thursday, May 15, 2008 12:44 PM To: FreeRadius users mailing list Subject: RE: FreeRADIUS 2 not listening on right port
No I am not doing any kind of NAT. I actually have IPTables disabled right now.
Thomas E. Casartello, Jr. Infrastructure Technician Linux Specialist Department of Information Technology Westfield State College Wilson 105-A (413) 572-8245 E-Mail: tcasartello@wsc.ma.edu
Red Hat Certified Technician (RHCT)
-----Original Message----- From: freeradius-users- bounces+tcasartello=wsc.ma.edu@lists.freeradius.org [mailto:freeradius- users-bounces+tcasartello=wsc.ma.edu@lists.freeradius.org] On Behalf Of Danner, Mearl Sent: Thursday, May 15, 2008 1:42 PM To: FreeRadius users mailing list Subject: RE: FreeRADIUS 2 not listening on right port
You're not running NAT/PAT through iptables are you?
It'll translate 1812/1813 inside to <some high port>/<some high port> outside.
Not sure how the server will pick that up. Maybe the port after translation.
If so you'll need to not port translate the radius ports. I can do it in a Pix, but haven't used iptables for translation in a long while.
Mearl
From: freeradius-users- bounces+jmdanner=samford.edu@lists.freeradius.org [mailto:freeradius- users-bounces+jmdanner=samford.edu@lists.freeradius.org] On Behalf Of Casartello, Thomas Sent: Thursday, May 15, 2008 12:31 PM To: FreeRadius users mailing list Subject: RE: FreeRADIUS 2 not listening on right port
Compiling from source did NOT solve the problem.
Thomas E. Casartello, Jr. Infrastructure Technician Linux Specialist Department of Information Technology Westfield State College Wilson 105-A (413) 572-8245 E-Mail: tcasartello@wsc.ma.edu
Red Hat Certified Technician (RHCT)
From: freeradius-users- bounces+tcasartello=wsc.ma.edu@lists.freeradius.org [mailto:freeradius- users-bounces+tcasartello=wsc.ma.edu@lists.freeradius.org] On Behalf Of Casartello, Thomas Sent: Thursday, May 15, 2008 1:16 PM To: freeradius-users@lists.freeradius.org Subject: FreeRADIUS 2 not listening on right port
I just upgraded by FreeRADIUS server from the version 1 to version 2 family. I have the listen {} statements configured as follows: radiusd: #### Opening IP addresses and Ports #### listen { type = "auth" ipaddr = * port = 1812 } listen { type = "acct" ipaddr = * port = 1813 } main { snmp = no smux_password = "" snmp_write_access = no } Listening on authentication address * port 41045 Listening on accounting address * port 54893 Listening on proxy address * port 38374 Ready to process requests.
However as you can see if always listens on random ports. What am I doing wrong? I am using version 2.0.2 which was distributed with Fedora 9.
Thomas E. Casartello, Jr. Infrastructure Technician Linux Specialist Department of Information Technology Westfield State College Wilson 105-A (413) 572-8245 E-Mail: tcasartello@wsc.ma.edu
Red Hat Certified Technician (RHCT)
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Casartello, Thomas wrote:
Compiling from source did NOT solve the problem.
It looks like Fedora is broken. The server code does this: if (port == 0) { call system function to look up "radius" port in /etc/services if (found ) { port = port found in /etc/services } else { port = 1812 } } The only way I can see it choosing "random" ports is if the lookup in /etc/services returns "found", with a random port. I suggest hard-coding the port numbers (1812/1813) into the "listen" sections. Maybe also see if 'radius" and "radacct" are defined in /etc/services. Alan DeKok.
I tried hardcoding them in the listen section. Same result. Thomas E. Casartello, Jr. Infrastructure Technician Linux Specialist Department of Information Technology Westfield State College Wilson 105-A (413) 572-8245 E-Mail: tcasartello@wsc.ma.edu Red Hat Certified Technician (RHCT) -----Original Message----- From: freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius.org [mailto:freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius .org] On Behalf Of Alan DeKok Sent: Thursday, May 15, 2008 2:16 PM To: FreeRadius users mailing list Subject: Re: FreeRADIUS 2 not listening on right port Casartello, Thomas wrote:
Compiling from source did NOT solve the problem.
It looks like Fedora is broken. The server code does this: if (port == 0) { call system function to look up "radius" port in /etc/services if (found ) { port = port found in /etc/services } else { port = 1812 } } The only way I can see it choosing "random" ports is if the lookup in /etc/services returns "found", with a random port. I suggest hard-coding the port numbers (1812/1813) into the "listen" sections. Maybe also see if 'radius" and "radacct" are defined in /etc/services. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Casartello, Thomas wrote:
I tried hardcoding them in the listen section. Same result.
Weird. My guess, then, is that it seems to be a problem with the specific GCC version on Fedora. Please try the attached patch. If it doesn't work, then the only way to fix it is for me to get an SSH login to a fedora machine. Oh, and 2.0.4. works on Ubuntu, Debian, *BSD, Solaris... Alan DeKok.
No luck on that patch. I'll try to get you a login sometime over the next couple days. Thomas E. Casartello, Jr. Infrastructure Technician Linux Specialist Department of Information Technology Westfield State College Wilson 105-A (413) 572-8245 E-Mail: tcasartello@wsc.ma.edu Red Hat Certified Technician (RHCT) -----Original Message----- From: freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius.org [mailto:freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius .org] On Behalf Of Alan DeKok Sent: Thursday, May 15, 2008 3:32 PM To: FreeRadius users mailing list Subject: Re: FreeRADIUS 2 not listening on right port Casartello, Thomas wrote:
I tried hardcoding them in the listen section. Same result.
Weird. My guess, then, is that it seems to be a problem with the specific GCC version on Fedora. Please try the attached patch. If it doesn't work, then the only way to fix it is for me to get an SSH login to a fedora machine. Oh, and 2.0.4. works on Ubuntu, Debian, *BSD, Solaris... Alan DeKok.
Hi, Exact same problem here... Really thinking about reverting to v1.x Casartello, Thomas a écrit :
I tried hardcoding them in the listen section. Same result.
Thomas E. Casartello, Jr. Infrastructure Technician Linux Specialist Department of Information Technology Westfield State College Wilson 105-A (413) 572-8245 E-Mail: tcasartello@wsc.ma.edu
Red Hat Certified Technician (RHCT)
-----Original Message----- From: freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius.org [mailto:freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius .org] On Behalf Of Alan DeKok Sent: Thursday, May 15, 2008 2:16 PM To: FreeRadius users mailing list Subject: Re: FreeRADIUS 2 not listening on right port
Casartello, Thomas wrote:
Compiling from source did NOT solve the problem.
It looks like Fedora is broken.
The server code does this:
if (port == 0) { call system function to look up "radius" port in /etc/services if (found ) { port = port found in /etc/services } else { port = 1812 } }
The only way I can see it choosing "random" ports is if the lookup in /etc/services returns "found", with a random port.
I suggest hard-coding the port numbers (1812/1813) into the "listen" sections. Maybe also see if 'radius" and "radacct" are defined in /etc/services.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
I'm running FC9, by the way... maybe that explains this sudden amount of same problems, since the FC9 release was on tuesday. Casartello, Thomas a écrit :
I tried hardcoding them in the listen section. Same result.
Thomas E. Casartello, Jr. Infrastructure Technician Linux Specialist Department of Information Technology Westfield State College Wilson 105-A (413) 572-8245 E-Mail: tcasartello@wsc.ma.edu
Red Hat Certified Technician (RHCT)
-----Original Message----- From: freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius.org [mailto:freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius .org] On Behalf Of Alan DeKok Sent: Thursday, May 15, 2008 2:16 PM To: FreeRadius users mailing list Subject: Re: FreeRADIUS 2 not listening on right port
Casartello, Thomas wrote:
Compiling from source did NOT solve the problem.
It looks like Fedora is broken.
The server code does this:
if (port == 0) { call system function to look up "radius" port in /etc/services if (found ) { port = port found in /etc/services } else { port = 1812 } }
The only way I can see it choosing "random" ports is if the lookup in /etc/services returns "found", with a random port.
I suggest hard-coding the port numbers (1812/1813) into the "listen" sections. Maybe also see if 'radius" and "radacct" are defined in /etc/services.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
As am I. Thomas E. Casartello, Jr. Infrastructure Technician Linux Specialist Department of Information Technology Westfield State College Wilson 105-A (413) 572-8245 E-Mail: tcasartello@wsc.ma.edu Red Hat Certified Technician (RHCT) -----Original Message----- From: freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius.org [mailto:freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius.org] On Behalf Of Hoggins! Sent: Thursday, May 15, 2008 4:05 PM To: FreeRadius users mailing list Subject: Re: FreeRADIUS 2 not listening on right port I'm running FC9, by the way... maybe that explains this sudden amount of same problems, since the FC9 release was on tuesday. Casartello, Thomas a écrit :
I tried hardcoding them in the listen section. Same result.
Thomas E. Casartello, Jr. Infrastructure Technician Linux Specialist Department of Information Technology Westfield State College Wilson 105-A (413) 572-8245 E-Mail: tcasartello@wsc.ma.edu
Red Hat Certified Technician (RHCT)
-----Original Message----- From: freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius.org [mailto:freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius .org] On Behalf Of Alan DeKok Sent: Thursday, May 15, 2008 2:16 PM To: FreeRadius users mailing list Subject: Re: FreeRADIUS 2 not listening on right port
Casartello, Thomas wrote:
Compiling from source did NOT solve the problem.
It looks like Fedora is broken.
The server code does this:
if (port == 0) { call system function to look up "radius" port in /etc/services if (found ) { port = port found in /etc/services } else { port = 1812 } }
The only way I can see it choosing "random" ports is if the lookup in /etc/services returns "found", with a random port.
I suggest hard-coding the port numbers (1812/1813) into the "listen" sections. Maybe also see if 'radius" and "radacct" are defined in /etc/services.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hoggins! wrote:
I'm running FC9, by the way... maybe that explains this sudden amount of same problems, since the FC9 release was on tuesday.
Maybe someone running FC9 could try "debugging" the problem. I haven't run a redhat-based system for *years*. Since this works on every other system on the planet, it sounds *very* much like an issue in FC9. Alan DeKok.
Install the freeradius rpm or install from source. It basically binds to a random port no matter what you do in the config files. Freeradius 1.1.7 works fine in Fedora 9. I'm going to try using 2.0.4 on Fedora 8 box. Thomas E. Casartello, Jr. Infrastructure Technician Linux Specialist Department of Information Technology Westfield State College Wilson 105-A (413) 572-8245 E-Mail: tcasartello@wsc.ma.edu Red Hat Certified Technician (RHCT) -----Original Message----- From: freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius.org [mailto:freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius .org] On Behalf Of A.L.M.Buxey@lboro.ac.uk Sent: Thursday, May 15, 2008 5:00 PM To: FreeRadius users mailing list Subject: Re: FreeRADIUS 2 not listening on right port Hi,
Maybe someone running FC9 could try "debugging" the problem.
as, no doubt, one of my systems will be FC9 in a short while I could look att his - what exactly should I be looking for? i'll dig around for the new features and changes they've made. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Fedora 9 did change a lot of things from 8. It's also the first version where they went to the 2.0 freeradius family. The release their RPM is using is 2.0.2 I think. Thomas E. Casartello, Jr. Infrastructure Technician Linux Specialist Department of Information Technology Westfield State College Wilson 105-A (413) 572-8245 E-Mail: tcasartello@wsc.ma.edu Red Hat Certified Technician (RHCT) -----Original Message----- From: freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius.org [mailto:freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius .org] On Behalf Of A.L.M.Buxey@lboro.ac.uk Sent: Thursday, May 15, 2008 5:00 PM To: FreeRadius users mailing list Subject: Re: FreeRADIUS 2 not listening on right port Hi,
Maybe someone running FC9 could try "debugging" the problem.
as, no doubt, one of my systems will be FC9 in a short while I could look att his - what exactly should I be looking for? i'll dig around for the new features and changes they've made. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Fedora 9 did do a pretty big gcc version jump. Fedora 8 used 4.1.2, while 9 uses 4.3.0. BTW I tested it in Fedora 8 and it worked fine, so it's definitely a 9 issue. Thomas E. Casartello, Jr. Infrastructure Technician Linux Specialist Department of Information Technology Westfield State College Wilson 105-A (413) 572-8245 E-Mail: tcasartello@wsc.ma.edu Red Hat Certified Technician (RHCT) -----Original Message----- From: freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius.org [mailto:freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius .org] On Behalf Of Alan DeKok Sent: Thursday, May 15, 2008 4:22 PM To: FreeRadius users mailing list Subject: Re: FreeRADIUS 2 not listening on right port Hoggins! wrote:
I'm running FC9, by the way... maybe that explains this sudden amount of same problems, since the FC9 release was on tuesday.
Maybe someone running FC9 could try "debugging" the problem. I haven't run a redhat-based system for *years*. Since this works on every other system on the planet, it sounds *very* much like an issue in FC9. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Shouldn't the maintainer of the specific FC9 freeradius package be aware of this critical issue ? I guess a newer release is for very soon. Casartello, Thomas a écrit :
Fedora 9 did do a pretty big gcc version jump. Fedora 8 used 4.1.2, while 9 uses 4.3.0. BTW I tested it in Fedora 8 and it worked fine, so it's definitely a 9 issue.
Thomas E. Casartello, Jr. Infrastructure Technician Linux Specialist Department of Information Technology Westfield State College Wilson 105-A (413) 572-8245 E-Mail: tcasartello@wsc.ma.edu
Red Hat Certified Technician (RHCT)
-----Original Message----- From: freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius.org [mailto:freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius .org] On Behalf Of Alan DeKok Sent: Thursday, May 15, 2008 4:22 PM To: FreeRadius users mailing list Subject: Re: FreeRADIUS 2 not listening on right port
Hoggins! wrote:
I'm running FC9, by the way... maybe that explains this sudden amount
of
same problems, since the FC9 release was on tuesday.
Maybe someone running FC9 could try "debugging" the problem.
I haven't run a redhat-based system for *years*.
Since this works on every other system on the planet, it sounds *very* much like an issue in FC9.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
It's not just the Fedora package. Even if you compile the latest freeradius from source it still has the problem. Thomas E. Casartello, Jr. Infrastructure Technician Linux Specialist Department of Information Technology Westfield State College Wilson 105-A (413) 572-8245 E-Mail: tcasartello@wsc.ma.edu Red Hat Certified Technician (RHCT) -----Original Message----- From: freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius.org [mailto:freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius.org] On Behalf Of Hoggins! Sent: Thursday, May 15, 2008 8:21 PM To: FreeRadius users mailing list Subject: Re: FreeRADIUS 2 not listening on right port Shouldn't the maintainer of the specific FC9 freeradius package be aware of this critical issue ? I guess a newer release is for very soon. Casartello, Thomas a écrit :
Fedora 9 did do a pretty big gcc version jump. Fedora 8 used 4.1.2, while 9 uses 4.3.0. BTW I tested it in Fedora 8 and it worked fine, so it's definitely a 9 issue.
Thomas E. Casartello, Jr. Infrastructure Technician Linux Specialist Department of Information Technology Westfield State College Wilson 105-A (413) 572-8245 E-Mail: tcasartello@wsc.ma.edu
Red Hat Certified Technician (RHCT)
-----Original Message----- From: freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius.org [mailto:freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius .org] On Behalf Of Alan DeKok Sent: Thursday, May 15, 2008 4:22 PM To: FreeRadius users mailing list Subject: Re: FreeRADIUS 2 not listening on right port
Hoggins! wrote:
I'm running FC9, by the way... maybe that explains this sudden amount
of
same problems, since the FC9 release was on tuesday.
Maybe someone running FC9 could try "debugging" the problem.
I haven't run a redhat-based system for *years*.
Since this works on every other system on the planet, it sounds *very* much like an issue in FC9.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
I did a little looking into this this evening. This assessment looks to be correct as it looks to be related to compiler optimizations. With the optimizations disabled in Make.inc, FreeRADIUS will start up on the correct port. For the fr_socket function, gcc appears to be optimizing the arguments by sending them through the registers instead of the stack frame, but the "port" argument is being clobbered ("optimized out") before the htons(port) call. Specifically, according to a step-through with GDB, after the first function call in fr_socket (which is to socket()), the port variable is gone ("optimized out"). --Mike On May 15, 2008, at 4:30 PM, Casartello, Thomas wrote:
Fedora 9 did do a pretty big gcc version jump. Fedora 8 used 4.1.2, while 9 uses 4.3.0. BTW I tested it in Fedora 8 and it worked fine, so it's definitely a 9 issue.
Thomas E. Casartello, Jr. Infrastructure Technician Linux Specialist Department of Information Technology Westfield State College Wilson 105-A (413) 572-8245 E-Mail: tcasartello@wsc.ma.edu
Red Hat Certified Technician (RHCT)
-----Original Message----- From: freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius.org [mailto:freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius .org] On Behalf Of Alan DeKok Sent: Thursday, May 15, 2008 4:22 PM To: FreeRadius users mailing list Subject: Re: FreeRADIUS 2 not listening on right port
Hoggins! wrote:
I'm running FC9, by the way... maybe that explains this sudden amount of same problems, since the FC9 release was on tuesday.
Maybe someone running FC9 could try "debugging" the problem.
I haven't run a redhat-based system for *years*.
Since this works on every other system on the planet, it sounds *very* much like an issue in FC9.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Michael Griego wrote:
I did a little looking into this this evening. This assessment looks to be correct as it looks to be related to compiler optimizations. With the optimizations disabled in Make.inc, FreeRADIUS will start up on the correct port. For the fr_socket function, gcc appears to be optimizing the arguments by sending them through the registers instead of the stack frame, but the "port" argument is being clobbered ("optimized out") before the htons(port) call. Specifically, according to a step-through with GDB, after the first function call in fr_socket (which is to socket()), the port variable is gone ("optimized out").
<sigh> I've started testing the server with other compilers. GCC is getting too ugly for my liking. I'll put a note on the main web page.: DON'T USE -O2 ON FEDORA! Alan DeKok.
Alan DeKok wrote:
Michael Griego wrote:
I did a little looking into this this evening. This assessment looks to be correct as it looks to be related to compiler optimizations. With the optimizations disabled in Make.inc, FreeRADIUS will start up on the correct port. For the fr_socket function, gcc appears to be optimizing the arguments by sending them through the registers instead of the stack frame, but the "port" argument is being clobbered ("optimized out") before the htons(port) call. Specifically, according to a step-through with GDB, after the first function call in fr_socket (which is to socket()), the port variable is gone ("optimized out").
<sigh> I've started testing the server with other compilers. GCC is getting too ugly for my liking.
I'll put a note on the main web page.: DON'T USE -O2 ON FEDORA!
I can confirm this; I've opened a bug in the Fedora bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=446864 ...with any luck, the toolchain will get fixed - it's clearly not a FreeRadius bug, and I wonder what else it's broken...
Yeah I just compiled without optimization and its working fine now. Thomas E. Casartello, Jr. Infrastructure Technician Linux Specialist Department of Information Technology Westfield State College Wilson 105-A (413) 572-8245 E-Mail: tcasartello@wsc.ma.edu Red Hat Certified Technician (RHCT) -----Original Message----- From: freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius.org [mailto:freeradius-users-bounces+tcasartello=wsc.ma.edu@lists.freeradius .org] On Behalf Of Phil Mayers Sent: Friday, May 16, 2008 10:49 AM To: FreeRadius users mailing list Subject: Re: FreeRADIUS 2 not listening on right port Alan DeKok wrote:
Michael Griego wrote:
I did a little looking into this this evening. This assessment looks to be correct as it looks to be related to compiler optimizations. With the optimizations disabled in Make.inc, FreeRADIUS will start up on the correct port. For the fr_socket function, gcc appears to be optimizing the arguments by sending them through the registers instead of the stack frame, but the "port" argument is being clobbered ("optimized out") before the htons(port) call. Specifically, according to a step-through with GDB, after the first function call in fr_socket (which is to socket()), the port variable is gone ("optimized out").
<sigh> I've started testing the server with other compilers. GCC is getting too ugly for my liking.
I'll put a note on the main web page.: DON'T USE -O2 ON FEDORA!
I can confirm this; I've opened a bug in the Fedora bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=446864 ...with any luck, the toolchain will get fixed - it's clearly not a FreeRadius bug, and I wonder what else it's broken... - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
What did you expect from Fedora... To many bugs for my taste :) Michael Griego wrote:
On May 16, 2008, at 9:49 AM, Phil Mayers wrote:
...with any luck, the toolchain will get fixed - it's clearly not a FreeRadius bug, and I wonder what else it's broken...
After discovering what the problem was, I immediately wondered the same thing myself.....
--Mike - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Phil Mayers wrote:
Alan DeKok wrote:
Michael Griego wrote:
I did a little looking into this this evening. This assessment looks to be correct as it looks to be related to compiler optimizations. With the optimizations disabled in Make.inc, FreeRADIUS will start up on the correct port. For the fr_socket function, gcc appears to be optimizing the arguments by sending them through the registers instead of the stack frame, but the "port" argument is being clobbered ("optimized out") before the htons(port) call. Specifically, according to a step-through with GDB, after the first function call in fr_socket (which is to socket()), the port variable is gone ("optimized out").
<sigh> I've started testing the server with other compilers. GCC is getting too ugly for my liking.
I'll put a note on the main web page.: DON'T USE -O2 ON FEDORA!
I can confirm this; I've opened a bug in the Fedora bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=446864
...with any luck, the toolchain will get fixed - it's clearly not a FreeRadius bug, and I wonder what else it's broken...
FYI, I have rebuilt the F-9 RPM with optimization turned off and submitted it for an update (should hit the mirrors sometime soon). Just a heads up. I have some time constraints at my end. The only thing I had time for before leaving until next Wednesday was to rebuild the package, I cannot not confirm at this moment if the resulting package resolves the issue, but given the comments in this thread it would appear to solve the problem in the near term. I thought it was worthwhile to push the new RPM out, even under these constraints. When I return I will investigate the root cause of the failure further. Obviously this is a temporary workaround and if there are compiler issues it needs to get addressed as soon as possible. In the interim I would appreciate feedback on the new package. The new package is: freeradius-2.0.3-3.fc9 My sincere thank you to everyone who contributed to diagnosing the problem and my apologies for not catching this earlier. -- John Dennis <jdennis@redhat.com>
John Dennis wrote:
FYI, I have rebuilt the F-9 RPM with optimization turned off and submitted it for an update (should hit the mirrors sometime soon).
Did I mention I love Redhat? Thanks. Fast turn-around times are wonderful.
My sincere thank you to everyone who contributed to diagnosing the problem and my apologies for not catching this earlier.
If I can get access to a build machine, I'm sure I can do loads of testing... Alan DeKok.
John Dennis wrote:
Phil Mayers wrote:
Alan DeKok wrote:
Michael Griego wrote:
I did a little looking into this this evening. This assessment looks to be correct as it looks to be related to compiler optimizations. With the optimizations disabled in Make.inc, FreeRADIUS will start up on the correct port. For the fr_socket function, gcc appears to be optimizing the arguments by sending them through the registers instead of the stack frame, but the "port" argument is being clobbered ("optimized out") before the htons(port) call. Specifically, according to a step-through with GDB, after the first function call in fr_socket (which is to socket()), the port variable is gone ("optimized out").
<sigh> I've started testing the server with other compilers. GCC is getting too ugly for my liking.
I'll put a note on the main web page.: DON'T USE -O2 ON FEDORA!
Please note, this bug only seems to be present in the F-9 (recently released version 9 of Fedora).
I can confirm this; I've opened a bug in the Fedora bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=446864
...with any luck, the toolchain will get fixed - it's clearly not a FreeRadius bug, and I wonder what else it's broken...
FYI, I have rebuilt the F-9 RPM with optimization turned off and submitted it for an update (should hit the mirrors sometime soon).
Just a heads up. I have some time constraints at my end. The only thing I had time for before leaving until next Wednesday was to rebuild the package, I cannot not confirm at this moment if the resulting package resolves the issue, but given the comments in this thread it would appear to solve the problem in the near term. I thought it was worthwhile to push the new RPM out, even under these constraints.
When I return I will investigate the root cause of the failure further. Obviously this is a temporary workaround and if there are compiler issues it needs to get addressed as soon as possible. I have investigated this further. It does appear as though there is a compiler bug based on my examination of the generated machine code, I have opened the following bug report against GCC. The bug report includes the preprocessed C code, the generated machine code, and the disassembly of the machine code. The bug report also points the exact line (compound statement) which seems to be omitted in the optimized machine code.
https://bugzilla.redhat.com/show_bug.cgi?id=448743 For the time being I will build the F-9 FreeRADIUS packages without optimization until this is resolved.
In the interim I would appreciate feedback on the new package.
The new package is: freeradius-2.0.3-3.fc9
My sincere thank you to everyone who contributed to diagnosing the problem and my apologies for not catching this earlier.
-- John Dennis <jdennis@redhat.com>
Hi,
Please note, this bug only seems to be present in the F-9 (recently released version 9 of Fedora).
For the time being I will build the F-9 FreeRADIUS packages without optimization until this is resolved.
is it a case of this bug doing OTHER things to the codebase etc or is it worth ONLY turning off optimization for the single bit of affected code. turning off optimization for the routines that deal with encryptions etc could be painful. alan
A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
Please note, this bug only seems to be present in the F-9 (recently released version 9 of Fedora).
For the time being I will build the F-9 FreeRADIUS packages without optimization until this is resolved.
is it a case of this bug doing OTHER things to the codebase etc or is it worth ONLY turning off optimization for the single bit of affected code. turning off optimization for the routines that deal with encryptions etc could be painful.
This is a good question. The compiler folks have not responded yet so I don't know if this is an isolated issue in specific code or a more general problem which might rear it's head elsewhere. Unscientific hallway conversations have not turned up any other known F-9 compiler bugs, so this might be isolated to just one function. But in the absence of concrete information about the extent of the compiler malfunction the only prudent thing to do is to completely disable optimization on the belief correct program behaviour trumps performance, especially on a brand new OS release. When more concrete information is known I will consider rebuilding with different optimization. If someone wants to be a guinea pig and run with optimization disabled only on packet.c and see if they have any anomalous behaviour then I'm sure we would all benefit from that experiment, however I cannot in good conscience push such a package into general distribution at this stage. -- John Dennis <jdennis@redhat.com>
Hi,
If someone wants to be a guinea pig and run with optimization disabled only on packet.c and see if they have any anomalous behaviour then I'm sure we would all benefit from that experiment, however I cannot in good conscience push such a package into general distribution at this stage.
updates-testing ? I thought that was the point of that repo ? alan
A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
Please note, this bug only seems to be present in the F-9 (recently released version 9 of Fedora).
For the time being I will build the F-9 FreeRADIUS packages without optimization until this is resolved.
is it a case of this bug doing OTHER things to the codebase etc or is it worth ONLY turning off optimization for the single bit of affected code. turning off optimization for the routines that deal with encryptions etc could be painful.
All, For those not following the Fedora bug, it (or rather, it's dependency) has been closed by Ulrich Drepper. He seems to be saying that the FreeRadius code is incorrect and specifically that an invalid typecast is triggering the compiler to generate bad code: https://bugzilla.redhat.com/show_bug.cgi?id=448743#c6 Summary (as far as I can make out): Because the code looks like this: struct addr if v==4: i = (ip4*)&addr i->port = xx elif v==6: i = (ip6*)&addr i->port = xx bind(&addr) ...the compiler can't detect that the "i" value is "used", and optimises the code touching it away. The "right" way to do it is: union { ip4 i4; ip6 i6; } addr; if v==4: addr.i4.port = xx elif v==6: addr.i6.port = xx bind(&addr) I believe the Python guys have had similar issues in the past; -fno-strict-aliasing might be required under gcc. I'm not expert enough in the C99 standard to judge whether the comments at the above URL are correct or not; I suspect it's a matter of some controversy, and will back slowly away now... ;o)
Phil Mayers wrote:
For those not following the Fedora bug, it (or rather, it's dependency) has been closed by Ulrich Drepper. He seems to be saying that the FreeRadius code is incorrect and specifically that an invalid typecast is triggering the compiler to generate bad code:
Interesting. So GCC doesn't complain, and it generates bad assembly for C code that it thinks is perfectly valid.
https://bugzilla.redhat.com/show_bug.cgi?id=448743#c6
Summary (as far as I can make out): Because the code looks like this: ... ...the compiler can't detect that the "i" value is "used", and optimises the code touching it away.
i.e. GCC doesn't properly analyze the code that it optimizes, so it generates the wrong optimizations. GCC has a history of doing this...
I'm not expert enough in the C99 standard to judge whether the comments at the above URL are correct or not; I suspect it's a matter of some controversy, and will back slowly away now... ;o)
I think your comments about the underlying cause are correct. Ulrich's comments about Posix are interesting:
The invalid casts are forbidden by ISO C. POSIX does not and cannot guarantee anything about this type of use of sockaddr_storage.
To quote the Opengroup page: http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/socket.h.html ... The <sys/socket.h> header shall define the sockaddr_storage structure. This structure shall be: * Large enough to accommodate all supported protocol-specific address structures * Aligned at an appropriate boundary so that pointers to it can be cast as pointers to protocol-specific address structures and used to access the fields of those structures without alignment problems ... i.e. the code in FreeRADIUS is correct. It uses sockaddr_stoage as a generic container for protocol-specific address structures. It casts a pointer to sockaddr_storage to a pointer to protocol-specific address structures. The recommendation to use a union to hold both sockaddr_storage && sockaddr_in is... interesting. If you have to do that, WTF is the use of sockaddr_storage? Looking on the net, I also found a fair amount of code using sockaddr_storage in the recommended Posix way. It appears that FreeRADIUS is OK, and just got hit by a GCC bug. i.e. for ANY code like this: foo = (type_t *) bar; switch (x) { case 1: foo->a = 1; break; ... } function(&bar); GCC will "optimize away" the line doing "foo->a = 1;". Nice. Alan DeKok.
Alan DeKok wrote:
Phil Mayers wrote:
For those not following the Fedora bug, it (or rather, it's dependency) has been closed by Ulrich Drepper. He seems to be saying that the FreeRadius code is incorrect and specifically that an invalid typecast is triggering the compiler to generate bad code:
I wanted to understand the issues surrounding strict aliasing better. I found the following article to be well written, quite readable, and informative: Understanding Strict Aliasing <http://www.cellperformance.com/mike_acton/2006/06/understanding_strict_aliasing.html> http://www.cellperformance.com/mike_acton/2006/06/understanding_strict_alias... If one is to take away any simple concept and/or rule from the article it would have to be these 3 statements: "One pointer is said to /alias/ another pointer when both refer to the same location or object. " "In C99, it is /illegal/ to create an alias of a different type than the original." "Strict aliasing means that two objects of different types cannot refer to the same location in memory." However, note that this is exactly what fr_socket is doing, &salocal is a pointer to sockaddr_storage, sa is in one scope is a pointer to sockaddr_in and in another scope sa is a pointer to sockaddr_in6. Each of these 3 pointers point to exact same memory location, according to the above definitions this is a classic case of illegal pointer aliasing. if (ipaddr->af == AF_INET) { struct sockaddr_in *sa; sa = (struct sockaddr_in *) &salocal; sa->sin_port = htons((uint16_t) port); } else if (ipaddr->af == AF_INET6) { struct sockaddr_in6 *sa; sa = (struct sockaddr_in6 *) &salocal; sa->sin6_port = htons((uint16_t) port); }
Interesting. So GCC doesn't complain, and it generates bad assembly for C code that it thinks is perfectly valid.
Agreed, GCC should have flagged this. However, for what it's worth the above article states the compiler may not always be able to recognize various illegal constructs and programmers should not depend it. If and when GCC should emit warnings is a subject for debate, but I think we can all agree it would have been nicer if GCC had emitted a warning. It's a shame it didn't, but I don't think it changes the overarching issue. Also, in expediency I did not try building with the various GCC warning flags to see if I could get GCC to emit a warning for this case, perhaps GCC at some level of verbosity would have complained.
https://bugzilla.redhat.com/show_bug.cgi?id=448743#c6
Summary (as far as I can make out): Because the code looks like this:
...
...the compiler can't detect that the "i" value is "used", and optimises the code touching it away.
Yup, this is weird, but as I understand it illegal constructs produce undefined results, perhaps the fact GCC stored some LHS values but not others is just an example of "undefined".
i.e. GCC doesn't properly analyze the code that it optimizes, so it generates the wrong optimizations. GCC has a history of doing this...
I'm not expert enough in the C99 standard to judge whether the comments at the above URL are correct or not; I suspect it's a matter of some controversy, and will back slowly away now... ;o)
I think your comments about the underlying cause are correct. Ulrich's comments about Posix are interesting:
The invalid casts are forbidden by ISO C. POSIX does not and cannot guarantee anything about this type of use of sockaddr_storage.
To quote the Opengroup page:
http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/socket.h.html
... The <sys/socket.h> header shall define the sockaddr_storage structure. This structure shall be:
* Large enough to accommodate all supported protocol-specific address structures
* Aligned at an appropriate boundary so that pointers to it can be cast as pointers to protocol-specific address structures and used to access the fields of those structures without alignment problems ...
i.e. the code in FreeRADIUS is correct. For what it's worth my reading of the above statements is different than yours. I read the above as sockaddr_storage provides a type whose size is sufficient to hold all sockaddr types while respecting the alignment requirement in any given sockaddr type. The discussion of pointer casting fails to make explicit such casting must still conform to the rules of C99. I do not read the second paragraph as meaning pointer aliasing shall be supported, something outside that scope of that document.
Proper type casting is discussed in the above article in the section: "Casting through a union (1 & 2)" which states "The most commonly accepted method of converting one type of object to another is by using a union". Note this is what both Jakub and Ulrich independently suggested in the bug report. Also note that the suggested union contains "a compatible member", which as I understand is necessary to satisfy the rules as well as providing enough information for the compiler.
It uses sockaddr_stoage as a generic container for protocol-specific address structures. It casts a pointer to sockaddr_storage to a pointer to protocol-specific address structures. The recommendation to use a union to hold both sockaddr_storage && sockaddr_in is... interesting. If you have to do that, WTF is the use of sockaddr_storage?
Looking on the net, I also found a fair amount of code using sockaddr_storage in the recommended Posix way. It appears that FreeRADIUS is OK, and just got hit by a GCC bug.
i.e. for ANY code like this:
foo = (type_t *) bar; switch (x) { case 1: foo->a = 1; break; ... } function(&bar);
GCC will "optimize away" the line doing "foo->a = 1;". Nice.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
I have created a patch for packet.c which uses a union (the patch is attached). I built freeradius 2.0.4 with the patch and -O2 optimization and the random port problem seems to have been resolved. Note, I have not looked though all the source code to see if there are other code constructs which may also require a fix. I expect I'll push a 2.0.4 version of FreeRADIUS with full -O2 optimization into the F-9 updates-testing stream with the patch. However, I'll wait a bit to see if others chime in with any other known problem areas first which should be folded into any such patch. Also, does anyone (Alan?) have any problems with updating the bug report with some of this email dialog to capture the issues for future readers? -- John Dennis <jdennis@redhat.com> diff -u freeradius-server-2.0.4/src/lib/packet.c.orig freeradius-server-2.0.4/src/lib/packet.c --- freeradius-server-2.0.4/src/lib/packet.c.orig 2008-05-29 11:53:26.000000000 -0400 +++ freeradius-server-2.0.4/src/lib/packet.c 2008-05-29 12:13:41.000000000 -0400 @@ -175,8 +175,14 @@ int fr_socket(fr_ipaddr_t *ipaddr, int port) { int sockfd; - struct sockaddr_storage salocal; socklen_t salen; + union { + struct sockaddr sa; + struct sockaddr_storage ss; + struct sockaddr_in in4; + struct sockaddr_in6 in6; + } sa; + if ((port < 0) || (port > 65535)) { librad_log("Port %d is out of allowed bounds", port); @@ -198,25 +204,19 @@ } #endif - memset(&salocal, 0, sizeof(salocal)); + memset(&sa, 0, sizeof(sa)); if (ipaddr->af == AF_INET) { - struct sockaddr_in *sa; - - sa = (struct sockaddr_in *) &salocal; - sa->sin_family = AF_INET; - sa->sin_addr = ipaddr->ipaddr.ip4addr; - sa->sin_port = htons((uint16_t) port); - salen = sizeof(*sa); + sa.in4.sin_family = AF_INET; + sa.in4.sin_addr = ipaddr->ipaddr.ip4addr; + sa.in4.sin_port = htons((uint16_t) port); + salen = sizeof(sa.in4); #ifdef HAVE_STRUCT_SOCKADDR_IN6 } else if (ipaddr->af == AF_INET6) { - struct sockaddr_in6 *sa; - - sa = (struct sockaddr_in6 *) &salocal; - sa->sin6_family = AF_INET6; - sa->sin6_addr = ipaddr->ipaddr.ip6addr; - sa->sin6_port = htons((uint16_t) port); - salen = sizeof(*sa); + sa.in6.sin6_family = AF_INET6; + sa.in6.sin6_addr = ipaddr->ipaddr.ip6addr; + sa.in6.sin6_port = htons((uint16_t) port); + salen = sizeof(sa.in6); #if 1 /* @@ -240,7 +240,7 @@ return sockfd; /* don't bind it */ } - if (bind(sockfd, (struct sockaddr *) &salocal, salen) < 0) { + if (bind(sockfd, &sa.sa, salen) < 0) { close(sockfd); return -1; }
John Dennis wrote:
I wanted to understand the issues surrounding strict aliasing better. I found the following article to be well written, quite readable, and informative:
I found a NetBSD post with similar information: http://mail-index.netbsd.org/tech-kern/2003/08/11/0001.html
However, note that this is exactly what fr_socket is doing, &salocal is a pointer to sockaddr_storage, sa is in one scope is a pointer to sockaddr_in and in another scope sa is a pointer to sockaddr_in6. Each of these 3 pointers point to exact same memory location, according to the above definitions this is a classic case of illegal pointer aliasing.
Under ISO C89, and ISO C99. But it appears to be legal under the Posix description for "struct sockaddr_storage". Aren't standards wonderful.
It's a shame it didn't, but I don't think it changes the overarching issue. Also, in expediency I did not try building with the various GCC warning flags to see if I could get GCC to emit a warning for this case, perhaps GCC at some level of verbosity would have complained.
I've done some builds with "-fstrict-aliasing -Wstrict-aliasing=2". Ignoring the casts on parameters to functions, I've fixed a number of things, through the simple expedient of using memcpy() to copy from (struct sockaddr_storage) to (struct sockaddr_in), and back. It's ugly, but it SHOULD work.
For what it's worth my reading of the above statements is different than yours. I read the above as sockaddr_storage provides a type whose size is sufficient to hold all sockaddr types while respecting the alignment requirement in any given sockaddr type. The discussion of pointer casting fails to make explicit such casting must still conform to the rules of C99. I do not read the second paragraph as meaning pointer aliasing shall be supported, something outside that scope of that document.
At the minimum, the Opengroup specs seem misleading.
Proper type casting is discussed in the above article in the section: "Casting through a union (1 & 2)" which states "The most commonly accepted method of converting one type of object to another is by using a union".
Note this is what both Jakub and Ulrich independently suggested in the bug report.
Which makes me wonder WTF is the use of 'struct sockaddr_storage'. All of the documentation I've read indicates that it's *supposed* to be the preferred structure to cast back and forth to 'struct sockaddr_in'... but that's forbidden by ISO C89. You'd think that if the Posix people read the ISO C specs, they would have created a 'struct sockaddr_union', which was defined to be the union of all types, and which would have avoided these problems. Maybe I'm naive...
I have created a patch for packet.c which uses a union (the patch is attached). I built freeradius 2.0.4 with the patch and -O2 optimization and the random port problem seems to have been resolved. Note, I have not looked though all the source code to see if there are other code constructs which may also require a fix.
There's a number. Please try CVS head. I've committed a whack of memcpy's, which SHOULD avoid these issues. (And avoid umpteen unions).
Also, does anyone (Alan?) have any problems with updating the bug report with some of this email dialog to capture the issues for future readers?
I'd like to say that for me, the Posix spec is clear: casting between 'struct sockaddr_storage' and other 'struct sockaddr_*' is explicitely allowed. Looking at code on the net, there are LOTS of programs doing this. What is a different about FreeRADIUS is that it's *accessing* the pointer after the cast, and not just passing it to a function. This appears to be explicitly required by Posix: ...pointers to it can be cast as pointers to protocol-specific address structures and used to access the fields of those structures without alignment problems... i.e. TO ACCESS the fields. ACCESS to me means ACCESS. R/W ACCESS. Except that this is forbidden by ISO C89, and no one else does it. <sigh> It serves me right for reading only half of the 10's of 1000's of pages of specs. Alan DeKok.
Just installed 2.0.4 with MySQL Support from Ubuntu Repositories and got the same problem: (http://packages.ubuntu.com/de/intrepid/i386/freeradius/download and http://packages.ubuntu.com/de/intrepid/i386/freeradius-mysql/download) Listening on authentication address * port 1087 Listening on accounting address * port 1088 Listening on proxy address * port 1089 Ready to process requests. next start: Listening on authentication address * port 1090 Listening on accounting address * port 1091 Listening on proxy address * port 1093 Ready to process requests. next start: Listening on authentication address * port 1093 Listening on accounting address * port 1094 Listening on proxy address * port 1095 Ready to process requests. ...... Seems that the Port are increasing. Greets Chris -- View this message in context: http://www.nabble.com/FreeRADIUS-2-not-listening-on-right-port-tp17258249p17... Sent from the FreeRadius - User mailing list archive at Nabble.com.
doc74 wrote:
Just installed 2.0.4 with MySQL Support from Ubuntu Repositories and got the same problem: .... Seems that the Port are increasing.
Wow. There's nothing in the server that remembers ports from one execution to the next. I'm running FreeRADIUS on ubuntu 7.10, and I don't see this. I've also run it (again from source) on 8.04, and I don't see this. Try compiling it from source... Alan DeKok.
Alan DeKok wrote:
doc74 wrote:
Just installed 2.0.4 with MySQL Support from Ubuntu Repositories and got the same problem:
....
Seems that the Port are increasing.
Wow. There's nothing in the server that remembers ports from one execution to the next.
I'm running FreeRADIUS on ubuntu 7.10, and I don't see this. I've also run it (again from source) on 8.04, and I don't see this.
Try compiling it from source...
Recall this problem is the consequence of two independent factors: * the C source code use of pointer aliasing * the compiler used and optimization level The 2.0.5 version has Alan's fixes for pointer aliasing, if you build from source using a version less than 2.0.5 then your results will be dependent on the compiler. Rather than relying on your local compiler being more forgiving it might be wise to use 2.0.5 which contain the fixes which provoked the problem in the first place. -- John Dennis <jdennis@redhat.com>
participants (10)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Casartello, Thomas -
Danner, Mearl -
doc74 -
Hoggins! -
John Dennis -
Marinko Tarlac -
Michael Griego -
Phil Mayers