[Bug 258849] IPSec may generate duplicate SPIs

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258849 --- Comment #4 from Mateusz Guzik --- So I don't think this is fixable in a clean manner without significant refactoring in the area. I think the pragmatic thing to do here is to try to hoist the sahtree lock out of key_do_getnewspi. The

[Bug 258527] wpa_supplicant(8) from the base is not able to bring up wlan(4) interface correctly due to SIGSEGV after EAP/PEAP MSCHAPv2 authentication

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258527 --- Comment #25 from Marek Zarychta --- Thank you again for fixing the issue in stable/13. -- You are receiving this mail because: You are on the CC list for the bug.

[Bug 258732] [tcp] TCP_MAXSEG does not work

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258732 Tom Jones changed: What|Removed |Added CC||t...@freebsd.org --- Comment #4 from T

[Bug 258732] [tcp] TCP_MAXSEG does not work

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258732 --- Comment #5 from Michael Tuexen --- We discussed this at the transport call. This is not a bug, it is a feature request. However, we are not sure what the use case of this feature would be. So it would be good to answer comment #4. --

[Bug 258732] [tcp] TCP_MAXSEG does not work

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258732 --- Comment #6 from zhhzhh --- My Code: int mss; socklen_t mss_size; mss_size = sizeof(mss); getsockopt(fd, IPPROTO_TCP, TCP_MAXSEG, &mss, &mss_size); //mss <1460 setsockopt(fd2, IPPROTO_TCP, TCP_MAXSEG, &mss, mss_size); //need sam

[Bug 258975] unsupported socket(AF_NETLINK, 3, NETLINK_ROUTE)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258975 Ed Maste changed: What|Removed |Added CC||ema...@freebsd.org Assignee|n

[Bug 258732] [tcp] TCP_MAXSEG does not work

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258732 --- Comment #7 from Michael Tuexen --- (In reply to zhhzhh from comment #6) But why do you need to synchronise two TCP sockets. TCP provides a byte stream service. So why do you bother what the MSS is? It is clear that the MSS option

[Bug 258986] [ixgbe] sysctl stats don't report jumbo frames

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258986 Mark Linimon changed: What|Removed |Added Keywords||IntelNetworking Assignee|

[Bug 258986] [ixgbe] sysctl stats don't report jumbo frames

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258986 Kevin Bowling changed: What|Removed |Added CC||kbowl...@freebsd.org S

[Bug 258986] [ixgbe] sysctl stats don't report jumbo frames

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258986 --- Comment #2 from Kevin Bowling --- Do you have any input based on the above? I think it would be strenuous to rename the sysctl as it stands but maybe we can correct the description? -- You are receiving this mail because: You are the

[Bug 258732] [tcp] TCP_MAXSEG does not work

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258732 --- Comment #8 from zhhzhh --- For high performance ipv6 to ipv4 forwarding, mss is required (TCP_NODELAY ON) and in rfc879 page 2, Section 3, "The MSS can be used completely independently in each direction of data flow. The resu