sequence number wrap
Abdul Jabbar
I am observing a somewhat peculiar behavior with the sequence numbers
and I am not sure which sequence number it is. (802.11) wifi maybe? In
short, when I run a simple 3 node wireless simulation (file attached),
in which 2 nodes have a udp connection between then and the third node
is idle, I see the following (warning?) message on the screen.
anonymous@anonymous:~/Desktop/ns-3.2$ ./waf --run scratch/
simpleadhoc_test
Entering directory `/home/egemen/Desktop/ns-3.2/build'
Compilation finished successfully
Sequence numbers have looped back. last recorded=65535 currently
seen=39840
Sequence numbers have looped back. last recorded=65535 currently
seen=48544
Sequence numbers have looped back. last recorded=65535 currently
seen=56576
Sequence numbers have looped back. last recorded=65535 currently
seen=32912
Sequence numbers have looped back. last recorded=65535 currently
seen=37072
Sequence numbers have looped back. last recorded=65535 currently
seen=37088
An examination of output pcap file with wireshark shows that the mac
sequence number correctly loops after 4096 (which is in agreement with
the 12 bits assigned to sequence number in 802.11 specs). So I am not
able to understand the meaning of the above output or should I even
care.
Just to complicate the issue, the above messages disappear when I
remove the 3rd idle node from the simulation. Also, the number of
these messages seem to be dependent on the time between the last
application stop and the simulation stop.
Any ideas would be welcome.
Thanks
Abdul.
======================================
#include <fstream>
#include <iostream>
#include "ns3/core-module.h"
#include "ns3/common-module.h"
#include "ns3/node-module.h"
#include "ns3/helper-module.h"
#include "ns3/mobility-module.h"
#include "ns3/contrib-module.h"
#include "ns3/wifi-module.h"
using namespace ns3;
NS_LOG_COMPONENT_DEFINE ("simpleadhoc");
int
main (int argc, char *argv[])
{
Config::SetDefault ("ns3::OnOffApplication::PacketSize",
StringValue ("210"));
Config::SetDefault ("ns3::OnOffApplication::DataRate", StringValue
("448kb/s"));
NodeContainer adhocNodes;
adhocNodes.Create (3);
WifiHelper wifi;
wifi.SetMac ("ns3::AdhocWifiMac");
wifi.SetPhy ("ns3::WifiPhy");
NetDeviceContainer adhocDevices = wifi.Install (adhocNodes);
InternetStackHelper internet;
internet.Install (adhocNodes);
Ipv4AddressHelper address;
address.SetBase ("10.1.1.0", "255.255.255.0");
Ipv4InterfaceContainer adhocInterfaces;
adhocInterfaces = address.Assign (adhocDevices);
MobilityHelper mobility;
mobility.SetMobilityModel ("ns3::RandomWalk2dMobilityModel",
"Bounds", RectangleValue (Rectangle (-10, 10, -10, 10)));
mobility.Install (adhocNodes);
NS_LOG_INFO ("Enabling OLSR routing on all adhoc nodes");
OlsrHelper olsr;
olsr.Install (adhocNodes);
uint16_t port = 9;
OnOffHelper onoff1 ("ns3::UdpSocketFactory",Address
(InetSocketAddress (adhocInterfaces.GetAddress (0), port)));
onoff1.SetAttribute ("OnTime", RandomVariableValue
(ConstantVariable (1)));
onoff1.SetAttribute ("OffTime", RandomVariableValue
(ConstantVariable (0)));
ApplicationContainer apps1 = onoff1.Install (adhocNodes.Get (1));
apps1.Start (Seconds (1.0));
apps1.Stop (Seconds (25.0));
PacketSinkHelper sink ("ns3::UdpSocketFactory", InetSocketAddress
(Ipv4Address::GetAny (), port));
apps1 = sink.Install (adhocNodes.Get (0));
apps1.Start (Seconds (1.0));
apps1.Stop (Seconds (25.0));
NS_LOG_INFO ("Configure Tracing.");
std::ofstream ascii;
ascii.open ("simpleadhoc.tr");
WifiHelper::EnableAsciiAll (ascii);
MobilityHelper::EnableAsciiAll (ascii);
WifiHelper::EnablePcapAll ("simpleadhoc");
NS_LOG_INFO ("Run Simulation.");
Simulator::Stop (Seconds (30));
Simulator::Run ();
Simulator::Destroy ();
}
====================================================
----------
Abdul Jabbar
Ph.D Candidate
ITTC, University of Kansas
2335 Irving Hill Rd
Lawrence, KS, 66046
Mathieu Lacage
On Wed, 2008-10-15 at 11:34 -0500, Abdul Jabbar wrote:
> Hi,
>
> I am observing a somewhat peculiar behavior with the sequence numbers
> and I am not sure which sequence number it is. (802.11) wifi maybe? In
yes.
> short, when I run a simple 3 node wireless simulation (file attached),
> in which 2 nodes have a udp connection between then and the third node
> is idle, I see the following (warning?) message on the screen.
>
> anonymous@anonymous:~/Desktop/ns-3.2$ ./waf --run scratch/
> simpleadhoc_test
> Entering directory `/home/egemen/Desktop/ns-3.2/build'
> Compilation finished successfully
> Sequence numbers have looped back. last recorded=65535 currently
> seen=39840
> Sequence numbers have looped back. last recorded=65535 currently
> seen=48544
> Sequence numbers have looped back. last recorded=65535 currently
> seen=56576
> Sequence numbers have looped back. last recorded=65535 currently
> seen=32912
> Sequence numbers have looped back. last recorded=65535 currently
> seen=37072
> Sequence numbers have looped back. last recorded=65535 currently
> seen=37088
>
> An examination of output pcap file with wireshark shows that the mac
> sequence number correctly loops after 4096 (which is in agreement with
> the 12 bits assigned to sequence number in 802.11 specs). So I am not
> able to understand the meaning of the above output or should I even
> care.
This warning is shown to outline the fact that the delta between the
last recorded sequence number and the new observed sequence number is so
big that it is very suspicious. It probably happens because you moved
out of range at some point, and just moved back in range.
> Just to complicate the issue, the above messages disappear when I
> remove the 3rd idle node from the simulation. Also, the number of
> these messages seem to be dependent on the time between the last
> application stop and the simulation stop.
>
> Any ideas would be welcome.
This warning seems to confuse a lot of people so, it probably makes
sense to remove it at some point but, before doing this, it would be
helpful to figure out what real devices do in this case and how they
handle such big deltas in observed sequence numbers. Would you mind file
a bug in www.nsnam.org/bugzilla to keep track of this issue ?
Mathieu
Abdul Jabbar
I am not sure if this was the case in my scenario. We did a very
simple test in which all the nodes were in communication range. The
pcap results shows that all packets were received and no mac sequence
numbers were skipped. I manually went through all the sequence
numbers. Moreover, the total number of packets sent in the simulation
were far less than the 65K as is being reported in these messages.
>
>
>> Just to complicate the issue, the above messages disappear when I
>> remove the 3rd idle node from the simulation. Also, the number of
>> these messages seem to be dependent on the time between the last
>> application stop and the simulation stop.
>>
>> Any ideas would be welcome.
>
> This warning seems to confuse a lot of people so, it probably makes
> sense to remove it at some point but, before doing this, it would be
> helpful to figure out what real devices do in this case and how they
> handle such big deltas in observed sequence numbers. Would you mind
> file
> a bug in www.nsnam.org/bugzilla to keep track of this issue ?
This seems like a good idea if we can conclude that the message is a
result
of big deltas in the mac sequence numbers. In my example there should
be no gap
at all in the sequence numbers.
I will file a bug report on bugzilla.
Thanks,
Abdul.
>
>
> Mathieu
>
>
> >