[Ns-bugs] [Bug 632] New: Sending packet to and from same node fails.

code@nsnam.ece.gatech.edu code at nsnam.ece.gatech.edu
Wed Jul 8 14:22:42 PDT 2009


http://www.nsnam.org/bugzilla/show_bug.cgi?id=632

           Summary: Sending packet to and from same node fails.
           Product: ns-3
           Version: ns-3-dev
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P5
         Component: routing
        AssignedTo: ns-bugs at isi.edu
        ReportedBy: jpelkey at gatech.edu
   Estimated Hours: 0.0


Created an attachment (id=521)
 --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=521)
This is exactly like first.cc, but with client and server both on node zero.

I have taken the simple first.cc example (a two node p2p link) and
modified it so that the server and client both reside on node zero.
Therefore, node zero should send packets to itself.  I know this is
odd, but shouldn't this be possible?  I ask because I get an assert
failed when I try to do this.  Here are the last few lines of NS_LOG:

2s Ipv4ListRouting:RouteInput(0x8062350, tos 0x0 ttl 64 id 0 protocol
17 offset 0 flags [none] length: 1052 10.1.1.1 > 10.1.1.1, 0)

2s Ipv4ListRouting:RouteInput(): RouteInput logic for node: 0

2s Ipv4L3Protocol:GetInterfaceForDevice(Command ['/home/jpelkey/repos/
ns-3.5/build/debug/scratch/myfirst'] exited with code -11

The specific assert is: 
assert failed. file=../src/routing/list-routing/ipv4-list-routing.cc, line=108,
cond="m_ipv4->GetInterfaceForDevice (idev) >= 0"

Based on this it looks like idev is null when it reaches RouteInput
(which is why there is an assert fail in Ipv4ListRouting::RouteInput
()).  My first guess is something with static or list routing which is somehow
sending out a packet with a null pointer to the net device.

I should also add that this occurs in ns-3.5 and ns-3-dev, but it
works in ns-3.4. 

Test case attached.


-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the Ns-bugs mailing list