[lwip-devel] [bug #26309] Implement SOF_BROADCAST

[Frédéric Bernon]

URL:
  <http://savannah.nongnu.org/bugs/?26309>

                 Summary: Implement SOF_BROADCAST
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: fbernon
            Submitted on: jeu 23 avr 2009 15:10:55 CEST
                Category: None
                Severity: 3 - Normal
              Item Group: Feature Request
                  Status: None
                 Privacy: Public
             Assigned to: fbernon
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: CVS Head

    _______________________________________________________

Details:

I propose to implement SOF_BROADCAST option. I post that like a bug because
without it, we could block the stack some cases. I explain:

On my network, one application use a "IP device detection" like this: the
application send a "discover device" udp message in broadcast, the device send
its response with a broadcast on the application's "source" udp port. Like
this, the device can be detected even if the application and the device are
not on the same ip subnet. In my domain (IP video devices), lot of
manufacturers do the same thing.

The problem is the response: since the application create its socket with
"any" as port, most of time, the source port is sometimes 4096/udp. On my lwIP
device (which is not managed by this application), I got a udp socket which
only send udp packets, so, it is also binded with "any" port, and lwIP give
it... 4096 (which is defined by UDP_LOCAL_PORT_RANGE_START).

Since I never "read" the socket (the protocol doesn't need it), each time
that the other device send its response to 255.255.255.255:4096, my lwIP
device receive the packet, and this one is queued. Since I never read the
socket, and since my mailboxes are not really limited, all my PBUF_POOL (the
type I use for incoming packets) are queued, and after several months (that's
why it was difficult to find the problem), all resources are queued in my
mailbox, and the stack stop to work, due to the fact that don't have any
PBUF_POOL for incoming packets.

I thought, and it was my mistake, that SO_BROADCAST (SOF_BROADCAST in RAW
API), was implemented. When I look in sockets.h, its indicated
"Unimplemented", but the setsockopt doesn't return ENOPROTOOPT (since the code
really put the SOF_BROADCAST flag in pcb.ip::so_options).

Since my lwip socket never set the option SO_BROADCAST, I thought I will
never got this problem. In most of systems (windows & linux), if you don't
have this option on a socket, it disable the broadcast on send and recv
operations. I now that
http://www.opengroup.org/pubs/online/7908799/xns/setsockopt.html only talks
about the "send", but not linux pages and MSDN ones talk about both
operations.

One workaround could be to use SO_RCVBUF option to have a "0 bytes" receive
buffer size. Another one is to patch my embedded code to be sure that all my
sockets flush any incoming packets (with a lwip_recvfrom + MSG_DONTWAIT).

But I thought it's better to implement this SOF_BROADCAST checking in
raw_input and in udp_input (at the level, the option would be valid for all
lwIP API). For the send, it could be done in raw_sendto and udp_sendto_if.

The only problem I see is that implement this option will change the current
lwIP behavior for application using broadcast, but I think it's better than
stay like this. Else, we could implement a LWIP_SOF_BROADCAST option in
opt.h.

Of course, in my case, I could got the same kind of problem if "someone" send
on this socket unicast udp packets. But it's a more a "security" case, than a
"stability" one.

Since the change will be small, I think to check in it in the current CVS.

Thoughts ?












    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?26309>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.nongnu.org/