qemu-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss] Coldfire 5282 Support


From: William Mahoney
Subject: Re: [Qemu-discuss] Coldfire 5282 Support
Date: Thu, 5 Oct 2017 18:55:10 +0000

OK I took a look at slirp.c as you suggested.
I put in some fprintf’s in slip.c for the ARP requests and also in 
arp_table_add and arp_table_search in arp_table.c. In the process I learned a 
lot about how the ARP services work within QEMU and in the process also 
realized what I was doing wrong. Long story. But now, if I do a redirect on the 
command line sending - for example - 6000 on the host to 5000 on the guest, and 
do a netcat listening on the guest, that works, I can “get in” from the host to 
the guest. And if I start up a listening netcat on the host and get the proper 
guestfwd on the command line that works fine as well.
(If anyone is interested… When uClinux starts up it sends an unsolicited ARP 
associating 10.0.2.15 with the correct MAC address. Suppose at that point I try 
to do “nc 10.0.2.15”. This connection is refused without ever even hitting the 
net drivers. If I do “nc 10.0.2.2” it does search the ARP table for the .15 
address (not the .2 address) and finds it, obviously. QEMU sends back the ARP 
reply and uClinux on the guest sees it. Then uClinux says “Connection refused” 
anyway. In slip.c it just rejects everything not on the same subnet, so had I 
realized this it’d have saved me some time, but now I learned how it works!)
Anyway it does work as advertised but I was misreading or not understanding 
somewhere along the line. Thanks everyone.

Bill



On Oct 3, 2017, at 12:40 PM, Peter Maydell 
<address@hidden<mailto:address@hidden>> wrote:

On 3 October 2017 at 18:14, Thomas Huth <address@hidden<mailto:address@hidden>> 
wrote:
Not sure, but it might be normal that the host is not answering here.
The "user" networking is using NAT, so the host OS might think that it
is talking to itself here and thus ARP is not needed. You might want to
try "tap" networking instead. Or maybe try to connect to another host
from within the guest first (for example "nc 
www.google.com<http://www.google.com> 80" ... and
then type "GET / HTTP/1.0").

With the user-mode networking QEMU should do all the handling
of guest ARP requests and responses internally; they'll never get out
to the host because the host will have no idea what to do with
them. (See arp_input() in slirp/slirp.c.)

thanks
-- PMM


reply via email to

[Prev in Thread] Current Thread [Next in Thread]