> This implies changes, however, to things like dissect_IP, as it will have
> to pass along in some structure the source and destination IP addresses.
>
> Any comments?
The way Microsoft Network Monitor handles this is to pass to
per-protocol routines:
an indication of the protocol that's calling them;
the offset in the frame of the beginning of the data for that
protocol;
which presumably means it's their obligation to dig out stuff such as
the UDP port numbers for a protocol such as TFTP running atop UDP. It
also appears to make it tricky to go two layers up.
An alternative might be to have the calling routine pass that stuff
directly to the called routine, as it's presumably already extracted it.
The problem there is that either
1) it means that the calling sequence for a routine depends on
the protocol calling it
or
2) you have to cheat and pass, say, a pointer to that stuff as a
"void *" or something such as that
and if a given protocol can be called from more than one lower-level
protocol (e.g., SMB could be called from the NetBIOS-over-TCP session
service, as well as the NetBIOS-over-IPX and NetBEUI equivalents), it'd
have to be passed an indication of the protocol calling it (and other
protocols, if that can't be inferred from the protocol calling it).
My inclination is to go with 2), to handle the case of protocols that
can be layered atop several different types of protocol.
"dissect_tcp()" and "dissect_udp()" would pass a pointer to, say, a
structure containing source and destination IP addresses and source and
destination ports; they'd get the IP addresses from the structure passed
to them. Unfortunately, this is one case where the full stack can't be
inferred from "TCP" or "UDP", as "dissect_tcp()" and "dissect_udp()" can
be called from "dissect_ipv6()" as well as "dissect_ip()".
I also don't know what would be required for non-Internet protocol
stacks.
