TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS
. Path: i2pn2.org!.POSTED!not-for-mail
From: Anonymous@news.novabbs.com (Anonymous)
Newsgroups: rocksolid.nodes
Subject: Re: dovenet on retrobbs
Date: Fri, 1 Sep 2023 06:44:43 +0000
Organization: novaBBS
Message-ID: <cf66606e5c82a1e4a205c2f27f41dffa@news.novabbs.com>
References: <fe59310b85095c405948aa80ab48a393@rocksolidbbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="242186"; mail-complaints-to="usenet@i2pn2.org";
posting-account="t+lO0yBNO1zGxasPvGSZV1BRu71QKx+JE37DnW+83jQ";
User-Agent: Rocksolid Light 0.9.1
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on i2pn2.org
X-Rslight-Site: $2y$10$hBo18tZMcrW7h8rfq5Sgl.IRBxDXtOgcpHbrCh5tD46b0N2Z0cAga
X-Rslight-Posting-User: 7f6804869f1c7a2172f0313e46d7f0689fb804f5
Xref: retrobbs rocksolid.nodes:1026

TCP having problems doing T usually means unreliable network packet delivery. And reliably repeating unreliable network packet delivery most often points to MTU problems, as the rest of the stuff either works always, or doesn't work at all.

Virtual NICs (and software defined networks in general) do not actually emulate the behaviour of sending and receiving packets on a wire, they quickly grab some virtual hardware data buffers filled by guest OS drivers and transfer them to the host process which deals with data, emulates low level network activity like ARP if needed, and makes packets appear at some real interface. The link between guest and host does not follow all the rules of real physical link.

The link between your server and client system is real, though, and it has to deal with packet fragmentation if it happens. I guess that: a) the link has lower MTU size due to VLAN or VPN encapsulation; b) ICMP messages that should report fragmentation are filtered by some firewall (I see mentions of DDoS). Systems that connect to each other with default MTU settings can't figure out that something is wrong, and it just so happens that big packet gets lost in the end, stalling the connection indefinitely.

There are numerous guides how to check whether maximum sized packets can reach both systems both ways. If any of the systems is set to use jumbo frames, their proper fragmentation should be tested, too. A sledgehammer approach would be to set MTU to a lower value, test the operation, then call it a day. Of course, any system change or forgetting to do it manually afterwards can reintroduce the problem.

I would also look at TCP connections in Wireshark. It is possible that they are constantly operating in heart attack mode, with re-transmissions and oscillating throughput.

Though it all is just my fantasy fueled by your post.

--
Posted on novaBBS