Bug 859

Summary: Output interface estimation for the source address bound socket in IPv4 Raw socket
Product: ns-3 Reporter: Hajime Tazaki <tazaki>
Component: internetAssignee: ns-bugs <ns-bugs>
Status: VERIFIED FIXED    
Severity: normal CC: tomh
Priority: P3    
Version: pre-release   
Hardware: All   
OS: All   
Attachments: Picking output interface from source address
changeset 6173 6ff89f45451c

Description Hajime Tazaki 2010-04-04 10:31:38 UTC 
If the source address is specified, and output device is not specified, *AND* the destination address is 255.255.255.255 or multicast address, output device can be the device that owns specfied source address (at lease, in Linux 2.6.31 is like that).

Attached patch will do this behavior.
Comment 1 Hajime Tazaki 2010-04-07 10:42:56 UTC 
Created attachment 814 [details]
Picking output interface from source address
Comment 2 Tom Henderson 2010-04-07 11:11:50 UTC 
+1
Comment 3 Hajime Tazaki 2010-04-07 19:41:16 UTC 
(In reply to comment #2)
> +1

Tom, thanks.

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.
Comment 4 Hajime Tazaki 2010-04-07 19:45:48 UTC 
(In reply to comment #3)
I'm sorry, but I had mistaken to reply message. Comment #3 is not reply for this bug.
Please ignore it.
> (In reply to comment #2)
> > +1
> 
> Tom, thanks.
> 
> In order to reflect this modification, I've added one test in udp-test.cc as
> follows, but it cause another problem.
Comment 5 Hajime Tazaki 2010-04-07 22:29:40 UTC 
Created attachment 816 [details]
changeset 6173 6ff89f45451c
Comment 6 Hajime Tazaki 2010-04-07 23:02:11 UTC 
(In reply to comment #5)
> Created an attachment (id=816) [details]
> changeset 6173 6ff89f45451c

I've added test code and already pushed.

test code is:
changeset:   6175:910171e4181c