Adrian, Thanks for the bug report. I opened a new issue:
https://github.com/adjacentlink/emane/issues/19 -- Steven Galgano Adjacent Link LLC www.adjacentlink.com On 05/01/2015 03:34 PM, Adrian Granados Murillo wrote: > 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 > <http://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] > <mailto:[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 <http://www.fit.edu> > > > > > > > _______________________________________________ emane-users mailing list [email protected] http://pf.itd.nrl.navy.mil/mailman/listinfo/emane-users
