Selecting ethernet adapter using winsock in VS C++

Question

0.00/5 (No votes)

See more:

I have an application that needs to discover devices connected to a Windows PC. That PC may have multiple Ethernet adapters. This is done by sending a broadcast UDP/IP packet to which the device replies. Typically one adapter is connected to a WAN and the other a LAN. If Windows 'uses' the LAN as the primary adapter, or the WAN adapter is disabled, all goes well. If not, the reply doesn't make it back to the application (Wireshark verifies that the device receives and replies to the request). How can I force Windows to use the LAN adapter for broadcasting the discovery request and receive the reply?

What I have tried:

I've tried multiple web searches with no meaningful results.

Posted 11-Mar-19 9:35am

cwparker

Updated 12-Mar-19 5:57am

Add a Solution

Comments

Rick York 11-Mar-19 16:57pm

Using Wireshark with both adapters enabled, have you verified that the message goes out both of them? Are the addresses of the adapters in different subnets or the same one? This can make a HUGE difference.

[no name] 11-Mar-19 17:08pm

Why can't you just Ping a range in order to "discover"?

11917640 Member 12-Mar-19 2:58am

You need to bind UDP socket to the adapter IP address. Using GetIpAddrTable function you can enumerate all adapters and get their addresses.

cwparker 12-Mar-19 9:20am

The two adapters are connected to two different physical networks. For example, one adapter has an IP of 192.168.1.207 and the other has an IP of 172.28.74.254 (both with a subnet mask of 255.255.254.0). Windows thinks the adapter connected to 172.28.74.254 is the primary adapter. If the device is connected to the 172.28.74.x WAN, the app finds it. If it is connected to the 192.168.1.x LAN, it does not find it unless the 172.28.74.254 adapter is disabled. The IP address of the device is unknown, but for this example, let's say it's 192.168.1.2. It really doesn't matter what it's IP is. The problem is that the app can't find it if it isn't connected to the 'primary' adapter. For this app, there's no problem in having the user specify which adapter to use. It is a problem to disable the 'primary' adapter so that the device can be discovered on the 'secondary' adapter.

Yes, I've tried a lot of things. Selecting the adapter's IP with bind() does not work. My guess is because I'm trying to send and receive broadcast packets.

Since the device's IP address is completely unknown (may not be 192.168.1.x, could be 172.172.172.172 for example), it isn't really possible to ping a range to discover it.

I know Wireshark somehow manages to allow you to select the adapter you're sniffing, so it must be possible. I just don't know how to do it.

Rick York 12-Mar-19 10:54am

I am not sure if this will help but take a look at MSTCPIP.h and the functions GetAdaptersInfo() and SetAdaptersInfo(). They might help lead you to what you need. One possibility is to use those and programmatically disable an adapter so you can try the other one and find the machine.

cwparker 13-Mar-19 9:21am

OK, I think I've solved the mystery, but not the problem:

Enumerating all the adapters to get their IP address and using bind() before broadcasting the discovery request does work (as verified by Wireshark) but 2 things are happening that made me thing things weren't working:

1) I have Symantec (really hate it, but IT forces it on me) firewall running. What I've found is that Symantec blocks the incoming broadcast response from the device if it isn't on the primary adapter! If I disable Symantec, it sort of works (see 2).

2) The request sent on a non-primary adapter is echoed back. So the first recv() you do after the request, get the request back (I ignored since it was an invalid response). If I check for that, throw it away and do a second recv() I get the actual response! Odd, don't need to do that on the primary adapter?

So I can deal with 2) but for now, all I can do is tell the user to disable their firewall to get it to work with 1).

Thanks everyone for your help with this.

11917640 Member 17-Mar-19 2:01am

Device doesn't need to use broadcast, it can use sendto having the sender IP.

cwparker 19-Mar-19 8:22am

Unfortunately, the 'device' needs to broadcast it's response, otherwise the PC which is running the 'app' won't receive the response in the case where the 'device's IP address is 'logically' on another subnet than the PC's. For example, the PC's IP address may be 192.168.0.207 but the 'device's configured IP is 192.168.7.13 (both have a subnet mask of 255.255.255.0). Physically they're both on the same LAN (a switch will pass packets between them, switches don't care about subnet masks), but the PC will throw away a packet from the 'device' unless it's a broadcast (since the PC thinks it is from a different subnet). In this situation, I have no way to know what the 'device's configured IP address is, but I have to discover it, so that I can send a request for it to renumber itself to one that is on the same subnet as the PC (so then static IP packets will work).

The whole purpose of this 'app' is to renumber the IP address of the 'device'. The typical usage is to directly attach the 'device' to the PC and then run the renumbering 'app'. All works well if the user's PC only has one Ethernet adapter or the physical port they attach the device to is the 'primary' adapter. This is an existing 'app' that has been working well for years. Only recently have more and more laptops with WiFi adapters been identifying the WiFi port as the primary adapter causing the app to fail. I can't change the firmware in the device to deal with this, so I've been trying to update the 'app' to handle this situation.

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

steveb · Answer 1 · 2019-03-12T05:21:00

First glance at the quote

How can I force Windows to use the LAN adapter for broadcasting the discovery request and receive the reply?

would constitute an exploitable security hole sizeof Texas. It is usually up to network admins to configure adapters and requires root/admin access to do so.

Other than that each adapter has its own IP address. So knowing that address you can connect to the adapter in question and as long as there some type of server is running behind that adapter you can query it for whatever that server provides. It sounds like you searching for the bridge adapter:
"https://en.wikipedia.org/wiki/Bridging_(networking)"

Gerry Schmitz · Answer 2 · 2019-03-12T05:57:00

Solution 3

Sounds like you need a router.

The PC (with ONE physical adapter) goes to the router; the (wired and / or wireless) router in turn is connected to the WAN and the LAN.

To me that is more "typical" than what you're describing (2 NICs).

Posted 12-Mar-19 5:57am

Gerry Schmitz

Updated 12-Mar-19 5:58am

v2

Comments

cwparker 12-Mar-19 13:40pm

see comment for Solution 2. Not a WAN vs. LAN issue. I just used that in my example. All the Ethernet adapters could be connected to separate physical LANs.