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

[Frédéric Bernon]

Follow-up Comment #2, bug #26309 (project lwip):

The problem is I received in my lwIP device's socket some broadcast traffic
between another application (not mine) and another device (not mine).

In a classical system (windows or linux), don't have the SO_BROADCAST option
enabled on a socket will avoid to receive and queue such broadcast traffic
where the "dest" port is the same than my socket local one (this is a unlucky
case, but this case happens on the field).

>For a normal socket, not reading from it when it is receiving data is
essentially a bug in the application

It's not, if the socket is only use to send packets, why do you want I do any
extra recvfrom ? Here a classical socket "sender" (without any checking for
the explain = socket( AF_INET, SOCK_DGRAM, 0);

memset( &saLocal, 0, sizeof(saLocal));
saLocal.sin_family      = AF_INET;
saLocal.sin_port        = htons(INADDR_ANY);
saLocal.sin_addr.s_addr = htonl(INADDR_ANY);

bind( ivp->hSocket, (struct sockaddr *)&saLocal, sizeof(saLocal));

namelen = sizeof(saLocal);
getsockname( hSocket, (struct sockaddr *)&saLocal, &namelen);
printf("saLocal.sin_port==%lun", (unsigned long)ntohs(saLocal.sin_port));

while(1) {
  sendto(...)
}

In a such code, the socket only send data (rtp packets in my case). The
getsockname show that the local port is 4096. In the case I described, any
broadcast traffic with dest to 4096/udp will be queued on lwIP (since even if
SO_BROADCAST is not set, packets are enqueued since the option is not
implemented). On Linux or Windows, you will not have such problem since their
IP stacks implement SO_BROADCAST: so, since the option is not set on the
socket, broadcast packets are dropped by the stack...

Since lwIP use a common poll of resources for all sockets, this case can stop
the stack to work (by example, ARP packets will stop to be received, with all
the bad consequences you can guess).

Of course, in raw api, since all incoming packets can be processed by the
recv callback, it's different. But with sockets, we should not have to call
lwip_recvfrom + MSG_DONTWAIT to flush any incoming traffic: doing a such
workaround is not a "nice" solution.

I will write a patch file to explain how I see the solution. I think that
only some lines are needed...



    _______________________________________________________

Reply to this item at:

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

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