On Wed, 2005-08-24 at 19:23 -0700, Francois Rioux wrote: > I don't understand why this doesn't work. Is it Windows preventing the > write is the exchange this a limitation in QEMU or in SLiRP? As I > understand it SLiRP translates some tcp headers and acts as a firewall > preventing incoming calls but autorizes outgoing calls from the guest > out. That's why web browsing works in user network mode. Should't > file transfer work too? Is the network file sharing protocol more > complex than that for writes? Or is that rather a Windows security > issue? >
Could be an authentication issue. Probably you should be typing in the fully qualified username and password into the net use command net use z: \\10.0.2.2\MyShare /USER:domain\username password or just ctrl-esc->Run-> \\10.0.2.2\MyShare<ENTER> and type the fully qualified username and password at the prompt. After making the share connection, what do you get as output when you just type net use<ENTER> Knowing a bit about the NetBT protocol and the stunning quality of the Slirp NAT code I'm kind of surprised that it works at all. CIFS requires some assistance from an application level gateway (ALG) to work well across a NAT. In the direction you're going (guest to host) there are less problems, but I think there are still NAT issues with browsing and name binding; but then you're using IP addresses rather than names so it may not matter. If none of the above works, I'd look at it with a snooper on either side of the connection (in the guest and on the host), and see what packets are getting dropped (shows up on one side of snooper but not the other) or improperly NATed (private IP addresses leak out either in headers or in packet payload onto the host network). You might also try port forwarding the NetBT (NetBIOS over TCP/IP, aka CIFS) TCP and UDP ports. See RFCs 1001, 1002 for port numbers. -- John. _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
