Is traceroute supposed to work in user mode networking (slirp) ?

Is traceroute supposed to work in user mode networking (slirp) ?

[Ottavio Caruso]

[Originally asked on qemu-discuss but I didn't get any feedback.
Thanks for your patience.

Hi,

I have enabled pinging from the guest changing the
"net.ipv4.ping_group_range" on my Linux host. I can now ping any host
using icmp. But I cannot get  traceroute to work with standard udp
from any of my guests.

$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 40 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
[and so on]

And if I use traceroute over icmp, I only get one hop shown:

$ traceroute -I 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 60 byte packets
 1  dns.google (8.8.8.8)  26.147 ms  27.88 ms  20.048 ms

I have tested this with various guest OSes (OpenBSD, FreeBSD, NetBSD,
Small Damn Linux).

I've played around with various virtual interfaces but I have the same result.

Any clues? Is this intended behaviour? Any workarounds that don't
involve tap/tun/bridges?

--
Ottavio Caruso

Re: Is traceroute supposed to work in user mode networking (slirp) ?

[Samuel Thibault]

Hello,

Ottavio Caruso, le mar. 14 juil. 2020 12:15:48 +0100, a ecrit:
> I cannot get traceroute to work with standard udp from any of my
> guests.
> 
> $ traceroute 8.8.8.8
> traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 40 byte packets
>  1  * * *

That was because

- libslirp was not forwarding the ttl value, thus always set to 64 hops
- libslirp was not reporting icmp errors.

I had a try at both, and that indeed seems to be fixing the issue:
https://gitlab.freedesktop.org/slirp/libslirp/-/merge_requests/48
https://gitlab.freedesktop.org/slirp/libslirp/-/merge_requests/49

> Any clues? Is this intended behaviour? Any workarounds that don't
> involve tap/tun/bridges?

Not without updating libslirp with the abovementioned patches.

Samuel

Re: Is traceroute supposed to work in user mode networking (slirp) ?

[Ottavio Caruso]

On Sun, 19 Jul 2020 at 03:50, Samuel Thibault <samuel.thibault@gnu.org> wrote:
>
> Hello,
>
> Ottavio Caruso, le mar. 14 juil. 2020 12:15:48 +0100, a ecrit:
> > I cannot get traceroute to work with standard udp from any of my
> > guests.
> >
> > $ traceroute 8.8.8.8
> > traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 40 byte packets
> >  1  * * *
>
> That was because
>
> - libslirp was not forwarding the ttl value, thus always set to 64 hops
> - libslirp was not reporting icmp errors.
>
> I had a try at both, and that indeed seems to be fixing the issue:
> https://gitlab.freedesktop.org/slirp/libslirp/-/merge_requests/48
> https://gitlab.freedesktop.org/slirp/libslirp/-/merge_requests/49
>
> > Any clues? Is this intended behaviour? Any workarounds that don't
> > involve tap/tun/bridges?
>
> Not without updating libslirp with the abovementioned patches.

Thanks Samuel. I've added a comment on the portal, but for the benefit
of qemu-devel:

Applying this patch on the latest qemu (5.0.90), does indeed implement
traceroute, but it only reports one hop. I've tested this on a FreeBSD
guest and a minimal DSL Linux guest:

root@FreeBSD:/home/oc # uname -sr
FreeBSD 12.1-RELEASE-p5
root@FreeBSD:/home/oc # traceroute google.com
traceroute to google.com (216.58.206.110), 64 hops max, 40 byte packets
 1  lhr25s14-in-f14.1e100.net (216.58.206.110)  20.555 ms  19.981 ms  19.042 ms
root@FreeBSD:/home/oc # traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 64 hops max, 40 byte packets
 1  one.one.one.one (1.1.1.1)  19.722 ms  19.171 ms  19.018 ms



-- 
Ottavio Caruso

Re: Is traceroute supposed to work in user mode networking (slirp) ?

[Samuel Thibault]

Ottavio Caruso, le dim. 19 juil. 2020 12:07:21 +0100, a ecrit:
> On Sun, 19 Jul 2020 at 03:50, Samuel Thibault <samuel.thibault@gnu.org> wrote:
> > Ottavio Caruso, le mar. 14 juil. 2020 12:15:48 +0100, a ecrit:
> > > I cannot get traceroute to work with standard udp from any of my
> > > guests.
> > >
> > > $ traceroute 8.8.8.8
> > > traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 40 byte packets
> > >  1  * * *
> >
> > That was because
> >
> > - libslirp was not forwarding the ttl value, thus always set to 64 hops
> > - libslirp was not reporting icmp errors.
> >
> > I had a try at both, and that indeed seems to be fixing the issue:
> > https://gitlab.freedesktop.org/slirp/libslirp/-/merge_requests/48
> > https://gitlab.freedesktop.org/slirp/libslirp/-/merge_requests/49
> >
> > > Any clues? Is this intended behaviour? Any workarounds that don't
> > > involve tap/tun/bridges?
> >
> > Not without updating libslirp with the abovementioned patches.
> 
> Thanks Samuel. I've added a comment on the portal, but for the benefit
> of qemu-devel:
> 
> Applying this patch on the latest qemu (5.0.90),

Did you also apply
https://gitlab.freedesktop.org/slirp/libslirp/-/merge_requests/48 ?

Samuel

Re: Is traceroute supposed to work in user mode networking (slirp) ?

[Ottavio Caruso]

On Sun, 19 Jul 2020 at 12:16, Samuel Thibault <samuel.thibault@gnu.org> wrote:
>
> Ottavio Caruso, le dim. 19 juil. 2020 12:07:21 +0100, a ecrit:
> > On Sun, 19 Jul 2020 at 03:50, Samuel Thibault <samuel.thibault@gnu.org> wrote:
> > > Ottavio Caruso, le mar. 14 juil. 2020 12:15:48 +0100, a ecrit:
> > > > I cannot get traceroute to work with standard udp from any of my
> > > > guests.
> > > >
> > > > $ traceroute 8.8.8.8
> > > > traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 40 byte packets
> > > >  1  * * *
> > >
> > > That was because
> > >
> > > - libslirp was not forwarding the ttl value, thus always set to 64 hops
> > > - libslirp was not reporting icmp errors.
> > >
> > > I had a try at both, and that indeed seems to be fixing the issue:
> > > https://gitlab.freedesktop.org/slirp/libslirp/-/merge_requests/48
> > > https://gitlab.freedesktop.org/slirp/libslirp/-/merge_requests/49
> > >
> > > > Any clues? Is this intended behaviour? Any workarounds that don't
> > > > involve tap/tun/bridges?
> > >
> > > Not without updating libslirp with the abovementioned patches.
> >
> > Thanks Samuel. I've added a comment on the portal, but for the benefit
> > of qemu-devel:
> >
> > Applying this patch on the latest qemu (5.0.90),
>
> Did you also apply
> https://gitlab.freedesktop.org/slirp/libslirp/-/merge_requests/48 ?

No, because I thought that 49 would include 48. Let me give a try and
come back. Updates on Gitlab.



-- 
Ottavio Caruso

Re: Is traceroute supposed to work in user mode networking (slirp) ?

[Ottavio Caruso]

On Sun, 19 Jul 2020 at 15:15, Ottavio Caruso
<ottavio2006-usenet2012@yahoo.com> wrote:
>
> On Sun, 19 Jul 2020 at 12:16, Samuel Thibault <samuel.thibault@gnu.org> wrote:
> >
> > Ottavio Caruso, le dim. 19 juil. 2020 12:07:21 +0100, a ecrit:
> > > On Sun, 19 Jul 2020 at 03:50, Samuel Thibault <samuel.thibault@gnu.org> wrote:
> > > > Ottavio Caruso, le mar. 14 juil. 2020 12:15:48 +0100, a ecrit:
> > > > > I cannot get traceroute to work with standard udp from any of my
> > > > > guests.
> > > > >
> > > > > $ traceroute 8.8.8.8
> > > > > traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 40 byte packets
> > > > >  1  * * *
> > > >
> > > > That was because
> > > >
> > > > - libslirp was not forwarding the ttl value, thus always set to 64 hops
> > > > - libslirp was not reporting icmp errors.
> > > >
> > > > I had a try at both, and that indeed seems to be fixing the issue:
> > > > https://gitlab.freedesktop.org/slirp/libslirp/-/merge_requests/48
> > > > https://gitlab.freedesktop.org/slirp/libslirp/-/merge_requests/49
> > > >
> > > > > Any clues? Is this intended behaviour? Any workarounds that don't
> > > > > involve tap/tun/bridges?
> > > >
> > > > Not without updating libslirp with the abovementioned patches.
> > >
> > > Thanks Samuel. I've added a comment on the portal, but for the benefit
> > > of qemu-devel:
> > >
> > > Applying this patch on the latest qemu (5.0.90),
> >
> > Did you also apply
> > https://gitlab.freedesktop.org/slirp/libslirp/-/merge_requests/48 ?
>
> No, because I thought that 49 would include 48. Let me give a try and
> come back. Updates on Gitlab.

Thanks.

https://gitlab.freedesktop.org/slirp/libslirp/-/merge_requests/49#note_573654

When are we going to see this imported into qemu? I'm not extremely
familiar with git modules. I assume this will one day be part of qemu
upstream?


-- 
Ottavio Caruso