Usermode networking hostfwd only listens on IPv4

Bug #1724590 reported by Willem Mulder
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
QEMU
Expired
Wishlist
Unassigned

Bug Description

When forwarding ports in usermode networking (-net user,hostfwd=), QEMU binds to IPv4 only. Therefore, connecting to the port over IPv6 results in 'connection refused'.

I experienced this in QEMU 2.10.1, but it looks to still be present in the current master (861cd431c99e56ddb5953ca1da164a9c32b477ca), since slirp_hostfwd in net/slirp.c uses in_addr instead of in6_addr.

Revision history for this message
Samuel thibault (samuel-thibault) wrote :

Hello,

This is indeed not implemented, patches welcome :)

Samuel

Thomas Huth (th-huth)
Changed in qemu:
importance: Undecided → Wishlist
Revision history for this message
Bilal Wasim (bwasim123) wrote :

Hi Guys - I'm currently trying to use IPv6 with QEMU on ARM / AARCH64 Models (Sabre-Lite / Zync SOCs) and I see this problem. The system gets an IPv6 address from the QEMU in-built router which can be used to ping the default gateway (the dhcp router itself). All this is good but not really useful as I want to communicate with a TCP6 client on the host (Windows / Linux) machine running on port 8080. I've added the co-responding port mappings (like I do with IPv4) but I never receive packets from the host OS which is this issue. So I have the following questions,
- It seems that this issue is still open and on the wishlist. Is this correct ? If so, is there any ETA to when someone will take this up ? If none, may be I can look at this ;-).. I'm currently using QEMU 3.0
- Assuming that its not working, what are the alternatives that I can use ? I understand that there is TAP-TUN Networking where the QEMU model can communicate with the hardware interface over a bridge.. This should work with IPv6.. Can you confirm ?

This needs quick closure on my side and so quick comments will be appreciated..

Thanks,
Bilal

Revision history for this message
Thomas Huth (th-huth) wrote :

The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.

Changed in qemu:
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for QEMU because there has been no activity for 60 days.]

Changed in qemu:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.