search

riebl / artery

OMNeT++ V2X simulation framework for ETSI ITS-G5
GNU General Public License v2.0
203 stars 129 forks source link

Can't retrieve message at Physical Layer #237

Closed maroueneboubakri closed 2 years ago

maroueneboubakri commented 2 years ago

Hi @riebl, @Venturina,

I was playing with TestBed scenario using a configuration without USRP, it turns out that Physical and Link layer are omitted from the message to be handled at OtaInterfaceStub::sendMessage is that an intended behaviour ?

Digging into the code, I saw that only Network up to Application layer are only taken. See here: https://github.com/riebl/artery/blob/master/src/artery/testbed/OtaInterfaceLayer.cc#L49

Is there any reason for that ? The issue now, is when changing to auto range = create_byte_view(packet->getPayload(), OsiLayer::Physical, OsiLayer::Application); still can't get the Phy/Link headers. I mean auto range = create_byte_view(packet->getPayload(), OsiLayer::Link); returns empty.

It would be interesting to get the whole message instead, such can forward it as it is to a DUT. Is there any way to get it ?

Reagrds Maro

riebl commented 2 years ago

Dear @maroueneboubakri,

yes, this is intended behaviour: The PHY and MAC headers are handled by the software running on/along with the USRP. Vanetza ships with some code for dealing with ITS-G5/802.11 MAC headers, which may be useful for you: https://github.com/riebl/vanetza/blob/master/vanetza/access/g5_link_layer.hpp

maroueneboubakri commented 2 years ago

Hello @riebl,

Thank you ! I stepped into this code https://github.com/riebl/vanetza/blob/master/tools/socktap/cohda.cpp and took pieces from it to construct the MAC header.

EDIT: move vanetza related issue to https://github.com/riebl/vanetza/issues/143

Regards Maro