lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [patch #9169] Allows multicast packets through udp input la


From: Alex Moran
Subject: [lwip-devel] [patch #9169] Allows multicast packets through udp input layer
Date: Tue, 22 Nov 2016 21:06:11 +0000 (UTC)
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36

Follow-up Comment #7, patch #9169 (project lwip):

> You (OP) mix up remote address with local address. udp_connect() tells the
stack something about the remote address. This is the SRC in incoming packets.
You compare it against DST of these packets but only for multicast IPs. That
does not make sense at all! 

It does make sense. The incoming IP header of a multicast packet has the DST
as the multicast address and the src as the senders IP. If we have "connected"
the pcb to a multicast address, we want to process at the application layer
all packets that are sent to 239.1.80.1. So if the connected IP address is the
PCB's remote pcb is multicast, we want to compare the DST address with the
remote PCB.

To take an example of an ip's from 192.168.1.2 and 192.168.1.3 are sending
packets to Multicast Address 239.1.80.1, and the receiver (us) connects to a
pcb to address 239.1.80.1. We want to receive all the packets sent to
239.1.80.1 on one PCB.

The multicast packet will have a src of 192.168.1.2/3 with a destination of
239.1.80.1, and the remote PCB will be looking for all traffic going to
239.1.80.1.

Currently, it is only comparing the pcb->remote_ip (239.1.80.1) with the src
ip (192.168.1.2/3). If the remote IP is 239.1.80.1, a multicast address, we
want to compare the destination IP (239.1.80.1) with our remote IP (also
239.1.80.1).

If the connected remote PCB is not a multicast address, we want to do 
           ip_addr_cmp(&(pcb->remote_ip), &current_iphdr_src) 
Otherwise, we'd want 
           ip_addr_cmp(&(pcb->remote_ip), &current_iphdr_dest)

Without the patch, I'm not sure how it passes the packet up the application
layer.

Am I missing something?

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/patch/?9169>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]