Bug 255054 - vtnet0: jng files to run: ngctl msg vtnet0: setpromisc 1: ngctl: send msg: Operation not supported
Summary: vtnet0: jng files to run: ngctl msg vtnet0: setpromisc 1: ngctl: send msg: Op...
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 13.0-STABLE
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-net (Nobody)
URL:
Keywords:
Depends on: 254343
Blocks:
  Show dependency treegraph
 
Reported: 2021-04-14 14:56 UTC by Tim Foster
Modified: 2021-04-21 23:29 UTC (History)
5 users (show)

See Also:
koobs: mfc-stable13?


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Foster 2021-04-14 14:56:36 UTC
Having recently upgraded to 13.0-STABLE, I found that none of my jng-enabled jails were coming up after boot.

root@puroto:/ # service jail start pupuru
Starting jails: cannot start jail  "pupuru":
ngctl: send msg: Operation not supported
jail: pupuru: jng bridge pupuru vtnet0: failed
.
root@puroto:/ #

In this case the jails.conf entry was:

pupuru {
  exec.prestart += "jng bridge pupuru vtnet0";
  exec.poststop += "jng shutdown pupuru";
}

Digging into what jng was doing, we were trying to switch the parent interface to promiscuous mode, failing, and then bailing out:

# ngctl msg vtnet0: setpromisc 1
ngctl: send msg: Operation not supported

Just commenting out that line in jng seemed to be sufficient, though I don't know
what side effects that might have. My jails all came up ok after that, and were
at least able to send/recv traffic, ping the jail host, etc.

    306                 # Set promiscuous mode and don't overwrite src addr
    307                 # ngctl msg $iface: setpromisc 1 || return
    308                 ngctl msg $iface: setautosrc 0 || return

I checked that my copy of /usr/sbin/jng wasn't significantly different to the one being shipped in /usr/share/examles/jails.
Comment 1 Kristof Provost freebsd_committer 2021-04-14 15:33:39 UTC
I'm pretty sure this has the same cause as #254343 , which is a vtnet bug, not a jail or bridge bug.