Fedora 26 (kernel 4.11.9) and VMWare Workstation 12.5.7

I just upgraded Fedora 25 to Fedora 26 and of course there was a problem with VMWare Workstation. If you try to start vmware binary, it just silently fails. Anyway, I managed to find a solution here. In essence it is necessary to replace two share libraries and then manually compile vmmon and vmnet modules. The reason for this is that on Fedora GCC 7.1 is used which is a newer compiler that used to compile VMWare. So, to replace libraries, type:

# cp -r /usr/lib/vmware-installer/2.1.0/lib/lib/libexpat.so.0 /usr/lib/vmware/lib
# cd /usr/lib/vmware/lib/libz.so.1
# mv -i libz.so.1 libz.so.1.old
# ln -s /usr/lib64/libz.so.1 .

And to compile vmmon and vmnet you have to go into /usr/lib/vmware/modules/sources directory and unpack vmnet.tar and vmmon.tar files. Then, in each of them, issue make command. Finally, files ending with .ko move to /lib/modules/`uname -r`/misc (create it if necessary) and then run 'depmod -a' command. I also had to manually load those modules with 'modprobe vmnet' and 'modprobe vmmon' commands.

The only problem I noticed so far is that after inserting vmnet kernel module network interfaces are not automatically created. To fix that just run vmware-netcfg command and save configuration. After that, everything should be OK.

Fedora 25, kernel 4.9 and VMWare Workstation 12.5.2

Well, after upgrading Fedora 25 which included kernel 4.9.5, VMWare Workstation stopped working again! The fix is easy, even though it annoying to constantly have to patch something in VMWare. Anyway, the procedure - taken from here - is:

1. Switch to root account.
2. Go to /usr/lib/vmware/modules/source.
3. Make backup of files vmmon.tar and vmnet.tar.
4. Unpack those files using 'tar xf' command.
5. Patch file vmnet-only/user_if.c, i.e. you have to open it in you favorite text editor and in function UserifLockPage() that's around line 113 change the following part:
   

   #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 6, 0)
       retval = get_user_pages(addr, 1, 1, 0, &page, NULL);
   #else
       retval = get_user_pages(current, current->mm, addr,
                   1, 1, 0, &page, NULL);
   #endif

   with the following:
   

   #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 9, 0)
        retval = get_user_pages(addr, 1, 0, &page, NULL);
   #else
   #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 6, 0)
        retval = get_user_pages(addr, 1, 1, 0, &page, NULL);
   #else
        retval = get_user_pages(current, current->mm, addr,
                    1, 1, 0, &page, NULL);
   #endif
   #endif

6. Then, in file vmmon-only/linux/hostif.c in function HostIFGetUserPages() that's around line 1158, change the following
   

   #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 6, 0)
      retval = get_user_pages((unsigned long)uvAddr, numPages, 0, 0, ppages, NULL);
   #else
      retval = get_user_pages(current, current->mm, (unsigned long)uvAddr,
                              numPages, 0, 0, ppages, NULL);
   #endif

   with
   

   #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 9, 0)
      retval = get_user_pages((unsigned long)uvAddr, numPages, 0, ppages, NULL);
   #else
   #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 6, 0)
      retval = get_user_pages((unsigned long)uvAddr, numPages, 0, 0, ppages, NULL);
   #else
      retval = get_user_pages(current, current->mm, (unsigned long)uvAddr,
                              numPages, 0, 0, ppages, NULL);
   #endif
   #endif

7. Create new vmmon.tar and vmnet.tar using the following commands:
   

   tar cf vmnet.tar vmnet-only
   tar cf vmmon.tar vmmon-only

8. Start vmware as you would normally start it. This will trigger module compilation and everything should work.

Note that you are doing everything at you own risk! :)

Fedora 24, kernel 4.7 and VMWare Workstation 12.1.

As usual, when Fedora upgrades kernel to a new major version VMWare stops working. In this particular case my Fedora was upgraded to Linux kernel version 4.7.2. The fix I found is the following one:

# cd /usr/lib/vmware/modules/source
# tar xf vmnet.tar
# mv vmnet.tar vmnet.old.tar
# sed -i -e 's/dev->trans_start = jiffies/netif_trans_update\(dev\)/g' vmnet-only/netif.c
# tar cf vmnet.tar vmnet-only
# vmware-modconfig --console --install-all

And that was it!

Note that this works if you upgraded from linux kernel version 4.6. In case you've upgraded from some earlier version, you'll have to patch it first for those version. Here is how to patch VMWare Workstation to work with Linux kernel version 4.6.

Quick note about Fedora 24 and VMWare Workstation 12.1

I just updated Fedora 24 from update-testing repository and that pulled Linux kernel 4.6. Well, as usual, VMWare Workstation needed some patching in order to work. Luckily, I quickly found a fix on VMWare forums. Note that at the end of the thread there is a script you can use to automatically patch necessary files. But, be careful, I didn't try it!

Anyway, after patching, run:

vmware-modconfig --console --install-all

and that should be it!

Just as a sidenote, turns out that the same info I found on Arch Wiki page devoted to VMWare. And that page is full of information so you should bookmark it and whenever you have a problem with VMWare check there.

Edit 20160707: The script mentioned above had some errors in it. Here is the fixed version.

Fedora 23 and VMWare Workstation 12.1

In the post about VMWare 11 I wrote about the problem that newest Fedoras are compiled using gcc5 which breaks C++ ABI thus making VMWare unrunnable. Several commenters suggested workarounds of which the simplest and most elegant solution is by user Andy who suggested that before running vmware command the environment variable LD_PRELOAD should be set to /usr/lib/vmware/lib/libglibmm-2.4.so.1/libglibmm-2.4.so.1, i.e. you should execute the following command:

export LD_PRELOAD=/usr/lib/vmware/lib/libglibmm-2.4.so.1/libglibmm-2.4.so.1 /usr/bin/vmware

This works for VMWare 12 as it did for VMWare 11.

Now, at some point it will happen that VMWare notifies you about newer version and offers you to download it and install it. But, you won't be able to run update and you'll receive the following error message:

/tmp/vmis.lLCMq3/install/vmware-installer/vmware-installer: line 56: 14595 Aborted (core dumped) VMWARE_INSTALLER="$VMWARE_INSTALLER" VMISPYVERSION="$VMISPYVERSION" "$VMWARE_INSTALLER"/vmis-launcher "$VMWARE_INSTALLER"/vmware-installer.py "$@"

What you have to do in that case is to manually download update and start it without defining LD_PRELOAD variable. Note that if you changed /usr/bin/vmware after upgrade you'll have to change it again.

Intercepting and redirecting traffic from VMWare Workstation

After some time I decided to try again sslstrip (note that there is enhanced version of sslstrip on GitHub). First, I tried to do everything on a single host, i.e. sslstrip is running on a same machine as is browser whose traffic I wanted to intercept. It turned out that this isn't so easy because there is no rule for iptables that would allow me to differentiate traffic of Firefox and SSLStrip.  Because of that fact, if I were to redirect traffic that tries to go the port 80 on the Internet so that Firefox's traffic goes to SSLStrip, I would also redirect traffic from SSLStrip to itself creating infinite loop. For some reason filtering based on PID, a.k.a. process identified, isn't possible. It used to be possible, but then it was removed. There are two solutions to overcome the problem of running everything within a single OS:

1. Run SSLStrip as a separate user (or Firefox as a separate user). IPTables allows match on UID, or
2. Run Firefox or SSLStrip in a separate network namespace.

Instead, I decided to use VMWare Workstation (I had a version 11.1.2 when I wrote this post) and to intercept its traffic. The reason I chose VMWare was that I had one virtual machine already running at hand. But it turned out that it isn't so easy, either. In the end, the problem was caused by my lack of understanding on how VMWare Workstation works. Additional problems were caused by delays that happen after changing network parameters, i.e. it takes time that the changes take effect and thus to be observable.

So, the main problem was that traffic generated by the virtual machine isn't intercepted by standard Netfilter rules when default configuration is used along with NAT networking. To see why, look at the following figure which show logical network topology:

The figure shows that traffic from Guest OS goes to virtual switch (vswitch) and then to the external network bypassing Host's netfilter hooks. So, even though there is vmnet8 in the host OS and traffic can be seen on the given interface, it doesn't go through standard NETFILTER hooks. Actually, vmnet8 is Host's interface to virtual switch. Also, if you take look at how the network is configured within Guest OS you'll note that the gateway address is set to x.y.z.2 while IP address of vmnet8 is x.y.z.1.

The behavior when the gateway is x.y.z.2 is:

1. If you try to filter packets going from Guest OS to the Internet using iptables you won't succeed. I tried to put DENY rule in filter table of all chains and it didn't work. Actually, nothing will work as netfilter hooks aren't called at all.

So, the trick, in the end, is to change default GW on Guest OS so that traffic is routed to HostOS where you can then manipulate it. In that case you'll have to also:

1. enable IP forwarding (/proc/sys/net/ipv4/ip_forward) on Host OS.
2. Activate NAT or masquerade for outgoing traffic if you want guest machine to communicate with the outside world!

Note that you can observe some delay between setting some parameter/behavior (like adding NAT rule) and the time the behavior starts to be observable, i.e. it works. Anyway, at this point you can redirect network traffic, in other words, you can then use netfilter hooks.

So, to finish this post, you should start SSLStrip and add the following rule on Host OS:

iptables -A PREROUTING -t nat -i vmnet8 -p tcp \
        --dport 80 -j REDIRECT --to-port 10000

And then try to access, e.g. http://www.facebook.com. Be careful that you didn't previously access Facebook because in that case browser will know it must use https and it won't try to use http, even if you typed it in the URL bar. If this happens than just clean the complete browser history and try again.

Problem with automatic VMWare upgrade from 9.0.1 to 9.0.2

VMWare Workstation checks upon startup if there are new version of the software, and if it is then it asks you if you want to upgrade. In case automatic checking is disabled, there is an option under the Help menu that allows manual triggering of that process. For some time now I was getting notification about free upgrade from 9.0.1 to 9.0.2 which I would enable, but which never finished for unknown reason. Instead of trying to figure out what was wrong I decided to try to do it manually. In the end, it turned out to be a semi-manual process. Namely, when I received an error message about being unable to upgrade I looked where downloaded files are. It turned out that they are stored in /tmp directory but that they have UUID like names, i.e.:

$ ls -l
total 381768
-rw-r--r--.  1 sgros zemris  66211840 Kol 29 13:28 06dd4484-5c02-4c5d-992c-ff705703e6cb
-rw-r--r--.  1 sgros zemris  11253760 Kol 29 13:29 1cf5e724-f7d4-4f24-b484-30ebb16d593e
-rw-r--r--.  1 sgros zemris  61777920 Kol 29 13:29 2007e14d-3593-416f-b60e-08c4cd18693a
-rw-r--r--.  1 sgros zemris 232693760 Kol 29 13:31 364c998b-8b3b-4cfd-a2dc-67352a3eb082
-rw-r--r--.  1 sgros zemris  13096960 Kol 29 13:31 4b7424a6-e114-4832-be21-f0a3acf8c24b
-rw-r--r--.  1 sgros zemris     81920 Kol 29 13:31 8a8d105f-fd3d-404a-afc9-28411d6566fe
-rw-r--r--.  1 sgros zemris   5795840 Kol 29 13:31 d969898b-30bb-4c6d-bf45-5a7d52918359

Now, using file command it was easy to determine that they are actually tar archives so. So, I created new directory and unpacked all those files there. What I've got was one file with extension bundle and several files with an extension component.

# ls -l
total 390904
-rw-r--r--. 1   201    201      1161 Vel 26  2013 descriptor.xml
-rw-r--r--. 1   201    201  15207519 Vel 26  2013 vmware-tools-freebsd-9.2.3-1031769.x86_64.component
-rw-r--r--. 1   201    201  66202162 Vel 26  2013 vmware-tools-linux-9.2.3-1031769.x86_64.component
-rw-r--r--. 1   201    201     76615 Vel 26  2013 vmware-tools-netware-9.2.3-1031769.x86_64.component
-rw-r--r--. 1   201    201  13088243 Vel 26  2013 vmware-tools-solaris-9.2.3-1031769.x86_64.component
-rw-r--r--. 1   201    201  61771010 Vel 26  2013 vmware-tools-windows-9.2.3-1031769.x86_64.component
-rw-r--r--. 1   201    201  11247429 Vel 26  2013 vmware-tools-winPre2k-9.2.3-1031769.x86_64.component
-rwxr-xr-x. 1 sgros zemris 232680125 Vel 26  2013 VMware-Workstation-9.0.2-1031769.x86_64.bundle

The bundle type file is actually an installer for a new version of VMWare, so I've run it as a root user and it installed new version of VMWare. The component files, on the other hand, have to be installed using vmware-install tool, e.g. to install vmware-tools-windows-9.2.3-1031769.x86_64.component file, execute the following command as a root user:

vmware-installer --install-component=vmware-tools-windows-9.2.3-1031769.x86_64.component

The same command has to be repeated for the other files too. But, note that those files are optional, depending what you've running. You can check which components you have installed using vmware-installer command with an option -t, i.e.
vmware-installer -t
And that was it. Of course, before being able to run VMWare I had to patch it again. But that was it.

VMWare Workstation DNS server...

I just figured out very interesting thing about DNS server used by VMWare virtual machines. It uses /etc/hosts file on host machine to resolve names. The trick is that those names have to have .localdomain suffix. So, for example, if you have the following entry in /etc/hosts file of host machine:

1.1.1.1        test

and then you ask with nslookup within guest machine for that name, you'll receive:

# nslookup test
Server: 192.168.178.2
Address: 192.168.178.2#53

Name: test.localdomain
Address: 1.1.1.1

Note that localdomain is automatically appended. This is specified with search directive in /etc/resolv.conf of guest machine (there is a line search localdomain or something similar). Otherwise, without localdomain, the name wouldn't be found:

# nslookup test.
Server: 192.168.178.2
Address: 192.168.178.2#53

** server can't find test.: NXDOMAIN

In this example, the dot I appended after the name prevents anything from being appended and only name test is looked for.

To conclude, the rule is simple. If the name to be looked up ends with localdomain, then it is searched within /etc/hosts file of the host operating system.

I discovered this by accident. Namely, I did nslookup within guest machine expecting to receive error message about non-existing host name, but I got good response!? At first, I was confused, and it took me several minutes to figure out what's happening. Well, so the things go when you don't read manuals. ;)

VMWare Workstation on Fedora 17...

Today, when I started VMWare Workstation, it notified me that there is a free security update. Since it is advisable to update whenever there are security issues, I approved it, but of course that after update I had a problem starting VMWare workstation. Since there are constantly problems with VMWare and Fedora I finally decided to track everything I had to do in this post. In other words, this post will be updated whenever I have to do something to VMWare Workstation to get it to work.

Ok, as I said, on a fully updated Fedora 17 (kernel-3.4.2-4.fc17.x86_64) when a new VMWare Workstation 8.0.4 is installed (or updated) it can not configure itself because of errors in kernel modules. As I wrote this I wasn't able to find a patch that fixes everything in one step, but I managed to combine two fixes that allowed VMWare to start. First, I had to apply patch for 8.0.3 that fixed vmnet.tar file. To do that I also had to modify a bit the script distributed with patch so that it accepts the fact that I'm using a newer version of VMWare (i.e. 8.0.4 instead of 8.0.3). Then, I had to apply a small fix for vmblock.tar that I wrote about in other post. Finally, I tried to start VMWare Workstation but it failed again?! After a bit poking, I realized  that there were dangling processes/modules so I had to kill all VMWare processes, remove modules, and that start succeeded. Of course that I could also restart the laptop, but because of the number of open windows I have, that wasn't an option. :)

When I did all that, then I found out that there is a patch that does all this, i.e. those two steps but combined, but it is for VMWare Workstation 8.0.2, which means you still have to poke a bit in script that applies a patch. And finally, this blog seems to be a good place to look when you have some problems with VMWare (and VirtualBox) and newer versions of kernel.