On a win32 multiple nic computer, how to force DNS resolving through gethostbyname() on a specific nic if all nics have different DNS configured and have the same metric ?
Otherwise, how to know which DNS will be used to resolve names each time a gethostbyname() call will be performed by the application ?
You can't do this, at least I'm fairly certain you can't specify an interface to send out the queries from using gethostbyname() or any of the standard socket utilities. (There might be a very esoteric win32 option for this, but I'm betting against it)
If you absolutely need this functionality, you'll need to pick a third party DNS library that provides you with such an ability ... or even write one from scatch.
The library will need to provide you with a means of binding the UDP socket that will be issuing the DNS queries to a specified address.
There also might be a way of configuring Windows to issue DNS queries from an interface using system settings, but I strongly doubt there is a means of doing this from within a program.
That might be better answered at https://serverfault.com/ It's a site geared more toward administering a machine. SO is best for programming.
Consider to use raw sockets and implement your own DNS query mechanism.
Related
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 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.
I wrote a tool running on a system (Win7) with two network interfaces, each linked to a different subnet, each with its own gateway which is then linked to two separate distant networks (there are outgoing firewalls after each gateway). I’m initiating outgoing TCP connections via both NICs by using Socket.Bind (before doing Connect) to each relevant NIC’s IP address. First NIC is working fine, but for the second NIC, I’m getting SocketException: “A socket operation was attempted to an unreachable network”.
My original understanding was that since sockets are bound to concrete NIC’s local endpoint, which has its gateway defined, the connection should be routed to this gateway and therefore should work. However, it seems that source IP address is ignored and the routing is working according to local routing table (i.e. second NIC’s connect request goes to first, default, network and being rejected because it has wrong subnet).
Adjusting local routing tables helps, but it makes me wonder about the whole reasoning behind ability of the socket to bind to specific local IP.
Doing some extra reading, I found out that, indeed, there’s such thing as “source IP routing”, but it is disabled in Windows by default (via DisableIPSourceRouting registry setting), due to security reasons, as described, e.g. here:
http://msdn.microsoft.com/en-us/library/ff648853.aspx
http://www.bloggersbase.com/disableipsourcerouting/
Questions:
If my original understanding was correct (i.e. Socket.Bind should be enough) – why it is not working without modifying routing tables?
If my understand was NOT correct (i.e. Socket.Bind is ignored and routing is used) – what’s the point of having Socket.Bind? Why doing it at all?
Also, I’d like to understand better, what is the actual risk of having source IP routing enabled (preferably with example of a possible exploit)?
Any ideas of solving the requirement without manually modifying local routing table will be greatly appreciated.
Many thanks.
OK, after some reading, here are some high-level explanations on what's happening. I still need to verify the below conclusions in my system. Apparently, local binding is typically ignored when selecting network interface. Instead, routing table is used for this. However, in Strong Host Model (default for Vista and newer, non-existant in XP), source IP is used as a 'constraint' in the routing table lookup.
Brief explanation about strong host model vs. weak host model:
http://technet.microsoft.com/en-us/magazine/2007.09.cableguy.aspx
Explanation on what's different in XP vs newer Windows versions in respect to the above:
http://blogs.technet.com/b/networking/archive/2009/04/24/source-ip-address-selection-on-a-multi-homed-windows-computer.aspx
To help users, I would like my code to discover Oracle databases on the LAN. I thought to do this by first detecting all hosts, then checking each host to see if it is listening on Oracle's default port.
Any ideas how to go about this? Preferably in Java, but any language or algorithm would do.
Are you using DHCP? If so, your DHCP server has a list of the leases it has passed out. That should do you for a list of hosts on the LAN. Then try opening a connection to the Oracle port on each of those hosts and see if it accepts the connection.
It should be pretty simple to implement as a shell script with half a dozen lines or so. Java seems like overkill for something like this. Loop through the leases file, grab the IP from each lease, and telnet to the Oracle port; if it connects, disconnect and print the IP to standard out.
If you want to stay platform-independant, and unless you have access to some kind of database that lists the hosts, the only way to get a list is to try each IP address in the local network - might as well try to connect to the Oracle port on each of them.
There are lots of problems with this approach:
Will only search through the local network, which may only be a small part of the LAN (in case of large companies with lots of subnets)
Can take a long time (you definitely want to reduce the timeout for the connection attempts, but if someone has configured his LAN as a class A network, it will still take forever)
Can trigger all kinds of alerts, such as desktop users' personal firewalls, and intrusion detection systems - because you're doing exactly the same thing someone trying to exploit a security hole in Oracle servers would do
As brazzy points out, scanning for hosts is likely to cause problems, especially if there is a bug in your scanner.
A better approach may be to get the owners of the databases to register them somewhere, for example in a local DNS service (or does Oracle have zeroconf support?), or simply on some intranet webpage or wiki.
You better register the SID names/addresses to some server with a fixed address(maybe with a simple web service), and then query the list from there. Another approach is the bruteforce one (explained by #brazzy) by scanning one or more subnets, but this isn't really a good thing to do.
In case you are looking for a tool Loo#Lan can do this for you. Unfortunately there's no source available...
All of these smart answers are the reasons why many companies do not use the default port. Using a different port for each database is entirely possible, you know.
Consider the following setup:
A windows PC with a LAN interface and a WiFi interface (the standard for any new laptop). Each of the interfaces might be connected or disconnected from a network. I need a way to determine which one of the adapters is the one connected to the internet - specifically, in case they are both connected to different networks, one with connection to the internet and one without.
My current solution involves using IPHelper's "GetBestInterface" function and supplying it with the IP address "0.0.0.0".
Do you have any other solutions you might suggest to this problem?
Following some of the answers, let me elaborate:
I need this because I have a product that has to choose which adapter to bind to. I have no way of controlling the setup of the network or the host where the product will run and so I need a solution that is as robust as possible, with as few assumptions as possible.
I need to do this in code, since this is part of a product.
#Chris Upchurch: This makes me dependent on google.com being up (usually not a problem) and on any personal firewall that might be installed to allow pinging.
#Till: Like Steve Moon said, relying on the adapter's address is kind of risky because you make a lot of assumptions on the internal network setup.
#Steve Moon: Looking at the routing table sounds like a good idea, but instead of applying the routing logic myself, I am trying to use "GetBestInterface" as described above. I believe what it should do is exactly what you outlined in your answer, but I am not really sure. The reason I'm reluctant to implement my own "routing logic" is that there's a better chance that I'll get it wrong than if I use a library/API written and tested by more "hard-core" network people.
Technically, there is no "connected to the Internet". The real question is, which interface is routeable to a desired address. Right now, you're querying for the "default route" - the one that applies if no specific route to destination exists. But, you're ignoring any specific routes.
Fortunately, for 99.9% of home users, that'll do the trick. They're not likely to have much of a routing table, and GetBestInterface will automatically prefer wired over wireless - so you should be good. Throw in an override option for the .1% of cases you screw up, and call it a day.
But, for corporate use, you should be using GetBestInterface for a specific destination - otherwise, you'll have issues if someone is on the same LAN as your destination (which means you should take the "internal" interface, not the "external") or has a specific route to your destination (my internal network could peer with your destination's network, for instance).
Then again, I'm not sure what you plan to do with this adapter "connected to the Internet", so it might not be a big deal.
Apparently, in Vista there are new interfaces that enable querying for internet connectivity and more. Take a look at the NLM Interfaces and specifically at INetworkConnection - you can specifically query if the network connection has internet connectivity using the GetConnectivity method.
See also: Network Awareness on Windows Vista
Unfortunately, this is only available on Vista, so for XP I'd have to keep my original heuristic.
I'd look at the routing table. Whichever NIC has an 0.0.0.0 route AND is enabled AND has the lowest metric, is the nic that's currently sending packets to the internet.
So in my case, the top one is the 'internet nic'.
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.0.0.10 10.0.0.51 20
0.0.0.0 0.0.0.0 10.0.0.10 10.0.0.50 25
(much other stuff deleted)
Another alternative is to ping or GetBestInterface 4.2.2.2 - this is an old and venerable DNS server, currently held by GTEI; formerly by Sprint if I remember right.
Start > Run > cmd.exe (this works in XP and Vista): ipconfig /all
This displays all info about the interfaces in your computer. The "public" facing interface should have a public IP address. For starters, it should not be 192.168.x.x or 10.x.x.x :)
running traceroute to some public site will show you. Of course, there may be more than one interface that would get you there.
Look at the routing table? Generally, unless you're routing between the networks in windows (which is possible, but unusual for a client computer these days) the interface that holds the default route is going to have the Internet connection.
Your question didn't detail why or what you're doing this with so I can't provide any specifics. The command line tool "route" may be of some help, but there are probably libraries for whatever programming language you're using to look at the routing table.
You can't rely on the IP address of the interface (e.g., assuming an RFC-1918 address [192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8] isn't the internet) since most sites have some kind of NATed firewall or proxy setup and the "internet" interface is really on a "private" lan that gets you out to the Internet.
UPDATE: Based on your further information, it sounds like you have a decent solution. I'm not so sure about the choice of 0.0.0.0 since that's a boundary case for IP address -- might be OK on your particular mix of platform/language. Sounds (from the API description) like you could just specify an address, so why not some address known to be on the Internet, e.g. the IP address of your web site, or something more random like 65.66.67.68? Just make sure not to pick one of the rfc-1918 addresses, or the localhost range (127.0.0.0/8), or multicast, any other reserved range, and any address that resolves to a .mil or .gov (while it doesn't sound like getbestinterface sends any traffic, it would suck to find out by having the feds break your door down... :)
Looking at the network point of view, either could be routing to the "internet" at any time. If things like spanning tree protocol are enabled on a switch then you may find that what may have been the routing card to begin with may not be anymore.
Ping google.com though each NIC.