Akm0d
commented
4 years ago I solved a similar issue in idem-windows a while back, the code in idem-windows might be helpful for finding a solution
Open r-pufky opened 4 years ago
Akm0d
commented
4 years ago I solved a similar issue in idem-windows a while back, the code in idem-windows might be helpful for finding a solution
xeacott
commented
4 years ago @r-pufky Thanks for so much detail in the report. Ill get started on a fix for this.
xeacott
commented
4 years ago So this boils down to salt see's the interface name as Wintun Userspace Tunnel, on Windows...
But on linux, salt see's it as salt-client?
And both systems are using source_interface_name: salt-client
xeacott
commented
4 years ago It also looks like in minion.py there is a check for
if opts['source_interface_name']:
log.trace("Custom source interface required: %s", opts["source_interface_name"])
interfaces = salt.utils.network.interfaces()
log.trace("The following interfaces are available on this Minion:")
log.trace(interfaces)and there are log.trace messages saying that if it can't connect to what was provided, the minion log should have this message in it:
else:
log.warning(
"%s is not a valid interface. Ignoring.", opts["source_interface_name"]
)Would you be able to look at see what in in your minion on startup?
r-pufky
commented
4 years ago So this boils down to salt see's the interface name as
Wintun Userspace Tunnel, on Windows... But on linux, salt see's it assalt-client?And both systems are using
source_interface_name: salt-client
Correct.
It also looks like in
minion.pythere is a check forif opts['source_interface_name']: log.trace("Custom source interface required: %s", opts["source_interface_name"]) interfaces = salt.utils.network.interfaces() log.trace("The following interfaces are available on this Minion:") log.trace(interfaces)and there are log.trace messages saying that if it can't connect to what was provided, the minion log should have this message in it:
else: log.warning( "%s is not a valid interface. Ignoring.", opts["source_interface_name"] )Would you be able to look at see what in in your minion on startup?
I clipped the trace log to the relevant information.
[DEBUG ] Connecting to master. Attempt 1 (infinite attempts)
[TRACE ] Custom source interface required: salt-client
[TRACE ] The following interfaces are available on this Minion:
[TRACE ] {'WireGuard Tunnel': {'up': True, 'inet': [{'label': 'WireGuard Tunnel', 'gateway': '', 'address': '172.31.255.10', 'broadcast': '172.31.255.255', 'netmask': '255.255.255.0'}], 'hwaddr': ':::::'}, 'Intel(R) Ethernet Connection (2) I219-V': {'up': True, 'inet6': [{'address': '{REDACTED}', 'gateway': ''}], 'inet': [{'label': 'Intel(R) Ethernet Connection (2) I219-V', 'gateway': '{REDACTED}', 'address': '{REDACTED}', 'broadcast': '{REDACTED}', 'netmask': '{REDACTED}'}], 'hwaddr': '{REDACTED}'}, 'Software Loopback Interface 1': {'up': True, 'inet6': [{'address': '::1', 'gateway': ''}], 'inet': [{'label': 'Software Loopback Interface 1', 'gateway': '', 'address': '127.0.0.1', 'broadcast': '127.255.255.255', 'netmask': '255.0.0.0'}], 'hwaddr': ':::::'}}
[WARNING ] salt-client is not a valid interface. Ignoring.
[DEBUG ] Master URI: tcp://172.31.255.254:4506PS C:\salt> .\salt-call.bat network.interface salt-client
[ERROR ] Interface "salt-client" not in available interfaces: "Software Loopback Interface 1", "Intel(R) Ethernet Connection (2) I219-V", "WireGuard Tunnel"
local:
Interface "salt-client" not in available interfaces: "Software Loopback Interface 1", "Intel(R) Ethernet Connection (2) I219-V", "WireGuard Tunnel"Get-NetAdapter
Name InterfaceDescription ifIndex Status MacAddress LinkSpe
ed
---- -------------------- ------- ------ ---------- -------
Ethernet 2 Adapter for Windows 19 Up AA-BB-CC-DD-EE-FF ...Mbps
Ethernet Intel(R) Ethernet Connection (2) I219-V 5 Up AA-BB-CC-DD-EE-FF 1 Gbps
salt-client WireGuard Tunnel 3 Up ...GbpsLet me know if you need anything else!
xeacott
commented
4 years ago Thanks for getting all that information for me 😄 Going down the rabbit hole of all this eventually leads to this function:
def get_interface_info():
"""
This function will return network interface information for the system and
will use the best method to retrieve that information. Windows 7/2008R2 and
below will use WMI. Newer systems will use .NET.
Returns:
dict: A dictionary of information about the Network interfaces
"""
# On Windows 7 machines, use WMI as dotnet 4.0 is not available by default
if USE_WMI:
return get_interface_info_wmi()
else:
return get_interface_info_dot_net_formatted()Since it appears you're on a Win10 box (likewise here, too) you'll actually be using the python dotnet framework instead of WMI because of this...
if IS_WINDOWS:
USE_WMI = StrictVersion(platform.version()) < StrictVersion("6.2")
if USE_WMI:
import wmi
import salt.utils.winapi
else:
import clr
from System.Net import NetworkInformationJust keeping all this info here... the rabbit hole for gathering network interfaces goes like 10 calls down, phew!
xeacott
commented
4 years ago Oh, finally could you run a salt-call --local network.interfaces for me and see what you get? Looks like we only count a network interface if its status is "Up", and then the "name" that we give each interface is actually the description itself: name = interfaces[i_face]['description'] See if this PR works for you...https://github.com/saltstack/salt/pull/57633
r-pufky
commented
4 years ago No worries. Here you are:
C:\salt> .\salt-call.bat --local network.interfaces
local:
----------
Intel(R) Ethernet Connection (2) I219-V:
----------
hwaddr:
{REDACTED}
inet:
|_
----------
address:
{REDACTED}
broadcast:
{REDACTED}
gateway:
{REDACTED}
label:
Intel(R) Ethernet Connection (2) I219-V
netmask:
{REDACTED}
inet6:
|_
----------
address:
{REDACTED}
gateway:
up:
True
Software Loopback Interface 1:
----------
hwaddr:
:::::
inet:
|_
----------
address:
127.0.0.1
broadcast:
127.255.255.255
gateway:
label:
Software Loopback Interface 1
netmask:
255.0.0.0
inet6:
|_
----------
address:
::1
gateway:
up:
True
WireGuard Tunnel:
----------
hwaddr:
:::::
inet:
|_
----------
address:
172.31.255.10
broadcast:
172.31.255.255
gateway:
label:
WireGuard Tunnel
netmask:
255.255.255.0
up:
TrueSince it appears you're on a Win10 box (likewise here, too)
Correct. Here's the grain info for Windows 10:
os:
Windows
os_family:
Windows
osfinger:
Windows-10
osfullname:
Microsoft Windows 10 Pro
osmanufacturer:
Microsoft Corporation
osrelease:
10
osrelease_info:
- 10
osservicepack:
None
osversion:
10.0.18363
I3urny
commented
1 year ago Any particular reason #57633 got closed without a comment? This is still an issue in v3006 and it seems to me as if that was the correct solution. I'd be happy help resolve this issue but I can't imagine there's much missing as @xeacott has done 99% of the work already.
v3006 behaviour:
> salt-call --local network.interfaces
local:
----------
Intel(R) Ethernet Connection (16) I219-V:
----------
hwaddr:
{REDACTED}
inet:
|_
----------
address:
{REDACTED}
broadcast:
{REDACTED}
gateway:
{REDACTED}
label:
Intel(R) Ethernet Connection (16) I219-V
netmask:
{REDACTED}
inet6:
|_
----------
address:
{REDACTED}
gateway:
prefixlen:
64
up:
True
Software Loopback Interface 1:
----------
hwaddr:
:::::
inet:
|_
----------
address:
127.0.0.1
broadcast:
127.255.255.255
gateway:
label:
Software Loopback Interface 1
netmask:
255.0.0.0
inet6:
|_
----------
address:
::1
gateway:
prefixlen:
128
up:
True
WireGuard Tunnel:
----------
hwaddr:
:::::
inet:
|_
----------
address:
10.0.0.2
broadcast:
10.0.0.2
gateway:
label:
WireGuard Tunnel
netmask:
255.255.255.255
up:
TrueUsing alias instead of description as described in #57633:
> salt-call --local network.interfaces
local:
----------
Ethernet:
----------
hwaddr:
{REDACTED}
inet:
|_
----------
address:
{REDACTED}
broadcast:
{REDACTED}
gateway:
{REDACTED}
label:
Ethernet
netmask:
{REDACTED}
inet6:
|_
----------
address:
{REDACTED}
gateway:
prefixlen:
64
up:
True
Loopback Pseudo-Interface 1:
----------
hwaddr:
:::::
inet:
|_
----------
address:
127.0.0.1
broadcast:
127.255.255.255
gateway:
label:
Loopback Pseudo-Interface 1
netmask:
255.0.0.0
inet6:
|_
----------
address:
::1
gateway:
prefixlen:
128
up:
True
wg0:
----------
hwaddr:
:::::
inet:
|_
----------
address:
10.0.0.2
broadcast:
10.0.0.2
gateway:
label:
wg0
netmask:
255.255.255.255
up:
True
Description Expected interface name is not returned for network.interface on Windows 10 salt clients.
Intended result: Have minions contact salt-master via wireguard tunnel, named "salt-client". This network is confirmed to: work, pingable on both minion/master machines and correctly applies salt states, minion client upgrades, etc. through the tunnel without specifying the interface, salt-minions will use the correct network adapter to contact the salt-master over wireguard (working).
However, explicitly specifying the interface name will cause windows minions to fail.
Linux
Working as intended. Properly identifies the salt-client wireguard tunnel and uses it.
Windows
Will report that the interface does not exist.
windows salt-client interface retrieval.
powershell reports interface names appropriately.
Control Panel reports properly as well.
Detailed interface list shows
A clear and concise description of what the bug is.
Expected interface name is not returned for network.interface on Windows 10 salt clients.
Expected Name:
salt-clientReturned Name:Wintun Userspace TunnelThis value is used in salt minion
source_interface_nameand diverges from linux minions.Setup
(Please provide relevant configs and/or SLS files (be sure to remove sensitive info).
See above.
Steps to Reproduce the behavior
(Include debug logs if possible and relevant)
c:/salt/minion
state.highstateor./salt-call network.interface salt-clientExpected behavior
A clear and concise description of what you expected to happen.
The same behavior as linux.
network.interface salt-clientreturns the correct interface.source_interface_name: salt-clientis valid for windows salt minions properly configured.Versions Report
salt-master
salt-minion (windows)
salt-minion (linux)
Additional context Add any other context about the problem here.
Happy to upgrade windows minion to 3000.3; but that's a red herring, giving the return value context for the windows minion.
edit: provided the right versions report for windows client.