Bug 13690 - runqemu with slirp, forwarded host ports are not available on host
Summary: runqemu with slirp, forwarded host ports are not available on host
Status: RESOLVED OBSOLETE
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: Scripts and Tools (show other bugs)
Version: 3.1
Hardware: x86 Multiple
: Medium normal
Target Milestone: 5.99
Assignee: Unassigned
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2019-12-06 23:55 UTC by Amanda Brindle
Modified: 2026-04-30 15:10 UTC (History)
5 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: Regression (Used to work)
Verified:
Documentation change: Don't know


Attachments
Log File with ssh=True (23.03 KB, text/x-log)
2019-12-06 23:55 UTC, Amanda Brindle
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Amanda Brindle 2019-12-06 23:55:06 UTC
Created attachment 4595 [details]
Log File with ssh=True

When running runqemu with slirp, unable to ssh into image because forwarded host ports are not available. 

test_boot_machine_slirp does not test for ssh connection; test times out if ssh=True
Comment 1 Tim Orling 2019-12-10 18:04:34 UTC
The host port forwarding is being set on this line:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/scripts/runqemu#n1030

But something in the syntax of qemu or other has changed the behavior. Neither port 2222 (ssh) nor port 2323 (telnet) are able to connect to the qemu target. Both simply time out.
Comment 2 Tim Orling 2019-12-10 18:16:27 UTC
Nothing immediately stands out in a quick read through the changelog for qemu:

https://wiki.qemu.org/ChangeLog
https://wiki.qemu.org/ChangeLog/3.1
(3.0.0 -> 3.1.0 poky commit: 	d1c2b732e7d516741f785586db5047dc704ae7c9)

https://wiki.qemu.org/ChangeLog/4.0 
(3.1.0 -> 4.0.0 poky commit: 69085ccb296b35b0b0ed67c871f0f60106c27a48)

https://wiki.qemu.org/ChangeLog/4.1 (current version on master)
(4.0.0 -> 4.1.0 poky commit: 5a308c55a60282b475545f3c7346e5e8053aba3f)

https://wiki.qemu.org/ChangeLog/4.2
4.2.0-rc4
Dec 3rd 2019
Comment 3 Paul Eggleton 2019-12-12 04:19:16 UTC
On my Fedora system I can successfully use "runqemu slirp" and then "ssh 127.0.0.1 -p 2222" in a separate shell session - I'm assuming that doesn't work in your case? 

Setting ssh=True in the test_boot_machine_slirp *does* also fail for me though - there is already some logic in QemuRunner that understands how to deal with slirp but it isn't enabled in this situation. I added a parameter and plumbed things through and now the test works for me with ssh=True:

http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=paule/qemu-slirp

What do you see if you use this patch?
Comment 4 Tim Orling 2019-12-12 15:37:35 UTC
Do you have Docker-CE installed? Perhaps docker is borking iptables and that is the cause of port forwarding failure. Amanda and I both have docker-ce installed.
Comment 5 Paul Eggleton 2019-12-15 21:48:59 UTC
I do now - still works. Also tested on two internal machines (running Ubuntu 16.04), no issues there either. I'm not giving up though :)
Comment 6 Tim Orling 2019-12-15 22:20:15 UTC
I think I figured out what was going on. When trying to figure out what IP address to use for ssh, we were running "ip addr show" or similar inside qemu.

However, if you run "netstat ntlp" on the host, you see 0.0.0.0:2222 and 0.0.0.0:2323, which means the correct way to ssh into the qemu VM is:

$ ssh -p 2222 root@locahost

or the equivalent:

$ ssh -p 2222 root@127.0.0.1

On Debian/Ubuntu, "netstat" can by installed with:

$ sudo apt update -y && sudo apt upgrade -y && sudo apt install net-tools

docker
------
Also, when running qemu inside a container, you normally run "runqemu slirp nographic". This means the first tty is tied up running qemu. From a second terminal on the host, exec into the docker container:

$ docker exec -it [container-id] bash

You could also bind mount port 2222 from the host to 2222 inside the poky-container, allowing a regular host terminal to be used to ssh into qemu. Modify th command used to start the poky-container similar to:

$ docker run -it -p 2222:2222 [...]
Comment 7 Amanda Brindle 2019-12-16 19:22:39 UTC
I am now able to ssh into slirp by checking the proper port and using 127.0.0.1. 

Just a note, when I tried to ssh into a core-image-minimal image, I got this error: 

ssh_exchange_identification: read: Connection reset by peer

I will try this same process in the CROPS containers.
Comment 8 Paul Eggleton 2020-01-07 21:45:17 UTC
Amanda - when you say a core-image-minimal image do you mean core-image-minimal with an SSH server added? If so which one (dropbear or openssh)?
Comment 9 Randy MacLeod 2020-01-16 15:57:44 UTC
Amanda, can you reply to Paul please?
Comment 10 Amanda Brindle 2020-01-16 18:59:10 UTC
@Paul I just realized I didn't add an ssh server, I'll try it with that, but the original bug of sshing when using slirp is working now.
Comment 11 Tim Orling 2020-04-23 08:57:02 UTC
While the original root cause was some confusion and misremembering, the test case change that Paul has seems valuable.

Perhaps it would be best to have two test cases, one with SSH (that will be skipped if SSH test does not pass) and one without SSH so that SLIRP is tested no matter what.

Bumping to 3.2M1, since we ran out of time before 3.1M4 closed.
Comment 12 Tim Orling 2020-09-29 22:34:56 UTC
What is desired here is the ability to conditionally skip a test of ssh is not available on the target. We do not have examples of conditionally skipping tests in oeqa/selftest/cases/, only in oeqa/runtime/cases.

The ssh test case should skip if ssh-server-openssl or ssh-server-dropbear are not in IMAGE_FEATURES (fully expanded, including EXTRA_IMAGE_FEATUES)

Cases where dropbear or openssh are added to IMAGE_INSTALL are not recommended, so do not test for that. Rather skip and recommend the IMAGE_FEATURES syntax.
Comment 13 Randy MacLeod 2023-10-30 15:37:27 UTC
Build move to 5.0 -- ../Randy
Comment 14 Randy MacLeod 2024-04-25 01:13:54 UTC
Bulk move of 5.0 medium importance issues to 5.99.
Move to 5.1 if you want to actively work on an issue.
Comment 15 Randy MacLeod 2024-04-25 01:23:13 UTC
Move to 5.99 since no one is actively working on this issue.
Move to 5.x if you start on a task, please.
Comment 16 Mathieu Dubois-Briand 2026-04-30 15:10:07 UTC
The original issue was resolved