[Bug 250366] [tcp] The ioctl of socket fd should return -1 after listen to avoid misusing.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250366 Michael Tuexen changed: What|Removed |Added Flags||mfc-stable12? -- You are receivi

[Bug 250366] [tcp] The ioctl of socket fd should return -1 after listen to avoid misusing.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250366 Michael Tuexen changed: What|Removed |Added Status|New |In Progress --- Comment #2 from M

Panic in in6_joingroup_locked

Today at $WORK we saw a panic due to a race between in6_joingroup_locked and if_detach_internal. This happened on a branch that's about 2 years behind head, but the relevant code in head does not appear to have changed. The backtrace of the panic was this: panic: Fatal trap 9: general protection

[Bug 248652] iflib: netmap pkt-gen large TX performance difference between 11-STABLE and 12-STABLE/CURRENT on ix & ixl NIC

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652 --- Comment #32 from Vincenzo Maffione --- (In reply to Sylvain Galliano from comment #29) Thanks again for your tests. I'm inclined to think that the pkt-gen hang issue that you see is not directly caused by the ixl patch. Would you pleas

[Bug 248652] iflib: netmap pkt-gen large TX performance difference between 11-STABLE and 12-STABLE/CURRENT on ix & ixl NIC

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652 --- Comment #31 from Vincenzo Maffione --- (In reply to Krzysztof Galazka from comment #30) Hi Krzysztof, I agree, and created a separate review for this possible change: https://reviews.freebsd.org/D26896 It would be nice if you guys cou

Re: safe_pause_us() is always at least 1 millisecond long

Using min is definitely not correct. That would ensure that you either got a pause of 1 tick or 0 ticks. This may get you better granularity, depending on the system. pause_sbt("e1000_delay", x * SBT_1US, x < 1000 ? 100 * SBT_1US : SBT_1MS, 0); ___ fre

[Bug 250499] [tcp] Should we reject the packet with timestamp if no timestamp in SYN and SYN_ACK?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250499 Michael Tuexen changed: What|Removed |Added Assignee|n...@freebsd.org |tue...@freebsd.org

Re: ims_merge in in_mcast.c

The ims_merge function is invoked only when the imsl_st[0] and imsl_st[1] are different i.e. a filter mode change. The new filter mode is updated in ims_st[1]. Thanks for the clarification. Thanks Dheeraj On Tue, Oct 13, 2020 at 9:58 AM Dheeraj Kandula wrote: > Thanks, HPS for the response. I t

[Bug 250499] [tcp] Should we reject the packet with timestamp if no timestamp in SYN and SYN_ACK?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250499 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|n...@freebsd.org -- You are receiv

Re: Help with VNET

On 21 Oct 2020, at 13:50, Patrick M. Hausen wrote: Hi all, Am 21.10.2020 um 13:37 schrieb Kristof Provost : On 21 Oct 2020, at 13:36, Andrea Venturoli wrote: On 10/21/20 12:20 PM, Kristof Provost wrote: This is your problem. You can’t bridge over wifi interfaces. That’s a limitation of stat

Re: Help with VNET

Hi all, > Am 21.10.2020 um 13:37 schrieb Kristof Provost : > > On 21 Oct 2020, at 13:36, Andrea Venturoli wrote: >> On 10/21/20 12:20 PM, Kristof Provost wrote: >> >>> This is your problem. You can’t bridge over wifi interfaces. >>> That’s a limitation of station mode wifi. >> >> I had the susp

Re: Help with VNET

On 21 Oct 2020, at 13:36, Andrea Venturoli wrote: On 10/21/20 12:20 PM, Kristof Provost wrote: This is your problem. You can’t bridge over wifi interfaces. That’s a limitation of station mode wifi. I had the suspect... Is this documented somewhere? Is this a bug or feature? That’s inherent t

Re: Help with VNET

On 10/21/20 12:20 PM, Kristof Provost wrote: This is your problem. You can’t bridge over wifi interfaces. > That’s a limitation of station mode wifi. I had the suspect... Is this documented somewhere? Is this a bug or feature? Try routing, or try with a wired interface. I'll try and get

Re: Help with VNET

On 10/21/20 12:19 PM, Goran Mekić wrote: Did you setup NAT? No. Should I? Why? The IP I gave to the jail is in the same subnet as the host. BTW, I have similar (working) setups with bhyve (using tap instead of epair) and I didn't setup NAT there. bye & Thanks av. __

Re: Help with VNET

On 21 Oct 2020, at 12:13, Andrea Venturoli wrote: Hello. I've been using jails for years with ezjail. Now I'm trying to experiment with VNET. I've looked for a tutorial, but found scarce (and possibly outdated) info. Box is a 12.1/amd64. Basic configuration involves wlan0 configured via DH

Re: Help with VNET

On October 21, 2020 10:13:38 AM UTC, Andrea Venturoli wrote: >Hello. > >I've been using jails for years with ezjail. Now I'm trying to >experiment with VNET. >I've looked for a tutorial, but found scarce (and possibly outdated) >info. > > > >Box is a 12.1/amd64. >Basic configuration involves wlan

Help with VNET

Hello. I've been using jails for years with ezjail. Now I'm trying to experiment with VNET. I've looked for a tutorial, but found scarce (and possibly outdated) info. Box is a 12.1/amd64. Basic configuration involves wlan0 configured via DHCP (192.168.133.26). Host networking works. For a st

[Bug 248652] iflib: netmap pkt-gen large TX performance difference between 11-STABLE and 12-STABLE/CURRENT on ix & ixl NIC

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652 Krzysztof Galazka changed: What|Removed |Added CC||krzysztof.gala...@intel.com --