mirror of https://github.com/OISF/suricata
pfring: fix vlan handling issues
When Suricata was monitoring traffic with a single vlan layer, the stats and output instead showed 2. This was caused by the raw packets PF_RING feeds Suricata would hold the vlan header, but the code assumed that the header was stripped and the vlan_id passed to Suricata through PF_RING's extended_hdr.parsed_pkt. This patch adds the following logic: Check vlan id from the parser packet PF_RING prepared. PF_RING sets the vlan_id based on its own parsing or based on the hardware offload. It gives no indication on where the vlan_id came from, so we rely on the vlan_offset field. If it's 0, we assume the PF_RING parser did not see the vlan header and got it from the hardware offload. In this case we will use this information directly, as we won't get a raw vlan header later. If PF_RING did set the offset, we do the parsing in the Suricata decoder so that we have full control. PF_RING *should* put back the vlan header in all cases, and also set the vlan_offset field, but as a extra precaution keep the check described above. Bug #2355.pull/3108/head
parent
711b6fb389
commit
189b521239
Loading…
Reference in New Issue