Hy!
Have a box with 4 interfaces (all em driver) running stable for more than a year. After updating to 20.7.4 the WAN interfaces comes up normally (get's IP via DHCP4), but after a few minutes the interfaces get's blown away, reboot helps only for 1-2 minutes:
2020-10-30T11:02:15 opnsense[93169] /usr/local/etc/rc.filter_configure: There were error(s) loading the rules: /tmp/rules.debug:186: no routing address with matching address family found. - The line in question reads [186]: pass out route-to ( em2 aaa.bbb.ccc.ddd ) from {em2} to {!(em2:network)} keep state allow-opts label "470b24148e83cbf020300f9a54691951" # let out anything from firewall host itself (force gw)
2020-10-30T11:02:15 opnsense[24319] /usr/local/etc/rc.linkup: Clearing states for stale wan route on em2
2020-10-30T11:02:15 opnsense[24319] /usr/local/etc/rc.linkup: DEVD Ethernet detached event for wan
"Prevent interface removal" is set for the WAN interface.
I disables suricata completely and now it's stable for some 10 min...
Any help? :-(
Was 20.7.3 the previous running version?
Yes! Any way to get that kernel back? No time to mess around with the router these days...
Leave Suricata disabled until you have time to mess around with the router, if this is a stable solution.
Quote from: chemlud on October 30, 2020, 05:54:41 PM
Yes! Any way to get that kernel back? No time to mess around with the router these days...
https://docs.opnsense.org/manual/opnsense_tools.html
Hi mimugmail!
I read there
Quote
Example 2:
The previous revert of strongswan was not the solution you expected so you try to completely revert to the previous OPNsense version:
# opnsense-revert -r 18.1.4 opnsense
Be aware to also check if there were kernel updates like above to also downgrade the kernel if needed!
...but don't really understand what the last sentence means. ?!?
And furthermore:
Quote
Warning
Before reverting a kernel please consult the forums or open an issue via Github. You should only revert kernels on test machines or when qualified team members advise you to do so!
...so is this really risky to revert back to 20.7.3?
Many thanks in advance!
Just revert the kernel, shouldnt be a problem
# opnsense-update -kr 20.7.3
Reboot and it should be better in this case. Lock kernel package from GUI to avoid accidental overwrite in the next update.
Cheers,
Franco
I get here:
# opnsense-update -kr 20.7.3
Fetching kernel-20.7.3-amd64.txz: ...... done
!!!!!!!!!!!! ATTENTION !!!!!!!!!!!!!!!
! A critical upgrade is in progress. !
! Please do not turn off the system. !
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Installing kernel-20.7.3-amd64.txz... done
Please reboot.
After reboot I enabled suricata, but it took only about one minute to kill the WAN again. And then I saw that kernel is still 20.7.4?!? I disabled again suricata for the moment, any ideas what went wrong? opnsense-revert instead of opnsense-update, maybe?
PS: The SSD has perfect SMART status, only 1130 h , not read-only.... What's the problem here?
Where do you see you have never kernel?
Ooops! I thought that it's "base " under System -> Firmware -> Packages, but it's "kernel"! And "base" is 20.7.4, while kernel is 20.7.3.
So the kernel is apparently not the problem here! What else could cause the interface (and only the WAN interface) to disconnect with suricata enabled?
I enabled suricata for the different LAN interfaces, no problem. Only if WAN is included in suricata the WAN interface disconnects....
When you just use IDS it works?
Can you also revert Suri like within the docs?
...in IDS mode with WAN it's stable for some 10 min now...
Should I revert suricata now? Or update the kernel and then revert suricata (to which version?)?
First revert Suricata
I did a
opnsense-revert -r 20.7.3 suricata
and rebooted, enabled IPS again (with WAN and all LAN's) and within 2-3 min WAN interface detached with the same log entry as posted above (DEVD Ethernet detached event for WAN).
So which package is the next suspect? :-O
PS: in IPS mode it's stable for the moment...
Maybe disable all rules, perhaps your ram blows away
You have to look in the difference between legacy and inline mode to find the culprit.
Quote from: mimugmail on November 02, 2020, 07:16:31 AM
Maybe disable all rules, perhaps your ram blows away
It's an i3 with 8GB RAM, usage 15% at most... No other package to downgrade? opnsense base, maybe?
Quote from: Supermule on November 02, 2020, 08:20:38 AM
You have to look in the difference between legacy and inline mode to find the culprit.
Hi, could you elaborate on that a little bit, I'm a user, not a coder... ;-)
Look at the console for the error why it freezes
I have a second box with comparable hardware, doing fine with 20.7.3 and suricata in IPS mode on LAN and WAN. But this morning at about 9:00 the WAN went down, reboot helped only for 1-2 minutes.
After third loss of WAN I disabled IPS and the connection is stable, but only until I enable IPS again, then the WAN interface get's down pretty much immediately.
2020-11-02T12:23:08 opnsense[20113] /usr/local/etc/rc.linkup: DEVD Ethernet detached event for wan
I changed nothing on this box! Can the IPS interfere with the box? Scary....
Quote from: mimugmail on November 02, 2020, 09:21:32 AM
Look at the console for the error why it freezes
Normally there is no error message in the serial console when the WAN goes down, but some minutes ago I had in the console while WAN down (on the second machine, starting this morning, with 20.7.3 installed):
...466.167540 [1742] nm_rxsync_prologue em0 RX1: fail 'head < kring->nr_hwcur || head > kring->nr_hwtail' h 0 c 0 t 1022 rh 0 rc 0 rt 1022 hc 1021 ht 1022
466.181403 [1787] netmap_ring_reinit called for em0 RX1
472.463680 [1742] nm_rxsync_prologue em0 RX1: fail 'head < kring->nr_hwcur || head > kring->nr_hwtail' h 31 c 31 t 21 rh 31 rc 31 rt 21 hc 20 ht 21
472.477197 [1787] netmap_ring_reinit called for em0 RX1
473.254040 [1742] nm_rxsync_prologue igb2 RX1: fail 'head < kring->nr_hwcur || head > kring->nr_hwtail' h 714 c 714 t 713 rh 714 rc 714 rt 713 hc 711 ht 713
473.268350 [1787] netmap_ring_reinit called for igb2 RX1
475.718351 [1742] nm_rxsync_prologue igb2 RX1: fail 'head < kring->nr_hwcur || head > kring->nr_hwtail' h 725 c 725 t 723 rh 725 rc 725 rt 723 hc 721 ht 723
475.732652 [1787] netmap_ring_reinit called for igb2 RX1
475.740008 [1742] nm_rxsync_prologue igb2 RX1: fail 'head < kring->nr_hwcur || head > kring->nr_hwtail' h 724 c 724 t 723 rh 724 rc 724 rt 723 hc 566 ht 723
475.754306 [1787] netmap_ring_reinit called for igb2 RX1
483.402555 [1742] nm_rxsync_prologue igb0 RX2: fail 'head < kring->nr_hwcur || head > kring->nr_hwtail' h 26 c 26 t 22 rh 26 rc 26 rt 22 hc 21 ht 22
483.416156 [1787] netmap_ring_reinit called for igb0 RX2
489.248676 [1742] nm_rxsync_prologue em0 RX1: fail 'head < kring->nr_hwcur || head > kring->nr_hwtail' h 106 c 106 t 100 rh 106 rc 106 rt 100 hc 99 ht 100
489.262805 [1787] netmap_ring_reinit called for em0 RX1
492.266657 [1742] nm_rxsync_prologue em0 RX1: fail 'head < kring->nr_hwcur || head > kring->nr_hwtail' h 114 c 114 t 108 rh 114 rc 114 rt 108 hc 107 ht 108
492.280870 [1787] netmap_ring_reinit called for em0 RX1
492.324378 [1742] nm_rxsync_prologue igb2 RX1: fail 'head < kring->nr_hwcur || head > kring->nr_hwtail' h 752 c 752 t 747 rh 752 rc 752 rt 747 hc 744 ht 747
492.338674 [1787] netmap_ring_reinit called for igb2 RX1
496.058933 [1742] nm_rxsync_prologue em0 RX1: fail 'head < kring->nr_hwcur || head > kring->nr_hwtail' h 142 c 142 t 127 rh 142 rc 142 rt 127 hc 126 ht 127
496.073143 [1787] netmap_ring_reinit called for em0 RX1
502.387235 [1742] nm_rxsync_prologue em0 RX1: fail 'head < kring->nr_hwcur || head > kring->nr_hwtail' h 144 c 144 t 142 rh 144 rc 144 rt 142 hc 141 ht 142
502.401452 [1787] netmap_ring_reinit called for em0 RX1
504.390558 [1742] nm_rxsync_prologue em0 RX1: fail 'head < kring->nr_hwcur || head > kring->nr_hwtail' h 147 c 147 t 145 rh 147 rc 147 rt 145 hc 144 ht 145
504.404775 [1787] netmap_ring_reinit called for em0 RX1
But I could not catch all the output.
Quote from: chemlud on November 02, 2020, 01:15:21 PM
Quote from: mimugmail on November 02, 2020, 09:21:32 AM
Look at the console for the error why it freezes
Normally there is no error message in the serial console when the WAN goes down, but some minutes ago I had in the console while WAN down (on the second machine, starting this morning, with 20.7.3 installed):
...466.167540 [1742] nm_rxsync_prologue em0 RX1: fail 'head < kring->nr_hwcur || head > kring->nr_hwtail' h 0 c 0 t 1022 rh 0 rc 0 rt 1022 hc 1021 ht 1022
466.181403 [1787] netmap_ring_reinit called for em0 RX1
472.463680 [1742] nm_rxsync_prologue em0 RX1: fail 'head < kring->nr_hwcur || head > kring->nr_hwtail' h 31 c 31 t 21 rh 31 rc 31 rt 21 hc 20 ht 21
472.477197 [1787] netmap_ring_reinit called for em0 RX1
473.254040 [1742] nm_rxsync_prologue igb2 RX1: fail 'head < kring->nr_hwcur || head > kring->nr_hwtail' h 714 c 714 t 713 rh 714 rc 714 rt 713 hc 711 ht 713
473.268350 [1787] netmap_ring_reinit called for igb2 RX1
475.718351 [1742] nm_rxsync_prologue igb2 RX1: fail 'head < kring->nr_hwcur || head > kring->nr_hwtail' h 725 c 725 t 723 rh 725 rc 725 rt 723 hc 721 ht 723
475.732652 [1787] netmap_ring_reinit called for igb2 RX1
475.740008 [1742] nm_rxsync_prologue igb2 RX1: fail 'head < kring->nr_hwcur || head > kring->nr_hwtail' h 724 c 724 t 723 rh 724 rc 724 rt 723 hc 566 ht 723
475.754306 [1787] netmap_ring_reinit called for igb2 RX1
483.402555 [1742] nm_rxsync_prologue igb0 RX2: fail 'head < kring->nr_hwcur || head > kring->nr_hwtail' h 26 c 26 t 22 rh 26 rc 26 rt 22 hc 21 ht 22
483.416156 [1787] netmap_ring_reinit called for igb0 RX2
489.248676 [1742] nm_rxsync_prologue em0 RX1: fail 'head < kring->nr_hwcur || head > kring->nr_hwtail' h 106 c 106 t 100 rh 106 rc 106 rt 100 hc 99 ht 100
489.262805 [1787] netmap_ring_reinit called for em0 RX1
492.266657 [1742] nm_rxsync_prologue em0 RX1: fail 'head < kring->nr_hwcur || head > kring->nr_hwtail' h 114 c 114 t 108 rh 114 rc 114 rt 108 hc 107 ht 108
492.280870 [1787] netmap_ring_reinit called for em0 RX1
492.324378 [1742] nm_rxsync_prologue igb2 RX1: fail 'head < kring->nr_hwcur || head > kring->nr_hwtail' h 752 c 752 t 747 rh 752 rc 752 rt 747 hc 744 ht 747
492.338674 [1787] netmap_ring_reinit called for igb2 RX1
496.058933 [1742] nm_rxsync_prologue em0 RX1: fail 'head < kring->nr_hwcur || head > kring->nr_hwtail' h 142 c 142 t 127 rh 142 rc 142 rt 127 hc 126 ht 127
496.073143 [1787] netmap_ring_reinit called for em0 RX1
502.387235 [1742] nm_rxsync_prologue em0 RX1: fail 'head < kring->nr_hwcur || head > kring->nr_hwtail' h 144 c 144 t 142 rh 144 rc 144 rt 142 hc 141 ht 142
502.401452 [1787] netmap_ring_reinit called for em0 RX1
504.390558 [1742] nm_rxsync_prologue em0 RX1: fail 'head < kring->nr_hwcur || head > kring->nr_hwtail' h 147 c 147 t 145 rh 147 rc 147 rt 145 hc 144 ht 145
504.404775 [1787] netmap_ring_reinit called for em0 RX1
But I could not catch all the output.
Thats a netmap related error and enough of them will crash the machine.
Legacy mode doesnt use netmap.
Quote from: Supermule on November 02, 2020, 01:28:00 PM
Quote from: chemlud on November 02, 2020, 01:15:21 PM
...
Thats a netmap related error and enough of them will crash the machine.
Legacy mode doesnt use netmap.
Hmm, I know this legacy thing only for Snort, where to configure in opnsense IDS/IPS?
I updated the second box to 20.7.4, same game, whenever I enable IPS, the WAN is dead within 1-2 minutes. No idea what to try next...
Quote from: chemlud on November 02, 2020, 10:57:27 PM
I updated the second box to 20.7.4, same game, whenever I enable IPS, the WAN is dead within 1-2 minutes. No idea what to try next...
And it was 20.7.3 before?
Quote from: mimugmail on November 03, 2020, 06:30:47 AM
Quote from: chemlud on November 02, 2020, 10:57:27 PM
I updated the second box to 20.7.4, same game, whenever I enable IPS, the WAN is dead within 1-2 minutes. No idea what to try next...
And it was 20.7.3 before?
Yes, the box that started loosing WAN yesterday around 9:00 the first time. I will activate my testing box with comparable (but slightly different, see https://forum.opnsense.org/index.php?topic=19377.msg89581#msg89581) hardware to see what happens there...
Quote from: chemlud on October 31, 2020, 04:18:24 PM
I get here:
# opnsense-update -kr 20.7.3
Fetching kernel-20.7.3-amd64.txz: ...... done
!!!!!!!!!!!! ATTENTION !!!!!!!!!!!!!!!
! A critical upgrade is in progress. !
! Please do not turn off the system. !
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Installing kernel-20.7.3-amd64.txz... done
Please reboot.
After reboot I enabled suricata, but it took only about one minute to kill the WAN again. And then I saw that kernel is still 20.7.4?!? I disabled again suricata for the moment, any ideas what went wrong? opnsense-revert instead of opnsense-update, maybe?
Huh, what made you say it's still "20.7.4"? The commands to verify this are "opnsense-version kernel" and "uname -a".
Cheers,
Franco
@franco
Quote from: chemlud on November 01, 2020, 01:51:02 PM
Ooops! I thought that it's "base " under System -> Firmware -> Packages, but it's "kernel"! And "base" is 20.7.4, while kernel is 20.7.3.
...discussion moved on quite a bit since the post you quoted ;-)
I updated my third Dell box with 5 NICs to 20.7.4, enabled IPS on WAN and LANs (set various rule sets to block). Stable for the moment, but the differences are: WAN has a private IP (no chance to connect directly to ISP during day time) and virtually no traffic going back and forth, as only one client in LAN...
Transfered the config to the newer Dell Optiplex 7020 and the IPS can be started without breaking WAN. Interesting. Both older Optiplex 790 had the error on boot described earlier
https://forum.opnsense.org/index.php?topic=19377.msg89368#msg89368
and both recently started to loose the WAN interface with IPS enabled, one on 20.7.3 (after running fine for weeks with that version), one after updating to 20.7.4.
This makes hardly any sense to me. But seems hardware-related.
And: No, it's not the RAM, I moved the RAM from the 790 to the 7020 and it works just fine in this machine...
And: All machines are on latest BIOS version available.
How to get IPS back on the second opnsense with Optiplex 790? Do I have to buy a new machine? :-o
OK, fresh install with 20.7 on a 790er, (last fresh install with 20.1...) and import of config. No error message on boot and IPS doing fine for more than an hour.
Quote from: chemlud on November 05, 2020, 09:23:05 PM
OK, fresh install with 20.7 on a 790er, (last fresh install with 20.1...) and import of config. No error message on boot and IPS doing fine for more than an hour.
Thx, please keep us updated.
No idea why I didn't see this yesterday, but on the 7020 with fresh install the error came back:
2020-11-04T16:59:29 opnsense[30930] /usr/local/etc/rc.filter_configure: There were error(s) loading the rules: /tmp/rules.debug:186: no routing address with matching address family found. - The line in question reads [186]: pass out route-to ( em2 aaa.bbb.ccc.ddd ) from {em2} to {!(em2:network)} keep state allow-opts label "470b24148e83cbf020300f9a54691951" # let out anything from firewall host itself (force gw)
....
2020-11-04T16:59:17 opnsense[98631] /usr/local/etc/rc.linkup: Hotplug event detected for xxxxxx(opt3) but ignoring since interface is configured with static IP (aaa.bbb.ccc.ddd ::)
2020-11-04T16:59:17 kernel em3: link state changed to UP
2020-11-04T16:59:16 opnsense[52609] /usr/local/etc/rc.linkup: Hotplug event detected for yyyyyyyy(opt2) but ignoring since interface is configured with static IP (vvv.bbb.nnn.mmm ::)
2020-11-04T16:59:16 kernel em0: link state changed to DOWN
2020-11-04T16:59:16 opnsense[25138] /usr/local/etc/rc.linkup: Hotplug event detected for LAN2(opt1) but ignoring since interface is configured with static IP (fff.ddd.sss.aaa ::)
2020-11-04T16:59:15 kernel em4: link state changed to DOWN
2020-11-04T16:59:15 opnsense[96867] /usr/local/etc/rc.linkup: Hotplug event detected for LAN(lan) but ignoring since interface is configured with static IP (qqq.www.eee.rrr ::)
2020-11-04T16:59:15 kernel em1: link state changed to DOWN
2020-11-04T16:59:14 opnsense[80384] /usr/local/etc/rc.linkup: Hotplug event detected for xxxxx(opt3) but ignoring since interface is configured with static IP (aaa.bbb.ccc.ddd ::)
2020-11-04T16:59:14 kernel em3: link state changed to DOWN
The log session starts with all interfaces (including WAN (em2), which is the built-in NIC of the Optiplex board) going down some minutes after a reboot. Then 6 seconds later the WAN is said to be up from kernel. And new WAN IP is requested via DHCP from ISP.
THEN (!) the "DEVD: Ethernet detached event for wan" error message occurs, followed by the ": no routing address with matching address family found. " error message.
But in the seconds thereafter the interfaces go down again. And some 5-6 minutes later all interfaces go down again. And some 10 minutes later interfaces down again, but then (without any interference by admin) the interfaces are stable.
Does this make sense at all?
IPS with 20.7.4 stable for the moment.
Just to add: after first reboot also the second OPNsense has the same error shown in the Dashboard:
2020-11-11T19:44:27 opnsense[59392] /usr/local/etc/rc.filter_configure: There were error(s) loading the rules: /tmp/rules.debug:207: no routing address with matching address family found. - The line in question reads [207]: pass out route-to ( em2 wan.add.res.1 ) from {em2} to {!(em2:network)} keep state allow-opts label "470b24148e83cbf020300f9a54691951" # let out anything from firewall host itself (force gw)
Is this a provider modem giving out DHCP addresses?
Nope, one install has a Cisco cabel modem in bridge mode, the other one a fiber converter. In both cases the DHCP server is on ISPs network (although at least one ISP uses a private subnet IP for DHCP (what I see from system logs), which is apparently not (!) blocked by the "Block private networks" on the WAN interface.
Both installs have IPv6 disabled wherever I can find it. But sometimes when I test DNS (with websites for testing) I get in the results even an IPv6 address for one of the configured DNS (DoT) servers. I have a feeling that the OPNsense services itself (such as unbound) might be using IPv6 even when generally disabled ("no routing address with matching address family found")...
PS: To be 100% clear: The topic of this thread (Wan blown away in suricata IPS mode) is resolved by the re-installation of OPNsense 20.7, but the other issue (error on reboot) is still valid, starting from SECOND reboot after re-installing the config.xml in BOTH OPNsense installs.
On rebooting everything looks normal at first:
2020-11-11T19:43:07 kernel OK
2020-11-11T19:43:07 kernel pflog0: promiscuous mode enabled
2020-11-11T19:43:07 kernel pflog0: promiscuous mode disabled
2020-11-11T19:43:07 kernel
2020-11-11T19:43:07 kernel done.
2020-11-11T19:43:07 kernel ...
2020-11-11T19:43:07 /flowd_aggregate.py[36005] vacuum done
2020-11-11T19:43:07 /flowd_aggregate.py[36005] start watching flowd
2020-11-11T19:43:06 /flowd_aggregate.py[36005] startup, check database.
But after 1 min. and 7 seconds all interfaces go down and then up again:
2020-11-11T19:44:28 opnsense[24025] /usr/local/etc/rc.newwanip: IPv4 renewal is starting on 'ovpns5'
2020-11-11T19:44:27 opnsense[54704] /usr/local/etc/rc.newwanip: OpenVPN server 5 instance started on PID 29501.
2020-11-11T19:44:27 kernel ovpns5: link state changed to UP
2020-11-11T19:44:27 opnsense[59392]
2020-11-11T19:44:27 opnsense[59392] /usr/local/etc/rc.filter_configure: There were error(s) loading the rules: /tmp/rules.debug:207: no routing address with matching address family found. - The line in question reads [207]: pass out route-to ( em2 fff.ggg.hhh.jjj ) from {em2} to {!(em2:network)} keep state allow-opts label "470b24148e83cbf020300f9a54691951" # let out anything from firewall host itself (force gw)
2020-11-11T19:44:27 opnsense[94696] /usr/local/etc/rc.linkup: Clearing states for stale wan route on em2
2020-11-11T19:44:27 opnsense[94696] /usr/local/etc/rc.linkup: DEVD Ethernet detached event for wan
2020-11-11T19:44:27 opnsense[74449] plugins_configure newwanip (execute task : webgui_configure_do(,opt2))
2020-11-11T19:44:26 opnsense[74449] plugins_configure newwanip (execute task : vxlan_configure_interface())
2020-11-11T19:44:26 kernel ovpns5: link state changed to DOWN
2020-11-11T19:44:26 opnsense[54704] /usr/local/etc/rc.newwanip: Resyncing OpenVPN instances for interface WAN.
2020-11-11T19:44:26 kernel pflog0: promiscuous mode enabled
2020-11-11T19:44:26 kernel pflog0: promiscuous mode disabled
...
2020-11-11T19:44:19 kernel em1: link state changed to UP
2020-11-11T19:44:18 kernel em0: link state changed to UP
2020-11-11T19:44:18 kernel em2: link state changed to DOWN
2020-11-11T19:44:17 opnsense[74449] /usr/local/etc/rc.newwanip: On (IP address: aaa.bbb.ccc.ddd) (interface: LAN2[opt2]) (real interface: em4).
2020-11-11T19:44:17 opnsense[74449] /usr/local/etc/rc.newwanip: IPv4 renewal is starting on 'em4'
2020-11-11T19:44:17 opnsense[93354] /usr/local/etc/rc.linkup: Hotplug event detected for LAN3(opt2) but ignoring since interface is configured with static IP (ddd.eee.fff.ggg ::)
2020-11-11T19:44:17 kernel em4: link state changed to UP
2020-11-11T19:44:16 opnsense[50217] /usr/local/etc/rc.linkup: Hotplug event detected for LAN(lan) but ignoring since interface is configured with static IP (bbb.aaa.sss.ddd ::)
2020-11-11T19:44:16 kernel em1: link state changed to DOWN
2020-11-11T19:44:15 opnsense[82468] /usr/local/etc/rc.linkup: Hotplug event detected for LAN2(opt1) but ignoring since interface is configured with static IP (aaa.ccc.vvv.bbb ::)
2020-11-11T19:44:15 kernel em0: link state changed to DOWN
2020-11-11T19:44:14 opnsense[4008] /usr/local/etc/rc.linkup: Hotplug event detected for LAN3(opt2) but ignoring since interface is configured with static IP (ccc.qqq.www.eee ::)
2020-11-11T19:44:14 kernel em4: link state changed to DOWN
I just skipped some lines with messages that aliases could not be resolved (as WAN is down...)
And: Yes, the line AFTER the message, starting with "kernel " is REALLY empty in the system log.
But after the last one every interface is up and working?
Now: Yes
Before reinstall: No.
Puh ... no idea :/
What happenz about 1 min after reboot is completed to reproducibly kill off all physical interfaces? That makes no sense to me at all...
Hmmm:
Suricata starts something with netmap!
2020-11-11T19:44:23 suricata[11099] [100109] <Notice> -- all 8 packet processing threads, 4 management threads initialized, engine started.
2020-11-11T19:44:22 suricata[11099] [100325] <Notice> -- opened netmap:em2/T from em2: 0x3d4a9fcf300
2020-11-11T19:44:21 suricata[11099] [100325] <Notice> -- opened netmap:em2^ from em2^: 0x3d4a9fcf000
2020-11-11T19:44:19 suricata[11099] [100316] <Notice> -- opened netmap:em2^ from em2^: 0x3d4a84c5300
2020-11-11T19:44:18 suricata[11099] [100316] <Notice> -- opened netmap:em2/R from em2: 0x3d4a84c5000
2020-11-11T19:44:16 suricata[11099] [100315] <Notice> -- opened netmap:em1/T from em1: 0x3d4a7400300
2020-11-11T19:44:16 suricata[11099] [100315] <Notice> -- opened netmap:em1^ from em1^: 0x3d4a7400000
2020-11-11T19:44:16 suricata[11099] [100307] <Notice> -- opened netmap:em1^ from em1^: 0x3d4a6e18300
2020-11-11T19:44:16 suricata[11099] [100307] <Notice> -- opened netmap:em1/R from em1: 0x3d4a6e18000
2020-11-11T19:44:15 suricata[11099] [100306] <Notice> -- opened netmap:em0/T from em0: 0x3d4a5ec9300
2020-11-11T19:44:15 suricata[11099] [100306] <Notice> -- opened netmap:em0^ from em0^: 0x3d4a5ec9000
2020-11-11T19:44:15 suricata[11099] [100298] <Notice> -- opened netmap:em0^ from em0^: 0x3d4a5c38300
2020-11-11T19:44:15 suricata[11099] [100298] <Notice> -- opened netmap:em0/R from em0: 0x3d4a5c38000
2020-11-11T19:44:15 suricata[11099] [100297] <Notice> -- opened netmap:em4/T from em4: 0x3d4a4d85300
2020-11-11T19:44:14 suricata[11099] [100297] <Notice> -- opened netmap:em4^ from em4^: 0x3d4a4d85000
2020-11-11T19:44:14 suricata[11099] [100288] <Notice> -- opened netmap:em4^ from em4^: 0x3d4a328e300
2020-11-11T19:44:14 suricata[11099] [100288] <Notice> -- opened netmap:em4/R from em4: 0x3d4a328e000
The second it starts, the same moment the interface is blown away...
And takes about 3 sec. to recover...
Can you ping user @mb here in the forums if he has an idea?