tasklwIP - A Lightweight TCP/IP stack - Tasks: task #6995, Implement SO_REUSEADDR

 
 

You are not allowed to post comments on this tracker with your current authentication level.

task #6995: Implement SO_REUSEADDR

Submitter:  Frédéric Bernon <fbernon>
Submitted:  Sat 09 Jun 2007 12:02:00 PM UTC
   
 
Category:  None Should Start On:  Fri 08 Jun 2007 10:00:00 PM UTC
Should be Finished on:  Fri 08 Jun 2007 10:00:00 PM UTC Priority:  1 - Later
Status:  Done Privacy:  Public
Assigned to:  goldsimon Percent Complete:  100%
Open/Closed:  Closed Planned Release:  None
Effort:  0.00

Jump to the original submission

Mon 17 May 2010 12:55:29 PM UTC, comment #11: 

Great, thanks for testing!

 Simon Goldschmidt <goldsimon>
Group administrator
Mon 17 May 2010 09:25:42 AM UTC, comment #10: 

Hi Simon,
thanks for implementing this so quickly.
I tested it this morning successfully for UDP and TCP.

Stephane Lesage <slesage>
Sat 15 May 2010 05:15:50 PM UTC, comment #9: 


> What remains is that for multicast/broadcast, received data
> would have to be duplicated so that all (UDP-)PCBs listening on
> the same port get a copy of the data.


Done. Added an extra option SO_REUSE_RXTOALL for that as it is kind of slow (traverses the full udp_pcbs list a 2nd time for every broadcast/multicast packet received).

Also, for full SO_REUSEADDR support, I had to add a 5-tuple-uniqueness-check in tcp_connect() and tcp_listen().

The 3rd change was to allow binding multiple listening pcbs to the same port by allowing IP_ADDR_ANY and specific IPs (e.g. IP of every netif) and then in tcp_input(), first searching for a specific match and only if that fails passing the SYN packet to the IP_ADDR_ANY-listening pcb.

All this only changed with SO_REUSE==1 (which is still off by default), so doesn't have a negative impact for those who don't use it.

 Simon Goldschmidt <goldsimon>
Group administrator
Wed 12 May 2010 10:36:13 PM UTC, comment #8: 

Nearly done: SO(F)_REUSEADDR must be set to allow sharing a local port (and/or address).

What remains is that for multicast/broadcast, received data would have to be duplicated so that all (UDP-)PCBs listening on the same port get a copy of the data.

 Simon Goldschmidt <goldsimon>
Group administrator
Sat 13 Feb 2010 11:28:09 AM UTC, comment #7: 

Since this task has been about UDP/multicast mainly, just a link to discussion about SO_REUSEADDR for TCP: patch #6865: SO_REUSEADDR for TCP

 Simon Goldschmidt <goldsimon>
Group administrator
Thu 29 Nov 2007 01:44:41 AM UTC, comment #6: 

You should be able to bind to 255.255.255.255 - it is meant to have the same meaning as INADDR_ANY. From the ip(7) manpage on linux:
-=-=-=-=-=-=-=-
       There are several special addresses: INADDR_LOOPBACK (127.0.0.1) always refers to the local host via the
       loopback device; INADDR_ANY (0.0.0.0) means any address for binding; INADDR_BROADCAST  (255.255.255.255)
       means any host and has the same effect on bind as INADDR_ANY for historical reasons.
-=-=-=-=-=-=-=-

In order to send/receive broadcast datagrams, instead in POSIX the SO_BROADCAST flag is used:
http://www.opengroup.org/pubs/online/7908799/xns/setsockopt.html

Although that link only says "transmission" and my Linux man page says: "When enabled, datagram sockets receive packets sent to a broadcast address and they are allowed to send packets to a broadcast address."

 Jonathan Larmour <jifl>
Group Member
Wed 28 Nov 2007 07:16:48 PM UTC, comment #5: 

one of the local ip addresses, or "any" (all interfaces).

That's why I asked in bug #21656 if there was any real reference to know what is a "standard" practice, and what is not.

Is it possible to bind to the broadcast address (255.255.255.255)? What is/should be the behavior?

Frédéric Bernon <fbernon>
Group Member
Wed 28 Nov 2007 07:11:42 PM UTC, comment #4: 


> bind a local multicast address?


I thought that was how it's done... Never used multicast...

Which local address do you bind to when receiving UDP multicast?

 Simon Goldschmidt <goldsimon>
Group administrator
Wed 28 Nov 2007 01:16:59 PM UTC, comment #3: 


>udp_bind does currently not check for multiple binding, which looks like a bug to me! This was disabled because it prevented binding multiple pcbs to a local multicast address. I think that should be changed.


bind a local multicast address? When you want to receive multicast, you just have to bind to a local/netif ip address (or "any"), and join the group. Same for broadcast. Or I don't understand your comment?



Frédéric Bernon <fbernon>
Group Member
Wed 28 Nov 2007 12:44:32 PM UTC, comment #2: 

Some more notes:

- udp_bind does currently not check for multiple binding, which looks like a bug to me! This was disabled because it prevented binding multiple pcbs to a local multicast address. I think that should be changed.

- when incoming packets are for multicast, udp_input should call the recv function for all udp_pcbs listening to that port & address. Currently, only the first pcb in the list will receive the data...

 Simon Goldschmidt <goldsimon>
Group administrator
Tue 04 Sep 2007 09:03:35 AM UTC, comment #1: 

Some notes:

in udp.c, we can found some code disabled by LWIP_UDP_TODO option, in udp_bind, and this comment:

"this code does not allow upper layer to share a UDP port for listening to broadcast or multicast traffic (See SO_REUSE_ADDR and SO_REUSE_PORT under *BSD). TODO: See where it fits instead, OR combine with implementation of UDP PCB flags. Leon Woestenberg."

Frédéric Bernon <fbernon>
Group Member
Sat 09 Jun 2007 12:02:00 PM UTC, original submission:  

Replace http://savannah.nongnu.org/bugs/?2809:

"Implement REUSEADDR in udp.c (by expanding the udp_pcb data structure)."

Frédéric Bernon <fbernon>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by slesage (Posted a comment)
  • -email is unavailable- added by jifl (Posted a comment)
  • -email is unavailable- added by goldsimon (Posted a comment)
  • -email is unavailable- added by fbernon (Submitted the item)

    •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-05-15 goldsimon StatusIn Progress Done
        Percent Complete90% 100%
        Open/ClosedOpen Closed
    2010-05-12 goldsimon StatusNone In Progress
        Percent Complete0% 90%
        Assigned toNone goldsimon

    Back to the top

    Copyright © 2024 Free Software Foundation, Inc.
    Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
    The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team.
    Page source code

    Powered by Savane 3.13-8a8d.
    Corresponding source code