Samuel Thibault, le lun. 01 mars 2021 17:27:47 +0100, a ecrit: > Doug Evans, le lun. 01 mars 2021 08:23:03 -0800, a ecrit: > > On Sun, Feb 28, 2021 at 1:40 PM Samuel Thibault <[1]samuel.thiba...@gnu.org> > > wrote: > > > > [...] > > > Note that one issue I am leaving for later (i.e., I don't want to drag > > this > > > patch series out to include it), is whether and how to support > > ipv4-host-> > > > ipv6-guest forwarding and vice versa. Can libslirp support this? > > > > That would be feasible yes: since the data flow is completely rebuilt > > between the host and the guest, there is no remnant of the IP version. > > It was simpler to have e.g. udp_listen and udp6_listen separate to keep > > uint32_t / in6_addr parameters, but there is no strict reason for this: > > the haddr is only passed to the bind() call, and the laddr is only > > recorded in the so. Put another way, a refactoring patch could be to > > just hand udp_listen two sockaddrs, and it will just work fine. We'd > > then introduce a slirp_add_hostfwd that takes two sockaddr instead of > > host/port. > > > > > > > > I guess I'm not familiar enough with this code. > > Help me understand how passing two addresses to udp_listen is simpler. > > That feels confusing from an API viewpoint. > > ? udp_listen already takes two addresses + two ports. I just mean > replacing that with two sockaddr, which contains both, but also contains > the address family. I submitted this to > > https://gitlab.freedesktop.org/slirp/libslirp/-/merge_requests/74
And the public API to https://gitlab.freedesktop.org/slirp/libslirp/-/merge_requests/75 Ideally we'd then just drop the ipv6-only public API. Samuel