diff options
Diffstat (limited to 'results/classifier/118/graphic/1724590')
| -rw-r--r-- | results/classifier/118/graphic/1724590 | 57 |
1 files changed, 57 insertions, 0 deletions
diff --git a/results/classifier/118/graphic/1724590 b/results/classifier/118/graphic/1724590 new file mode 100644 index 00000000..04166fce --- /dev/null +++ b/results/classifier/118/graphic/1724590 @@ -0,0 +1,57 @@ +graphic: 0.870 +user-level: 0.844 +architecture: 0.832 +network: 0.809 +arm: 0.757 +device: 0.720 +performance: 0.691 +socket: 0.681 +ppc: 0.671 +kernel: 0.660 +semantic: 0.619 +register: 0.605 +hypervisor: 0.597 +mistranslation: 0.568 +PID: 0.565 +vnc: 0.562 +files: 0.558 +permissions: 0.528 +VMM: 0.518 +peripherals: 0.512 +risc-v: 0.497 +x86: 0.477 +TCG: 0.472 +assembly: 0.467 +debug: 0.454 +virtual: 0.440 +i386: 0.435 +KVM: 0.396 +boot: 0.362 + +Usermode networking hostfwd only listens on IPv4 + +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. + +Hello, + +This is indeed not implemented, patches welcome :) + +Samuel + +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 + +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. + + +[Expired for QEMU because there has been no activity for 60 days.] + |