Thank you, Steven. I think I found the problem and it has to do with how EMANE handles frames with “unknown protocol” types.
If you see the method “parseFrame” in
src/transports/common/ethernettransport.cc, EMANE is assuming that the
destination NEM for a frame that contains an “unknown protocol” type is
NEM_BROADCAST_MAC_ADDRESS. I don’t believe EMANE should make such assumption.
In my particular scenario, the proprietary protocol I’m testing has an ether
type 0x2800 (unknown for EMANE), but the source and destination MAC addresses
are interpreted as normal and can be unicast or broadcast. Because EMANE
assumes broadcast, it processes all frames with unicast and broadcast MAC
destinations using the multicast rate. In my scenario, multicastrate=2 and
unicastrate=8, which results in nodes A and B seeing each other using broadcast
but not using unicast frames. This is why “ping” works (nodes CANNOT ping each
other) but the “unknown protocol” doesn’t (nodes CAN communicate with each
other).
My suggestion is to change:
// unknown protocol
default:
LOGGER_VERBOSE_LOGGING(pPlatformService_->logService(),
DEBUG_LEVEL,
"TRANSPORTI %03d EthernetTransport::%s allow
unknown protocol %02X",
id_,
__func__,
u16ethProtocol);
// use broadcast mac addr
rNemDestination = NEM_BROADCAST_MAC_ADDRESS;
// set dscp to 0
rDspc = 0;
to:
// unknown protocol
default:
LOGGER_VERBOSE_LOGGING(pPlatformService_->logService(),
DEBUG_LEVEL,
"TRANSPORTI %03d EthernetTransport::%s allow
unknown protocol %02X",
id_,
__func__,
u16ethProtocol);
// broadcast always mode
if(bBroadcastMode_)
{
rNemDestination = NEM_BROADCAST_MAC_ADDRESS;
}
// use ether dst
else
{
rNemDestination = Utils::ethaddr4_to_id(&pEthHeader->dst);
}
// set dscp to 0
rDspc = 0;
After making the change above, the emulation works as expected.
Thanks,
Adrian
On May 1, 2015, at 7:52 AM, Steven Galgano <[email protected]> wrote:
> Adrian,
>
> The IEEE 802.11abg radio model knows nothing of the underlying protocols
> associated with the traffic it transmits. The PCR curves apply to all
> inbound over-the-air traffic.
>
> In emane, the transport layer is responsible for mapping message
> destinations to NEM addresses. The virtual transport does this by
> mapping ethernet mac addresses to NEM Ids. All ethernet frames become
> opaque data at the point they are sent downstream to the radio model.
>
> The default IEEE 802.11abg curves use pktsize="128" to adjust POR based
> on packet size:
>
> https://github.com/adjacentlink/emane/wiki/IEEE-802.11abg-Model#packet-completion-rate
>
> --
> Steven Galgano
> Adjacent Link LLC
> www.adjacentlink.com
>
>
> On 04/30/2015 04:50 PM, Adrian Granados Murillo wrote:
>> Hi All,
>>
>> I’m emulating an 802.11b/g network (4 nodes) using the IEEE 802.11abg
>> model and location events. So far so good, I can create the topology I
>> need and nodes that are far away can’t see each other or experience
>> packet loss accordingly to PCR curves. The problem I’m having is that
>> the PCR curves for packets sent over proprietary protocols (they have
>> their own ether type value) don’t seem to have any effect on them. For
>> example, in my topology, nodes A and B have a POR of about 60% based on
>> the SINR of the link. If I run “ping” (ICMP), I see about 40% packet
>> loss, which is correct. But if I run my proprietary protocol, I see 0%
>> packet loss. Now, if nodes are too far away so that frames are dropped
>> at the PHY layer, I see 100% packet loss in both cases as expected.
>>
>> So, the question is: does PCR curves only apply for ARP or IP datagrams,
>> for example? Or do they apply for all protocols and I’m just missing
>> something about the configuration?
>>
>> Thanks,
>> Adrian
>>
>> Adrian Granados
>> Research Associate
>> Intelligent Communication and Information Systems Laboratory
>> Florida Institute of Technology
>> Tel. 321-674-8262
>> www.fit.edu <http://www.fit.edu>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> emane-users mailing list
>> [email protected]
>> http://pf.itd.nrl.navy.mil/mailman/listinfo/emane-users
>>
Adrian Granados
Research Associate
Intelligent Communication and Information Systems Laboratory
Florida Institute of Technology
Tel. 321-674-8262
www.fit.edu
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ emane-users mailing list [email protected] http://pf.itd.nrl.navy.mil/mailman/listinfo/emane-users
