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,
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, 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
Numero Dos:
Furthermore 6 octets have been added to the end of the
header in order to distinguish customers from each
other.
To give some background as to what is going on: Nortel
have built a box that accepets lots of companies
ethernet packets, each one into a different port on a
Metro box (fiber optic box that allows private links
generally buried under motorways or rail tracks,
between different cities, the companies buy so many
ports on these links and pay less than they would
going through telecom companies).
These boxes wrap up the incoming packets in a MAC
header and "something like and IP header" but which
isn't really an "IP header" or at least won't be in
the near future, then in order to distinguish the
companies and not to flood their arp tables they use
one MAC header per company and bogus IP addresses in
order to route the packets.
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...). Now I have solved the
bitfields problem thanks to everyones help (thanks for
the advice :)
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 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;
next_tvb = tvb_new_subset(
tvb,
26,
MIN(available_length, reported_length),
reported_length
);
call_dissector(eth_handle, next_tvb, pinfo,
parent_tree);
return;
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, since I
have obviously managed to send the packet to the eth
dissector, the outer layers are dissecting nicely, and
I would have expected to have at least got an ethernet
subtree after the optical ethernet subtree. I don't
the dissection goes wrong, and I haven't found
anything on how to debug ethereal, other than XXX To
Do in the readme.
Amused and perserverant
All the best
Charles
--- Guy Harris <gharris@xxxxxxxxx> wrote:
> Charles Wilkinson wrote:
>
> > Yes there is a protocol ID in the IP header that
> tells
> > ethereal that this is MAC in MAC encapsulation.
>
> If there's an IP header in the middle, I'd describe
> that as
> MAC-in-something-sort-of-like-IP-in-MAC, not
> MAC-in-MAC (which wouldn't
> require IP).
>
> > Furthermore the IP header had slitghtly different
> > fields than the normal IP haeder so it seemed
> > justified to alter IP.c in order to intercept
> ethereal
> > at the IP level.
>
> Different in what way?
>
> > Furthermore the IP header has 6
> > octets added to it, which are not part of the
> classic
> > IP header.
>
> Added at the end? If so, they could also be
> considered a header for the
> MAC-in-IP protocol, rather than part of the IP
> header.
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
>
http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
___________________________________________________________
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
