I'm doing some polling of specific adapters on some PCs running windows via SNMP. I've noticed that polling using an OID constructed with the interface's ifIndex is unreliable as it appears that the ifTable is created dynamically.
I found some Cisco documentation that mentions that ifIndex is no longer persistent as of RFC2863. The documentation introduces a feature of Cisco routers that allows for ifIndex persistence between reboots.
Can such a thing be achieved in Windows? I want to avoid enumeration and identification of interfaces as it is impractical/difficult to do for my application
Unlike (newer, IOS 12+) Cisco devices, Windows does not have a fixed interface scheme.
The interface list is generated on boot and can change while running (think Wireless, dial-up, VPN, or tunneling interfaces; or link loss). That being said, on a stable Windows system the values should be consistent.
I would try the last known value, do a sanity check and re-enumerate the interfaces if it fails.
Related
The closest thing to a solution I've found is using Get-NetConnectionProfile to return all active interfaces, which works fine when there's only an active physical interface and the VPN itself. However, this would not work if the user's machine has 2 active physical interfaces (e.g Wi-Fi + Ethernet) along with the VPN.
Ideally, I'd like a solution that works similarly to "ifconfig -v" in MacOS, which tells you the effective interface for a virtual interface:
Unfortunately it seems there is no sure-fire way to get the underlying physical adapter for a VPN using a Windows API. Short of involving a packet sniffer such as Wireshark, the best solution I found involves parsing the output of two PowerShell commands: Get-NetAdapter and Get-NetRoute.
With the information from these commands, I can know which interfaces are virtual and which ones are physical, and I can rank the physical interfaces by 3 different criteria (in case of tie, we move on to the next criteria):
Sorting the physical interfaces by the interface metric + the route metric to the default gateway (0.0.0.0).
Wired connections over wireless ones (PhysicalMediaType=802.3).
Prioritizing faster adapters.
With this logic all the VPNs I tested appear to reflect the expected network interface, although some VPNs let you force traffic through a particular physical adapter in which case obviously this all goes out the window.
First,
You can install wireshark or some other traffic monitoring tool and capture the relevant packets (filtering using openvVPN protocol or port etc.)
Second,
As far as I know there is no hard linking between the virtual network interface and the regular (ethernet, WIFI etc.) interface, at least not in OpenVPN (there are diffrent VPN protocols). The openVPN packets will be routed to the remote server using you OS routing table.
This way if your ethernet interface is your primary default gateway, and it gets unplugged, your VPN service will be able to recover, since it will have a route to your remote VPN-server address using your WIFI interface.
We have an NDIS LWF driver, and it seems like it cannot get attached to Virtual Network Adapters, for example the one that Kerio Control VPN client creates (Kerio Virtual Network).
When i try to install the NDIS LWF in the network adapter manually by giving it our INF file (Install -> service -> Have disk), the driver doesn't appear in the network service list.
Then i found out that i if add nolower in the FilterMediaTypes in the inf file, it does appear in the network service list, but even then, when i click on OK, it doesn't get added to the list of items and doesn't get attached.
My question is, How can i attach to this Kerio Virtual Network Adapter in order to monitor its packets?
LWFs cannot bind to a network interface that has HKR, Ndi\Interfaces,LowerRange,,nolower in its INF. Generally speaking, the network interface ought to have at least one real LowerRange, and it's reasonable to ask the vendor to add one. For whatever it's worth, we (the Windows OS team) originally shipped the Bluetooth PAN adapter with nolower, and then later realized we needed to update it to have something there, so LWFs could bind to it. Perhaps that anecdote helps motivate this vendor to update their INF.
If the NDIS datapath uses a 14 byte Ethernet-like header and is roughly compatible with Ethernet's ideas of unicast & multicast, then ethernet is the correct thing to put in LowerRange. See the docs for more details.
It's not supported to try and add the nolower token to your LWF driver INF's FilterMediaTypes; you can't reasonably expect to bind to any unknown type of interface. What if the next network adapter indicates packets in some yet-to-be-invented framing layer — how could your LWF possibly make sense of those packets? For that reason, nolower is not a binding interface; it's a special token that means "the empty list".
LWFs also cannot bind to CoNDIS network adapters. This is simply because the LWF programming model has never been extended to cover all the additional signaling for connection management.
I am not personally familiar with the "Kerio" network interface — I don't know if it has nolower in its INF or whether it's CoNDIS (!ndiskd would tell you this). If it's the former, you should ask that vendor to update their INF.
Is this kind of link aggregation even possible?
On a Windows machine, there are several 3rd-party applications which make use of bonding and load balancing multiple network interfaces for increased throughput, such as Connectify Dispatcher, for example. Would it be possible to develop such an app for OSX? Is there already any 3rd-party software which does this on OSX? The closest thing I could find was IPNetRouterX, which I've failed to use for bonding USB and WiFi network interfaces.
I have also tried the following line in OSX's terminal:
sudo networksetup -createBond bond0 en1 en3
...where en1 is my WiFi interface and en3 is my USB network interface, which simply results in:
** Error: The parameters were not valid.
Likely, there would need to be some sort of Layer 2 "magic glue" to make this in any way a possibility... but primarily being a Windows programmer, I'm not sure if Apple would enjoy allowing that level of programming access, considering how proprietary they like to be...
Any idea what can be done here?
There are options to networksetup to tell you whether the OS can bond a particular port or not. To do so, you need to hand it a "hardware port", which you can find by using:
networksetup -listallhardwareports
Each of those, in turn, can be queried using
networksetup -isbondsupported <HW Port Name>
Bonded networks are set up using the networksetup port name, not the kernel interface name, so if you were to bond two ethernet networks, you would do so like this:
networksetup -createBond myBondedNet 'Ethernet 1' 'Ethernet 2'
Querying the ports on my 2009 MacPro running 10.9, I find only the hardware ethernet ports to respond YES to the -isbondsupported inquiry.
Note that I didn't have to have the port operational in order for -isbondsupported to return YES, so in my case both of my ethernets responded YES even though only one is currently connected.
gaige thanks for your technical answer but RectangleEquals is not asking how to do Link Aggregation through terminal but
IF Link Aggregation can work for USB, WIFI, or other type of internet connections.
The answer is NO.
Apple didn't created Link Aggregation. It's a separated feature Unix had. Therefore Apple has zero idea how to improve it - nor does it want to spent resource to figure it out because it is not a common enough demand. Even if it wants to give you the feature it will not provide in a regular version of OS X but will provide in a server version and charge you for it.
And there are developers who can do it, by writing a lot of codes - so no free version of such application exist. You can try Connectify Switchboard for OS X.
I found that there is actually no decent way of accomplishing this, thanks to the way that networking is handled via separate interfaces. Although it would be possible to use two separate interfaces to connect to the same remote data source, it would require kernel-level programming skills to get these two interfaces working in unison... And the packets returned through each separate interface would be handled VERY differently, and the network packets would be far too out of sync with each other... So even then, if you were to create some sort of magic bridge to handle all of these situations and somehow use two separate interfaces to pull the same synchronous data, it would end up being (best case scenario) the exact same speed -- but likely SLOWER -- than with just one network interface. Far too much hassle for almost zero benefit.
i am working on a network discovery program which employs snmp to discover devices in the network. My program takes the router-ip as input, scans the iprotetable(iprouttenext hop),to determine if any other routers are connected to it. for non router devices (like switch) the algorithm scans the arptable (ipnettomediatable) of the router, but cant find the connected switch unless i ping from the switch to the router. is there any way where i can determine the device connected directly to the router ..?
Getting the devices connected to a router or switch is not that easy. Switches usually maintain a MAC forwarding database where it stores which MAC address has been seen on which switch port. This table can be easily read by using the bridge MIB. Unfortunately, there are several issues to take care of:
Those entries disappear again, when a device to the switch has been switched off or is simply not communicating. Usually, the entries in the MAC forwarding tables age out after 5 minutes or so.
The fact that a MAC address has been seen on a switch port doesn't mean that the device having the mac address is directly connected to the port. There might be any number of other switches, routers or hubs inbetween.
Some manufacturers like Cisco or HP use their own protocols to determine the network topology. There are several protocols (that area usually also available through a SNMP MIB):
CDP (Cisco Discovery Protocol): This is a proprietary protocol developed by Cisco to expose network topology information. Some vendors licensed this technology and implement that protocol in their products.
LLDP (Link Layer Discovery Protocol): A standard similar to CDP, but without paying Cisco license fees :-)
And many more. I know kthat Extreme Networks has their own protocols and I am pretty sure that other vendors have them as well.
The problem with those protocols is when you have a mixed environment. Cisco switches talking CDP do not understand Extremen Network's protocol and vica versa.
If your goal is to find IP addresses to discover, then you might use the ARP caches for routers. Scanning the ARP caches for switches makes no real sense, because they're operating on layer 2.
I was using broadcast message for my java snmp agent
I have to scan my Infrastructure and find it out the way I should use (WMI, SSH, SNMP, etc.) to discover the device details.
The approach I am following as of now is
Get the availability of device.
Query using WMI (If responding? use this protocol to discover this device)
If the above device does not respond to WMI use another protocol like SSH or SNMP (it's configurable) etc.
Is there any other way of discovery for a mixed environment? Please suggest.
The approach you are taking seems reasonable. Alternatively, you could have some existing software do this for you.