Bugzilla – Bug 1302
Flow monitor bug
Last modified: 2012-02-08 05:13:13 UTC
Created attachment 1274 [details] test program from Mauro Vidotto See https://groups.google.com/d/topic/ns-3-users/U_MnZRioG60/discussion No idea if it is a bug or not... i could see that in my case this error produces when an ARP package is dropped at some intermediate node because of the droptail queue policy.
./waf --run "scratch/sbs4.test --tcpModel=ns3::TcpNewReno --nCsma=10"
My best bet is: ARP isn't IP-encapsulated (baaaad ARP, BAD!), so it isn't tagged by FlowMon. On the other hand when it's dropped the packet IS sent to FlowMon to be analyzed. Thus FlowMon Complains. Fix for this: don't loose ARPs. Seriously, I know Gustavo is working on it, so I'll leave him the burden to find a good design fix. My "n00b" fix would be: + you got a dropped packet? Check if it's an ARP. If it is, then who cares, else try to find the tag. Cheers, T.
I am not working on it, unfortunately, I haven't had time lately :-( But it doesn't sound complicated to fix, now that we have a simple way to reproduce it.
Created attachment 1330 [details] test program from Mauro Vidotto, updated to ns-3-dev API
This code path was introduced by bug 854.
I think the problem is simply that the Flow Monitor is assuming that all queue drops are for packets that passed through the IP stack before, and are all IP packets. However, this is a wrong assumption, a L2 device can receive non-IP packets, and these can be dropped. We can use the presence (or not) Ipv4FlowProbeTag itself to decide whether this is an IP packet or not. If the tag is missing, ignore it, don't abort.
And, yes, I am to blame for this, since I asked for the assert. I just didn't think it through. changeset: 7703:a982d8c7aa32 tag: tip user: Gustavo J. A. M. Carneiro <gjc@inescporto.pt> date: Wed Feb 08 11:12:17 2012 +0100 summary: Bug 1302 - Flow monitor bug