[fuse-emulator-devel] [ fuse-emulator-Bugs-3459755 ] Spectranet cannot bind udp server port

[SourceForge.net <no...@so...>]

Bugs item #3459755, was opened at 2011-12-14 15:00
Message generated for change (Comment added) made by sbaldovi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=596648&aid=3459755&group_id=91293

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Sergio Baldovi (sbaldovi)
Assigned to: Philip Kendall (pak21)
Summary: Spectranet cannot bind udp server port

Initial Comment:
"udpserver" example doesn't work because the socket is not bound to the source port.

Wiznet W5100 datasheet advise us to set source port before OPEN command. Is this mandatory?
Sn_MR = 0x02; /* sets UDP mode */
Sn_PORT = source_port; /* sets source port number */
Sn_CR = OPEN; /* sets OPEN command */

However, socklib works differently:
socket() /* sets UDP mode and OPEN command */
bind() /* sets source port number */
recvfrom() /* process incoming data */

Comes bind() too late to the party? Does anyone know if this example works in a real Spectranet?

Since OPEN is the sole command used, I guess we should bind the UDP port when the Sn_PORT register is written. E.g., see attachment.

----------------------------------------------------------------------

>Comment By: Sergio Baldovi (sbaldovi)
Date: 2011-12-25 12:44

Message:
It looks great but there is a missing return statement.

Index: peripherals/nic/w5100_socket.c
===================================================================
--- peripherals/nic/w5100_socket.c	(revision 4614)
+++ peripherals/nic/w5100_socket.c	(working copy)
@@ -405,6 +405,7 @@
       if( w5100_socket_bind_port( self, socket ) ) {
         w5100_socket_release_lock( socket );
         socket->bind_count = 0;
+        return;
       }
       w5100_socket_release_lock( socket );
       nic_w5100_wake_io_thread( self );


----------------------------------------------------------------------

Comment By: Philip Kendall (pak21)
Date: 2011-12-24 08:10

Message:
A rewritten but logically the same version of this has been committed in
r4614 - thanks.

On further thought:

* Don't do the "bind on PORTn write" for TCP connections, as it might cause
problems. We're safe if we always bind when the socket is first used.
* Keep the "bind on sendto()" behaviour for UDP clients, as it can't cause
any problems.

----------------------------------------------------------------------

Comment By: Philip Kendall (pak21)
Date: 2011-12-24 02:19

Message:
I've discussed this with Dylan before, and it certainly does work on the
real Spectranet, despite what the datasheet says. TCP sockets and UDP
sendto()s work round this by binding the socket on listen/connect/sendto,
but we don't get a place to hook into to use that same pattern with UDP
recvfrom(), so I can't see a way of doing it which is fundamentally better
than this patch - I'd like to push the count variable down into the socket
structure rather than having it as a global variable, but there's no real
difference there.

I *think* that if we do this change, we won't need the hook in
w5100_socket_send() to bind the socket (as that will already have been
done). Similarly, I think we could do the same thing for TCP sockets and
then not need the hooks in w5100_socket_listen() and
w5100_socket_connect(), but all this will need testing - I'll try and do
that over the next couple of days.

Just a word of warning for any Debian users trying to compile the
Spectranet examples: z88dk version 1.8.ds1-9 in testing seems to me to be
fundamentally broken - see http://bugs.debian.org/653110 The good news here
is that you can revert back to the stable version (1.8.ds1-7) and things
work again.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=596648&aid=3459755&group_id=91293