Re: TCP Connection hang - MSS again

06.04.2021 19:54, Rodney W. Grimes wrote: >> 05.04.2021 19:44, Rozhuk Ivan wrote: >> > As I understand, in some cases remote host does not reply with MSS > option, and host behind router continue use mss 8960, that dropped > by router. If the peer does not provide an MSS option,

Re: TCP Connection hang - MSS again

05.04.2021 19:44, Rozhuk Ivan wrote: >>> As I understand, in some cases remote host does not reply with MSS >>> option, and host behind router continue use mss 8960, that dropped >>> by router. >> If the peer does not provide an MSS option, your local FreeBSD based >> host should use an MSS of n

Re: TCP Connection hang - MSS again

05.04.2021 16:44, Rozhuk Ivan wrote: > Is any other other options to work around this? Yes. Each entry in the routing table has "mtu" attribute limiting TCP MSS, too. You should use default route with -mtu 1500 attribute. For example, in /etc/rc.conf: defaultroute="X.X.X.X -mtu 1500" _

Re: FCP-101: obsolete driver removal planned for 2019-05-18

12.05.2019 8:21, Warner Losh wrote: > >> I've posted a review to remove obsolete 10 and 10/100 Ethernet drivers > >> as previous approved in FCP-101. > >> The following drivers are slated for > >> removal from FreeBSD-HEAD (to be FreeBSD-13): > >> ae, bm, cs, de, ed, ep, ex, fe

Re: FCP-101: obsolete driver removal planned for 2019-05-18

11.05.2019 22:59, Julian H. Stacey wrote: >> 11.05.2019 21:32, Julian H. Stacey wrote: >> I've posted a review to remove obsolete 10 and 10/100 Ethernet drivers as previous approved in FCP-101. The following drivers are slated for removal from FreeBSD-HEAD (to be FreeBSD-13): >

Re: FCP-101: obsolete driver removal planned for 2019-05-18

11.05.2019 21:32, Julian H. Stacey wrote: >> I've posted a review to remove obsolete 10 and 10/100 Ethernet drivers >> as previous approved in FCP-101. >> The following drivers are slated for >> removal from FreeBSD-HEAD (to be FreeBSD-13): >> >> ae, bm, cs, de, ed, ep, ex, fe, pcn, sf, sn, tl, tx

Re: Painfully slow compilation (read: "make buildworld buildkernel") on not-so-weak system

08.12.2018 18:13, Lev Serebryakov wrote: > I'm completely lost. Is it problem of software? Hardware? If it is > hardware problem what should I blame? Try using different kern.timecounter.hardware and/or kern.eventtimer.timer but first try kern.eventtimer.periodic=1 instead of default 0. If some

D15247: add rcorder(8) support to /etc/rc.resume

Hi! While dealing with https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227866 I've found we have no easy way to insert custom "hooks" after ACPI resume procedure other than devd(8). And running devd itself may be undesirable for several reasons. Manual editing of /etc/rc.resume is not desirable

Re: need help using ng_patch to modify src/dst packets or alternative way

17.12.2017 17:59, Sami Halabi wrote: > Hi Eugene, > I'm looking for a solution for IP traffic. in linux iptables its possible but > I couldn't find freebsd way yet. > bkuncr soulution works for tcp only. Then, you need to realize that for every packet, you need to change (translate) both of sour

Re: How to know the address ranges of kernel stacks, for user processes and kernel threads?

On 29.01.2015 07:54, Yue Chen wrote: > It seems that each kernel stack has two pages (IA-32) to use. Does x86_64 > still have two pages or more? One can change number of kernel stack pages for i386 and amd64 platforms by means of /boot/loader.conf without need to rebuild a kernel using kern.kstac

Re: nanoBSD boot problem (on USB stick or as a HD)

On 15.09.2015 16:31, Stefano Garzarella wrote: > Hi all, > I created a nanoBSD image for my gsoc project (ptnetmap on bhyve). > > I would like to boot this image on USB stick or in the hypervisor as a HD. > I have some problem because if I set NANO_DRIVE="da0" (for USB boot) > in the nanoBSD confi