New Header is being incorrectly read on receiving Access Point

203 views
Skip to first unread message

Avinash Sridhar

unread,
Apr 16, 2014, 5:12:20 PM4/16/14
to ns-3-...@googlegroups.com
Hi All,

I hope someone can help me with this query.

Basically here is an overview of what I am doing:
  • STA is appending a new header 'CallPreserveHeader' with Src_Port, Dest_Port, and IsCallActive fields into the header.The code section I modified is 'sta-wifi-mac.cc' which basically includes a new header file 'cp-header.h' too.
  • I can see the header being printed correctly when performing Packet:EnablePrinting
  • Now on the Access Point, I have modified the code of 'ap-wifi-mac.cc' so that when an Association Request is received, it will attempt to decode the CallPreserveHeader that STA sent to it. Again we have referenced cp-header.h here too.
  • I have created logging on cp-header.cc so that when we read the Src_Port, Dest_Port, and IsCallActive on access point post de serialization, I will print it as NS_LOG_INFO.

Problem is that when the access point is reading this information out, we are getting junk values instead of the actual port values.

+++++++++++++++++++++++++++++++++++++++++++++++++++++

LOG SNIPPETS is being done by running wifi-ap.cc from the examples/wireless section:

--Station sends CallPreserveHeader with below values:

PHYTX mode=OfdmRate6Mbps ns3::WifiMacHeader (MGT_ASSOCIATION_REQUEST ToDS=0, FromDS=0, MoreFrag=0, Retry=0, MoreData=0 Duration/ID=60us, DA=00:00:00:00:00:03, SA=00:00:00:00:00:02, BSSID=00:00:00:00:00:03, FragNumber=0, SeqNumber=0) ns3::CallPreserveHeader ( Source UDP Port 22000 Destination UDP Port 23000 Is call active? 1) ns3::MgtAssocRequestHeader (ssid=wifi-default, rates=[6mbs 9mbs 12mbs 18mbs 24mbs 36mbs 48mbs 54mbs], HT Capabilities=^@|^@|^@|^@) ns3::WifiMacTrailer ()

--Access point is receiving packet :

PHYRXOK mode=OfdmRate6Mbps snr=1.58001e+11 ns3::WifiMacHeader (MGT_ASSOCIATION_REQUEST ToDS=0, FromDS=0, MoreFrag=0, Retry=0, MoreData=0 Duration/ID=60us, DA=00:00:00:00:00:03, SA=00:00:00:00:00:02, BSSID=00:00:00:00:00:03, FragNumber=0, SeqNumber=0) ns3::CallPreserveHeader ( Source UDP Port 22000 Destination UDP Port 23000 Is call active? 1) ns3::MgtAssocRequestHea

Now when access point is attempting to get these values into variables, we are getting wrong values:

From Logs:

CallPreserveHeader_Get_CPSrcPort: SrcPort=47
CallPreserveHeader_Get_CPDestPort: DestPort=20079
CallPreserveHeader_Get_iscallactive: IsCallActive?=25600

+++++++++++++++++++++++++++++++++++++++++++++++++++++

FILE UPLOADED FOR REFERENCE:

cp-header.cc ---> CALL PRESERVE HEADER

my-ap-wifi-mac.cc my-ap-wifi-mac.h ---> ACCESS POINT MODIFIED CODE

my-sta-wifi-mac.cc my-sta-wifi-mac.h ---> STATION MODIFIED CODE

Feel free to ping me in case you need any other info. Thanks in advance.

~Avinash







cp-header.cc
my-ap-wifi-mac.cc
my-ap-wifi-mac.h
sta-wifi-mac.cc
sta-wifi-mac.h

Konstantinos

unread,
Apr 16, 2014, 5:34:16 PM4/16/14
to ns-3-...@googlegroups.com
I see a problem in your code which potentially causes this wrong assignement.

The serialized size you give is wrong. You write 3*16 = 48bits = 6 bytes, but your GetSerializedSize method returns 12! Why?

Avinash Sridhar

unread,
Apr 19, 2014, 3:13:39 PM4/19/14
to ns-3-...@googlegroups.com
Thanks Konstantinos,

I made the return value on GetSerializedSize to '6' but that didn't seem to fix it.

Does the order of serialization / deserialization matter? For eg. if header 1 is being added before header 2, does it implying on the receiving end we must first decode header 2 followed by header 1.

Sender --> ADD HEADER 1 --> ADD HEADER 2 --> CHANNEL
CHANNEL --> STRIP HEADER 2 --> STRIP HEADER 1 --> RECEIVER.

Does this order matter or we can read any header of in any order from a packet?

Because when I  changed stripped the header from AP end ( my-ap-wifi-mac.cc ) earlier to the MAC header for Association_Response, I am able to read the contents perfectly.

Thanks,
Avinash


--
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/Z418Ih8neUA/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.



--
Avinash Sridhar
Electrical Engineering Department
Columbia University

Konstantinos

unread,
Apr 19, 2014, 4:16:05 PM4/19/14
to ns-3-...@googlegroups.com
Yes, the order does matter. For more information about the packets and headers read the documentations http://www.nsnam.org/docs/models/html/packets.html


On Saturday, April 19, 2014 8:13:39 PM UTC+1, Avinash Sridhar wrote:
Thanks Konstantinos,

I made the return value on GetSerializedSize to '6' but that didn't seem to fix it.

Does the order of serialization / deserialization matter? For eg. if header 1 is being added before header 2, does it implying on the receiving end we must first decode header 2 followed by header 1.

Sender --> ADD HEADER 1 --> ADD HEADER 2 --> CHANNEL
CHANNEL --> STRIP HEADER 2 --> STRIP HEADER 1 --> RECEIVER.


This is correct order.
 
To unsubscribe from this group and all its topics, send an email to ns-3-users+unsubscribe@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.
Reply all
Reply to author
Forward
0 new messages