Sorry for the diff, after I sent the mail I remembered I should have used diff -u ...
First of all: I didn't get the email, and as today is Tuesday I don't think
the mail is just delayed.
Thanks for including the code for code for seeing the Symantec interface, I just
tested the new source code with my Symantec traces and it worked perfectly!
Checkpoint: I didn't analyze the original code very deely so I did not see that
the UUID check was "the other way round". Thank you for checking.
On my Nokias the long interface strings are exactly 10 chars and therefore not
null-terminated. With shorter interface strings (for example 6 chars) the rest
is filled with zeroes and therefore null-terminated.
with UUID/SUID:
The interface name is shortened to 6 bytes, followed by the UUID/SUUID.
In my example on interface eth-s2p1c0 I see in the trace
"6f 31 65 74 68 2d 73 32 00 00 82 fd" "o1eth-s2".
I checked the Checkpoint documentation about the UUID and it looks like that:
without UUID:
----------------------------------------------------------
|Byte | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10| 11|
----------------------------------------------------------
|tcpdump | Source MAC address |Destination MAC address|
----------------------------------------------------------
|fw |pck|cha| Interface name |
|monitor |dir|pos| |
----------------------------------------------------------
with UUID/SUUID:
----------------------------------------------------------
|Byte | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10| 11|
----------------------------------------------------------
|tcpdump | Source MAC address |Destination MAC address|
----------------------------------------------------------
|fw |pck|cha| Interface name | UUID / SUUID |
|monitor |dir|pos| | |
----------------------------------------------------------
The 4 UUID bytes are derived from four 32bit values.
byte 1+2: A counter which is used if the timestamp is not unique
(or more exactly the two least significant bytes of the counter).
byte 3+4: the two least significant bytes of the timestamp.
The other two values are not included in the trace.
>From this definition I think that the counter should always be zero
or small values but there is no way to guarantee that.
I did some traces on my firewalls and always got a counter of zero.
But for heavy traffic in very short time the counter could grow over 255
and then there is no more null-termination of the interface name string
if the interface string is 6 chars or more.
Martin