I guess as a related question, could you explain a little how the broadcast NEM works?
For example, if I have 3 nodes, A, B, C where due to range, A can talk to B and C can talk to A, but not A: A ---- B ---- C If a packet gets sent from A to the broadcast NEM, does C also receive a copy of this packet? If so, would the PHY layer drop it? Or would it go all the way up to the kernel before getting dropped? I would think that everyone gets it from the OTA, but the PHY would calculate the distance and drop it (not deliver it up the NEM stack).. But wanted to verify. In otherwords, is it safe to assume that "A"'s packet will NOT show up in C's MAC statistics? Thanks! On 4/11/13 10:48 PM, "Cheng, Bow-Nan - 0665 - MITLL" <[email protected]> wrote: >Thanks Steve, > >One quick related question -- do you know the impact of everything getting >sent with the NEM broadcast address? > >Looking through the code, it seems ARP packets (because they have a >special ETHER_TYPE) are intercepted to add the entry to the neighbor >cache. Since IPv6 doesn't have "ARP", you guys intercept IPv6 packets and >then do a deeper search to see if its and ICMP Neighbor Solicitation or >Advertisement message before adding the entry into the neighbor table. >Since we replace the IPv6 ETHERTYPE with our custom one (we do not do the >same for ARP), this function won't get exercised. My guess is that all our >IPv6 packets (OSPF hello, LSAs, IPv6 neighbor discovery packets, etc.) are >getting sent to the broadcast NEM and that's probably why it shows up that >we're receiving and sending a lot more multicast packets (in EMANE >Upstream/Downstream stats) since everyone is receiving and it won't get >dropped until it goes up to the kernel. Does that sound like a reasonable >assessment? > >Here's the section of code I was talking about: > > case EMANEUtils::ETH_P_IPV6: > { > //ipv6 header > const EMANEUtils::Ip6Header *pIp6Header = >(EMANEUtils::Ip6Header*) ((EMANEUtils::EtherHeader*) pEthHeader + 1); > > // check for icmpv6 > if (pIp6Header->u8Ipv6next == EMANEUtils::IPV6_P_ICMP) > { > // icmpv6 header > const EMANEUtils::IP6ICMPHeader *pICMP6Header = >(EMANEUtils::IP6ICMPHeader*) ((EMANEUtils::Ip6Header*) pIp6Header + 1); > > // icmp type > const ACE_UINT8 icmpv6Type = pICMP6Header->u8Type; > > // icmpv6 neighbor solicitation or advertisement > if ((icmpv6Type == EMANEUtils::IP6_ICMP_NEIGH_SOLICIT) || >(icmpv6Type == EMANEUtils::IP6_ICMP_NEIGH_ADVERT)) > { > addEntry(pEthHeader->src, nemId); > } > } > } > > > >Thanks again for your help. > > >On 4/11/13 9:16 PM, "Steven Galgano" <[email protected]> wrote: > >>Bow-Nan, >> >>It is the responsibility of the EMANE transport layer to determine the >>NEM destination Id to use for traffic routed through the emulator. The >>transport acts as a boundary understanding enough of the input protocol >>to determine the appropriate NEM destination Id. >> >>Both the raw transport and the virtual transport operate on ethernet >>frames. For a given input frame, these transports map the destination >>MAC address to the appropriate NEM Id. When this is not possible the >>NEM broadcast address is used. Since all over-the-air frames in EMANE >>are delivered to all NEMs for physical layer processing, this will have >>no impact on the emulation. The MAC layers (provided they are of the >>same waveform) will process the messages as if they were broadcast and >>pass them back to the corresponding transport which will then deliver >>the packets to the kernel for processing. >> >>In this case, if it turns out that a packet was unicast and not >>broadcast but was not for the receiving node, the kernel will drop it. >> >>As far as DSCP is concerned, a 0 value is used for non-IP packets. >>A DSCP value of 0 would have no impact on the RF Pipe model but could >>have an impact on the IEEE80211abg Model if WMM (Wireless Multi Media) >>is enabled and the DSCP values are being set by the application >>generating the traffic. >> >>-- >>Steven Galgano >>Adjacent Link LLC >> >> >> >>On 04/11/2013 06:04 PM, Cheng, Bow-Nan - 0665 - MITLL wrote: >>> Hello, >>> >>> We're implementing some IP Header Compression protocols. To do so, we >>> modify the ETHERTYPE to be something custom. Looking through some of >>>the >>> EMANE 0.8.1 Code, it seems that a non-IP/ARP ETHERTYPE gets accepted, >>> but I'm wondering what the repercussions are of not having an IP header >>> in EMANE? For example, some models search for DSCP values in the >>>header, >>> IPv6 ND packets would not have parsable headers since the IPv6 header >>> would be compressed, etc. I'm seeing a lot of multicast traffic being >>> pushed down and upstream in EMANE by doing an unknown Ethertype and >>> unknown network layer header and was wondering if its requiring >>> something special from the IP header I'm not giving. Using RF Pipe.. >>> >>> Thanks! >>> >>> -Bow-Nan >>> >>> -- >>> Bow-Nan Cheng, Ph.D. >>> MIT Lincoln Laboratory >>> Airborne Networks Group >>> 244 Wood St Lexington MA 02420 >>> 781-981-4997 >>> >>> >>> _______________________________________________ >>> emane-users mailing list >>> [email protected] >>> http://pf.itd.nrl.navy.mil/mailman/listinfo/emane-users >>>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ emane-users mailing list [email protected] http://pf.itd.nrl.navy.mil/mailman/listinfo/emane-users
