[Bug 272124] The socket option "SCTP_DELAYED_ACK_TIME" is not available

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272124

--- Comment #1 from Michael Tuexen  ---
The SCTP_DELAYED_ACK_TIME socket option was replaced by the SCTP_DELAYED_SACK
in the socket API specification in draft-ietf-tsvwg-sctpsocket-14. base r170056
changed the code, but missed updating the man page.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 272124] The socket option "SCTP_DELAYED_ACK_TIME" is not available

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272124

--- Comment #2 from commit-h...@freebsd.org ---
A commit in branch main references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=133b132bc1b612abe591c8f54680c3da8491e194

commit 133b132bc1b612abe591c8f54680c3da8491e194
Author: Michael Tuexen 
AuthorDate: 2023-06-21 07:03:30 +
Commit: Michael Tuexen 
CommitDate: 2023-06-21 07:18:05 +

sctp: fix man page for socket option controlling delayed acks

The SCTP_DELAYED_ACK_TIME socket option was replaced by the
SCTP_DELAYED_SACK in the socket API specification in
draft-ietf-tsvwg-sctpsocket-14.
The code was updated in r170056, but the man page was not.

PR: 272124
MFC after:  3 days

 share/man/man4/sctp.4 | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 272094] pfilctl IPFW hook order not works with PF route-to

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272094

--- Comment #3 from Alfa  ---
(In reply to Kristof Provost from comment #1)

"you can use dummynet with pf, and can also do basic layer 2 filtering with pf.
No doubt it's also possible to implement captive portal entirely with ipfw."

I am also using ip_divert with ipfw because PF divert-to not works as expected
#260867 this bug references divert-to infinite loop problem this bug still
exists

"Correct. pf_route() calls ifp->if_output() directly and the packet will not be
seen by another firewall."

Sorry to bother but i am confused about PFILCTL tool, to make it clear What is
this tool's main purpose?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 272094] pfilctl IPFW hook order not works with PF route-to

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272094

--- Comment #4 from Kristof Provost  ---
(In reply to Alfa from comment #3)
> I am also using ip_divert with ipfw because PF divert-to not works as 
> expected #260867 this bug references divert-to infinite loop problem this bug 
> still exists

I don't remember that bug. It's not on my todo list. Perhaps you can get ipfw
to do everything you need.

> Sorry to bother but i am confused about PFILCTL tool, to make it clear What 
> is this tool's main purpose?

https://man.freebsd.org/cgi/man.cgi?query=pfilctl&sektion=8&manpath=FreeBSD+13.1-RELEASE

I don't actually know anything more about it than the man page. If that's not
sufficient I'm afraid all I can recommend is that you look at the code.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 272094] pfilctl IPFW hook order not works with PF route-to

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272094

--- Comment #5 from Gleb Smirnoff  ---
(In reply to Alfa from comment #3)
> Sorry to bother but i am confused about PFILCTL tool, to make it clear What 
> is this tool's main purpose?

To change how firewalls are hooked into the network stack. Sorry for obvious
answer :) A more practical answer:

- Somebody may want to filter only on input, skipping any filtering on output.
- There are some drivers that provide a NIC level hook. This allows to unhook
firewalls from default path and hook them on the NIC only. First, these NIC
level hooks allow to drop packets at a much lower cost. Second, you can build
your firewall based on interfaces, very much like Cisco or Juniper do.
- Although running a stack of firewalls (pf, ipfw, ipfilter) is not something
that is supported or recommended, some people do that and some configurations
(apparently without route-to) work excellent. pfilctl allows to reconfigure the
stack.

P.S. We probably should enable interface level hooks in general, for those
drivers that don't support NIC level hooks. That won't provide a packet drop
performance gain, but will allow to design router-style firewall with any NICs.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 272094] pfilctl IPFW hook order not works with PF route-to

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272094

Franco Fichtner  changed:

   What|Removed |Added

 CC||fra...@opnsense.org

--- Comment #6 from Franco Fichtner  ---
Two things here:

1. Having a netpfil facility accommodating for multiple packet filters at the
same time and saying you shouldn't mix it is not a good argument, because e.g.
the ordering between ipfw/pf is easily made deterministic with something like:

# pfctl -d
# pfctl -e

2. route-to's if_output is derived from OpenBSD where only one packet filter
exists.  There has been a proposal for several years to change that:

https://reviews.freebsd.org/D8877

It's practically been accepted back then, but was never merged. I have updated
code based on stable/13.  I am happy to rebase on main if someone can take this
on...


Cheers,
Franco

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 245981] bnxt(4): BCM57414 / BCM57416 not initializing: bnxt0: Unable to allocate device TX queue / queue memory

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245981

NL  changed:

   What|Removed |Added

 CC||noslin...@gmail.com

--- Comment #35 from NL  ---
I'm facing a similar issue with latest TrueNAS CORE 13.0-U5.1 and the Broadcom
BCM57414. The NIC has the latest firmware (225.1.95.0), but I'm encountering
problems. Interestingly, an older card with firmware (214.4.42) seems to be
working fine. I'm currently testing different firmware versions to find which
one works. 

DMESG---
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.%driver)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.%location)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.%pnpinfo)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.%parent)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.%domain)!
bnxt0:  mem
0x39e1-0x39e1,0x39d0-0x39df,0x39e22000-0x39e23fff
at device 0.0 numa-domain 1 on pci19
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.iflib.driver_version)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.iflib.override_ntxqs)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.iflib.override_nrxqs)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.iflib.override_qs_enable)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.iflib.disable_msix)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.iflib.rx_budget)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.iflib.tx_abdicate)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.iflib.core_offset)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.iflib.separate_txrx)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.iflib.use_logical_cores)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.iflib.override_ntxds)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.iflib.override_nrxds)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.nvram.mfg_id)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.nvram.device_id)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.nvram.sector_size)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.nvram.size)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.nvram.reserved_size)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.nvram.available_size)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.rss_key)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.rss_type)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.rx_stall)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.vlan_strip)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.if_name)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.intr_coal_rx_usecs)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.intr_coal_rx_frames)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.intr_coal_rx_usecs_irq)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.intr_coal_rx_frames_irq)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.intr_coal_tx_usecs)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.intr_coal_tx_frames)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.intr_coal_tx_usecs_irq)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.intr_coal_tx_frames_irq)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.hw_lro.enable)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.hw_lro.gro_mode)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.hw_lro.max_agg_segs)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.hw_lro.max_aggs)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.hw_lro.min_agg_len)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.fc.tx)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.fc.rx)!
sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.fc.autoneg)!
bnxt0: Using 256 TX descriptors and 256 RX descriptors
bnxt0: Using 16 RX queues 16 TX queues
bnxt0: Using MSI-X interrupts with 17 vectors
bnxt0: Ethernet address: 5c:6f:69:XXX
bnxt0: Unknown phy type
bnxt1:  mem
0x39e0-0x39e0,0x39c0-0x39cf,0x39e2-0x39e21fff
at device 0.1 numa-domain 1 on pci19
bnxt1: Using 256 TX descriptors and 256 RX descriptors
bnxt1: Using 16 RX queues 16 TX queues
bnxt1: Using MSI-X interrupts with 17 vectors
bnxt1: Ethernet address: 5c:6f:69:XXX
bnxt1: Unknown phy type
bnxt2:  mem
0x3a3fffe1-0x3a3fffe1,0x3a3fffd0-0x3a3fffdf,0x3a3fffe22000-0x3a3fffe23fff
at device 0.0 numa-domain 1 on pci21
bnxt2: Using 256 TX descriptors and 256 RX descriptors
bnxt2: Using 16 RX queues 16 TX queues
bnxt2: Using MSI-X interrupts with 17 vectors
bnxt2: Ethernet address: 5c:6f:69:X
bnxt2: Unknown phy type
bnxt3:  mem
0x3a3fffe0-0x3a3fffe0,0x3a3fffc0-0x3a3fffcf,0x3a3fffe2-0x3a3fffe21fff
at device 0.1 numa-domain 1 on pci21
bnxt3: Using 256 TX descriptors and 256 RX descriptors
bnxt3: Using 

-current dropping ssh connections

[bob prohaska]

I've got a Pi4 running -current that seems to selectively drop ssh connections.

Connections running a shell seem to stay up, but a session running tip to a
usb-serial adapter (FTDI TTL232R-3V3) seems go away within a few hours. 
There don't seem to be any error messages on the console at all, the client 
session simply reports 
client_loop: send disconnect: Broken pipe

Searches through /var/log/sshd_debug.log find many transactions between
the ssh client and the -current target host, but none seem to be error
messages; all are either connection reports or disconnects by user.

This sort of behavior has been intermittent with aarch64 among both
the Pi4 and a pair of Pi3s for some time, but now only the Pi4 is
dropping connections. 

I've tried searching /var/log/sshd_debug.log for the keywords tip,
ucom, the IP address of the NAT client used to connect and cuaU0.
Are there other things worth looking for?

Right now I'm using in /etc/rc.conf the line
sshd_flags="-E /var/log/sshd_debug.log"
which is already quite verbose. Is there a better
option that emphasizes errors over normal traffic?

Thanks for reading,

bob prohaska

Re: -current dropping ssh connections

[Mark Millard]

On Jun 21, 2023, at 10:24, bob prohaska  wrote:

> I've got a Pi4 running -current that seems to selectively drop ssh 
> connections.

Only when the ssh has text streaming over it? Even when it
is idle? Any other types of context differences that lead
to observable differences of some type related to the
disconnects (vs. lack of them)?

> Connections running a shell seem to stay up, but a session running tip to a
> usb-serial adapter (FTDI TTL232R-3V3) seems go away within a few hours. 

The way that reads, ssh to a shell and then running tip in
that shell would stay up. (Does it?) tip is being run
without ssh running a shell? May be more detail about the
two contexts of establishing the connection is needed here?

> There don't seem to be any error messages on the console at all, the client 
> session simply reports 
> client_loop: send disconnect: Broken pipe
> 
> Searches through /var/log/sshd_debug.log find many transactions between
> the ssh client and the -current target host, but none seem to be error
> messages; all are either connection reports or disconnects by user.
> 
> This sort of behavior has been intermittent with aarch64 among both
> the Pi4 and a pair of Pi3s for some time, but now only the Pi4 is
> dropping connections. 
> 
> I've tried searching /var/log/sshd_debug.log for the keywords tip,
> ucom, the IP address of the NAT client used to connect and cuaU0.
> Are there other things worth looking for?
> 
> Right now I'm using in /etc/rc.conf the line
> sshd_flags="-E /var/log/sshd_debug.log"
> which is already quite verbose. Is there a better
> option that emphasizes errors over normal traffic?

I'm not likely to identify such, unfortunately.

===
Mark Millard
marklmi at yahoo.com

Re: -current dropping ssh connections

[bob prohaska]

On Wed, Jun 21, 2023 at 10:45:25AM -0700, Mark Millard wrote:
> On Jun 21, 2023, at 10:24, bob prohaska  wrote:
> 
> > I've got a Pi4 running -current that seems to selectively drop ssh 
> > connections.
> 
> Only when the ssh has text streaming over it? Even when it
> is idle? Any other types of context differences that lead
> to observable differences of some type related to the
> disconnects (vs. lack of them)?

I can't detect any consistent pattern. For a while I thought load on the
sshd-host end made a difference, but the latest disconnect was on an idle
system with serial console output the only traffic on the dropped connection. 
 
> > Connections running a shell seem to stay up, but a session running tip to a
> > usb-serial adapter (FTDI TTL232R-3V3) seems go away within a few hours. 
> 
> The way that reads, ssh to a shell and then running tip in
> that shell would stay up. (Does it?) tip is being run
> without ssh running a shell? May be more detail about the
> two contexts of establishing the connection is needed here?
> 

No, other way 'round. In both cases an ssh connection was made which
started a shell. In one a tip session was started, which seems prone 
to dropping. In the other an active shell (typically running buildworld, 
or maybe idle) kept running. This makes me think (perhaps wrongly) that 
tip is involved with the disconnection. Both shells are started as a
regular user and then su-d to root.

I'm fairly confident this isn't a client-side or NAT problem, simply because
there are a dozen or so other ssh sessions running from the ssh client to the
various Pi2/3/4 hosts in my collection which stay up basically until they're
taken down deliberately.

I seem to (vaguely) recall a discussion of ssh problems over NAT some months 
ago, something about tolerating misssing ts (timestamps?). Is that still 
possible?

Thanks for writing!

bob prohaska

[Bug 272089] FreeBSD -CURRENT panic: panic invalid slot (wg(4) related)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272089

Mark Linimon  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|n...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 272090] [igb][i350] hwvlanfilter issue

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272090

Mark Linimon  changed:

   What|Removed |Added

   Keywords||IntelNetworking
   Assignee|b...@freebsd.org|n...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 272117] bnxt: kernel crash with sysctl and jumbo frames

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272117

Mark Linimon  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|n...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 272089] FreeBSD -CURRENT panic: panic invalid slot (wg(4) related)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272089

Kyle Evans  changed:

   What|Removed |Added

 CC||ema...@freebsd.org,
   ||j...@freebsd.org,
   ||kev...@freebsd.org,
   ||n...@freebsd.org
   Assignee|n...@freebsd.org |kev...@freebsd.org

--- Comment #1 from Kyle Evans  ---
>From the backtrace, it looks like MOD_LOAD is failing and so we MOD_UNLOAD it,
but it's only partially initialized and we aren't expecting that. I suspect we
should just drop all of the free stuff in wg_module_init() and let MOD_UNLOAD
deal with it, though in wg_module_deinit() we also need to avoid calling
osd_jail_deregister() if wg_osd_jail_slot == 0 (i.e. we didn't reach that far
in initialization).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.

[Bug 272089] FreeBSD -CURRENT panic: panic invalid slot (wg(4) related)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272089

--- Comment #2 from Kyle Evans  ---
the free_crypto label in there is actually wrong anyways, if cookie_init()
failed we don't set `ret` to a failure so MOD_LOAD will succeed even though
things are partially borked.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 272119] bnxt: instapanic with debug kernel

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272119

Mark Linimon  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|n...@freebsd.org
   Keywords||crash

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 271991] Crash on some network packets with fresh stable

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271991

Mark Linimon  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|n...@freebsd.org
   Keywords||crash

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 272089] FreeBSD -CURRENT panic: panic invalid slot (wg(4) related)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272089

Kyle Evans  changed:

   What|Removed |Added

URL||https://reviews.freebsd.org
   ||/D40708

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: -current dropping ssh connections

[Cheng Cui]

>
> There don't seem to be any error messages on the console at all, the
> client
> session simply reports
> client_loop: send disconnect: Broken pipe
>

Have you tried SSH keepalive?
https://stackoverflow.com/questions/25084288/keep-ssh-session-alive

Best Regards,
Cheng Cui


On Wed, Jun 21, 2023 at 1:24 PM bob prohaska  wrote:

> I've got a Pi4 running -current that seems to selectively drop ssh
> connections.
>
> Connections running a shell seem to stay up, but a session running tip to a
> usb-serial adapter (FTDI TTL232R-3V3) seems go away within a few hours.
> There don't seem to be any error messages on the console at all, the
> client
> session simply reports
> client_loop: send disconnect: Broken pipe
>
> Searches through /var/log/sshd_debug.log find many transactions between
> the ssh client and the -current target host, but none seem to be error
> messages; all are either connection reports or disconnects by user.
>
> This sort of behavior has been intermittent with aarch64 among both
> the Pi4 and a pair of Pi3s for some time, but now only the Pi4 is
> dropping connections.
>
> I've tried searching /var/log/sshd_debug.log for the keywords tip,
> ucom, the IP address of the NAT client used to connect and cuaU0.
> Are there other things worth looking for?
>
> Right now I'm using in /etc/rc.conf the line
> sshd_flags="-E /var/log/sshd_debug.log"
> which is already quite verbose. Is there a better
> option that emphasizes errors over normal traffic?
>
> Thanks for reading,
>
> bob prohaska
>
>
>
>

Re: -current dropping ssh connections

[Marcin Cieslak]

On Wed, 21 Jun 2023, bob prohaska wrote:


I've got a Pi4 running -current that seems to selectively drop ssh connections.

There don't seem to be any error messages on the console at all, the client


I don't know what is the current way to do this, but maybe you could try to 
sniff tty and see what happens there.  If your console is UEFI console,
there is some fancy interaction with the UEFI systems, I hope it does not 
interfere (it stops booting for me, already discussed on -arm).


I've tried searching /var/log/sshd_debug.log for the keywords tip,
ucom, the IP address of the NAT client used to connect and cuaU0.
Are there other things worth looking for?


ipfw sometimes breaks scp for me, I had to disable it for that reason

Marcin

smime.p7s
Description: S/MIME Cryptographic Signature

Re: -current dropping ssh connections

[Michael Gmelin]

> On 21. Jun 2023, at 20:03, bob prohaska  wrote:
> 
> On Wed, Jun 21, 2023 at 10:45:25AM -0700, Mark Millard wrote:
>>> On Jun 21, 2023, at 10:24, bob prohaska  wrote:
>>> 
>>> I've got a Pi4 running -current that seems to selectively drop ssh 
>>> connections.
>> 
>> Only when the ssh has text streaming over it? Even when it
>> is idle? Any other types of context differences that lead
>> to observable differences of some type related to the
>> disconnects (vs. lack of them)?
> 
> I can't detect any consistent pattern. For a while I thought load on the
> sshd-host end made a difference, but the latest disconnect was on an idle
> system with serial console output the only traffic on the dropped connection. 
> 
>>> Connections running a shell seem to stay up, but a session running tip to a
>>> usb-serial adapter (FTDI TTL232R-3V3) seems go away within a few hours. 
>> 
>> The way that reads, ssh to a shell and then running tip in
>> that shell would stay up. (Does it?) tip is being run
>> without ssh running a shell? May be more detail about the
>> two contexts of establishing the connection is needed here?
>> 
> 
> No, other way 'round. In both cases an ssh connection was made which
> started a shell. In one a tip session was started, which seems prone 
> to dropping. In the other an active shell (typically running buildworld, 
> or maybe idle) kept running. This makes me think (perhaps wrongly) that 
> tip is involved with the disconnection. Both shells are started as a
> regular user and then su-d to root.
> 
> I'm fairly confident this isn't a client-side or NAT problem, simply because
> there are a dozen or so other ssh sessions running from the ssh client to the
> various Pi2/3/4 hosts in my collection which stay up basically until they're
> taken down deliberately.
> 
> I seem to (vaguely) recall a discussion of ssh problems over NAT some months 
> ago, something about tolerating misssing ts (timestamps?). Is that still 
> possible?

You can check if systctl net.inet.tcp.tolerate_missing_ts=1.

It should be set to 1 by default since 13.1, but maybe it’s different in 
current.

Best

Re: -current dropping ssh connections

[Jamie Landeg-Jones]

bob prohaska  wrote:

> I can't detect any consistent pattern. For a while I thought load on the
> sshd-host end made a difference, but the latest disconnect was on an idle
> system with serial console output the only traffic on the dropped connection. 

Could it be that the serial connection is sending the ssh-escape sequence?

Try adding "-e none" to the initial ssh connection command.

Cheers, Jamie

[Bug 272117] bnxt: kernel crash with sysctl and jumbo frames

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272117

Graham Perrin  changed:

   What|Removed |Added

 CC||bsd...@freebsd.org,
   ||grahamper...@freebsd.org
  Flags||maintainer-feedback?(bsdimp
   ||@FreeBSD.org)

--- Comment #3 from Graham Perrin  ---
I see bnxt(4)-related work by Sumit Saxena
, and
Bugzilla suggests a FreeBSD email address for this author, however: 

a) at least for recent commits, the author's address is @broadcom.com; and 

b)  does not list the name.

@bsdimp please, should Sumit be informed of this bug 272117 and nearby bug
272119?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 272117] bnxt: kernel crash with sysctl and jumbo frames

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272117

Warner Losh  changed:

   What|Removed |Added

 CC||i...@freebsd.org

--- Comment #4 from Warner Losh  ---
Sumit should be added.

This also points out we're not updating contributors very well... but that's a
separate issue...

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 272124] The socket option "SCTP_DELAYED_ACK_TIME" is not available

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272124

Graham Perrin  changed:

   What|Removed |Added

   Keywords|needs-patch |
  Flags|maintainer-feedback?(net@Fr |
   |eeBSD.org)  |

-- 
You are receiving this mail because:
You are on the CC list for the bug.