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

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

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

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

Panic in in6_joingroup_locked

2020-10-21 Thread Ryan Stone
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

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

2020-10-21 Thread bugzilla-noreply
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

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

2020-10-21 Thread bugzilla-noreply
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

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

2020-10-21 Thread Ryan Stone
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); ___

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

2020-10-21 Thread bugzilla-noreply
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

2020-10-21 Thread Dheeraj Kandula
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

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

2020-10-21 Thread bugzilla-noreply
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

Re: Help with VNET

2020-10-21 Thread Kristof Provost
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

Re: Help with VNET

2020-10-21 Thread Patrick M. Hausen
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

Re: Help with VNET

2020-10-21 Thread 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 suspect... Is this documented somewhere? Is this a bug or feature? That’s inherent

Re: Help with VNET

2020-10-21 Thread Andrea Venturoli
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

2020-10-21 Thread Andrea Venturoli
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

2020-10-21 Thread Kristof Provost
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

Re: Help with VNET

2020-10-21 Thread Goran Mekić via freebsd-net
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

Help with VNET

2020-10-21 Thread Andrea Venturoli
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

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

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