Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
IPv4 specific issue with USB tethering between my Debian laptop and my phone
56 views
Skip to first unread message
Vincent Lefevre
Dec 14, 2021, 7:20:05 PM12/14/21
to
Hi,
When I use USB tethering between my Debian/unstable laptop and my
Samsung Galaxy Note10+ phone (Android 11), everything is OK with
IPv6 connections (e.g. "wget -6"), but IPv4 connections freeze
(e.g. "wget -4" or "ssh -4"). I can notice this in particular when
testing with the same remote server. For instance, with "wget -4",
a few dozens of KB are downloaded, then the connection is completely
frozen.
I don't have any issue with the mobile hotspot (thus wifi between the
laptop and the phone) or with a Cosmo under Android 9 (instead of the
Samsung Galaxy Note10+), but in both cases, this is much slower, and
I sometimes get wifi disconnections.
On my Debian laptop, I'm using NetworkManager (nmcli).
--
Vincent Lefèvre <vin...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
When I use USB tethering between my Debian/unstable laptop and my
Samsung Galaxy Note10+ phone (Android 11), everything is OK with
IPv6 connections (e.g. "wget -6"), but IPv4 connections freeze
(e.g. "wget -4" or "ssh -4"). I can notice this in particular when
testing with the same remote server. For instance, with "wget -4",
a few dozens of KB are downloaded, then the connection is completely
frozen.
I don't have any issue with the mobile hotspot (thus wifi between the
laptop and the phone) or with a Cosmo under Android 9 (instead of the
Samsung Galaxy Note10+), but in both cases, this is much slower, and
I sometimes get wifi disconnections.
On my Debian laptop, I'm using NetworkManager (nmcli).
--
Vincent Lefèvre <vin...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Dan Ritter
Dec 14, 2021, 7:40:04 PM12/14/21
to
Vincent Lefevre wrote:
> Hi,
>
> When I use USB tethering between my Debian/unstable laptop and my
> Samsung Galaxy Note10+ phone (Android 11), everything is OK with
> IPv6 connections (e.g. "wget -6"), but IPv4 connections freeze
> (e.g. "wget -4" or "ssh -4"). I can notice this in particular when
> testing with the same remote server. For instance, with "wget -4",
> a few dozens of KB are downloaded, then the connection is completely
> frozen.
>
> I don't have any issue with the mobile hotspot (thus wifi between the
> laptop and the phone) or with a Cosmo under Android 9 (instead of the
> Samsung Galaxy Note10+), but in both cases, this is much slower, and
> I sometimes get wifi disconnections.
>
> On my Debian laptop, I'm using NetworkManager (nmcli).
Have you investigated the MTU? This sounds like a mismatch
> Hi,
>
> When I use USB tethering between my Debian/unstable laptop and my
> Samsung Galaxy Note10+ phone (Android 11), everything is OK with
> IPv6 connections (e.g. "wget -6"), but IPv4 connections freeze
> (e.g. "wget -4" or "ssh -4"). I can notice this in particular when
> testing with the same remote server. For instance, with "wget -4",
> a few dozens of KB are downloaded, then the connection is completely
> frozen.
>
> I don't have any issue with the mobile hotspot (thus wifi between the
> laptop and the phone) or with a Cosmo under Android 9 (instead of the
> Samsung Galaxy Note10+), but in both cases, this is much slower, and
> I sometimes get wifi disconnections.
>
> On my Debian laptop, I'm using NetworkManager (nmcli).
between what your laptop and phone are using.
Diagnosis (besides looking at connection details on both sides):
ping with increasingly large packet sizes. If it works at small
IPv4 packet sizes and then stops, that's the problem.
-dsr-
Tim Woodall
Dec 15, 2021, 1:10:05 AM12/15/21
to
The other thing I thought of was dodgy natting somewhere. Especially if
there's a firewall somewhere that drops 'middle of stream' packets where
no SYN has been seen first.
Vincent Lefevre
Dec 15, 2021, 12:00:07 PM12/15/21
to
On 2021-12-15 06:09:12 +0000, Tim Woodall wrote:
> On Tue, 14 Dec 2021, Dan Ritter wrote:
>
> > Vincent Lefevre wrote:
> > > Hi,
> > >
> > > When I use USB tethering between my Debian/unstable laptop and my
> > > Samsung Galaxy Note10+ phone (Android 11), everything is OK with
> > > IPv6 connections (e.g. "wget -6"), but IPv4 connections freeze
> > > (e.g. "wget -4" or "ssh -4"). I can notice this in particular when
> > > testing with the same remote server. For instance, with "wget -4",
> > > a few dozens of KB are downloaded, then the connection is completely
> > > frozen.
> > >
> > > I don't have any issue with the mobile hotspot (thus wifi between the
> > > laptop and the phone) or with a Cosmo under Android 9 (instead of the
> > > Samsung Galaxy Note10+), but in both cases, this is much slower, and
> > > I sometimes get wifi disconnections.
> > >
> > > On my Debian laptop, I'm using NetworkManager (nmcli).
> >
> > Have you investigated the MTU? This sounds like a mismatch
> > between what your laptop and phone are using.
> >
> > Diagnosis (besides looking at connection details on both sides):
> > ping with increasingly large packet sizes. If it works at small
> > IPv4 packet sizes and then stops, that's the problem.
Indeed, this works up to
> On Tue, 14 Dec 2021, Dan Ritter wrote:
>
> > Vincent Lefevre wrote:
> > > Hi,
> > >
> > > When I use USB tethering between my Debian/unstable laptop and my
> > > Samsung Galaxy Note10+ phone (Android 11), everything is OK with
> > > IPv6 connections (e.g. "wget -6"), but IPv4 connections freeze
> > > (e.g. "wget -4" or "ssh -4"). I can notice this in particular when
> > > testing with the same remote server. For instance, with "wget -4",
> > > a few dozens of KB are downloaded, then the connection is completely
> > > frozen.
> > >
> > > I don't have any issue with the mobile hotspot (thus wifi between the
> > > laptop and the phone) or with a Cosmo under Android 9 (instead of the
> > > Samsung Galaxy Note10+), but in both cases, this is much slower, and
> > > I sometimes get wifi disconnections.
> > >
> > > On my Debian laptop, I'm using NetworkManager (nmcli).
> >
> > Have you investigated the MTU? This sounds like a mismatch
> > between what your laptop and phone are using.
> >
> > Diagnosis (besides looking at connection details on both sides):
> > ping with increasingly large packet sizes. If it works at small
> > IPv4 packet sizes and then stops, that's the problem.
ping -4 -s 1472 joooj.vinc17.net
ping -6 -s 1452 joooj.vinc17.net
> Yes, probably - --clamp-mss-to-ptmu in iptables might be what is needed.
https://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.cookbook.mtu-mss.html
I've tried
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
and
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1024
and none of them have any effect. Or did I need something else?
Any other suggestion?
Tim Woodall
Dec 15, 2021, 12:10:05 PM12/15/21
to
When I look at where I've configured this in the past I've also done it
on the mangle chain:
iptables -t mangle -A FORWARD -p tcp -o $NET_IF --tcp-flags SYN,RST SYN
-j TCPMSS --clamp-mss-to-pmtu
ip6tables -t mangle -A FORWARD -p tcp -o $NETv6_IF --tcp-flags SYN,RST
SYN -j TCPMSS --clamp-mss-to-pmtu
etc. (you may or may not want to bother writing explicit rules for each
interface)
If you're going via a firewall then you (usually) only need -A FORWARD
But if you're trying to configure it on your laptop itself you probably
need -A OUTPUT (and possibly -A INPUT).
Dan Ritter
Dec 15, 2021, 1:40:05 PM12/15/21
to
Vincent Lefevre wrote:
> On 2021-12-15 06:09:12 +0000, Tim Woodall wrote:
> > On Tue, 14 Dec 2021, Dan Ritter wrote:
> >
> > > Vincent Lefevre wrote:
> > > > I don't have any issue with the mobile hotspot (thus wifi between the
> > > > laptop and the phone) or with a Cosmo under Android 9 (instead of the
> > > > Samsung Galaxy Note10+), but in both cases, this is much slower, and
> > > > I sometimes get wifi disconnections.
> > > >
> > > > On my Debian laptop, I'm using NetworkManager (nmcli).
> > >
> > > Have you investigated the MTU? This sounds like a mismatch
> > > between what your laptop and phone are using.
> > >
> > > Diagnosis (besides looking at connection details on both sides):
> > > ping with increasingly large packet sizes. If it works at small
> > > IPv4 packet sizes and then stops, that's the problem.
>
> Indeed, this works up to
> ping -4 -s 1472 joooj.vinc17.net
> ping -6 -s 1452 joooj.vinc17.net
ip link set USBNET0 mtu 1450, or something like that. I don't
> On 2021-12-15 06:09:12 +0000, Tim Woodall wrote:
> > On Tue, 14 Dec 2021, Dan Ritter wrote:
> >
> > > Vincent Lefevre wrote:
> > > > I don't have any issue with the mobile hotspot (thus wifi between the
> > > > laptop and the phone) or with a Cosmo under Android 9 (instead of the
> > > > Samsung Galaxy Note10+), but in both cases, this is much slower, and
> > > > I sometimes get wifi disconnections.
> > > >
> > > > On my Debian laptop, I'm using NetworkManager (nmcli).
> > >
> > > Have you investigated the MTU? This sounds like a mismatch
> > > between what your laptop and phone are using.
> > >
> > > Diagnosis (besides looking at connection details on both sides):
> > > ping with increasingly large packet sizes. If it works at small
> > > IPv4 packet sizes and then stops, that's the problem.
>
> Indeed, this works up to
> ping -4 -s 1472 joooj.vinc17.net
> ping -6 -s 1452 joooj.vinc17.net
know NetworkManager's syntax for that; random googling suggests
that they at least had a historical problem with not being able
to set MTU on anything other than a pure ethernet or wifi link,
but perhaps they've solved that?
-dsr-
Vincent Lefevre
Dec 16, 2021, 5:50:05 PM12/16/21
to
On 2021-12-15 17:01:54 +0000, Tim Woodall wrote:
> On Wed, 15 Dec 2021, Vincent Lefevre wrote:
> > I've tried
> >
> > iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
> >
> > and
> >
> > iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1024
> >
> I think you possibly want -A OUTPUT rules too.
This doesn't change anything.
> On Wed, 15 Dec 2021, Vincent Lefevre wrote:
> > I've tried
> >
> > iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
> >
> > and
> >
> > iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1024
> >
> I think you possibly want -A OUTPUT rules too.
> And also ip6tables rules.
There are no issues with IPv6.
> If you're going via a firewall then you (usually) only need -A FORWARD
> But if you're trying to configure it on your laptop itself you probably
> need -A OUTPUT (and possibly -A INPUT).
# iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
iptables v1.8.7 (nf_tables): RULE_APPEND failed (Invalid argument): rule in chain INPUT
And similar error with "-I INPUT":
iptables v1.8.7 (nf_tables): RULE_INSERT failed (Invalid argument): rule in chain INPUT
Vincent Lefevre
Dec 16, 2021, 7:10:05 PM12/16/21
to
Dan Ritter wrote:
> ip link set USBNET0 mtu 1450, or something like that. I don't
> know NetworkManager's syntax for that; random googling suggests
> that they at least had a historical problem with not being able
> to set MTU on anything other than a pure ethernet or wifi link,
> but perhaps they've solved that?
"ip link" works on its side. I can see with wireshark that something
> ip link set USBNET0 mtu 1450, or something like that. I don't
> know NetworkManager's syntax for that; random googling suggests
> that they at least had a historical problem with not being able
> to set MTU on anything other than a pure ethernet or wifi link,
> but perhaps they've solved that?
like "ip link set usb0 mtu 1300" is honored, but this doesn't solve
the problem (I've tried various values from 1000 to 1450).
Note that I could also see with wireshark that the iptables rules
with --clamp-mss-to-pmtu did not change the packet lengths.
Tim Woodall
Dec 17, 2021, 2:20:05 AM12/17/21
to
On Fri, 17 Dec 2021, Vincent Lefevre wrote:
> Dan Ritter wrote:
>> ip link set USBNET0 mtu 1450, or something like that. I don't
>> know NetworkManager's syntax for that; random googling suggests
>> that they at least had a historical problem with not being able
>> to set MTU on anything other than a pure ethernet or wifi link,
>> but perhaps they've solved that?
>
> "ip link" works on its side. I can see with wireshark that something
> like "ip link set usb0 mtu 1300" is honored, but this doesn't solve
> the problem (I've tried various values from 1000 to 1450).
>
> Note that I could also see with wireshark that the iptables rules
> with --clamp-mss-to-pmtu did not change the packet lengths.
>
Does this happen on any connection or just some?
> Dan Ritter wrote:
>> ip link set USBNET0 mtu 1450, or something like that. I don't
>> know NetworkManager's syntax for that; random googling suggests
>> that they at least had a historical problem with not being able
>> to set MTU on anything other than a pure ethernet or wifi link,
>> but perhaps they've solved that?
>
> "ip link" works on its side. I can see with wireshark that something
> like "ip link set usb0 mtu 1300" is honored, but this doesn't solve
> the problem (I've tried various values from 1000 to 1450).
>
> Note that I could also see with wireshark that the iptables rules
> with --clamp-mss-to-pmtu did not change the packet lengths.
>
You said you could reproduce using ssh? Does that mean you can run
wireshark on both ends and see which packet is getting lost?
Did you try setting both mtu on the interface to something smallish plus
--clamp-mss-to-pmtu?
I'm pretty sure all ipv4 over mobile (which I think is what you are
testing) depends on NAT. So my other guess of a dodgy NAT device isn't
impossible. IIRC your ping tests suggested that ipv4 is being tunnelled
in ipv6
Vincent Lefevre
Dec 18, 2021, 6:00:05 PM12/18/21
to
On 2021-12-17 07:09:52 +0000, Tim Woodall wrote:
> On Fri, 17 Dec 2021, Vincent Lefevre wrote:
>
> > Dan Ritter wrote:
> > > ip link set USBNET0 mtu 1450, or something like that. I don't
> > > know NetworkManager's syntax for that; random googling suggests
> > > that they at least had a historical problem with not being able
> > > to set MTU on anything other than a pure ethernet or wifi link,
> > > but perhaps they've solved that?
> >
> > "ip link" works on its side. I can see with wireshark that something
> > like "ip link set usb0 mtu 1300" is honored, but this doesn't solve
> > the problem (I've tried various values from 1000 to 1450).
> >
> > Note that I could also see with wireshark that the iptables rules
> > with --clamp-mss-to-pmtu did not change the packet lengths.
> >
>
> Does this happen on any connection or just some?
On any IPv4 connection (tested with ssh to 2 remote machines, and
> On Fri, 17 Dec 2021, Vincent Lefevre wrote:
>
> > Dan Ritter wrote:
> > > ip link set USBNET0 mtu 1450, or something like that. I don't
> > > know NetworkManager's syntax for that; random googling suggests
> > > that they at least had a historical problem with not being able
> > > to set MTU on anything other than a pure ethernet or wifi link,
> > > but perhaps they've solved that?
> >
> > "ip link" works on its side. I can see with wireshark that something
> > like "ip link set usb0 mtu 1300" is honored, but this doesn't solve
> > the problem (I've tried various values from 1000 to 1450).
> >
> > Note that I could also see with wireshark that the iptables rules
> > with --clamp-mss-to-pmtu did not change the packet lengths.
> >
>
> Does this happen on any connection or just some?
with https on various web servers). IPv6 connections seem fine.
> You said you could reproduce using ssh? Does that mean you can run
> wireshark on both ends and see which packet is getting lost?
is a replacement tool that doesn't need an X11 connection, to just
do the capture of the packets.
> Did you try setting both mtu on the interface to something smallish
> plus --clamp-mss-to-pmtu?
> I'm pretty sure all ipv4 over mobile (which I think is what you are
> testing) depends on NAT. So my other guess of a dodgy NAT device isn't
> impossible. IIRC your ping tests suggested that ipv4 is being tunnelled
> in ipv6
didier gaumet
Dec 19, 2021, 3:10:05 AM12/19/21
to
Le samedi 18 décembre 2021 à 23:52 +0100, Vincent Lefevre a écrit :
[...]
> I haven't tried wireshark on the other end. I wonder whether there
> is a replacement tool that doesn't need an X11 connection, to just
> do the capture of the packets.
[...]
> is a replacement tool that doesn't need an X11 connection, to just
> do the capture of the packets.
Hello Vincent,
perhaps tshark (tshark package) would do?
https://www.wireshark.org/docs/wsug_html_chunked/AppToolstshark.html
Tim Woodall
Dec 19, 2021, 4:20:04 AM12/19/21
to
On Sun, 19 Dec 2021, didier gaumet wrote:
>
>
> Le samedi 18 d?cembre 2021 ? 23:52 +0100, Vincent Lefevre a ?crit?:
tcpdump is my tool of choice for this. I don't even use wireshark for
capture when I'll be capturing packets on the host I'll be viewing them
on.
>
>
> Le samedi 18 d?cembre 2021 ? 23:52 +0100, Vincent Lefevre a ?crit?:
> [...]
>> I haven't tried wireshark on the other end. I wonder whether there
>> is a replacement tool that doesn't need an X11 connection, to just
>> do the capture of the packets.
> [...]
>
> Hello Vincent,
>
> perhaps tshark (tshark package) would do?
> https://www.wireshark.org/docs/wsug_html_chunked/AppToolstshark.html
>
>
>
>
Missed this.
>> I haven't tried wireshark on the other end. I wonder whether there
>> is a replacement tool that doesn't need an X11 connection, to just
>> do the capture of the packets.
> [...]
>
> Hello Vincent,
>
> perhaps tshark (tshark package) would do?
> https://www.wireshark.org/docs/wsug_html_chunked/AppToolstshark.html
>
>
>
>
tcpdump is my tool of choice for this. I don't even use wireshark for
capture when I'll be capturing packets on the host I'll be viewing them
on.
0 new messages