VMWare Player guest OS and Host Kubuntu cannot SSH into each other

Bug #105697 reported by lefty.crupps on 2007-04-11
34
Affects Status Importance Assigned to Milestone
vmware-player (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: vmware-player

Maybe the same as this?
https://bugs.launchpad.net/ubuntu/+source/vmware-player/+bug/96445

Running Kubuntu 7.04h4 and VMWare Player; the guest VM is Debian Etch.

I can ping both machines (real and virtual) from the other. I can ping both and SSH into both from a third machine. I can ping and SSH into that third machine from both my real (K7.04) and virtual (Etch) machines. But I cannot SSH from my Kubuntu into virtual Etch, nor SSH from Virtual Etch into my real Kubuntu.

Download full text (6.0 KiB)

I have 3 ubuntu feisty machines here that all run vmware server. I installed vmware server as shown in the fourth post down on this link:

     http://ubuntuforums.org/showthread.php?t=338305&page=2

I ran exactly what the poster said with the exception of marking /etc/init.d/vmware executable.

Of these three machines one has the problem mentioned in this bug report. The machine that is giving me problems had at one point been running dapper, which was updated to edgy some time ago, and then to feisty, whereas the other computers came from clean installs of edgy to feisty. There are also differences in the packages and services installed on these machines as well.

The problem is exactly as the bug submitter mentions, but occurs between all vmware guests and the vmware host. The host and client can talk to all other machines on the network without and noticable problems. I can ssh from a vmware guest, to another physical machine, to the vmware host fine. I can do the reverse just fine. I can ssh from the host machine to the host machine without issue. I can ssh from the guest machine to any other guest machine with no problems. I seem to have general network connectivity inbetween the guest and the host(ie. they can ping each other, and a nmap inbetween the two hosts appears to yield proper results.

Depending on if the connection is coming from the vmware guest to the host or the vmware host to a guest the ssh -vvv looks a little different. Here is my output for the ssh daemon on a netbsd vmware guest, and the ssh -vvv output for the feisty vmware host that has been causing me problems:

SERVER:
(root@deathgate:~)-> /usr/sbin/sshd -d
debug1: sshd version OpenSSH_3.9 NetBSD_Secure_Shell-20061016
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug1: fd 6 clearing O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 6 out 6 newsock 6 pipe -1 sock 9

CLIENT:
(thrift@Epoch:~)-> ssh -vvv deathgate
OpenSSH_4.3p2 Debian-8ubuntu1, OpenSSL 0.9.8c 05 Sep 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to deathgate [192.168.0.77] port 22.
debug1: Connection established.
debug1: identity file /home/thrift/.ssh/identity type -1
debug3: Not a RSA1 key file /home/thrift/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: miss...

Read more...

Changed in vmware-player:
status: Unconfirmed → Needs Info
Mark Reitblatt (mark-reitblatt) wrote :

Thrift: Ubuntu doesn't ship vmware-server, so we can't support those problems here. Try asking for help on those problems @ the VMware forums.

Thrift (thrift24) wrote :

Well I thought the problem might be related to the vmnet kernel module, which came from the package vmware-server-kernel-modules, which in turn came from one of the Ubuntu repositories. It was working until I updated to feisty anyway.

Also I didn't really start the thread, lefty.crupps did. So anyway, I'm sure I'll find the solution to the problem with time, I just thought if the problem was coming from the feisty side of things more information about the problem might help lefty, myself, or someone else.

Thanks

Thrift (thrift24) wrote :

I don't know about the original poster, but I have fixed this issue on my machine.

Apparently with feisty there is an update to the e1000 driver that enables some functionality on the card that vmware doesn't take kindly too. I couldn't find any options with modinfo that would make e1000 act like it used too. The card works great for everything but vmware.

I simply installed a new card and disabled the onboard card in bios, edited /etc/iftab with the new cards mac address for eth0, rebooted and the issue was gone.

DaMoGan (dmgdsm) wrote :

I can confirm this. VMWare host is 7.04 Kubuntu, VMWare guests are various Linux and Windows versions. All have the aforementioned problem of being unable to ssh from/to host <-> guest, or complete any TCP connection. (Well, the connection seems to be established, but nothing else seems to happen).

Félix Velasco (felix-velasco) wrote :

Same trouble here, networking doesn't properly works between feisty host and any guest. I can ping both ways, but neither ssh nor http works.

However, my ethernet card uses the 8139too driver, and I'm using Ubuntu, not Kubuntu.

Thrift, which card do you use now?

Thrift (thrift24) wrote :

To clarify what my issue was and it's solution. I had two problems:

Port 902 was closed which kept remote users from connecting to vmware server:
   This occured because xinetd had somehow gotten removed during the upgrade to feisty. Installing xinetd and restarting the service fixed that.

Host and Guest could talk to each other when using non-TCP based services, but when TCP based services(SSH) were used the connection failed:
   I believe from looking at the vmware forums, that this can happen with any host operating system if the driver for your network card has some kind of TCP Offload Engine or something like that. I really have no idea. I assume that the feisty kernel has an updated e1000 module which somehow engaged that engine or something like it. I could not figure out how to disable the new functionality. My work around was to disable the onboard e1000 based NIC, plug in a generic card with an ADMtek Comet chipset(I think cards with this issue are the exception not the rule), edit my /etc/iftab, reboot, and everything worked as it should.

Hope that helps someone.

Mikael Frykholm (mikael) wrote :

I can confirm that
sudo ethtool -K eth0 sg off rx off tx off tso off
worked here on a 09:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5752 Gigabit Ethernet PCI Express (rev 02)
with vmware server from ubuntu commersial repository.

DaMoGan (dmgdsm) wrote :

Thanks Mikael, that command worked for me as well! For the record, I have (from lspci output):

00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)

Félix Velasco (felix-velasco) wrote :

I'm having this problem in two out of three feisty pc's I'm using. Both of them have Realtek-based ethernet cards.
from lspci:
02:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
and
02:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)

The working card I can't access right now, but I'm sure has a Broadcom card, and it works properly.
When I try the suggested command, the pc refuses to do it with the following output:

felix@mail:~$ sudo ethtool -K eth0 sg off rx off tx off tso off
Cannot set device rx csum settings: Operation not supported
felix@mail:~$ sudo ethtool -K eth0 sg off tx off tso off
Cannot set device tx csum settings: Operation not supported
felix@mail:~$ sudo ethtool -K eth0 sg off tso off
Cannot set device scatter-gather settings: Operation not supported
felix@mail:~$ sudo ethtool -K eth0 tso off
Cannot set device tcp segmentation offload settings: Operation not supported

As you can see, I had to remove parameters one by one (well, two each time, really) to get the next message. It seems the 8139too driver won't support that operations....
So, the problem is still here for me.

drink (drink) wrote :

Well, this just solved my problem.

Please note that I am now using the vmware-server package from Ubuntu. Before, I DID NOT HAVE THIS PROBLEM. I have NOT gone back however and tested to see if the latest version will fix the problem.

The Ubuntu vmware-server package is behind now (1.0.2 vs 1.0.3). I was excited because of the package's existence, but now it's looking like using it is a bad idea because it is behind the program version.

Anyway I used the command "sudo ethtool -K eth0 sg off rx off tx off tso off" and what do you know, it worked. I can now open connections between the host and linux guests. BTW my Windows 2000 guests have had no problem all along. And the Linux guests don't work whether you have vmware tools installed or not.

Maybe I should be creating a virtual interface, bridging to THAT, and then bridging THAT to my ethernet, to avoid problems like this?

Is there someplace I can put the ethtool commandline to make it permanent? I mean, I can think of several places to do it, but which one is best?

Thrift (thrift24) wrote :

I would think /etc/rc.local would be a good place to put it.

Dave Long (longwave) wrote :

This also happens on vmware-server in Feisty with this onboard network controller:

01:0b.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 13)

"sudo ethtool -K eth0 sg off rx off tx off" fixes it; adding "tso off" gives "Operation not supported", but it works fine without.

TiagoCruz (tiagocruz) wrote :

I have this problem too, but only on ubuntu using vmware-player from ubuntu repositories.

I have one VM running Mandriva, and I can't complete one ssh session when I'm using Ubuntu 7.04 on host machine and using "Bridged" connection. When I'm using NAT, I can complete SSH (sometimes...)

The same machine, works as well when I'm using VMware Player on Mandriva Host, so I think that the vmware-player from Ubuntu have some problem.

My virtual netcard is one Intel 82455EM (using e1000 module) and the tip of ethtool works here on my HOST Machine.

Tom Seago (tom-tomseago) wrote :

I can confirm this same problem. I am using a currently up-to-date Feisty installation on both the host and the guest. The host has the e1000 driver and when the offload engine is enabled, I can not connect with ssh between the host and the guest even though other machines on the network can connect to the guest.

I saw identical connection problems with LDAP over SSL as well. Specifically that an ldap client on the host could not connect to an LDAP server on the guest.

Disabling the offloading engine by using ethtool is the trick to make it work.

miasma (jmjm-iki) wrote :

I have a similar problem. Connections from all clients to outside world (LAN/internet) work. Connections to clients via NAT/host-only interfaces work too. But when using bridged mode, none of the services on the client respond to any queries (html, ssh, ...). I'll try the ethtool trick next week.

Peng Deng (d6g) wrote :

I confirm this problem. I am running VMWare Server 1.0.3 from Feisty commercial repository. Both host and guest system are running Ubuntu feisty, they can ping each other but all the other services (http/ftp/ssh ....) are not accessible between them.

The command "sudo ethtool -K eth0 sg off rx off tx off tso off" mentioned by drink can solve this problem. Thanks!

Launchpad Janitor (janitor) wrote :

[Expired for vmware-player (Ubuntu) because there has been no activity for 60 days.]

Darren Worrall (dazworrall) wrote :

Confirmed on 7.04 AMD64 using VMware server 1.0.3 from the commercial repository. I have an onboard e1000 and I cannot use any TCP based connections until I execute 'sudo ethtool -K eth0 sg off rx off tx off tso off' on the host.

I've put the command in /etc.rc.local for now so the change persists through reboots.

ubuntu 7.04 and vmware-server 1.0.3-1 from commercial repository

nVidia CK8S ethernet controller, with various offloads.
disabled offloads and tcp and udp traffic ok betweeen vmware guests and linux server hosting vmware-server started working

seems like vmware-server 1.0.4 is out at vmware, but not packaged yet, maybe this will help though the release notes aren't promising

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers