Ethereal-dev: Re: [Ethereal-dev] MAC in Mac encapsulation (Nortel)

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

Date Index Thread Index Other Months All Mailing Lists
Date Prev Date Next Thread Prev Thread Next
From: Guy Harris <gharris@xxxxxxxxx>
Date: Wed, 31 Aug 2005 11:01:30 -0700
Charles Wilkinson wrote:

Hi list, let me explain, I am a student doing an
internship at Nortel Networks, I know my C but have
never tinkered with ethereal before and have found
finding documentation difficult,
...and we didn't have any documentation on Nortel's modified IP until your most recent message, meaning that we didn't have enough context to understand what you were trying to do, and thus not enough context to know whether there might be a better way to do what you're trying to do. 


I now have a functional dissector living in the IP
dissector. For reasons thart are about to be
explained.

The problem is that nortel have used the same
ethertype  as for an IP header and it uses the same
layout as a 20 octet IP header except the TOS has been
changed and most of the fields are reserved for future
or custom usage,
OK, so they're running stuff incompatible with the IP standard; that's OK if the wire over which it's running doesn't have to run regular IP-over-Ethernet... 


which means some other poor little
intern like me is going to have to extend this
dissector when they add the rest of the fields...
Hence reason numero uno why my dissector lives in ip.c
...but if the dissector "lives in ip.c" (I presume you mean "packet-ip.c" by "ip.c"), the resulting Ethereal won't be able to dissect regular IP-over-Ethernet unless you add a protocol preference setting to control whether it's supposed to dissect the packets as regular IP or mutant Nortel sort-of-like-IP.
(Now, if *I* were Nortel I would have asked the friendly folks at The Institute of Electrical and Electronics Engineers for an Ethernet type value for this protocol: 

	https://standards.ieee.org/regauth/ethertype/ETH-form.shtml

and used that instead, but I'm not Nortel....)


I can't distinguish between the "something like IP
header" and an "IP header" based on the ether-type
since they are the same ;)  (hope everyone is following
this so far) SO I HAD TO INTERCEPT IT IN THE IP.C
file, since the ethertype is useless. And ethereal
bombs out after the last 6 octets of what it thinks is
an IP header, but which "isn't really an IP header".

As a bonus the IP header has these extra 6 octets
added on to it which need dissecting (and just to
spice it up a bit they aren't byte-allinged so they
need cutting up with bitmasks and all the rest of the
tricks lo-nibble etc...).
They might not be byte-aligned, but they are, at minimum, aligned on a 6-byte/6-octet boundary. If they're aligned on a 2-byte or 4-byte boundary, you can dissect them as bit fields within a 2-byte or 4-byte value. 


But I need to know how to pass the now raw ethernet
packet with IP, TCP and all of the customers packets
through ethereal. I would like to call the eth
dissector in order to pass it back through the layers
and have a nice decode of both the Optical headers and
the customers packets, how do I feed it back through.
This is what I am trying:
having dissected 26 octets in total
Presumably this means that this Nortel protocol doesn't have the equivalent of IP's option field, so that the header is *always* 26 octets long. 


I now want to feed
it back into the eth dissector with:
static dissector_handle_t eth_handle; 
eth_handle = find_dissector("eth");
int available_length = tvb_length(tvb) - 26;/*20 for
the ip header and 6 for the TLS*/
int reported_length = hlen - 26;
If your modified packet-ip.c is anything like the regular packet-ip.c, "hlen" is the header length from the packet header, *NOT* the total length of the packet. I don't know whether this Nortel protocol has a header length field similar to the header length field in the IP header; if it does, presumably it doesn't include the additional 6 bytes, as the IP header length field is in units of 4-byte words.
That would mean that "reported_length" would probably be negative, as "hlen" would probably be 20. 


next_tvb = tvb_new_subset(
  			tvb,
26, MIN(available_length, reported_length), 
			reported_length
			);
I don't know whether this Nortel protocol has a total length field similar to the total length field in the IP header. If it does, then, if, at that point in the code, the "set_actual_length()" call has been made, based on the total length, a call 

	next_tvb = tvb_new_subset(tvb, 26, -1, -1);

will suffice.


Now it doesn't crash but I don't get an ethernet
subtree or an IP subtree or any of the higher layer
protocols after the Optical dissector. All I get is
[Malformed Packet: IP]. Why is my question,
Perhaps because the length values being handed to tvb_new_subset() don't reflect the remaining data in the packet, so that either 

	1) Ethereal throws an exception when creating the tvbuff

or
2) the Ethernet dissector throws an exception when it tries to fetch anything from the tvbuff.