Mesh PCAP and Wireshark

325 views
Skip to first unread message

Sameer

unread,
Apr 21, 2014, 1:10:53 AM4/21/14
to ns-3-...@googlegroups.com
Hello NS3 users,

I have been trying to find an answer to this problem but amount of googling has led to anywhere fruitful. I ran the example mesh.cc to generate pcap files and I want to read then through wireshark. However I get a lot of malformed packet errors. I am on Arch Linux and have the latest stable build of wireshark (1.10.6) installted. I believe that this version does have the ability to read mesh packets. I tested it out with the sample mesh pcap from the wireshark web site and that file is read fine..

Can anyone help figure this out... what is the problem with the mesh pcap files generated through NS3

Thanks for your time

Tommaso Pecorella

unread,
Apr 21, 2014, 4:08:39 AM4/21/14
to ns-3-...@googlegroups.com, and...@iitp.ru, Tom Henderson
Hi,

there may be a bug somewhere. Mind pointing out which packets in the trace are malformed ?
Also, it is helpful to know what ns-3 version are you using. Iin case it's a bug, we'll try to fix it or 3.20.

Cheers,

T.

Sameer

unread,
Apr 21, 2014, 6:26:57 AM4/21/14
to ns-3-...@googlegroups.com, and...@iitp.ru, Tom Henderson
Hello,


On Monday, April 21, 2014 1:38:39 PM UTC+5:30, Tommaso Pecorella wrote:
Hi,

there may be a bug somewhere. Mind pointing out which packets in the trace are malformed ?
Also, it is helpful to know what ns-3 version are you using. Iin case it's a bug, we'll try to fix it or 3.20.

Cheers,

T.

This is on NS 3.15. I am attaching a screenshot of wireshark that shows the malformed packets.

Tommaso Pecorella

unread,
Apr 21, 2014, 8:25:01 AM4/21/14
to ns-3-...@googlegroups.com, and...@iitp.ru, Tom Henderson
Hi,

it seems a bug. I already sent an e-mail to the module maintainer.
Unfortunately, at best the bug will be fixed in 3.20, so I guess you'll have to update...

Cheers,

T.

Sameer Gurung

unread,
Apr 21, 2014, 8:35:51 AM4/21/14
to ns-3-...@googlegroups.com
Thanks so much... Is there nothing that can be done... I have a bunch of simulation that I run in 3.15. Dont if porting them to the newest release will be feasible for me.

Any help will be appreciated

Thanks,




--
You received this message because you are subscribed to a topic in the Google Groups "ns-3-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ns-3-users/ij_wTw2mElI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ns-3-users+...@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at http://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.

Tommaso Pecorella

unread,
Apr 21, 2014, 8:40:05 AM4/21/14
to ns-3-...@googlegroups.com
Hi,

if the simulations doesn't use "custom" changes to ns-3.15, then the porting is feasible with only a little effort. 

Cheers,

T.

Sameer Gurung

unread,
Apr 22, 2014, 2:07:22 AM4/22/14
to ns-3-...@googlegroups.com
On Mon, Apr 21, 2014 at 6:10 PM, Tommaso Pecorella <tomm...@gmail.com> wrote:
Hi,

if the simulations doesn't use "custom" changes to ns-3.15, then the porting is feasible with only a little effort. 


Can you suggest how I might go about doing this? Any help will be appreciated.

Tommaso Pecorella

unread,
Apr 22, 2014, 2:43:22 AM4/22/14
to ns-3-...@googlegroups.com
This may be helpful:

However the best way is to just install a fresh ns-3 copy, move ONE of your scripts in the new system and compile.
Errors will pop, of course. By fixing them you'll find out what have to be changed.
Most probably the fist ones will be about the random number generation (the syntax is new), but by looking at the differences in any example in 3.15 and 3.19, you'll find what's the way to modify them.

And, of course, you can ask specific points here :P

T

Sameer Gurung

unread,
Apr 22, 2014, 3:38:31 AM4/22/14
to ns-3-...@googlegroups.com
Eeeks I misunderstood your answer :) ..... I do have "custom" changes to ns 3.15... was hoping that the malformed packets bug can be dealth with even if i stick to 3.15

Silvio Sampaio

unread,
Apr 22, 2014, 5:30:20 AM4/22/14
to ns-3-...@googlegroups.com
Hi all,

The main issue here is that ns-3 dot11s implementation is based on IEEE 802.11s Draft 3.0, using old definitions. In this specific case, using different Element Information (IE) ID and (in some cases) format. Meanwhile, the Wireshark 's 802.11s dissector is now based on the recently released standard version. 

A patch to Wireshark 1.0.7 is available in http://www.nsnam.org/wiki/Mesh. I am not sure if this situation will be fixed on the ns-3.20. For years the dot11s implementation is not updated. In fact, to be standard compliant, it probably must be re-implemented, following the standard rules (some of them far away from the Draft 3.0). After some work on it, in my opinion, the results produced by the ns-3 dot11s model are far from the IEEE 802.11s standard, because it is to outdated. 

I've tried to update the ns-3 implementation, starting by the Peer Management Protocol. It works! It generates action frames readable on last version of Wireshark, which dissecator implements the IEEE 802.11 standard. Unfortunately, the rest of the current implemented model proved to hard to "just update". My opinion is: we really need to re-implement it! Probably from the scratch! Well... it is just my opinion. 

Anyways, it would be REALLY nice to see the dot11s model running according to the standard on the ns-20 version. Let's wait...

Regards,

Silvio Sampaio


--
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+...@googlegroups.com.

christoph...@freenet.de

unread,
Aug 27, 2014, 6:10:27 AM8/27/14
to ns-3-...@googlegroups.com
Dear Silvio,
 
i have also tried to update the ns3-implementation.
Updating the Peer Management Protocol with the correct assignment of categories and actions, the correct information elements and Element ID's was feasible.
Also a validation in Wireshark showed the correct implementation.
Beside the peering Management Protocol what else do you think is not compliant to the final standard.
 
thanks,
and best regards,
Christopher
Reply all
Reply to author
Forward
0 new messages