Cannot compile vmnet kernel module on kernel 6.4.10

[nikjoesta]

Problem

Building of vmnet module fails in newer kernel versions. For me it failed in kernel version 6.4.10-arch1-1. (Yes I use Archlinux)

I compiled with: 

vmware-modconfig --console --install-all

I got:

/tmp/modconfig-7XKYCP/vmnet-only/bridge.c: In function ‘VNetBridgeSendLargePacket’:
/tmp/modconfig-7XKYCP/vmnet-only/bridge.c:1413:11: error: implicit declaration of function ‘skb_gso_segment’; did you mean ‘tcp_gso_segment’? [-Werror=implicit-function-declaration]
1413 | segs = skb_gso_segment(skb, 0);
| ^~~~~~~~~~~~~~~
| tcp_gso_segment
/tmp/modconfig-7XKYCP/vmnet-only/bridge.c:1413:9: warning: assignment to ‘struct sk_buff *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
1413 | segs = skb_gso_segment(skb, 0);
| ^
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:252: /tmp/modconfig-7XKYCP/vmnet-only/bridge.o] Error 1
make[1]: *** [Makefile:2032: /tmp/modconfig-7XKYCP/vmnet-only] Error 2
make: *** [Makefile:117: vmnet.ko] Error 2
make: Leaving directory '/tmp/modconfig-7XKYCP/vmnet-only'
Unable to install all modules. See log for details.

Analysis

I figured out that in Linux kernel commit https://github.com/torvalds/linux/commit/d457a0e329b0bfd3a1450e0b1a18cd2b47a25a08 there was a change.

They moved code (including the function skb_gso_segment) from one "header" to another (<linux/inetdevice.h> to <net/gso.h>).

Commit message: "Move declarations into include/net/gso.h and code into net/core/gso.c"

Solution

In bridge.c one needs to add #include <net/gso.h>

How? I bet You are lazy... Assuming You have installed the .bundle and just want to compile... Try this:

# Cd to te dir where the vmware modules are.
cd /usr/lib/vmware/modules/source
# Unpack vmnet.
tar -xvf vmnet.tar
# Add the missing include (code is just there now)
sed -i '46 a#include <net/gso.h>' vmnet-only/bridge.c
# Backup original vmnet.tar
mv vmnet.tar vmnet.tar.original
# Pack the patched vmnet.
tar -cf vmnet.tar vmnet-only

Now if you are running

vmware-modconfig --console --install-all

again everything should work.

Disclaimer

Since it is a real pain to let You vmware guys know of a bug. I at least try to help people here. I couldn't figure a way to send You this...

Hope this helps ‌‌😀

[sknalodz]

Hi,

thanks for the asnwer.

i will try during the weekend.

[bdeyal]

See here:

https://communities.vmware.com/t5/Workstation-2023-Tech-Preview/Linux-Kernel-6-5-rc-vmmon-compile-fa...

[brandonarnold]

Why aren't VMWare engineers fixing this? This is a second module broken upstream. Now we need to do both `vmnet.tar` and `vmmon.tar`, because 2 things are broken.

[rakotomandimby]

AFAIK, VMWare workstation is known to work well with a set of supported Linux distribution https://kb.vmware.com/s/article/80807

VMware engineers will fix for those

[hwimmer]

We need to create a support group for this VMware Linux issue. Obviously VMware is not interested in fixing it as I have been dealing with it for over a year since 16.0 through 17.02

Same issues on kernel 6.5

[Technogeezer]

How about petitioning the Linux kernel developers to stop changing kernel interfaces and compliation systems on a whim. Trying to develop kernel modules for Linux is like trying to hit a moving target. 

[bdeyal]

I don't agree.

Linux kernel interfaces to user space will never change.

One can't use cutting edge SW and complain for glitches (latest and greatest kernel IS cutting edge)

[Technogeezer]

---

@bdeyal wrote:

I don't agree.

Linux kernel interfaces to user space will never change.

One can't use cutting edge SW and complain for glitches (latest and greatest kernel IS cutting edge)

---

I did not say user space. Kernel space is a different animal We can debate over what's "cutting edge" but if you look over the patch sets that mkubecek has delivered when LInux decides to change things you'll see what I mean. Distro xyz switches kernels, and oops. VMware modules don't compile any more since Linux changed things up that used to work fine. 

One can argue as to how much attention VMware's developers pay to changing Linux kernels between release, but It has to be time consuming and not predictable when Linus decides that things should change. 

[hwimmer]

Then why doesn't VMware break for a Windows update. I'm on the LTS version of Ubuntu. If I was on a beta sure.

These issues have been here in VMware 16 and nowhere does VMware seem to care to fix or even post instructions on how to fix. 

Thank God for that Kubecek guy for posting these updates. Why isn't VMware doing it?

This is simple for them to fix and test new versions and kernels. There is some underlying issue that could at least be addressed.

I am glad to see people discussing. I gave up on this forum long ago when I first looked for a solution. 

[Technogeezer]

Windows doesn’t break because Microsoft doesn’t change things like Linux does. Microsoft has had a history of maintaining compatibility for drivers where Linux does not.

Yes it is fair to ask why VMware can’t keep up though. VMware seems like they want to treat Linux like Windows where OS releases are on a release schedule from a single vendor instead of multiple release schedules from multiple vendors. Their current strategy works for distros that have long lifetimes for kernel versions (e.g. RHEL or SLES) but not so well for others with short lifetimes (Ubuntu non LTS versions, Fedora) or rolling distributions. Again, the issue is exacerbated by Linux’s propensity to change things more frequently than other operating systems  

Perhaps for Linux they should focus more on kernel versions than individual distros. 

Then there is the reality of agile development strategies, limited number of scrum teams, prioritizing of work, sprints, and having a free team to do the work. 

[hwimmer]

Then they should be extremely clear about what they support. Honestly without the kucerek got and trick, I wonder if it runs without issues on any Linux machine and if so, what is different.

If VMware said they only support certain distro and kernels, I would stick with that. 

[louyo]

https://kb.vmware.com/s/article/80807?lang=en_US&queryTerm=workstation%20pro%20operating%20systems

Last listed version of Fedora is 36, now shipping 38. 

I have been running WS on Debian and LMDE for many years without compiling issues.

Bleeding edge creates challenges and is not for the faint of heart. People like Kubecek make it much easier. 

[hwimmer]

Did you ever find a solution?

[brandonarnold]

He describes it. You need to unpack vmnet.tar, edit a file, and pack the tarball up again. On the latest arch build you also need to edit vmmon.tar similarly, and there is a post in this same forum for that, too.

[hwimmer]

I was of the understanding that the fix didn't work for him. I used GRUB and set my boot version back to 6.4 instead of 6.5 so the kubecek fix worked. I posted this error on kubecek's github and had some guy list another way to fix it (it is similar, adding in some include files into the C code) but the kubecek posted something about another fix and this wasn't the best way. I am wondering when he will incorporate the fix into the downloads but didn't get an answer on that. I think in the future I am going to have to test this somewhere before putting it on my production work machine because I can't be without VMWare because I run all my work stuff on windows VMs.

We need a support group for this stuff. I wonder if anyone would be interested in an email chain or something.

I don't understand why VMware doesn't seem to care...I have been doing the kubecek fix since version 16...

https://github.com/mkubecek/vmware-host-modules/issues/222