Ethereal-dev: Re: [Ethereal-dev] Symantec Enterprise Firewall & Checkpoint fw monitor - dumps
Pichlmaier Martin wrote:
I'm not a member of the ethereal-dev list,
If you don't get this mail, let us know - I did a "reply to all", and
it's replying only to the list, but sometimes a "reply to all" adds the
sender's address. I'd guessed that Mailman was adding the sender's name
to the Reply-To: header if the sender isn't on the list, but if you're
not on the list, that appears not to be the case. (Gerald indicated
that standard Mailman doesn't do that, but that there was a patch to let
it do that.)
Symantec: the first 4 bytes are the IP of the interface that saw the
packet. Helps to see going a packet through the firewall.
At least that works with my Symantec Firewalls (6.52 and 7.0 on NT),
never tried with Symantec 8 or with the appliances.
Here's the diff for the packet-symantec.c in epan/dissectors:
A "diff -c" or "diff -u" generally works better, as it is more likely to
work if the file has had changes checked in after the diff was
generated. (A forward diff is also a bit better, although "patch" can
often infer that a diff was done backwards.)
I've checked the change in, but used "proto_tree_add_item()" to add the
interface IP address, as "interface_ip" was only being used to add the
IP address to the protocol tree.
It appears to do something sensible on the one Symantec firewall capture
I have (which I think somebody with that firewall - I think it was the
person who submitted the patch to add Symantec firewall support - sent
to the list).
Checkpoint:
That new code for UUID/SUUID with taking only 5 (or 6) chars of interface name
makes interface name unreadable for longer strings if the UUID/SUUID flags
of fw monitor are not used. Especially with Nokia IP boxes the interface names
are like eth-s1p1c0 or eth-s2p1c0 and you get no difference in the first 5 chars.
I tried a modification in packet-fw1.c:
The dissector has a preference setting to indicate that the capture file
includes UUIDs; if you clear that Boolean preference, it *should* use
all 10 characters of the interface name, but it appears that the code
that fetches the interface name was backwards - it fetched the full 10
characters if the preference was *set* (i.e., if the capture *does* have
UUID information) and only 6 characters if it was *clear* (i.e., if the
capture *doesn't* have UUID information).
I've fixed it.
Is that string null-terminated (i.e., is the maximum length 5 if the
UUIDs are present and 9 characters if they're not present, because
there's *always* a '\0' at the end of the string), or null-*padded*
(i.e., is the maximum length 6 if the UUIDs are present and 10
characters if they're present, because if the string doesn't take up all
of the field, it's padded with '\0's)?
...
and it worked fine for me. Don't know whether there are some drawbacks.
What if the UUID/SUUID flags *were* used, and the interface name is 6
characters long? It'd include the UUID/SUUID as part of the interface
name string.
Is there any way
