[ECOS] fileio tests fail in a catch 22 situation ?!?

robin_singh@gmx.net robin_singh@gmx.net
Sun May 25 17:34:00 GMT 2003


Greetings. 
 
The io/fileio/socket.c and io/fileio/select.c tests are failing on my 
architecture in a 
mysterious manner. 
 
I am using the FreeBSD stack and eCos v2.0 (latest) 
 
Both tests create a global socket and associate a port (1234) with it. 
The IP to which the socket will bind is 127.0.0.1 (loopback). 
There are two POSIX threads created by these tests. 
One thread does a bind () using this socket, which is global. 
The other thread is doing a connect on the same socket. 
The test is failing because connect () returns -1 Can't assign requested
address 
(EADDRNOTAVAIL) 
 
While tracing through the code, I noticed the following: 
 
1. In file bsd_tcpip/current/src/sys/netinet/in_pcb.c 
The function in_pcbbind() does the following: 
182			 lport = sin->sin_port; 
183                 if (IN_MULTICAST(ntohl(sin->sin_addr.s_addr))) { 
184                         /* 
185                          * Treat SO_REUSEADDR as SO_REUSEPORT for
multicast; 
186                          * allow complete duplication of binding if 
187                          * SO_REUSEPORT is set, or if SO_REUSEADDR is
set 
188                          * and a multicast address is bound on both 
189                          * new and duplicated sockets. 
190                          */ 
191                         if (so->so_options & SO_REUSEADDR) 
192                                 reuseport = SO_REUSEADDR|SO_REUSEPORT; 
193                 } else if (sin->sin_addr.s_addr != INADDR_ANY) { 
194                         sin->sin_port = 0;              /* yech... */ 
195                         if (ifa_ifwithaddr((struct sockaddr *)sin) == 0)

196                                 return (EADDRNOTAVAIL); 
197                 } 
 
Why is the port number being zeroed in line 192 ? 
Later when the connect is done by the other thread, the code in the same
file, in 
function in_pcbladdr() does the following: 
314         if (sin->sin_port == 0) 
315                 return (EADDRNOTAVAIL); 
 
So hereafter, everytime a connect () call is made, the call will fail and
return 
EADDRNOTAVAIL since the bind() call made earlier has zeroed the sin_port
field of 
the sockaddr_in structure representing this socket!!! 
 
If this is the case, then the eCos tests supplied are incorrectly
associating the 
socket with the loopback address 127.0.0.1 but should in fact use INADDR_ANY

instead (this works for me!) 
 
This looks like a Catch 22 situation. 
 
I also tried changing the tests to use seperate sockets per thread rather
than the 
same global socket and the tests succeeded. 
 
I'm puzzled. 
 
Any clues would be much appreciated. 
Many thanks, 
Robin. 
 

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss



More information about the Ecos-discuss mailing list