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
