Given your scenario, this is what I would try to do:
1. Add a preference to the eth dissector, allowing the user to regard
top-level ethertype fields of "IP" to be "Optical IP".
2. Add an Optical IP dissector. At first it is a copy of the IP
dissector, with the modifications you've made. It ends up calling the
eth dissector.
3. At this point the eth dissector has to decide that it is not the
top-level eth header, so it no longer treads ethertype of "IP" as
"Optical IP". You should be able to check the pinfo (packet_info)
structure to see if the ethernet-related items are already set
(dl_src, dl_dst, or ethertype).
--gilbert
On 8/31/05, Charles Wilkinson <c_s_wilkinson@xxxxxxxxxxx> 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,
>
> 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
>
