I finally figured out the issue with the dovenet groups on retrobbs.i2p.

When pulling articles from a nntp server (Synchronet NNTP in this case),
rslight sends an XOVER command to get data about the articles it will (may)
pull. This is pretty standard for newsreaders.

I found that the full XOVER data was not making it from Synchronet to rslight
over the network. The data would stop before the last line "n.n" is received
so it would hang.

Synchronet is running in a VirtualBox session, and when pulling the same
XOVER data from the server itself, it works fine. When pulling from the HOST
machine, it works fine. But when pulling from beyond the HOST, it does not
work.

I have no idea at this time why this is happening, if someone has any clues
I should check (other than don't use VBOX, lol) I'd be glad to hear it.

For now, I have just lowered the number of articles pulled at one time to
hopefully avoid this issue temporarily, until I can find the actual solution.

--
Retro Guy

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.

Anonymous wrote:

> 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.

Thanks for the overview. While I have things running fine atm, it may be a nice exercise in troubleshooting to take a stab at it.

I've become less pleased with VBox over time. If I could ever figure out a proper way to get a bridged ip address that routes properly using kvm, that would be nice.

--
Retro Guy