buglwIP - A Lightweight TCP/IP stack - Bugs: bug #49662, UDP layer should filter incoming...

 
 

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

bug #49662: UDP layer should filter incoming multicast datagrams against the bound IP address

Submitted by:  Sam Kearney <skearney>
Submitted on:  Mon 21 Nov 2016 04:43:57 PM UTC  
 
Category: UDPSeverity: 3 - Normal
Item Group: Change RequestStatus: Fixed
Privacy: PublicAssigned to: None
Open/Closed: ClosedPlanned Release: None
lwIP version: Other

Wed 23 Nov 2016 03:03:25 PM UTC, comment #4:

I agree with David's comment. The BSD socket semantics allows receiving multicast if the socket is bound to IP_ADDR_ANY or the multicast group (assuming IP membership has been added on the socket as well). Being able to receive multicast when bound to an interface IP is not BSD semantics (strangely multicast receive works in Winsock this way)

I think LwIP code allows binding to a multicast group because when comparing pcb->local_ip with ip_current_dest_addr(), local_ip should be the multicast group

Joel Cunningham <jcunningham>
Project Member
Wed 23 Nov 2016 02:10:52 PM UTC, comment #3:

The change makes sense to me. I'd just like to add a small informational note regarding the patch's commit message, because I misunderstood the patch at first: "Multicast traffic is now only received on a UDP PCB [..] when the PCB is bound to IP_ADDR_ANY." - it should be, and I believe it still is, possible to receive multicast traffic from a single multicast address by binding the UDP socket to that multicast address (eg see RFC 3493 Sec. 5.2, very last sentence). That is however a different kind of filtering than what was changed here.

David van Moolenbroek <dcvmoole>
Wed 23 Nov 2016 12:06:12 PM UTC, comment #2:

To do the same in socket API (compare input netif with desired netif) we need to implement recvmsg() in socket API - which Simon just added as task #14247.

Dirk Ziegelmeier <dziegel>
Project Member
Wed 23 Nov 2016 12:04:09 PM UTC, comment #1:

Fixed in udp_input_local_match(). After some socket API reading, it seems this behavior is what the socket API does.

This may break existing applications - it is now NOT possible to receive multicasts just from a specific netif any more.

Users get the multicasts of all netifs now, and have to compare ip_current_netif() with the desired netif.

The current behavior was added in 2007, but it does not make much sense, because this can be solved otherwise, as described above.

lwip-developers: Is this change OK? Please comment.

Dirk Ziegelmeier <dziegel>
Project Member
Mon 21 Nov 2016 04:43:57 PM UTC, original submission:

Hi,

First a disclaimer: I'm not sure if this is the right place to register this gripe; I couldn't find a forum where someone could tell me if I'm being stupid or missing a compile-time option to change this behavior. So, sorry in advance if that's the case.

I am attempting to use lwIP 2.0.0 through the sockets API to support a higher-level protocol that makes heavy use of UDP multicast and unicast traffic on the same port. I'm finding that if I bind a socket to the specific interface IP address (rather than INADDR_ANY), that socket will still receive datagrams addressed to its port and a multicast address to which some other socket has subscribed. This seems to be due to the logic in udp_input_local_match(), which lets through any datagram addressed to a multicast address.

We have existing ports of our protocol for Windows, Mac OSX, Debian Linux and VxWorks, and all of those platforms filter incoming multicast datagrams against a socket's bound address in addition to the port. I hope this is sufficient justification to change this behavior, since standardization of multicast at the transport layer seems to be light.

It's difficult to add application-layer filtering to deal with this, since the lwIP sockets API doesn't seem to provide a way to get the <em>destination</em> address of an incoming datagram (this is possible in BSD sockets with the recvmsg function).

Sam Kearney <skearney>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by jcunningham (Posted a comment)
  • -unavailable- added by dcvmoole (Posted a comment)
  • -unavailable- added by dziegel (Posted a comment)
  • -unavailable- added by skearney
  • -unavailable- added by skearney (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 23 Nov 2016 12:04:09 PM UTCdziegelStatusNone=>Fixed
      Open/ClosedOpen=>Closed
    Mon 21 Nov 2016 07:13:26 PM UTCskearneyCarbon-Copy-=>Added -unavailable-

    Back to the top


    Powered by Savane 3.1-cleanup1