David S. Miller writes:
> From: Mateus Cordeiro Inssa <mateus@ifnet.com.br>
> Date: Sun, 30 Jan 2000 00:40:40 -0200 (BRDT)
>
> I saw this messages too and what I discovered was:
>
> 1) Create an udp socket and bind it to a port and INADDR_ANY
> 2) Send a mensage to this socket from localhost
> 3) The first recvfrom returns the sockaddr with address (IP) equal 0
> (not 127.0.0.1 or ethernet address) and replying to this request with
> this sockaddr causes that printk .
> 4) Next recvfrom returns sockaddr right.
>
> In #3 an error was returned, and when an error occurs the contents
> of the sockaddr you pass in is undefined on returned. This should
> be the only way you could see the behavior you describe.
I'm not sure, but it seemed full of zeroes.
> The IP address being zero supports this fact.
>
> So the code in question should have checked the error return
> from the recvmsg call at #3. I bet this application puts
> the socket in non-blocking mode too.
Of course the application check for errors, but the error always
occur in the first recvfrom. The application doesn't change any
socket property, so I assume it is on blocking mode.
The sequence is: socket, bind, select,recvfrom. No one uses any
extra param.
>
> Later,
> David S. Miller
> davem@redhat.com
Mateus Cordeiro Inssa
---------------------
Linux User: 76186 Kernel: 2.3.40
ICQ (Licq): 15243895
---------------------
mateus@ifnet.com.br
mateus@cwb.fnn.net
Mon Jan 31 09:13:54 BRDT 2000
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:28 EST