> Some problems with the current version of the code:
>
> 1) It uses C++-style comments to comment code out - not all C
> compilers accept C++-style comments.
>
> 2) It relies on the OS's headers to specify the layout of
> link-layer, IP, and TCP headers - and does so in a fashion
> that causes it not to compile on, for example, FreeBSD 3.4.
>
> It should, instead, define those data structures itself; note
> that Ethereal doesn't depend on the OS's headers to supply
> packet layouts and, as of tcpdump 3.6.1 and libpcap 0.6.1,
> tcpdump and libpcap don't depend on them, either - it's just
> too much of a pain to do so, given that those headers may
> differ significantly from platform to platform.
>
> 3) It's Ethernet-specific and IPv4-specific.
Guy,
thanks for your comments. Of course, you're right, and I'm willing to work
out all the issues you mentioned and then some more but: John McDermott
wrote that there had been some discussion whether it was correct to have
graphing incorporated in ethereal and you seem to allude to this topic too.
I've been unable to find an archive of this discussion so I don't know what
the results were. If the purists prevailed and not having graphing became
ethereal's policy then my code has little chance to make it into ethereal
however good it could be. I'm not a Windows user and as an ethereal user I
couldn't care less about Windows compatibility. If the code is to remain
the way it is now, just my personal ethereal extension, there's no point in
bothering with cross-platform issues. I mean, it would be nice if some
people compiled the patch (on linux if it doesn't compile anywhere else)
and told me that it makes sense to work on it some more.
To your comments: it should be trivial to comply with 1) and 2). As to 3),
I decided to focus on the graphing code itself first, then add support for
protocols that I don't use/have access to. Part of the reason is that I
failed to discover an easy way to use existing code inside ethereal for
detection of type of frame/packet and things like that. Before I started
coding I thought it would be possible to tell ethereal something along the
lines of "give me tcp header of segment #536" but I didn't find such API.
The whole interaction with ethereal guts is a mess that would probably
require cleaning up. I ended up with my own segment list that is created by
simple filtering ethereal's packet list immediately after the graph code is
activated. This approach is crude but it works OK for me. Again, we can
work this out if there's a reason to do so.
Please let me know whether the patch is any good and whether I should start
polishing and tightening loose ends. ;-)
pvl
