> On 10. Apr 2024, at 13:40, Nuno Teixeira wrote:
>
> Hello all,
>
> @ current 1500018 and fetching torrents with net-p2p/qbittorrent finished
> ~2GB download and connection UP until the end:
>
> ---
> Apr 10 11:26:46 leg kernel: re0: watchdog timeout
> Apr 10 11:26:46 leg kernel: re0:
> On 3. Apr 2024, at 19:46, Sad Clouds wrote:
>
> On Wed, 3 Apr 2024 17:28:52 +0200
> Michael Tuexen wrote:
>
>>> On 3. Apr 2024, at 15:44, Sad Clouds wrote:
>>>
>>> I found a bug that is still open from May 2010 and describes the same
&g
> On 3. Apr 2024, at 15:44, Sad Clouds wrote:
>
> I found a bug that is still open from May 2010 and describes the same
> behaviour that I see with my application:
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=146845
>
> If this hasn't been fixed over the last 14 years, then I guess I
> On 28. Mar 2024, at 15:00, Nuno Teixeira wrote:
>
> Hello all!
>
> Running rack @b7b78c1c169 "Optimize HPTS..." very happy on my laptop (amd64)!
>
> Thanks all!
Thanks for the feedback!
Best regards
Michael
>
> Drew Gallatin escreveu (quinta, 21/03/2024 à(s) 12:58):
> The entire point is
> On 18. Mar 2024, at 12:42, Nuno Teixeira wrote:
>
> Hello all!
>
> It works just fine!
> System performance is OK.
> Using patch on main-n268841-b0aaf8beb126(-dirty).
>
> ---
> net.inet.tcp.functions_available:
> Stack D AliasPCB count
>
> On 17. Mar 2024, at 16:39, Drew Gallatin wrote:
>
> I don't have the full context, but it seems like the complaint is a
> performance regression in bonnie++ and perhaps other things when tcp_hpts is
> loaded, even when it is not used. Is that correct?
Correct.
>
> If so, I suspect its
> On 16. Mar 2024, at 21:29, Nuno Teixeira wrote:
>
>> Just to double check: you only load the tcp_rack. You don't run
>> sysctl net.inet.tcp.functions_default=rack
>
> I'm not using sysctl, just loading module.
And you also don't have
net.inet.tcp.functions_default=rack
in /etc/sysctl.conf
> On 16. Mar 2024, at 20:06, Nuno Teixeira wrote:
>
>>> Will update amd64 laptop to main-n268827-75464941dc17 (Mar 16) and test it.
>> Please do so...
>
> @main-n268827-75464941dc17 GENERIC-NODEBUG amd64
>
> Ok, I think I have here some numbers related to disk performance being
> affected by
> On 16. Mar 2024, at 15:00, Nuno Teixeira wrote:
>
>> If you load tcp_rack via kldload, tcphtps get loaded automatically.
>> If you load if via /boot/loader.conf, you need to have
>> tcphpts_load="YES"
>> in addition to
>> tcp_rack_load="YES"
>
> As of my tests, loader.conf:
;> /usr/src/sys/netinet/tcp_hpts.c it adds a high precision timer
>> system for tcp, used by RACK and BBR.
>
> As tuexen said, on main, loader.conf: tcp_rack_load="YES" will load
> tcphpts.ko as I am seing in my rpi4 right now.
If you load tcp_rack via kldload, tcp
> On 16. Mar 2024, at 11:11, Nuno Teixeira wrote:
>
> (...)
>
>> These entries are missing in GENERIC:
>>
>> makeoptions WITH_EXTRA_TCP_STACKS=1
>
> From
> https://cgit.freebsd.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc
> WITH_EXTRA_TCP_STACKS was dropped.
>
>> options
> On 16. Mar 2024, at 08:57, Nuno Teixeira wrote:
>
> Hello all,
>
> On a laptop i7/16MB ram, desktop use and port testing (poudriere) I've
> noticed that all operations on OS was increased by 3 to 5 times
> longer.
> examples:
> - firefox took way long time to open
> - poudriere testport
> On 14. Mar 2024, at 11:04, Dag-Erling Smørgrav wrote:
>
> tue...@freebsd.org writes:
>> Gary Jennejohn writes:
>>> In the article we have option TCPHPTS and option TCP_RACK. But in
>>> /sys/conf/NOTES we have options TCPHPTS and options TCP_RACK and
>>> not option.
>> Thanks for reporting,
> On 13. Mar 2024, at 08:06, Gary Jennejohn wrote:
>
> On Tue, 12 Mar 2024 20:14:17 +0100
> tue...@freebsd.org wrote:
>
>>> On 12. Mar 2024, at 14:39, Nuno Teixeira wrote:
>>>
>>> Hello,
>>>
>>> I'm curious about tcp RACK.
>>>
>>> As I do not run on a server background, only a laptop and a
> On 12. Mar 2024, at 14:39, Nuno Teixeira wrote:
>
> Hello,
>
> I'm curious about tcp RACK.
>
> As I do not run on a server background, only a laptop and a rpi4 for
> poudriere, git, browsing, some torrent and ssh/sftp connections, will
> I see any difference using RACK?
> What tests should I
> On Feb 25, 2024, at 01:18, Hannes Hauswedell wrote:
>
> Hi everyone,
>
> I am coming here from
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=2771971160
I guess this should read:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277197
Best regards
Michael
>
> TL;DR:
>
> * I have a
> On Jan 5, 2024, at 08:48, tue...@freebsd.org wrote:
>
>> On Jan 4, 2024, at 21:39, Herbert J. Skuhra wrote:
>>
>> On Thu, 04 Jan 2024 21:22:22 +0100, tue...@freebsd.org wrote:
>>>
On Jan 4, 2024, at 18:52, Herbert J. Skuhra wrote:
On Thu, 04 Jan 2024 11:40:35 +0100, "Herbert
> On Jan 4, 2024, at 21:39, Herbert J. Skuhra wrote:
>
> On Thu, 04 Jan 2024 21:22:22 +0100, tue...@freebsd.org wrote:
>>
>>> On Jan 4, 2024, at 18:52, Herbert J. Skuhra wrote:
>>>
>>> On Thu, 04 Jan 2024 11:40:35 +0100, "Herbert J. Skuhra" wrote:
On Fri, 17 Nov 2023 14:31:02
> On Jan 4, 2024, at 18:52, Herbert J. Skuhra wrote:
>
> On Thu, 04 Jan 2024 11:40:35 +0100, "Herbert J. Skuhra" wrote:
>>
>> On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
>>>
>>> Hi,
>>>
>>> On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
> On Nov
> On Jan 4, 2024, at 15:22, Herbert J. Skuhra wrote:
>
> On Thu, 04 Jan 2024 14:57:59 +0100, tue...@fh-muenster.de wrote:
>>
>>> On Jan 4, 2024, at 11:40, Herbert J. Skuhra wrote:
>>>
>>> On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
Hi,
On Fri, 17 Nov
> On Jan 4, 2024, at 11:40, Herbert J. Skuhra wrote:
>
> On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
>>
>> Hi,
>>
>> On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
>>>
On Nov 16, 2023, at 20:06, Herbert J. Skuhra wrote:
On Thu, 16 Nov 2023
> On Dec 20, 2023, at 12:15, Scheffenegger, Richard wrote:
>
> Hi,
>
> I am curious if anyone here has expirience with the handling of ECN in
> TSO-enabled drivers/hardware...
Some data pointer if I read the specification correctly.
Have a look at the specification of the 10GBit/sec card ix:
> On Nov 16, 2023, at 20:06, Herbert J. Skuhra wrote:
>
> On Thu, 16 Nov 2023 19:07:29 +0100, Olivier Cochard-Labbé wrote:
>>
>> On Thu, Nov 16, 2023 at 5:10 PM Herbert J. Skuhra wrote:
>>
>>>
>>> OK, I am now running GENERIC-NODEBUG + "options TCPHPTS".
>>>
>>> After setting "sysctl
ad_file: /boot/kernel/tcp_rack.ko - unsupported file type
>>
>> So you have to build a kernel with "options TCPHPTS" first?
>
> OK, I am now running GENERIC-NODEBUG + "options TCPHPTS".
>
> After setting "sysctl net.inet.tcp.functions_default=r
> On Nov 16, 2023, at 13:06, Herbert J. Skuhra wrote:
>
> Hi,
>
> On Thu, 16 Nov 2023 10:13:05 +0100, tue...@freebsd.org wrote:
>>
>> Dear all,
>>
>> recently the main branch was changed to build the TCP RACK stack
>> which is a loadable kernel module, by default:
>>
Dear all,
recently the main branch was changed to build the TCP RACK stack
which is a loadable kernel module, by default:
https://cgit.FreeBSD.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc
As discussed on the bi-weekly transport call, it would be great if people
could test the RACK
> On 3. Aug 2023, at 19:18, Bakul Shah wrote:
>
> Not quite what you asked for but I recently found
> https://github.com/gcla/termshark -- it seems to be like wireshark but for a
> terminal window. Like tcpdump it has the -D option that will return a list of
> interfaces. If you are handy
> On 3. Aug 2023, at 14:59, Perttu Laine wrote:
>
> On Tue, Aug 1, 2023 at 11:38 PM Zane C B-H wrote:
>>
>> So what is a good way to get all packets passing through that the kernel
>> currently sees? Apparently any is not support on non-Linux systems and
>> pflog would require adding log to
> On 20. Mar 2023, at 07:24, Zhenlei Huang wrote:
>
>
>
>> On Mar 20, 2023, at 1:35 AM, tue...@freebsd.org wrote:
>>
>>> On 19. Mar 2023, at 16:59, Marek Zarychta
>>> wrote:
>>>
>>> W dniu 19.03.2023 o 14:42, tue...@freebsd.org pisze:
> On 19. Mar 2023, at 14:12, Marek Zarychta
>
> On 19. Mar 2023, at 16:59, Marek Zarychta
> wrote:
>
> W dniu 19.03.2023 o 14:42, tue...@freebsd.org pisze:
>>> On 19. Mar 2023, at 14:12, Marek Zarychta
>>> wrote:
>>>
>>> Dear subscribers of the list,
>>>
>>> TCP algo modules can be loaded/unloaded/changed on the fly. In FreeBSD
>>>
> On 19. Mar 2023, at 14:12, Marek Zarychta
> wrote:
>
> Dear subscribers of the list,
>
> TCP algo modules can be loaded/unloaded/changed on the fly. In FreeBSD
> 14-CURRENT one can even change it on an active socket with tcpsso(8) utility,
> but there is no way to run jail with different
111 divert all from any to any layer2 mac-type arp
>>> and write a program to dump what you get on the divert socket.
>>> I suspect you get an ethernet frame.
>>>
>>> And finally divert(4) says: NAME: divert kernel packet diversion mechanism
>>> That s
chanism
> That says packet, so again, IMHO, it should be arbitrary to what layer.
> It also later says "Divert sockets are similar to raw IP sockets",
> I think similar is the key aspect here, they are not identical.
I can confirm that using
sudo sysctl net.link.ether.ipfw=1
sudo
> On 2. Mar 2023, at 02:24, Rodney W. Grimes
> wrote:
>
>> Hi group,
>>
>> Maybe someone can help me with this question - as I am usually only
>> looking at L4 and the top side of L3 ;)
>>
>> In order to validate a peculiar switches behavior, I want to adjust some
>> fields in gracious arps
> On 1. Mar 2023, at 22:10, Scheffenegger, Richard
> wrote:
>
>>> On 1. Mar 2023, at 21:33, Scheffenegger, Richard
>>> wrote:
>>>
>>> Hi group,
>>>
>>> Maybe someone can help me with this question - as I am usually only looking
>>> at L4 and the top side of L3 ;)
>>
>>> In order to
> On 1. Mar 2023, at 21:33, Scheffenegger, Richard wrote:
>
> Hi group,
>
> Maybe someone can help me with this question - as I am usually only looking
> at L4 and the top side of L3 ;)
>
> In order to validate a peculiar switches behavior, I want to adjust some
> fields in gracious arps
> On 16. Nov 2022, at 16:15, Zhenlei Huang wrote:
>
>
>> On Nov 16, 2022, at 11:19 AM, Zhenlei Huang wrote:
>>
>>>
>>> On Nov 16, 2022, at 5:14 AM, tue...@freebsd.org wrote:
>>>
>>> Dear all,
>>>
>>> when us
> On 16. Nov 2022, at 08:54, Andrey V. Elsukov wrote:
>
> 16.11.2022 00:14, tue...@freebsd.org пишет:
>> when using the master branch of today (or 13.1) I get when running
>> tuexen@ampere128:~ % ping6 -c 1 -b 3 -s 2 ::1
>> PING6(20048=40+8+2 bytes) ::1
Dear all,
when using the master branch of today (or 13.1) I get when running
tuexen@ampere128:~ % ping6 -c 1 -b 3 -s 2 ::1
PING6(20048=40+8+2 bytes) ::1 --> ::1
20008 bytes from ::1, icmp_seq=0 hlim=64 time=0.709 ms
--- ::1 ping6 statistics ---
1 packets transmitted, 1 pack
> On 10. Nov 2022, at 08:07, Zhenlei Huang wrote:
>
>> On Nov 9, 2022, at 11:18 AM, Zhenlei Huang wrote:
>>
>>
>>> On Oct 22, 2022, at 6:14 PM, Hans Petter Selasky wrote:
>>>
>>> Hi,
>>>
>>> Some thoughts about this topic.
>>
>> Sorry for late response.
>>
>>>
>>> Delaying ACKs means
> On 27. Oct 2022, at 10:08, Scheffenegger, Richard
> wrote:
>
> It focuses on QUIC, but congestion control dynamics don't change
> with the protocol. You should be able to read there, but if not I'm
> happy to send anyone a pdf.
Is QUIC using an L=2 for ABC?
>>>
>>> I think
> On 26. Oct 2022, at 14:59, Tom Jones wrote:
>
> On Wed, Oct 26, 2022 at 02:55:21PM +0200, tue...@freebsd.org wrote:
>>> On 26. Oct 2022, at 10:57, Tom Jones wrote:
>>>
>>> On Sat, Oct 22, 2022 at 12:14:25PM +0200, Hans Petter Selasky wrote:
Hi,
Some thoughts about this topic.
> On 26. Oct 2022, at 10:57, Tom Jones wrote:
>
> On Sat, Oct 22, 2022 at 12:14:25PM +0200, Hans Petter Selasky wrote:
>> Hi,
>>
>> Some thoughts about this topic.
>>
>> Delaying ACKs means loss of performance when using Gigabit TCP
>> connections in data centers. There it is important to ACK
> On 21. Oct 2022, at 17:00, Zhenlei Huang wrote:
>
>
>> On Oct 21, 2022, at 10:34 PM, Michael Tuexen
>> wrote:
>>
>>> On 21. Oct 2022, at 16:19, Zhenlei Huang wrote:
>>>
>>> Hi,
>>>
>>> While I was repeating
> On 21. Oct 2022, at 16:19, Zhenlei Huang wrote:
>
> Hi,
>
> While I was repeating
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258755, I observed a
> strange behavior. The TCP ACKs from FreeBSD host are too aggressive.
>
> My setup is simple:
> A
> On 12. Jun 2022, at 18:40, Chris Ross wrote:
>
>
> Tl;dr;
> I don’t know why I’m getting an EINVAL from a call to bind for a second socket
>
>
>
>
> 20 years ago, I spent a lot of time adding IPv6 support to IPv4-only programs.
> So I thought this (adding IPv6 support to simpleproxy[1])
> On 22. Apr 2022, at 17:55, Gordon Bergling wrote:
>
> Hi,
>
> I recently build some personal infrastructure and experimented a little
> bit with tcp_bbr(4) and tcp_rack. Doing is this in a cloud environment
> is a little bit priced since the kernel must be rebuild with the build
> options
> On 2. Mar 2022, at 18:04, J.R. Oldroyd wrote:
>
> On Wed, 2 Mar 2022 17:21:22 +0100 Lutz Donnerhacke
> wrote:
>>
>> On Wed, Mar 02, 2022 at 04:40:38PM +0100, tue...@freebsd.org wrote:
>>> Is that what is expected? When using the above command I would expect
>>> that 100MBit/sec is used, not
> On 2. Mar 2022, at 16:33, J.R. Oldroyd wrote:
>
> An em(4) interface configured with fixed media/mediatype settings, as in:
> ifconfig em0 media 100baseTX mediatype full-duplex
> does not respond to autonegotiation from the switch it is connected to.
> (Actually, it does for 1000base but
> On 12. Nov 2021, at 16:29, Kurt Jaeger wrote:
>
> Hi!
>
> The basic ipfw firewall is active, but
Does it work, if you disable ipfw?
>
>>> No, unfortunatly not.
>
>> OK. Can you provide the output of
>> netstat -sptcp
>> after some packets were dropped.
>
>
> On 12. Nov 2021, at 16:06, Kurt Jaeger wrote:
>
> Hi!
>
>>> The basic ipfw firewall is active, but
>> Does it work, if you disable ipfw?
>
> No, unfortunatly not.
OK. Can you provide the output of
netstat -sptcp
after some packets were dropped.
Best regards
Michael
>
> --
>
> On 12. Nov 2021, at 14:09, Kurt Jaeger wrote:
>
> Hello,
>
> I'm trying to investigate tcp-179 connection issues with the
> local frr setup. See below for more background.
>
> The question is: What can I do to find the cause of the failing
> connection ? Is there a way to trace the incoming
> On 7. Sep 2021, at 11:47, Rozhuk Ivan wrote:
>
> On Tue, 7 Sep 2021 10:47:01 +0200
> Michael Tuexen wrote:
>
>>>>> I have strange case: FreeBSD 12.2 ignore TCP RST from windows host
>>>>> and continue retransmitting packets. sockstat show that s
> On 7. Sep 2021, at 04:10, Rozhuk Ivan wrote:
>
> On Sat, 4 Sep 2021 13:19:52 +0200
> Michael Tuexen wrote:
>
>>> On 4. Sep 2021, at 01:37, Rozhuk Ivan wrote:
>>>
>>> Hi!
>>>
>>>
>>> I have strange case: FreeBSD 12.2 ign
> On 4. Sep 2021, at 01:37, Rozhuk Ivan wrote:
>
> Hi!
>
>
> I have strange case: FreeBSD 12.2 ignore TCP RST from windows host and
> continue retransmitting packets.
> sockstat show that socket connected even after many tcp rst packets received.
>
> Any ideas how to fix it?
Where is the
> On 10. Apr 2021, at 23:59, Rick Macklem wrote:
>
> tue...@freebsd.org wrote:
>> Rick wrote:
> [stuff snipped]
With r367492 you don't get the upcall with the same error state? Or you
don't get an error on a write() call, when there should be one?
>> If Send-Q is 0 when the network is
> On 10. Apr 2021, at 17:56, Rick Macklem wrote:
>
> Scheffenegger, Richard wrote:
>>> Rick wrote:
>>> Hi Rick,
>>>
Well, I have some good news and some bad news (the bad is mostly for
Richard).
The only message logged is:
tcpflags 0x4; tcp_do_segment: Timestamp
> On 10. Apr 2021, at 17:04, Rick Macklem wrote:
>
> tue...@freebsd.org wrote:
>>> On 10. Apr 2021, at 02:44, Rick Macklem wrote:
>>>
>>> tue...@freebsd.org wrote:
> On 6. Apr 2021, at 01:24, Rick Macklem wrote:
>
> tue...@freebsd.org wrote:
> [stuff snipped]
>> OK. What
> On 10. Apr 2021, at 11:19, Scheffenegger, Richard
> wrote:
>
> Hi Rick,
>
>> Well, I have some good news and some bad news (the bad is mostly for
>> Richard).
>>
>> The only message logged is:
>> tcpflags 0x4; tcp_do_segment: Timestamp missing, segment processed
>> normally
>>
>>
> On 10. Apr 2021, at 02:44, Rick Macklem wrote:
>
> tue...@freebsd.org wrote:
>>> On 6. Apr 2021, at 01:24, Rick Macklem wrote:
>>>
>>> tue...@freebsd.org wrote:
>>> [stuff snipped]
OK. What is the FreeBSD version you are using?
>>> main Dec. 23, 2020.
>>>
It seems that the
> On 6. Apr 2021, at 19:02, Rodney W. Grimes
> wrote:
>
>> 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
> On 6. Apr 2021, at 19:02, Rodney W. Grimes
> wrote:
>
>> 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
> On 6. Apr 2021, at 01:24, Rick Macklem wrote:
>
> tue...@freebsd.org wrote:
> [stuff snipped]
>> OK. What is the FreeBSD version you are using?
> main Dec. 23, 2020.
>
>>
>> It seems that the TCP connection on the FreeBSD is still alive,
>> Linux has decided to start a new TCP connection
> On 5. Apr 2021, at 01:12, Rick Macklem wrote:
>
> tue...@freebsd.org wrote:
>>> On 4. Apr 2021, at 22:28, Rick Macklem wrote:
>>>
>>> Oops, yes the packet capture is on freefall (forgot to mention that;-).
>>> You should be able to:
>>> % fetch
> On 5. Apr 2021, at 11:44, Rozhuk Ivan wrote:
>
> Hi!
>
>
> TCP Connection hang then I try to open
> https://online.sberbank.ru/CSAFront/index.do#/
>
> FreeBSD 13 desktop + FreeBSD 13 router (pf).
> http://www.netlab.linkpc.net/download/software/os_cfg/FBSD/13/base/etc/sysctl.conf
> FreeBSD
> On 4. Apr 2021, at 22:28, Rick Macklem wrote:
>
> Oops, yes the packet capture is on freefall (forgot to mention that;-).
> You should be able to:
> % fetch https://people.freebsd.org/~rmacklem/linuxtofreenfs.pcap
>
> Some useful packet #s are:
> 1949 - partitioning starts
> 2005 - partition
> On 4. Apr 2021, at 17:27, Rick Macklem wrote:
>
> Well, I'm going to cheat and top post, since this is elated info. and
> not really part of the discussion...
>
> I've been testing network partitioning between a Linux client (5.2 kernel)
> and a FreeBSD-current NFS server. I have not gotten a
> On 2. Apr 2021, at 02:07, Rick Macklem wrote:
>
> I hope you don't mind a top post...
> I've been testing network partitioning between the only Linux client
> I have (5.2 kernel) and a FreeBSD server with the xprtdied.patch
> (does soshutdown(..SHUT_WR) when it knows the socket is broken)
>
a
>>> natural point of extension.
>>>
>>> /usr/tests has some existing examples of relying on out of tree
>>> binaries to run so I am not convinced we need to import packetdrill
>>> itself but I don't have a strong preference. tuexen, do you have any
>
net/tcp-testsuite) into src where they can
> follow along with the tree they are running on, and provide vendors a
> natural point of extension.
>
> /usr/tests has some existing examples of relying on out of tree
> binaries to run so I am not convinced we need to import packetdrill
&
on.
I'm happy to have them in the src repo. That way it would be possible
to also support stable/13 and (possibly) stable/12.
>
> /usr/tests has some existing examples of relying on out of tree
> binaries to run so I am not convinced we need to import packetdrill
> itself but I do
eebsd.org; Alexander Motin
> Betreff: Re: NFS Mount Hangs
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content is safe.
>
>
>
>
> Michael Tuexen wrote:
>>> On 1
> On 18. Mar 2021, at 21:55, Rick Macklem wrote:
>
> Michael Tuexen wrote:
>>> On 18. Mar 2021, at 13:42, Scheffenegger, Richard
>>> wrote:
>>>
>>>>> Output from the NFS Client when the issue occurs # netstat -an | grep
>>>>&g
> On 18. Mar 2021, at 21:09, Michael Tuexen wrote:
>
>> On 15. Mar 2021, at 12:56, Blake Hartshorn
>> wrote:
>>
>> The short version, when I use FreeBSD 13, delivering data can take 5 minutes
>> for 1MB over SSH or HTTP when using IPv6. This problem does n
> On 15. Mar 2021, at 12:56, Blake Hartshorn wrote:
>
> The short version, when I use FreeBSD 13, delivering data can take 5 minutes
> for 1MB over SSH or HTTP when using IPv6. This problem does not happen with
> IPv4. I installed FreeBSD 12 and Linux on that same device, neither had the
>
> On 18. Mar 2021, at 13:53, Rodney W. Grimes
> wrote:
>
> Note I am NOT a TCP expert, but know enough about it to add a comment...
>
>> Alan Somers wrote:
>> [stuff snipped]
>>> Is the 128K limit related to MAXPHYS? If so, it should be greater in 13.0.
>> For the client, yes. For the server,
> On 18. Mar 2021, at 13:42, Scheffenegger, Richard
> wrote:
>
>>> Output from the NFS Client when the issue occurs # netstat -an | grep
>>> NFS.Server.IP.X
>>> tcp0 0 NFS.Client.IP.X:46896 NFS.Server.IP.X:2049
>>> FIN_WAIT2
>> I'm no TCP guy. Hopefully others might
> On 16. Mar 2021, at 15:18, Marek Zarychta
> wrote:
>
> W dniu 16.03.2021 o 12:50, tue...@freebsd.org pisze:
>>> On 16. Mar 2021, at 11:55, Blake Hartshorn
>>> wrote:
>>>
>>> Hi Michael,
>>>
>>> I've attached tcpdumps for port 80 on both sides of a bad transfer, using 2
>>> VMs in the
> On 16. Mar 2021, at 11:55, Blake Hartshorn wrote:
>
> Hi Michael,
>
> I've attached tcpdumps for port 80 on both sides of a bad transfer, using 2
> VMs in the same datacenter, FreeBSD 13 serving and 12 as a client. A friend
> of mine suggested I also run some tests with iperf3, so pasting
> On 15. Mar 2021, at 12:56, Blake Hartshorn wrote:
>
> The short version, when I use FreeBSD 13, delivering data can take 5 minutes
> for 1MB over SSH or HTTP when using IPv6. This problem does not happen with
> IPv4. I installed FreeBSD 12 and Linux on that same device, neither had the
>
> On 25. Feb 2021, at 19:08, Andriy Gapon wrote:
>
> On 24/02/2021 00:40, Scheffenegger, Richard wrote:
>> Hi Andriy,
>>
>> I guess I am currently the person who has the most recent knowledge about
>> that
>> part of the base stack…
>>
>> Do you happen to have more (preceding) information
> On 20. Feb 2021, at 05:32, Doug Hardie wrote:
>
>> On 19 February 2021, at 01:48, Michael Tuexen
>> wrote:
>>
>>> On 19. Feb 2021, at 03:29, Doug Hardie wrote:
>>>
>>> I don't know if this is a feature or a bug. On FreeBSD 9, the followi
get
with FreeBSD CURRENT:
tuexen@cirrus:~ % ping6 -s 5000 -b 6000 fe80::2e09:4dff:fe00:c00%re0
PING6(5048=40+8+5000 bytes) fe80::aaa1:59ff:fe0c:da92%re0 -->
fe80::2e09:4dff:fe00:c00%re0
5008 bytes from fe80::2e09:4dff:fe00:c00%re0, icmp_seq=0 hlim=255 time=0.393 ms
5008 bytes from fe80::2
> On 22. Sep 2020, at 14:40, Eugene Grosbein wrote:
>
> Hi!
>
> Is our IP reassembly facility supposed to handle incoming out-of-order
> fragments?
> For example, IPIP packet created with gif(4) interface is fragmented with two
> parts,
> and parts are delivered out of order, last fragment
> On 8. Sep 2020, at 02:18, Doug Hardie wrote:
>
>
>> On 7 September 2020, at 13:57, Michael Tuexen
>> wrote:
>>
>> For UDP and TCP you always get IPv6 addresses on AF_INET6 sockets. If you
>> are actually using IPv4, IPv4-mapped IPv6 addresses are
> On 8. Sep 2020, at 01:41, Doug Hardie wrote:
>
>> On 7 September 2020, at 13:57, Michael Tuexen
>> wrote:
>>
>>> On 7. Sep 2020, at 22:48, Doug Hardie wrote:
>>>
>>> I was quite surprised to discover that the sockaddr structure returned f
> On 7. Sep 2020, at 22:48, Doug Hardie wrote:
>
> I was quite surprised to discover that the sockaddr structure returned from
> recv_fd and recvfrom handle IPv4 addresses differently when using an INET6
> socket. I don't know if this was intended, or a side effect. I started
> using SCTP
> On 19. Aug 2020, at 10:14, Michael Tuexen
> wrote:
>
>> On 19. Aug 2020, at 06:51, Liang Tian wrote:
>>
>> Hi everyone,
>>
>> We noticed CWND is growing much slower than expected during congestion
>> avoidance with new reno, and we cam
> On 19. Aug 2020, at 06:51, Liang Tian wrote:
>
> Hi everyone,
>
> We noticed CWND is growing much slower than expected during congestion
> avoidance with new reno, and we came to this piece of code in
> cc_ack_received() at tcp_input.c:353
>
> if (type == CC_ACK) {
>
>if
> On 17. Jul 2020, at 18:07, Bernd Walter wrote:
>
> I'm running an LED matrix with SCTP.
> The matrix consists from 24 raspberry pi running NFS-root FreeBSD
> 12.0-RELEASE (they have an SD card for u-boot and loader).
> A client system is running FreeBSD 12.1-RELEASE.
I fixed iterator
> On 10. Jul 2020, at 12:29, Doug Hardie wrote:
>
>> On 10 July 2020, at 02:39, Michael Tuexen wrote:
>>
>> Hi Eugene,
>>
>> you are completely right. However, it requires that the program needs to run
>> with root privileges just to be able to commun
> On 10. Jul 2020, at 02:06, Eugene Grosbein wrote:
>
> 10.07.2020 2:44, Doug Hardie wrote:
>
>>> On 9 July 2020, at 08:13, Mark Johnston wrote:
>>>
>>> Hi,
>>>
>>> I spent some time working on making it possible to load the SCTP stack
>>> as a kernel module, the same as we do today with
> On 9. Jul 2020, at 23:15, Doug Hardie wrote:
>
>> On 9 July 2020, at 13:10, Mark Johnston wrote:
>>
>> On Thu, Jul 09, 2020 at 12:44:25PM -0700, Doug Hardie wrote:
On 9 July 2020, at 08:13, Mark Johnston wrote:
Hi,
I spent some time working on making it possible
> On 9. Jul 2020, at 21:44, Doug Hardie wrote:
>
>> On 9 July 2020, at 08:13, Mark Johnston wrote:
>>
>> Hi,
>>
>> I spent some time working on making it possible to load the SCTP stack
>> as a kernel module, the same as we do today with IPSec. There is one
>> patch remaining to be
> On 9. Jul 2020, at 21:01, Eugene Grosbein wrote:
>
> 09.07.2020 23:59, Michael Tuexen wrote:
>
>>> This may be relaxed with "sctp_enable" knob for /etc/rc.conf and new
>>> startup script
>>> /etc/rc.d/sctp that: a) REQUIRE: kld; b) checks if
> On 9. Jul 2020, at 19:02, Mark Johnston wrote:
>
> On Thu, Jul 09, 2020 at 11:36:34PM +0700, Eugene Grosbein wrote:
>> 09.07.2020 22:41, Michael Tuexen wrote:
>>
>>>> I am wondering if anyone has any objections to or concerns about this
>>>> propo
> On 9. Jul 2020, at 18:36, Eugene Grosbein wrote:
>
> 09.07.2020 22:41, Michael Tuexen wrote:
>
>>> I am wondering if anyone has any objections to or concerns about this
>>> proposal. Any feedback is appreciated.
>
> I'm for it.
>
>> maybe it i
> On 9. Jul 2020, at 17:13, Mark Johnston wrote:
>
> Hi,
>
> I spent some time working on making it possible to load the SCTP stack
> as a kernel module, the same as we do today with IPSec. There is one
> patch remaining to be committed before that can be done in head. One
> caveat is that
> On 19. Jun 2020, at 13:25, Sebastian Huber
> wrote:
>
> Hello,
>
> I use the mDNSResponder from Apple in embedded devices on top of the FreeBSD
> network stack. I tried to update from v878.270.2 to v1096.40.7:
>
> https://opensource.apple.com/tarballs/mDNSResponder/
>
> However, the
> On 9. Mar 2020, at 11:01, Doug Hardie wrote:
>
>> I am trying to get sctp_sendmsgx to work and not having a lot of success. I
>> have not been able to find any examples on the web of using it. I have a
>> client using sctp_sendmsg working fine. I need to make use of the
>> multihoming
1 - 100 of 223 matches
Mail list logo
