Autore: Lars Noodén Data: To: dng Oggetto: Re: [DNG] IPv6 slow on one of my Linux hosts
On 11/10/23 21:39, jeremy ardley via Dng wrote: >
> On 10/11/23 22:20, Michael S. Keller via Dng wrote:
>> I did not have the opportunity to use the onboard NIC for this
>> point-to-point test, but with the USB network adapter, I saw no
>> slowdowns on a point-to-point link, while I did when it was connected
>> to my greater home network.
>>
>> I saw no sign in syslog of an address conflict.
>>
>> On 11/8/23 15:50, jeremy ardley via Dng wrote:
>>>
>>> On 9/11/23 05:37, Michael S. Keller via Dng wrote:
>>>> On 11/8/23 14:51, jeremy ardley via Dng wrote:
>>>>>
>>>>> On 9/11/23 03:56, Michael S. Keller via Dng wrote:
>>>>>> My oldest Linux host has trouble with IPv6. Apparently it's the
>>>>>> only host in my home network that does have trouble with it (of
>>>>>> those that can do IPv6), and I've run out of ideas. All tests are
>>>>>> in the same network - traffic does not cross into my ISP's area.
>>>>>> The same symptom has persisted across two different switch/router
>>>>>> combos - first an old Airport Extreme, now a TP-Link Deco XE75.
>>>> >Try setting up a direct cable connection between the two devices
>>>> >without a switch. That will eliminate the possibility of other
>>>> devices >on the LAN causing the problem.
>>>>
>>>> What sort of interference are you positing, that would affect just
>>>> this one host, and only with IPv6?
>>>> _______________________________________________
>>>
>>>
>>> There are several possibilities, but by just running a cable between
>>> devices you can isolate the problem to the specific host/O/S components.
>>>
>>> Example of interference from other systems could be QOS shaping, IPv6
>>> address conflicts, hardware faults, security software. etc etc.
>>>
>>> If the single cable shows the same faults you can then examine things
>>> like MTU, /etc./sysctl.conf, net.ipv6.tcp_rmem, |net.ipv6.tcp_wmem,
>>> |and look for differences from other systems without the problem.
>>>
> I suggest running wireshark on the host with the problem. Even if the
> host has no graphics, you can run wireshark and view results via ssh on
> a different system.
Or you can even capture using tcpdump, regardless of whether the system
has a GUI, and then transfer the PCAP file to the system which has
Wireshark to peruse at your convenience. Just be sure that if you are
connecting via SSH to exclude the SSH packets from your own SSH client
in tcpdump's filter rules.