Bug 857

Created attachment 811 [details]
Handle IPv4 Link-local multicast address correctly

+1

(In reply to comment #2)
> +1

Tom, thanks.

#I repied this message as wrong bug number (#859), but this message is surely for this bug.


In order to reflect this modification, I've added one test in udp-test.cc as
follows, but it cause another problem.


diff -r ddd5c567f02d src/internet-stack/udp-test.cc
--- a/src/internet-stack/udp-test.cc    Thu Apr 08 00:34:56 2010 +0900
+++ b/src/internet-stack/udp-test.cc    Thu Apr 08 01:31:43 2010 +0900
@@ -239,6 +239,16 @@
   m_receivedPacket->RemoveAllByteTags ();
   m_receivedPacket2->RemoveAllByteTags ();

+  // Simple Link-local multicast test
+
+  txSocket->BindToNetDevice (txDev1);
+  SendData (txSocket, "224.0.0.9");
+  NS_TEST_EXPECT_MSG_EQ (m_receivedPacket->GetSize (), 123, "trivial");
+  NS_TEST_EXPECT_MSG_EQ (m_receivedPacket2->GetSize (), 0, "second socket
should not receive it (it is bound specifically to the second interface's
address");
+
+  m_receivedPacket->RemoveAllByteTags ();
+  m_receivedPacket2->RemoveAllByteTags ();
+
   // Broadcast test with multiple receiving sockets

   // When receiving broadcast packets, all sockets sockets bound to

During using raw socket, we never face this problem (since every packet goes up
to the socket),
but in UDP, we use routing table for local delivery (in
Ipv4StaticRouting::RoutInput), but it seems not to working so far.


bool 
Ipv4StaticRouting::RouteInput  (Ptr<const Packet> p, const Ipv4Header
&ipHeader, Ptr<const NetDevice> idev,
                             UnicastForwardCallback ucb,
MulticastForwardCallback mcb,
                             LocalDeliverCallback lcb, ErrorCallback ecb)
{
<snip>
  // Multicast recognition; handle local delivery here
  //
  if (ipHeader.GetDestination ().IsMulticast ())
    {
      NS_LOG_LOGIC ("Multicast destination");
      Ptr<Ipv4MulticastRoute> mrtentry =  LookupStatic(ipHeader.GetSource (),
        ipHeader.GetDestination (), m_ipv4->GetInterfaceForDevice (idev));

Do you have any idea ?

I'll keep thinking how to solve it.

> 
> Do you have any idea ?
> 
> I'll keep thinking how to solve it.

I wonder whether this check in the endpoint demux:

      if (endP->GetBoundNetDevice ())
        {
          if (endP->GetBoundNetDevice () != incomingInterface->GetDevice ())
            {
              NS_LOG_LOGIC ("Skipping endpoint " << &endP
                            << " because endpoint is bound to specific device and"
                            << endP->GetBoundNetDevice ()
                            << " does not match packet device " << incomingInterface->GetDevice ());
              continue;
            }
        }


should be moved up the stack to UdpL4Protocol::Receive() method (also for Tcp).

(In reply to comment #4)
> > 
> > Do you have any idea ?
> > 
> > I'll keep thinking how to solve it.
> 
> I wonder whether this check in the endpoint demux:
> 
>       if (endP->GetBoundNetDevice ())
>         {
>           if (endP->GetBoundNetDevice () != incomingInterface->GetDevice ())
>             {
>               NS_LOG_LOGIC ("Skipping endpoint " << &endP
>                             << " because endpoint is bound to specific device
> and"
>                             << endP->GetBoundNetDevice ()
>                             << " does not match packet device " <<
> incomingInterface->GetDevice ());
>               continue;
>             }
>         }
> 
> 
> should be moved up the stack to UdpL4Protocol::Receive() method (also for Tcp).

It seems not the solution (I tried with this code).

I'm not sure what is true, but..

the socket trying to receive the packet is bound to "10.0.0.1", where destination address is "224.0.0.9".
In that case, should the socket not receive the packet?

If the socked is bound to "0.0.0.0", the packet to 224.0.0.9 is received by udp socket.

(In reply to comment #5)
> (In reply to comment #4)
> > > 
> > > Do you have any idea ?
> > > 
> > > I'll keep thinking how to solve it.
> > 
> > I wonder whether this check in the endpoint demux:
> > 
> >       if (endP->GetBoundNetDevice ())
> >         {
> >           if (endP->GetBoundNetDevice () != incomingInterface->GetDevice ())
> >             {
> >               NS_LOG_LOGIC ("Skipping endpoint " << &endP
> >                             << " because endpoint is bound to specific device
> > and"
> >                             << endP->GetBoundNetDevice ()
> >                             << " does not match packet device " <<
> > incomingInterface->GetDevice ());
> >               continue;
> >             }
> >         }
> > 
> > 
> > should be moved up the stack to UdpL4Protocol::Receive() method (also for Tcp).
> 
> It seems not the solution (I tried with this code).
> 
> I'm not sure what is true, but..
> 
> the socket trying to receive the packet is bound to "10.0.0.1", where
> destination address is "224.0.0.9".
> In that case, should the socket not receive the packet?
> 
> If the socked is bound to "0.0.0.0", the packet to 224.0.0.9 is received by udp
> socket.

At least, Linux seems to behave like that, if socket is bound to "10.0.0.1" or any other non-zero address, multicast packet is not delivered to socket.

Created attachment 821 [details]
Added testcase in udp-test.cc

(In reply to comment #6)

> 
> At least, Linux seems to behave like that, if socket is bound to "10.0.0.1" or
> any other non-zero address, multicast packet is not delivered to socket.

To clarify then, are you happy with your current patch because the testcase matches Linux behavior?  If not, can you clarify what behavior you'd like to see implemented?

(In reply to comment #8)
> (In reply to comment #6)
> 
> > 
> > At least, Linux seems to behave like that, if socket is bound to "10.0.0.1" or
> > any other non-zero address, multicast packet is not delivered to socket.
> 
> To clarify then, are you happy with your current patch because the testcase
> matches Linux behavior?  If not, can you clarify what behavior you'd like to
> see implemented?

I'm happy with this patch.
And quagga ripd/ospfd seems to satisfy this behavior on Linux.

If you agree, I'll push this patch into ns-3-dev.

(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #6)
> > 
> > > 
> > > At least, Linux seems to behave like that, if socket is bound to "10.0.0.1" or
> > > any other non-zero address, multicast packet is not delivered to socket.
> > 
> > To clarify then, are you happy with your current patch because the testcase
> > matches Linux behavior?  If not, can you clarify what behavior you'd like to
> > see implemented?
> 
> I'm happy with this patch.
> And quagga ripd/ospfd seems to satisfy this behavior on Linux.
> 
> If you agree, I'll push this patch into ns-3-dev.

Yes, I reviewed it and am OK with pushing it.

(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > (In reply to comment #6)
> > > 
> > > > 
> > > > At least, Linux seems to behave like that, if socket is bound to "10.0.0.1" or
> > > > any other non-zero address, multicast packet is not delivered to socket.
> > > 
> > > To clarify then, are you happy with your current patch because the testcase
> > > matches Linux behavior?  If not, can you clarify what behavior you'd like to
> > > see implemented?
> > 
> > I'm happy with this patch.
> > And quagga ripd/ospfd seems to satisfy this behavior on Linux.
> > 
> > If you agree, I'll push this patch into ns-3-dev.
> 
> Yes, I reviewed it and am OK with pushing it.

I've pushed this patch.

changeset 6181, 05727a89b220