[bugzilla-daemon@xxxxxxxxxxxxx]

Comment # 5 on bug 11424 from Aimen Al-Janabi

(In reply to Pascal Quantin from comment #4)
> (In reply to Aimen Al-Janabi from comment #3)
> > Thank you Pascal for the prompt response, I really appreciate the help. I
> > understand why this is happening now, and I will contact VSS for this. I was
> > just wondering if it is possible that the leading zero's are not part of the
> > trailer VSS is adding, instead it is part of the last segment of the packet
> > yet misinterpreted by Wireshark? I will exhaust the other options with VSS,
> > before I carry on with this.
> 
> We can see this with TCP packets that only have a header without payload
> (Rest packet for ex) so this really seems to be padding added on purpose by
> VSS Monitoring equipment. The fact that it is prepended instead of appended
> make it more painful for heuristic detection.

Hi Pascal, Thanks again for this. I will add the following information just in
case VSS require an update to the dissector. I will point their support to this
thread, and if they akgnowledge a bug in the VSS device, I will request the
closure of this ticket.

There are three features involved
a)    802.1ad:    VSS allow to use this tag to identify the source device and
port in a decimal number. (e.g. we set 300 for the device + 9 is built-in for
the port = ieee8021ad.id == 309 the physical port this packet came from). We
are using this feature, and it allows the 802.1Q tag to escape removal by
Windows kernel or the network card driver/vlan accelerator.
b)    Portstamping from VSS: We are not licensed for this feature, and we do
not see an option to enable this feature on our ports. That is not to say there
isn’t a bug still trying to add the port identifier.
c)    Timestamping from VSS

1.    If I enable both features (802.1ad and Timestamping), most of the packets
will decode  802.1ad, 802.1Q, and vssmonitoring timestamp correctly, without
seeing anything about vss portstamping. A small amount of packets will show the
trailer combined in the 802.1Q section with the leading zero’s. If I untick the
box for “use heuristics to identify if trailer contains VSS-monitoring data”,
the problematic packets will show vssmonitoring section, but datetime and
timesource decoded incorrectly.  The healthy packets do not seem to get
effected by the tickbox.
2.    If I disable the timestamping feature, the problematic packets start to
show vss portstamping (for the leading zeros’). Unticking the “use heuristics
to identify if trailer contains VSS-monitoring data” does not affect any
packets. (capture attached)
3.    If I disable both (802.1ad and Timestamping), I will get similar
behaviour to the previous condition. Except when I untick the “use heuristics
to identify if trailer contains VSS-monitoring data”, I will get some packets
where the tailing zero’s will be decoded as vss timestamps in 1/1/1970 epoch.
Of course, I will lose the 802.1Q as well, since they get stripped out by
Windows.
4.    If I enable Timestamping only with no 802.1ad, and consequently 802.1Q 
removed by Windows, I will get some packets with bad checksum because Wireshark
is looking in slightly shifted place for the checksum eth.fcs_bad.expert=true.
Unticking the “use heuristics to identify if trailer contains VSS-monitoring
data” does not affect any packets.

---

      You are receiving this mail because:

• You are watching all bug changes.