[Bug 240818] igb(4) vlanhwfilter feature generate link UP/DOWN for each new vlan created

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818 Raúl changed: What|Removed |Added CC||raul.mu...@custos.es --- Comment #16 from R

[Bug 240818] igb(4) vlanhwfilter feature generate link UP/DOWN for each new vlan created

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818 --- Comment #17 from martin.m...@orange.fr --- (In reply to Raúl from comment #16) No, unfortunately: Unplugging/repluging the cable doesn't work, like i said. The only way is to manually reset by ifconfig(8) down and up the parent interface

[Bug 246737] 4 sys.netipsec.tunnel tests fail after (r361466, r361490]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246737 --- Comment #8 from commit-h...@freebsd.org --- A commit references this bug: Author: lwhsu Date: Fri May 29 10:09:48 UTC 2020 New revision: 361623 URL: https://svnweb.freebsd.org/changeset/base/361623 Log: Revert r361497, these cases ar

[Bug 246737] 4 sys.netipsec.tunnel tests fail after (r361466, r361490]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246737 Li-Wen Hsu changed: What|Removed |Added Resolution|--- |FIXED Status|Open

[Bug 246748] feature wish: reply_from_interface and reply_src sysctl for IPv6

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246748 Andrey V. Elsukov changed: What|Removed |Added CC||a...@freebsd.org --- Comment #

[Bug 246748] feature wish: reply_from_interface and reply_src sysctl for IPv6

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246748 --- Comment #2 from Gert Doering --- No, as RFC3484 / RFC6724 do not take context into account ("packet comes in on em0, so use em0 source for the ICMP error packet, even if we intend to send the packet via em3"). I do not want *all* packe

[Bug 240818] igb(4) vlanhwfilter feature generate link UP/DOWN for each new vlan created

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818 --- Comment #18 from Raúl --- (In reply to martin.mato from comment #17) I'll look how to test it on site before returning it back home. Given covid-19 circumstances logistics are ... sort of worrisome. Thanks for the info. -- You are r

[Bug 246819] Kernel panic with ifconfig destroy

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246819 Andrey V. Elsukov changed: What|Removed |Added CC||a...@freebsd.org --- Comment #

Re: Netmap - Vale switch - tcp problem

Hi Vincenzo, thanks for your hints! I rebooted my guest FBSD 12.1 machine, and I have perfomed your steps #ifconfig vtnet1 -txcsum -rxcsum -tso4 -tso6 up promisc vtnet1: flags=28943 metric 0 mtu 1500 options=6c04b8 ether 0e:bd:ec:7a:08:06 media: Ethernet 10Gbase-T statu

[Bug 234073] ixl: SR-IOV causes "Malicious Driver Detection event" when not all VFs are in passthrough mode

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234073 Ofloo changed: What|Removed |Added CC||nos...@ofloo.net --- Comment #13 from Oflo

blacklistd: spurious whitelisting of IPs

Greetings. [I originally posted this to freebsd-questions, but that may have been the wrong list; I hope this one is right] My blacklistctl dump -a output currently looks a bit like this (IP addresses partially redacted): address/ma:port id nfail last access 130.209.XX.XX/3

[Bug 234073] ixl: SR-IOV causes "Malicious Driver Detection event" when not all VFs are in passthrough mode

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234073 --- Comment #14 from Ofloo --- When I passthrough first and then up the iavf0 interface I get this error iavf0: Unable to send opcode CONFIG_PROMISCUOUS_MODE to PF, ASQ is not alive iavf0: Unable to send opcode ENABLE_QUEUES to PF, ASQ is