Networking issues after installing AD

NethServer Version: 7.3.1611 (Final), Kernel release: 3.10.0-514.21.1.el7.x86_64


We had set up NethServer at office a few months ago. It is a physical computer (not a VM).

It runs in the following physical network configuration: Router > NethServer (RED - GREEN) > Network switch > Client computers

RED settings

GREEN settings
Gateway: None

DHCP settings (GREEN)

Web proxy
Green zone: Transparent with SSL

No further configuration had been done, and everything was working fine since the past few months.

Then, last week, we decided to create a domain and installed AD.

Active Directory local accounts provider settings
DNS domain name: ad.myoffice.local
NetBIOS domain name: MYOFFICE
Domain Controller IP address:

The installation bridged the GREEN NIC, so we had to re-enable DHCP on br0 (the new GREEN). Apart from that, the installation was flawless and the domain, users, groups and shares are working as expected.

However, we now have a strange issue which was not present earlier. (Note that we always shut down the server every night, since the office power mains are switched off).

When the server starts, RED interface says “Link status is down” and none of the client computers can access the internet.

Simply editing and saving br0 (without any changes) via the Server Manager GUI, fixes this immediately.

I tried creating a script that runs “systemctl restart network” on boot. This fixes the internet access issue, however, the firewall blocks all non-HTTP traffic (FTP, Steam, etc.) until the above edit/save on br0 is performed.

I would appreciate if someone could:

  1. (URGENT) Please let me know what command to give in lieu of “systemctl restart network” so that the system performs the same restarts as when br0 is edit/saved via the Server Manager GUI.
  2. (Not critical if the above is achieved) Please let me know if there is some setting to be done, so that this issues goes away permanently.

Thanks a bunch!


take a look a the DHCP config, to reattribute the DHCP server to the “correct NIC”

The ad installation create a bridged NIC and do few alteration at this level.

1 Like

Hi Jim,

Thanks for your reply!

The DCHP config shows…

Enable DHCP server on interfaces
[check-box] br0 - green

Essentially, if I could know the sequence of tasks that the server performs when I edit/save the br0 interface in the Network section, then I could write a small command line script to do the same, and this will “fix” the issue (albeit as a hack, not a proper fix).

The command is signal-event interface-update which carries multiple actions:

As you said, this is more a workaround than a permanent fix. Try to investigate the logs to find what is the issue.


You can try too, to make a “static route”, and attach the route to the “real” device

1 Like

I know there is a bug on some Intel drivers: in some cases, the network interface doesn’t come online and you need to turn it up manually. What ethernet interface do you have and what driver are you using?

If you’re hitting the mentioned bug, there is no fix from upstream AFAIK.

The problem is not directly connected with the AD provider itself, but it’s network related. Something wrong going on with the bridge? Just guessing.
By the way, turning on and off a server every day it’s not a good habit :wink:

1 Like

The sever has a ASUS H270M Plus motherboard. The GREEN interface is the on-board LAN, which according to the specifications page ( is an Intel I219V, 1 x Gigabit LAN Controller.

The thing is… We didn’t have this issue until AD was installed. The server was working super awesomely over the past couple of months. I installed AD last week.

Unfortunately, there’s nothing that can be done about switching off the server at night - the office power mains are switched off, so there’s no way for it to remain on! :grin:

Wow! Thanks for sourcing this information! :grinning:

I’m a first time Linux user (we have used Windows server since the past decade and only switched over this year). Would it be possible for you to help me out with which logs to look at, to discover the issue?

Thanks for the information! I will look at the logs, like @dnutan has suggested, and try to find the source of the issue. :slight_smile:

Can you share the model and driver of your network cards? On the server manager, you can find it under Configuration -> Network -> Edit button (of each interface).

Regarding the logs, you can look at /var/log/messages, and also at the journalctl -xe command.

enp3s0 (RED)
pci Realtek Semiconductor Co. Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
Driver r8169

br0 (GREEN)
Driver (blank)

enp0s31f6 (was GREEN earlier)
The bridged NIC. It doesn’t have an edit button.

I ran “lspci” on the command line and got this:
enp0s31f6 - Ethernet controller: Intel Corporation Ethernet Connection (2) I219-V
enp3s0 - Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)

I also ran “ethtool -i” on the command line and got this:
driver: e1000e
version: 3.2.6-k
firmware-version: 0.8-4
bus-info: 0000:00:1f.6
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

driver: r8169
version: 2.3LK-NAPI
firmware-version: rtl_nic/rtl8168e-2.fw
bus-info: 0000:03:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no

On a separate note, I added the following line in “visudo” (like I did for other commands I’ve given regular users access to):
USERNAME localhost=/sbin/signal-event interface-update

However, I am unable to use “sudo signal-event interface-update” in any other user account (apart from root). It says “sudo: signal-event: command not found”

On searching the “/sbin/” in the regular user logins, I discovered that the “signal-event” command is not present!

How do I get around this?

I think you hit the kernel bug :frowning: Maybe @filippo_carletti knows more about it.

The signal-event command is /sbin/e-smith/signal-event.

1 Like

The board is the same I’m having the issue with.
As a workaround, we can add an ifup later in the boot process.

1 Like

“I think you hit the kernel bug” :sob::sob::sob:

@giacomo, does this mean that there’s nothing that I can do, and am resigned to manually executing “signal-event interface-update” on each boot? :cry:

Also, @filippo_carletti - I’ve mentioned it previously, but just want to clarify with you that this issue did not exist until AD was installed.

If it is because of the intel interface, you could try to add another networking card in and not use the onboard adapter.

I do not know if it is the Intel driver issue, because we didn’t have any issue till AD was installed + it is the RED interface (Realtek PCI NIC) that is showing “Link down” (no access to the Internet). The GREEN interface (Intel) is functioning as expected (LAN, local networking and domain controls work fine).

I understand your point, but the only difference is that the AD provider creates a bridge. We looked into other server with the same problem, but we didn’t fine a common configuration to reproduce the issue.

Maybe you can try to add a command to the rc.local? (

Okay. Will do.

Meanwhile, if there’s any information that I can provide, which might help you solve this issue at the development level, please let me know!