Hi, The issue is that Snort processes packets starting from the Layer 3 (L3) header pointer as Benoit has mentioned above, whereas packets in device-input still contain the Layer 2 (L2) headers.
Creating a copy of the packet is expensive. Instead, you could use the Snort plugin as inline from within your plugin. This would require implementing snort-input and snort-output nodes that forward traffic to snort-enq and receive processed packets from the snort-deq node. For reference, the SFDP plugin includes a Snort service implementation that can be used as an example. -br Mohsin On Tue, 9 Jun 2026 at 09:25, [email protected] via lists.fd.io < [email protected]> wrote: > > -> Any reason why ip4-input is not appropriate? You'd get L2 and L3 > headers validation, and avoid sending ARP etc. to Snort. my own vpp plugin > will take over the traffic from device-input node, it will not go into > ip4-unicast node. we need a copy into snort, and then go back to my plugin. > Does that make sense ? > > ------------------------------------------------------------------ > 发件人：Benoit Ganne (bganne) via lists.fd.io <[email protected]> > 发送时间：2026年6月9日(周二) 16:07 > 收件人："[email protected]"<[email protected]> > 主 题：Re: [vpp-dev] Question about integrating custom node and snort_plugin > on device-input feature arc > > > Is the above design (moving snort_plugin to device-input) considered > reasonable? Could there be any missing prerequisites (e.g., L2 header not > yet processed, or missing flow information) that prevent Snort from > properly inspecting the packets? > > I am no expert, but the main difference between device-input and ip4-input > should be that the current packet offset (b->data + b->current_data) points > to the L2 header (ethernet) and not L3 (IP). So if you did not change > anything else, you might consider trying something like b->current_data += > sizeof(ethernet_header_t) before passing the packet to Snort. > > > If this design is not optimal, what alternative solutions would you > recommend to achieve both (a) custom processing at an early stage and (b) > sending a duplicate copy of the original packets to Snort? > > Any reason why ip4-input is not appropriate? You'd get L2 and L3 headers > validation, and avoid sending ARP etc. to Snort. > > Best > ben > > > > > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#27058): https://lists.fd.io/g/vpp-dev/message/27058 Mute This Topic: https://lists.fd.io/mt/119736439/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
