Project

General

Profile

Bug #15817

Plugins not obtaining an IP from DHCP

Added by aloisio mello over 3 years ago. Updated about 3 years ago.

Status:
Closed: Not To Be Fixed
Priority:
Expected
Assignee:
John Hixson
Category:
Middleware
Target version:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:

Asus H81M-K Bios 1103
i3-4130 @ 3.40 Ghz
RAM 8192 MB/DDR3 1600 Mhz

ChangeLog Required:
No

Description

As requested, opening a new ticket and assigning to John.

Build FreeNAS-9.10-STABLE-201605240427 (64fcd8e)
Platform Intel(R) Core(TM) i3-4130 CPU @ 3.40GHz
Memory 8034MB
System Time Mon Jun 06 13:22:17 EDT 2016
Uptime 1:22PM up 27 mins, 0 users
Load Average 0.28, 0.34, 0.32

Notes:
1 - Fresh 9.10 install
2 - Regular jail obtained IP from DHCP Server
3 - Installed transmission and virtualbox - none obtained an IP from DHCP server. Below details from transmission plugin showing no IP (after jail restart) and getting an IP with dhclient
4 - Attached debug is public as no private information used on test box intallation

root@transmission_1:/ # ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1 netmask 0xff000000
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
epair1b: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8<VLAN_MTU>
ether 02:ff:70:00:06:0b
inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
nd6 options=9<PERFORMNUD,IFDISABLED>
media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
status: active
root@transmission_1:/ # dhclient epair1b
DHCPDISCOVER on epair1b to 255.255.255.255 port 67 interval 8
DHCPOFFER from 10.10.10.1
DHCPREQUEST on epair1b to 255.255.255.255 port 67
DHCPACK from 10.10.10.1
bound to 10.10.10.112 -- renewal in 3600 seconds.
root@transmission_1:/ #

I_can_confirm_what_Aloisio_describes_in_his_PDF.png (69.3 KB) I_can_confirm_what_Aloisio_describes_in_his_PDF.png Matt Kessler, 08/18/2016 04:03 PM
disabling_IPv6_Autoconfigure.png (40.3 KB) disabling_IPv6_Autoconfigure.png disabling IPv6 Autoconfigure Matt Kessler, 08/19/2016 01:05 PM
6809
6814

Related issues

Related to FreeNAS - Bug #15984: Bug in GUI or Jails-DHCP problemClosed: Not To Be Fixed2016-06-06
Related to FreeNAS - Bug #16202: GUI: Edit Jail dialog is not working correct, when DHCP is ticked in Jails -> ConfigurationClosed: Not To Be Fixed2016-07-05
Has duplicate FreeNAS - Bug #17056: I cannot select DHCP for IPv4 on JailsClosed: Not To Be Fixed2016-08-262016-09-19

Associated revisions

Revision c3e6735e (diff)
Added by John Hixson over 3 years ago

Close on exec Ticket: #15817

Revision 4949d475 (diff)
Added by John Hixson over 3 years ago

Allow closing of file descriptors on exec Ticket: #15817

Revision 7b755952 (diff)
Added by John Hixson over 3 years ago

Close on exec Ticket: #15817 (cherry picked from commit c3e6735e382b4916c59f557dce85f28159797ece)

Revision 09e67d8c (diff)
Added by John Hixson over 3 years ago

Allow closing of file descriptors on exec Ticket: #15817 (cherry picked from commit 4949d475de0d822f797de0589d31020a812d01d4)

Revision 5be6f352 (diff)
Added by John Hixson over 3 years ago

Close on exec Ticket: #15817 (cherry picked from commit c3e6735e382b4916c59f557dce85f28159797ece)

Revision 305f1df4 (diff)
Added by John Hixson over 3 years ago

Allow closing of file descriptors on exec Ticket: #15817 (cherry picked from commit 4949d475de0d822f797de0589d31020a812d01d4)

Revision 5f7c2ac7 (diff)
Added by John Hixson over 3 years ago

Close on exec Ticket: #15817 (cherry picked from commit c3e6735e382b4916c59f557dce85f28159797ece)

Revision 2030b70b (diff)
Added by John Hixson over 3 years ago

Allow closing of file descriptors on exec Ticket: #15817 (cherry picked from commit 4949d475de0d822f797de0589d31020a812d01d4)

Revision 705df0bf (diff)
Added by John Hixson over 3 years ago

Close on exec Ticket: #15817 (cherry picked from commit c3e6735e382b4916c59f557dce85f28159797ece)

Revision 1cc881b2 (diff)
Added by John Hixson over 3 years ago

Allow closing of file descriptors on exec Ticket: #15817 (cherry picked from commit 4949d475de0d822f797de0589d31020a812d01d4)

History

#1 Updated by aloisio mello over 3 years ago

And, by the way, plugins obtained IPs after server reboot. That shouldn't be required and doesn't make sense for a server to be rebooted.

#2 Updated by John Hixson over 3 years ago

  • Status changed from Unscreened to 15
  • Target version set to 261

Thank you for attaching a debug, however, I need a debug when you aren't able to get an IP address. Can you provide one in that case? If so, are you also able to reproduce this issue? If you can reproduce this, that would be very helpful in being able to determine what is wrong.

#3 Updated by John Hixson over 3 years ago

Well, I noticed in another ticket that MAC addresses for jails aren't unique. That is clearly an issue and could very well be the issue here. Can you modify all your jails to have a unique MAC address and see if that changes things?

#4 Updated by aloisio mello over 3 years ago

  • File mello - testnas DHCP tests 2016-08-06.odt added
  • File debug-testnas-20160608112038.tgz added
  • File debug-testnas-20160608112829.tgz added

John Hixson wrote:

Well, I noticed in another ticket that MAC addresses for jails aren't unique. That is clearly an issue and could very well be the issue here. Can you modify all your jails to have a unique MAC address and see if that changes things?

Attached steps to install MineOS, screenshots, and debugs after install and after reboot.

#5 Updated by aloisio mello over 3 years ago

John Hixson wrote:

Well, I noticed in another ticket that MAC addresses for jails aren't unique. That is clearly an issue and could very well be the issue here. Can you modify all your jails to have a unique MAC address and see if that changes things?

Attached steps to install MineOS, screenshots, and debugs after install and after reboot.

Edit: Sorry didn't see your request.

I'm changing all jail plugins to the same MAC, if I understood you correctly. Further more, installing a new plugin and changing the MAC to the same and restarting the jail only to see if will obtain an IP.

Let me know if that's what you are looking for ...

I'm sure that will cause problems with my router as it seems the MAC for the DHCP Server to assign the IPs.

#6 Updated by aloisio mello over 3 years ago

aloisio mello wrote:

John Hixson wrote:

Well, I noticed in another ticket that MAC addresses for jails aren't unique. That is clearly an issue and could very well be the issue here. Can you modify all your jails to have a unique MAC address and see if that changes things?

Attached steps to install MineOS, screenshots, and debugs after install and after reboot.

Edit: Sorry didn't see your request.

I'm changing all jail plugins to the same MAC, if I understood you correctly. Further more, installing a new plugin and changing the MAC to the same and restarting the jail only to see if will obtain an IP.

Let me know if that's what you are looking for ...

I'm sure that will cause problems with my router as it seems the MAC for the DHCP Server to assign the IPs.

Clearly English is not my first language, so only understood the 2nd time... and yes, I did check that before and the MACs were different.

#7 Updated by aloisio mello over 3 years ago

Check this out to see if might be the issue:

created a 3rd jail -> interface created was epair2b, but dhclient was executed for epair2a. Also the there is a pccard_ether for epair2a (interface for the previous plugin installed).

Jun 8 15:10:35 testnas warden: Building new Jail... Please wait...
Jun 8 15:10:35 testnas warden: zfs clone pool1/jails_root/.warden-template-pluginjail@clean pool1/jails_root/syncthing_1
Jun 8 15:10:36 testnas warden: Success!
Jun 8 15:10:36 testnas warden: Jail created at /mnt/pool1/jails_root/syncthing_1
Jun 8 19:10:36 testnas devd: Executing '/etc/pccard_ether epair2a start'
Jun 8 19:10:36 testnas devd: Executing '/etc/pccard_ether epair2b start'
Jun 8 19:10:36 testnas devd: Executing '/etc/rc.d/dhclient quietstart epair2a'
Jun 8 15:10:36 testnas epair2a: Ethernet address: 02:ff:20:00:06:0a
Jun 8 15:10:36 testnas epair2b: Ethernet address: 02:ff:70:00:07:0b
Jun 8 15:10:36 testnas kernel: epair2a: link state changed to UP
Jun 8 15:10:36 testnas kernel: epair2a: link state changed to UP
Jun 8 15:10:36 testnas kernel: epair2b: link state changed to UP
Jun 8 15:10:36 testnas kernel: epair2b: link state changed to UP
Jun 8 15:10:36 testnas kernel: epair2a: promiscuous mode enabled
Jun 8 15:10:36 testnas kernel: ng_ether_ifnet_arrival_event: can't re-name node epair2b
Jun 8 15:10:36 testnas kernel: ng_ether_ifnet_arrival_event: can't re-name node epair2b
Jun 8 15:10:46 testnas notifier: Performing sanity check on nginx configuration:
Jun 8 15:10:46 testnas notifier: nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
Jun 8 15:10:46 testnas notifier: nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful
Jun 8 15:10:47 testnas manage.py: [freeadmin.navtree:630] An error occurred while unserializing from http://10.10.10.230:8080/plugins/syncthing/3/_s/treemenu: No JSON object could be decoded

#8 Updated by John Hixson over 3 years ago

Hi aloisio,

Can you edit /etc/devd.conf? Specifically line #41? Currently it has this:

match "subsystem" "!usbus[0-9]+";

Replace it with this:

match "subsystem" "!(epair|usbus)[0-9]+[a|b]?";

Once you do that, restart devd: service devd restart

After which, can you verify if this problem remains?

#9 Updated by aloisio mello over 3 years ago

New session:

notify 0 {
match "system" "IFNET";
match "subsystem" "!(epair|usbus)[0-9]+[a|b]?";
match "type" "ATTACH";
action "/etc/pccard_ether $subsystem start";
};

Devd restarted

[root@testnas] ~# service devd restart
Stopping devd.
Waiting for PIDS: 21076.
Starting devd.

owncloud plugin installed (5th plugin) -> No IP

Interface

epair4b: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8<VLAN_MTU>
ether 02:ff:70:00:09:0b
inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
nd6 options=9<PERFORMNUD,IFDISABLED>
media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
status: active

It run dhcllient for epair4a per console message

Jun 8 22:30:55 testnas warden: Building new Jail... Please wait...
Jun 8 22:30:55 testnas warden: zfs clone pool1/jails_root/.warden-template-pluginjail@clean pool1/jails_root/owncloud_1
Jun 8 22:30:56 testnas warden: Success!
Jun 8 22:30:56 testnas warden: Jail created at /mnt/pool1/jails_root/owncloud_1
Jun 8 22:30:56 testnas devd: Executing '/etc/rc.d/dhclient quietstart epair4a'
Jun 8 22:30:56 testnas epair4a: Ethernet address: 02:ff:20:00:08:0a
Jun 8 22:30:56 testnas epair4b: Ethernet address: 02:ff:70:00:09:0b
Jun 8 22:30:56 testnas kernel: epair4a: link state changed to UP
Jun 8 22:30:56 testnas kernel: epair4a: link state changed to UP
Jun 8 22:30:56 testnas kernel: epair4b: link state changed to UP
Jun 8 22:30:56 testnas kernel: epair4b: link state changed to UP
Jun 8 22:30:56 testnas kernel: epair4a: promiscuous mode enabled

#10 Updated by John Hixson over 3 years ago

aloisio, any chance I can get access to this system? I'd be much better at debugging this if so. We can exchange information privately if so.

#11 Updated by aloisio mello over 3 years ago

John Hixson wrote:

aloisio, any chance I can get access to this system? I'd be much better at debugging this if so. We can exchange information privately if so.

Sure, no problem. It is a test box exactly for this, so you can get in it and do whatever you need. Just let me know how to contact you to get it going.

#12 Updated by John Hixson over 3 years ago

aloisio mello wrote:

John Hixson wrote:

aloisio, any chance I can get access to this system? I'd be much better at debugging this if so. We can exchange information privately if so.

Sure, no problem. It is a test box exactly for this, so you can get in it and do whatever you need. Just let me know how to contact you to get it going.

You can email me:

#13 Updated by John Hixson over 3 years ago

So I've been at this all night. I've determined a few things:

1. This isn't broken from the command line. You can copy and paste the same commands used from the UI and it will always work.
2. If you restart django, create standard jails, they will get DHCP addresses fine
3. Creating a pluginjail jail (Installing a plugin) will break DHCP once the plugin is installed.

When trying to figure out what was going on with the DHCP issue before figuring out what seems to be a problem with the plugin path, I was able to witness the jail itself in a weird state when trying to get a DHCP address. It wasn't quite started, it was still in early boot, dhclient would fail on trying to chroot to /var/empty.

The problem is clearly in the UI. It appears to be in the plugin create path. I am still trying to figure this out. Thank you for allowing me to use your system to get to the bottom of this.

#14 Updated by aloisio mello over 3 years ago

John Hixson wrote:

So I've been at this all night. I've determined a few things:

1. This isn't broken from the command line. You can copy and paste the same commands used from the UI and it will always work.
2. If you restart django, create standard jails, they will get DHCP addresses fine
3. Creating a pluginjail jail (Installing a plugin) will break DHCP once the plugin is installed.

When trying to figure out what was going on with the DHCP issue before figuring out what seems to be a problem with the plugin path, I was able to witness the jail itself in a weird state when trying to get a DHCP address. It wasn't quite started, it was still in early boot, dhcpd would fail on trying to chroot to /var/empty.

The problem is clearly in the UI. It appears to be in the plugin create path. I am still trying to figure this out. Thank you for allowing me to use your system to get to the bottom of this.

No problem. The VM will be up for you to continue just in case. If you need to refresh the install let me know and I'll install another fresh 9.10 to that box.

#15 Updated by John Hixson over 3 years ago

So the culprit here is dhclient ultimately exits because it can't chroot into /var/empty. I am unclear why. This only fails from the UI, not from the command line. dhclient runs as the root user and does the chroot before dropping permissions, yet still fails with "Operation not permitted". To add to the confusion, I wrote a simple program that does a chroot to /var/empty as root prior to running dhclient, and sure enough it succeeds. More to come.

#16 Updated by John Hixson over 3 years ago

Here is the fix:

sysctl kern.chroot_allow_open_directories=2

I'm still trying to track down what directories are open. This will work in the mean time.

#17 Updated by aloisio mello over 3 years ago

John Hixson wrote:

Here is the fix:

sysctl kern.chroot_allow_open_directories=2

I'm still trying to track down what directories are open. This will work in the mean time.

Thanks John. I've upgraded one of my 9.3 to 9.10 and tested OK. I assume this won't "survive" a reboot as I run the above command in the shell or it will?

Let me know when I can close my firewall and take the VM/testnas down (no hurry).

#18 Updated by John Hixson over 3 years ago

aloisio mello wrote:

John Hixson wrote:

Here is the fix:

sysctl kern.chroot_allow_open_directories=2

I'm still trying to track down what directories are open. This will work in the mean time.

Thanks John. I've upgraded one of my 9.3 to 9.10 and tested OK. I assume this won't "survive" a reboot as I run the above command in the shell or it will?

You can configure this under system->tunables (as type sysctl) to persist across reboots and updates.

Let me know when I can close my firewall and take the VM/testnas down (no hurry).

#19 Updated by John Hixson over 3 years ago

The summary of what was happening is this:

When the jail would start, dhclient is run on the interface to get an IP address. dhclient was bailing because it was unable to chroot into /var/empty. The reason it could not chroot is either because the current process has file descriptors open to other directories, and/or the same process is already in a chroot. The latter is certainly not the case, however it has proved difficult to determine what open directories are held since there is lots of code that runs when installing a plugin. I've traced various paths, dtraced and looked at all opens and what not, however I find what I think is the better fix, which is to just set close on exec when forking the process that creates and starts the jail. I've tested this out and it works as expected. I will be implementing this in code shortly. For now, the sysctl can be used.

#20 Updated by John Hixson over 3 years ago

I've just committed c3e6735e382b4916c59f557dce85f28159797ece. This should fix the problem.

#21 Updated by Josh Paetzel over 3 years ago

[jpaetzel@roadrash] ~/git/freenas% grep -R pipesubr gui
gui/storage/views.py:from freenasUI.common.pipesubr import pipeopen
gui/storage/forms.py:from freenasUI.common.pipesubr import pipeopen
gui/jails/utils.py:from freenasUI.common.pipesubr import pipeopen
gui/jails/models.py:from freenasUI.common.pipesubr import pipeopen
gui/system/ixselftests/Tests/Replication.py:from freenasUI.common.pipesubr import pipeopen
gui/system/utils.py:from freenasUI.common.pipesubr import pipeopen
gui/directoryservice/forms.py:from freenasUI.common.pipesubr import run
gui/common/samba.py:from freenasUI.common.pipesubr import pipeopen
gui/common/freenasldap.py:from freenasUI.common.pipesubr import (
gui/common/pipesubr.py:log = logging.getLogger('common.pipesubr')
gui/common/cmd.py: from freenasUI.common.pipesubr import pipeopen
gui/common/sipcalc.py:from freenasUI.common.pipesubr import pipeopen
gui/common/system.py: from freenasUI.common.pipesubr import pipeopen
gui/common/system.py: from freenasUI.common.pipesubr import pipeopen
gui/common/warden.py:from freenasUI.common.pipesubr import pipeopen
gui/sharing/forms.py:from freenasUI.common.pipesubr import pipeopen
gui/middleware/notifier.py: from freenasUI.common.pipesubr import pipeopen
gui/tools/autosnap.py:from freenasUI.common.pipesubr import pipeopen
gui/tools/autorepl.py:from freenasUI.common.pipesubr import pipeopen
gui/reporting/rrd.py:from freenasUI.common.pipesubr import pipeopen
gui/account/forms.py:from freenasUI.common.pipesubr import pipeopen

That change seems really intrusive.

#22 Updated by John Hixson over 3 years ago

Josh Paetzel wrote:

[jpaetzel@roadrash] ~/git/freenas% grep -R pipesubr gui
gui/storage/views.py:from freenasUI.common.pipesubr import pipeopen
gui/storage/forms.py:from freenasUI.common.pipesubr import pipeopen
gui/jails/utils.py:from freenasUI.common.pipesubr import pipeopen
gui/jails/models.py:from freenasUI.common.pipesubr import pipeopen
gui/system/ixselftests/Tests/Replication.py:from freenasUI.common.pipesubr import pipeopen
gui/system/utils.py:from freenasUI.common.pipesubr import pipeopen
gui/directoryservice/forms.py:from freenasUI.common.pipesubr import run
gui/common/samba.py:from freenasUI.common.pipesubr import pipeopen
gui/common/freenasldap.py:from freenasUI.common.pipesubr import (
gui/common/pipesubr.py:log = logging.getLogger('common.pipesubr')
gui/common/cmd.py: from freenasUI.common.pipesubr import pipeopen
gui/common/sipcalc.py:from freenasUI.common.pipesubr import pipeopen
gui/common/system.py: from freenasUI.common.pipesubr import pipeopen
gui/common/system.py: from freenasUI.common.pipesubr import pipeopen
gui/common/warden.py:from freenasUI.common.pipesubr import pipeopen
gui/sharing/forms.py:from freenasUI.common.pipesubr import pipeopen
gui/middleware/notifier.py: from freenasUI.common.pipesubr import pipeopen
gui/tools/autosnap.py:from freenasUI.common.pipesubr import pipeopen
gui/tools/autorepl.py:from freenasUI.common.pipesubr import pipeopen
gui/reporting/rrd.py:from freenasUI.common.pipesubr import pipeopen
gui/account/forms.py:from freenasUI.common.pipesubr import pipeopen

That change seems really intrusive.

I've only committed it to master so that it can be tested further. I've tested here as best I can and all seems to be well. Can you think of any reasons that keeping open descriptors across a fork is necessary/intended ?

#23 Updated by Josh Paetzel over 3 years ago

I can't think of any reasons off the top of my head why keeping a descriptor across a fork is needed, but if you look at the list of things that touches I don't know that we have any way of testing them all.

There's a couple lower risk things that would make me a lot more comfortable with this change.

--- a/gui/common/pipesubr.py
+++ b/gui/common/pipesubr.py
@ -54,7 +54,7 @ def unblock_sigchld():
libc.sigprocmask(SIG_SETMASK, pmask, None)

-def pipeopen(command, important=True, logger=log, allowfork=False, quiet=False):
+def pipeopen(command, important=True, logger=log, allowfork=False, quiet=False, closefd=False):
if not quiet:
logger.log(
logging.NOTICE if important else logging.DEBUG,
@ -66,10 +66,16 @ def pipeopen(command, important=True, logger=log, allowfork=False, quiet=False):
if allowfork:
preexec_fn = unblock_sigchld

- return Popen(
- args, stdin=PIPE, stdout=PIPE, stderr=PIPE,
- close_fds=True, preexec_fn=preexec_fn
- )
+ if closefd:
+ return Popen(
+ args, stdin=PIPE, stdout=PIPE, stderr=PIPE,
+ close_fds=True, preexec_fn=preexec_fn
+ )
+ else:
+ return Popen(
+ args, stdin=PIPE, stdout=PIPE, stderr=PIPE,
+ close_fds=False, preexec_fn=preexec_fn
+ )

A patch like this combined with changing the specific pipeopen call that you want to change the behaviour of would avoid having any possible side affects anywhere but in the code you are actually fixing.

Another option would be a pipeopen2 function that is just used by the plugin code.

Of course documenting either route would make it a lot easier to unwind why this code exists.

#24 Updated by John Hixson over 3 years ago

  • Status changed from 15 to 19

I've committed a fix. It needs testing and review.

#25 Avatar?id=14398&size=24x24 Updated by Kris Moore over 3 years ago

  • Priority changed from No priority to Expected

#26 Updated by John Hixson over 3 years ago

  • Status changed from 19 to Needs Developer Review

#27 Updated by Vaibhav Chauhan over 3 years ago

  • Assignee changed from John Hixson to Josh Paetzel

requesting review.

#28 Updated by Josh Paetzel over 3 years ago

  • Status changed from Needs Developer Review to Reviewed
  • Assignee changed from Josh Paetzel to Vaibhav Chauhan

Approved.

#29 Updated by Vaibhav Chauhan over 3 years ago

Merged FIX-15817 to 9.10-STABLE, need FIX-TN-15817 branch for TN-9.10-STABLE.

#30 Updated by Vaibhav Chauhan over 3 years ago

  • Target version changed from 261 to 9.10.1

#31 Updated by Vaibhav Chauhan over 3 years ago

FIX-TN-15817 and FIX-15817 was merged in TN-9.10-STABLE and 9.10-STABLE, respectively.

#32 Updated by Vaibhav Chauhan over 3 years ago

  • Status changed from Reviewed to Ready For Release

#33 Updated by Vaibhav Chauhan over 3 years ago

  • Status changed from Ready For Release to Resolved

#34 Updated by aloisio mello over 3 years ago

  • File FreeNAS 9-10-1 jail DHCP broken.pdf added

Vaibhav Chauhan wrote:

FIX-TN-15817 and FIX-15817 was merged in TN-9.10-STABLE and 9.10-STABLE, respectively.

Please confirm as I can't duplicate.

#35 Updated by Matt Kessler over 3 years ago

6809

Just posted in #16310 about this.
I can confirm what Aloisio describes in his PDF.

#36 Updated by David Benjamin over 3 years ago

I can confirm this as well. I'm running the latest version of 9.10 after upgrading from 9.3.

Everything else seems to be working fine, but I'm having the same problem with jails. The DHCP can't be enabled on new jails and old ones (plugin or not) are not receiving an ip address.

Matt Kessler wrote:

Just posted in #16310 about this.
I can confirm what Aloisio describes in his PDF.

#37 Updated by Matt Kessler over 3 years ago

Hi David
What has resolved the ip4 DHCP issue was, disabling "IPv6 Autoconfigure:" in "Jails -> Configuration" and then clearing the check box for every Jail (see images in #16310).
If you could try an report back, please!?

#38 Updated by aloisio mello over 3 years ago

Matt Kessler wrote:

Hi David
What has resolved the ip4 DHCP issue was, disabling "IPv6 Autoconfigure:" in "Jails -> Configuration" and then clearing the check box for every Jail (see images in #16310).
If you could try an report back, please!?

I don't use IPv6 by the way and it is not working for me.

#39 Updated by David Benjamin over 3 years ago

It still doesn't seem to work for me. I had to downgrade to 9.3, get my jails back in order and then upgrade to 9.10.1. The jails from 9.3 are working just fine as they did before. I tried to create a new jail, but can't check the DHCP box. I've tried to uncheck the ip6 autoconfigure, but saving it doesn't stick. So, now my old jails are working, but I can't create any new ones that will enable DHCP.

Matt Kessler wrote:

Hi David
What has resolved the ip4 DHCP issue was, disabling "IPv6 Autoconfigure:" in "Jails -> Configuration" and then clearing the check box for every Jail (see images in #16310).
If you could try an report back, please!?

#40 Updated by Matt Kessler over 3 years ago

6814

David, about "but saving it doesn't stick"… you need to disabe "IPv6 Autoconfigure:" in "Jails -> Configuration"!
(see my upload)
I'm pretty sure it is still turned on there in your case — that is why it will just overwrite whatever you would like to set for your jail.

#41 Updated by aloisio mello over 3 years ago

Still unresolved on my end. Just moved a box to another location and had to create a virtualbox jail for a jump box vm and can't get DHCP to work.

#42 Updated by David Benjamin over 3 years ago

Apologies for not responding. You were correct about that checkbox, thank you for that, but the problem still remains for me. I now have DHCP working for all of my jails except for one, but I can pull an IP in on that one after it boots. It's annoying, but at least things are running. I still can't select DHCP in the admin area. From what I can tell, it seems to be a problem with whatever determines if that link should be checked or not. It does check for 1ms or two, but immediately is unchecked by some JS being fired.

Matt Kessler wrote:

David, about "but saving it doesn't stick"… you need to disabe "IPv6 Autoconfigure:" in "Jails -> Configuration"!
(see my upload)
I'm pretty sure it is still turned on there in your case — that is why it will just overwrite whatever you would like to set for your jail.

#43 Updated by aloisio mello over 3 years ago

Try type the word DHCP in caps as IP Address and click the IPv4 DHCP check box after that. It is working for me for new and existing jails.

#44 Updated by Matt Kessler over 3 years ago

aloisio mello wrote:

Try type the word DHCP in caps as IP Address and click the IPv4 DHCP check box after that. It is working for me for new and existing jails.

I can confirm this.
I put an image in bug #16310

#45 Updated by aloisio mello over 3 years ago

Matt Kessler wrote:

I can confirm this.
I put an image in bug #16310

Matt - What I'm trying to say is that there is a work around for the issue. If you type the word DHCP the option for IPv4 DHCP is accessible and the jail will get an IP from the DHCP server.

I've reported this issue with the way the GUI is acting up in bug 15720 - 3 months ago - but was closed as duplicate.

I do agree with you that:

- General jail configuration should be used as the default setting for the new jail been created;
- When creating a new jail, the user should have the option to change the default configuration to whatever he likes, by clicking advance - with some consistency checks of course;
- For existing jails, user can open the configuration and no changes will be made by the GUI (that was happening - jails IP configuration was changed when opening an existing jail setting); User will be allowed to change configurations to whatever he likes - with some consistency checks of course;

#46 Updated by Vaibhav Chauhan over 3 years ago

  • Category changed from 20 to 38
  • Status changed from Resolved to Unscreened
  • Assignee changed from Vaibhav Chauhan to John Hixson

I can confirm that this issue still exists on 9.10.1.
system in question,
https://stable-shark.ixsystems.com/ (root/meh)

#47 Updated by Vaibhav Chauhan over 3 years ago

  • Parent task set to #15984

#48 Updated by Vaibhav Chauhan over 3 years ago

  • Parent task deleted (#15984)

#49 Updated by Vaibhav Chauhan over 3 years ago

  • Related to Bug #15984: Bug in GUI or Jails-DHCP problem added

#50 Updated by Vaibhav Chauhan over 3 years ago

  • Related to Bug #16202: GUI: Edit Jail dialog is not working correct, when DHCP is ticked in Jails -> Configuration added

#51 Updated by Vaibhav Chauhan over 3 years ago

  • Target version changed from 9.10.1 to 9.10.1-U2

#52 Updated by Vaibhav Chauhan over 3 years ago

  • Has duplicate Bug #17056: I cannot select DHCP for IPv4 on Jails added

#53 Updated by John Hixson over 3 years ago

  • Status changed from Unscreened to Screened

#54 Avatar?id=14398&size=24x24 Updated by Kris Moore about 3 years ago

  • Target version changed from 9.10.1-U2 to 9.10.1-U3

#55 Updated by Dru Lavigne about 3 years ago

Will this make it into U3?

#56 Avatar?id=14398&size=24x24 Updated by Kris Moore about 3 years ago

  • Target version changed from 9.10.1-U3 to 9.10.2

#57 Avatar?id=14398&size=24x24 Updated by Kris Moore about 3 years ago

  • Status changed from Screened to Closed: Not To Be Fixed

Closing this now. We are working hard a new jail implementation for 9.10.3 (hopefully) which will change a lot of this functionality.

#58 Updated by Dru Lavigne about 2 years ago

  • File deleted (debug-freenas-20160606132434.tgz)

#59 Updated by Dru Lavigne about 2 years ago

  • File deleted (debug-testnas-20160608112038.tgz)

#60 Updated by Dru Lavigne about 2 years ago

  • File deleted (debug-testnas-20160608112829.tgz)

#61 Updated by Dru Lavigne almost 2 years ago

  • File deleted (mello - testnas DHCP tests 2016-08-06.odt)

#62 Updated by Dru Lavigne almost 2 years ago

  • File deleted (FreeNAS 9-10-1 jail DHCP broken.pdf)

Also available in: Atom PDF