Boot registers protocol family 40, which is not in configs

[Blair Houghton]

I noticed this line in the system log after boot:
"May 14 14:41:08 ubuntu kernel: [ 8.677878] NET: Registered protocol family 40"
I tried to find out what protocol that was, and eventually determined that the IANA thinks it's the IL protocol, which is deprecated and unusual in any case. Protocol number 40 doesn't appear in the expected config or alias files (for modprobe in /etc or /etc/modprobe.d/). Enabling a dead protocol without being told seems to be a thing an OS shouldn't be doing.

More context for the log line is below:
...
May 14 14:41:08 ubuntu vmsvc[1607]: [ warning] [GLib-GObject] Attempt to add property ToolsCoreService::tcs-app-ctx after class was initialised
May 14 14:41:08 ubuntu vmsvc[1607]: [ warning] [GLib-GObject] Attempt to add property ToolsCoreService::tcs-prop-thread-pool after class was initialised
May 14 14:41:08 ubuntu kernel: [ 8.677878] NET: Registered protocol family 40
May 14 14:48:36 ubuntu dbus[465]: [system] Activating service name='org.freedesktop.UPower' (using servicehelper)
May 14 14:48:36 ubuntu dbus[465]: [system] Successfully activated service 'org.freedesktop.UPower'
...
---
ApportVersion: 2.14.1-0ubuntu3.19
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: blair 2640 F.... pulseaudio
CurrentDesktop: Unity
DistroRelease: Ubuntu 14.04
HibernationDevice: RESUME=UUID=38a747e6-6da8-4ab9-b2c5-d7613992fbfb
InstallationDate: Installed on 2012-05-15 (1464 days ago)
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64 (20120425)
IwConfig:
 eth0 no wireless extensions.

 lo no wireless extensions.
Lsusb:
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
 Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
 Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
MachineType: VMware, Inc. VMware Virtual Platform
Package: linux (not installed)
ProcFB: 0 svgadrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-86-generic root=UUID=b4002a34-68be-4c40-a549-17edb4a1f7e9 ro quiet splash
ProcVersionSignature: Ubuntu 3.13.0-86.130-generic 3.13.11-ckt39
RelatedPackageVersions:
 linux-restricted-modules-3.13.0-86-generic N/A
 linux-backports-modules-3.13.0-86-generic N/A
 linux-firmware 1.127.22
RfKill:

Tags: trusty
Uname: Linux 3.13.0-86-generic x86_64
UpgradeStatus: Upgraded to trusty on 2014-04-26 (753 days ago)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 05/20/2014
dmi.bios.vendor: Phoenix Technologies LTD
dmi.bios.version: 6.00
dmi.board.name: 440BX Desktop Reference Platform
dmi.board.vendor: Intel Corporation
dmi.board.version: None
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 1
dmi.chassis.vendor: No Enclosure
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnPhoenixTechnologiesLTD:bvr6.00:bd05/20/2014:svnVMware,Inc.:pnVMwareVirtualPlatform:pvrNone:rvnIntelCorporation:rn440BXDesktopReferencePlatform:rvrNone:cvnNoEnclosure:ct1:cvrN/A:
dmi.product.name: VMware Virtual Platform
dmi.product.version: None
dmi.sys.vendor: VMware, Inc.

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1581890

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Joseph Salisbury (jsalisbury)]

Did this issue start happening after an update/upgrade? Was there a prior kernel version where you were not having this particular problem?

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.6 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-yakkety

[Blair Houghton (bph)]

apport information

[Blair Houghton (bph)]

apport information

[Blair Houghton (bph)]

apport information

[Blair Houghton (bph)]

apport information

[Blair Houghton (bph)]

apport information

[Blair Houghton (bph)]

apport information

[Blair Houghton (bph)]

apport information

[Blair Houghton (bph)]

apport information

[Blair Houghton (bph)]

apport information

[Blair Houghton (bph)]

apport information

[Blair Houghton (bph)]

apport information

[Blair Houghton (bph)]

apport information

[Blair Houghton (bph)]

apport information

[Blair Houghton (bph)]

As requested.

[Blair Houghton (bph)]

(In reply to comment #2 above)

I do not recall that this was seen immediately after an update. The machine has been running 14.04 (upgraded from 12.04) almost since 14.04 was released.

The anomaly was noticed only by chance; I was browsing the logs for other information and simply happened to get curious about that particular line, then discovered just how curious the line was on its own.

I can not run alternate configurations or test kernels on this installation without destabilizing the system configuration beyond my risk tolerance.

However, what I might be able to do is set up another VM and install another instance of 14.04 and then test it with the Mainline kernel. But I don't know enough about selecting versions to know if I'm getting the 14.04 that should exhibit the problem (is there only one rev of 14.04? if not, which should I start with to best replicate what I have now? to what level of update? Is that determinable from the data I've already uploaded?). Could you take a look and post a link to the proper Ubuntu config that I can use as a baseline in a clean VM, and then I'll see if the bug is there, and if it is, then I'll use the link you have provided to check the mainline kernel also.

[Kenneth R. Crudup (kenny-panix)]

"net-pf-40" is VMWare- they're apparently using it as a sort of IPC between VMs and it gets installed when the vmnet(?) module loads.

(Old bug, I know, but this was the first search result, so I'd figured I should answer this.)