Skip to content

Xdp tunnel 7674 v9#2969

Closed
catenacyber wants to merge 6 commits into
OISF:masterfrom
catenacyber:xdp-tunnel-7674-v9
Closed

Xdp tunnel 7674 v9#2969
catenacyber wants to merge 6 commits into
OISF:masterfrom
catenacyber:xdp-tunnel-7674-v9

Conversation

@catenacyber

Copy link
Copy Markdown
Collaborator

Ticket

Redmine ticket: https://redmine.openinfosecfoundation.org/issues/7674

#2777 continuation :

  • needed rebase
  • added last commit to not sleep, but count packets

@lukashino

Copy link
Copy Markdown
Contributor

I generally like the idea and the PR. Two things that I would suggest:

  • hints that live tests need to be run with root privileges -- perhaps some check when live mode is used, or to better evaluate the return codes?
  • if SV has a root access, then it can perhaps create a new virtual device with a random name, so the user does not need to specify any live interface -- I see in Xdp tunnel 7674 v12 suricata#15168 you use lo -- that's also possible, so perhaps take that as a default?

Then, for the final state, I would expect that at least the help command would give more info on what it is and what it requires (sudo + interface).

@lukashino

Copy link
Copy Markdown
Contributor

Especially with lo interface, I would suggest adding a BPF filter excluding localhost traffic from Suricata to avoid flaky tests.

I have received some during my short observation of the lo:

15:52:01.307090 IP localhost.45112 > localhost.23119: Flags [S], seq 1115579318, win 65495, options [mss 65495,sackOK,TS val 3816135067 ecr 0,nop,wscale 7], length 0
15:52:01.307105 IP localhost.23119 > localhost.45112: Flags [R.], seq 0, ack 1115579319, win 0, length 0
16:02:47.589532 IP localhost.mdns > mdns.mcast.net.mdns: 0 [3q] PTR (QM)? _nmea-0183._tcp.local. PTR (QM)? _ipps._tcp.local. PTR (QM)? _ipp._tcp.local. (62)
16:12:17.719838 IP localhost.50426 > localhost.23119: Flags [S], seq 2865223153, win 65495, options [mss 65495,sackOK,TS val 3817351480 ecr 0,nop,wscale 7], length 0
16:12:17.719848 IP localhost.23119 > localhost.50426: Flags [R.], seq 0, ack 2865223154, win 0, length 0

@catenacyber

Copy link
Copy Markdown
Collaborator Author

Especially with lo interface, I would suggest adding a BPF filter excluding localhost traffic from Suricata to avoid flaky tests.

You can use your own dummy interface other than lo ;-)

@catenacyber

Copy link
Copy Markdown
Collaborator Author
  • hints that live tests need to be run with root privileges -- perhaps some check when live mode is used, or to better evaluate the return codes?

@jasonish should I add uid: 0 ? to test requires (only in skip now)

  • if SV has a root access, then it can perhaps create a new virtual device with a random name, so the user does not need to specify any live interface -- I see in Xdp tunnel 7674 v12 suricata#15168 you use lo -- that's also possible, so perhaps take that as a default?

I think this is outside of the scope of SV and should be done by the caller...

@jasonish

Copy link
Copy Markdown
Member

@jasonish should I add uid: 0 ? to test requires (only in skip now)

You have to opt-in to live mode right? So can't run.py just do the check and error out if not root?

@jasonish

Copy link
Copy Markdown
Member
  • if SV has a root access, then it can perhaps create a new virtual device with a random name, so the user does not need to specify any live interface -- I see in Xdp tunnel 7674 v12 suricata#15168 you use lo -- that's also possible, so perhaps take that as a default?

I think this is outside of the scope of SV and should be done by the caller...

This has me wondering if integrating replay tests into the namespace based testing makes sense. A name space with a virtual network card could automatically be created as one of the environments, and the replay managed by the existing life cycle there. Just a thought for now, as I'm still iterating on that work quite rapidly and want to keep focus on live firewall testing at the moment.

@lukashino

Copy link
Copy Markdown
Contributor
  • if SV has a root access, then it can perhaps create a new virtual device with a random name, so the user does not need to specify any live interface -- I see in Xdp tunnel 7674 v12 suricata#15168 you use lo -- that's also possible, so perhaps take that as a default?

I think this is outside of the scope of SV and should be done by the caller...

Tricky argument. The same can be applied to "The script should not link up the interface and leave it like that" heh. Well, I think the use of lo can actually be pretty good for this use case. I would just root for the default BPF filter to avoid localhost traffic.

@catenacyber

Copy link
Copy Markdown
Collaborator Author

@jasonish should I add uid: 0 ? to test requires (only in skip now)

You have to opt-in to live mode right? So can't run.py just do the check and error out if not root?

But I think "root" may not be needed for all live tests, I think it is needed by the current test only for the ebpf part
What do you think ?

@catenacyber

Copy link
Copy Markdown
Collaborator Author

Tricky argument. The same can be applied to "The script should not link up the interface and leave it like that" heh. Well, I think the use of lo can actually be pretty good for this use case. I would just root for the default BPF filter to avoid localhost traffic.

Thanks for this, looks like my case was already overruled by Jason. So, I will try to create a new virtual device with a random name, so the user does not need to specify any live interface

@catenacyber

Copy link
Copy Markdown
Collaborator Author

Next version in #3045

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

framework Has a suricata-verify framework change requires suricata pr Depends on a PR in Suricata

Development

Successfully merging this pull request may close these issues.

3 participants