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
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.
Overview: I live in an apartment, and I wish to use Cisco routers to run my network for career development. I plan to place a 40 thread server in the other bedroom because I can't run it in the same room as my current desktop because it would overload the circuit. As a result, I require a Cisco router running IOS (I want the CLI) that possesses wireless capabilities to allow my IoT devices and phones/laptops to connect to the internet. I also require another cisco router with wireless capabilities to act as a bridge to the network for the server. I will also use two cisco switches, but that is the easy part of the equation unless the routers I find also have switches inside.
Running cables isn't an option because I can't drill the walls, and I would then have to run the cables from one bedroom to the other, which is not ideal.
Problem: The problem I am finding is that there is extremely cheap cisco routing equipment on eBay, but I am unable to know if these products have the capabilities I require. Also, finding the wireless NIC card that can be inserted into these devices is not easy. Deciphering compatibility is another issue entirely.
Question: Can someone please assist me in picking my devices. I am looking to use pre-owned hardware due to cost.
ISP: Version Fios 1gb pipe.
It would be expensive to create bridge over WiFi using Cisco routers, not just cost but the expertise to make it work. You are better off getting cheap Cisco IOS routers like old 2800 or 2900 series, then use two cheap WiFi routers like TP Link for the WiFi bridge. So your setup would look something like below.
[BEDROOM DEVICES] --> CISCO RTR Ethernet --> TPLINK WIFI BRIDGE
Same on the other end as well.
First allow me to say that I don't have any experience developing drivers for OSX, nor drivers for Windows. So, there are a lot of things that I don't understand about how drivers work; I'm sure it'll be evident in my question.
I have a modem that is able to open and close TCP/UDP sockets using AT commands. I would like to create some kind of program (kernel extension? driver?) that implements a network driver, converting the network interface calls into AT command serial messages.
That's the basic jist of it. I'm essentially asking if anybody can point me in the right direction / give me a high level overview of how they would approach it and what Apple guides to focus on.
The XNU networking stack -- like most network stacks -- expects network devices to send and receive IP packets directly. It isn't tooled to work with network devices that handle part of the network stack (like TCP or UDP) internally -- it won't be possible to implement a network driver which uses this device.
You might have more luck exposing this device as a SOCKS proxy. You will need to write a userspace daemon which listens on a TCP port on localhost (on the computer) and relays traffic to the serial device; once that's done, you can set the computer to use that device as a SOCKS proxy in the Networking control panel.
(As an aside: most devices that implement this type of interface have a very low limit on the number of open sockets -- often fewer than 10. They're unlikely to be able to handle the network load generated by a desktop OS.)
Summary: I'm trying to create sockets to pass data between two physical interfaces that exist on the same machine, and Win32 sockets always forwards the traffic directly in the kernel instead of pushing through the physical interfaces. Is there any way to disable this behavior, perhaps through device settings, registry tweaks, routing table shenanigans, or socket options? We're using Windows XP SP3.
Some background. I'm attempting to build some completely automated IP tests to exercise our custom IPv4 equipment. We have a large lab of Windows XP machines, and individual physical ethernet interfaces for each device we're connecting to. Our devices are effectively ethernet routers each with their own IPs.
We need to send data out our lab machines, through our devices, then back into the same computer. We will be sending Unicast and Multicast UDP, TCP, and broadcast IP traffic through the devices.
We want (and likely need) the traffic to originate on the same machine it is destined to.
To do this, we configure two separate NICs each with their own IP on their own subnet, for instance NIC #1 with 10.0.0.1/24 and NIC #2 with 10.0.1.1/24. Our devices then act like simple passthrough routers, and have two interfaces, one on the 10.0.0.0/24 subnet, one on the 10.0.1.0/24 subnet, which they just forward packets back and forth from.
To generate our data, we'd like to be able to use Win32 sockets, since it is well-understood, well-supported, what our customers are using, and would probably be the most rapid approach. Packet injection is probably feasible for UDP and broadcast IP, but very likely not so for TCP. I'd entertain ideas that used packet injection, but would strongly prefer standard Win32 sockets.
As stated in the summary, the packets never leave the machine. I've googled like a madman and I've not found much. Any ideas?
Use Windows' command-line ROUTE utility. You can configure it so any IP packet sent to a specific IP address on a specific Subnet gets sent to another IP/device. For example:
route ADD <NIC_1_IP> MASK <NIC_1_SUBNET> <DEVICE_IP_CONNECTED_TO_NIC_2> METRIC 1
route ADD <NIC_2_IP> MASK <NIC_2_SUBNET> <DEVICE_IP_CONNECTED_TO_NIC_1> METRIC 1
Alternatively, if you know the index numbers of the NIC interfaces, you can specify them instead:
route ADD <NIC_1_IP> MASK <NIC_1_SUBNET> METRIC 1 IF <NIC_2_INTF>
route ADD <NIC_2_IP> MASK <NIC_2_SUBNET> METRIC 1 IF <NIC_1_INTF>
This way, whenever a packet is sent to NIC #1's IP, the packet goes to the device connected to NIC #2, which will then pass it on to NIC #1. And vice versa for packets sent to NIC #2's IP.
For instance, this is a useful technique for allowing WireShark to capture local IP traffic if the PC is connected to a network with a router. Packets from one local IP/Port to another local IP/Port can be bounced off the router back to the PC so they travel through physical interfaces that WireShark can monitor (WireShark will see duplicate copies of each local packet - one outbound and one inbound - but you can filter out the duplicates).
Winsock is always going to bring the packet data up into the kernel space and deal with it there. Thats the whole point to a generic API is that any device is dealt with at the same "layer". If you want to stick with Winsock, I don't believe you can (or would want to) work around this behavior.
You can remove some of the buffer copying with TransmitPackets or TransmitFile, but not between two device interfaces.
That being said, are you having a performance issue with the additional buffer coping that Winsock performs? Security concerns?
How about running the endpoints of your tester inside of distinct virtual machines? Then you need only a single piece of hardware, but you'll have separate TCP/IP stacks that don't know each other are local (and most VM solutions pass the packet straight through the host unchanged, I don't think the host is going to grab the packet and send it straight to another VM unless you configure bridging between VMs... but you'll bind each VM to a different physical network adapter).
Does anyone know a good method for mapping devices on a network?
I am looking for something that can establish the connection layout between devices to build a visual network diagram.
Any ideas?
This isn't an algorithm, but rather a protocol (or protocols) for discovering neighbors. If your switches/devices have Link Layer Discovery Protocol (LLDP) enabled, you can use that to determine a network of physical connections.
Note that older Cisco switches might not have LLDP, but will have CDP, a proprietary implementation of discovery. Same goes for Nortel and Extreme switches which also have their proprietary protocols. But LLDP is now the standard (802.1AB) that should be used for discovery.
You can also see on the Wikipedia page that there are implementations of LLDP (and other proprietary protocols) for Linux/Windows/Mac. Also, VMware ESX implements CDP.