|
Bugzilla – Full Text Bug Listing |
| Summary: | Sending packet to and from same node fails. | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Josh Pelkey <jpelkey> |
| Component: | routing | Assignee: | ns-bugs <ns-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | tomh |
| Priority: | P5 | ||
| Version: | ns-3-dev | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: | This is exactly like first.cc, but with client and server both on node zero. | ||
changeset 7defe7a99e9c |
Created attachment 521 [details] 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.