I want to route packets sended from my application to another gateway but i don't know what options i must change via setsockopt.
I can't just add entries to routing table for specific hosts because second application also must connect to these hosts but via default gateway. Gateways have different public IPs.
I found topic about set "source routing" options via IP_OPTIONS socket option (though without format), but as i understand this option only for routers not for my network adapter.
Also i cannot add second adapter and connect it to same LAN.
Any suggestions how i can send packets on per application basis? May be routing API
P.S.: Windows versions are 32-bit XP SP3, 32- and 64 bit Windows 7 and one 64-bit Windows Server 2008 R2.
Short answer : this is really hard, are you sure you want to do it ? It is not possible directly via set sock opt. Most probably there are easier choices by adding routes manually with the command line utility "route". That will the best choice if your final destination is a known IP or network and that normal traffic can be routed through the other gateway as well.
Longer answer : if you are a code ninja, you have the following two options, good luck, I have no idea whether that will work in practice:
use raw sockets and IP_HDRINCL to do source routing by hand (ie add an option in the IP header with the address of your proxy). See here for an intro.
you may be able to code a Winsock LSP (introduction here) that you can use to intercept some packets and re route them.
Related
I want to create a C++ application that can be used (in part) to communicate between users on a local area network using UDP. Each instance of the application will have a thread dedicated to listening for other instances of the application and broadcasting its presence to other instances.
Is there a reliable way to perform this type of broadcast/listening on the LAN using pure C++ and POSIX system calls? I know there's no generally reliable way to find all IPs on a LAN, but I assume this is only because other devices are not willing to respond to pings.
Don't re-invent the wheel. There are two existing technologies, that, when combined, solve your problem in a standardized, well-designed, proven manner:
RFC6762 mDNS (Multicast DNS) is a protocol that works almost exactly like DNS, except it works using IP multicast. Instead of sending your DNS request to a unicast address, you send your DNS request to a multicast group, and any member of that group can answer your request (so you may get multiple answers).
RFC6763 DNS-SD (DNS-based Service Discovery) is a way to encode Services as DNS entries, which allows you then to retrieve Services from DNS using specially encoded hostnames. (For example, looking up the hostname _ipp._tcp.example.com would return a list of all printers that support the Internet Printing Protocol over TCP within the domain example.com)
So, we have one protocol that allows us to ask DNS about Services, and we have one protocol that allows us to ask a group of hosts to answer DNS queries … when we put the two together, we get a way of asking hosts for services! The combination of those two protocols is sometimes called Zeroconf networking, and is already implemented in macOS, iOS, tvOS, and watchOS (where it is called Bonjour), Android, most Unices (via Avahi, a portable implementation of those two protocols), and many home devices such as TVs. E.g. Spotify Connect, ChromeCast, Philips Hue and many others are also based on it. It's how iTunes devices find each other on the local network, for example.
Unfortunately, support in Windows is still limited, at the moment it seems to only exist for Windows 10 apps implemented in ECMAScript. (However, nothing stops you from shipping your own implementation with your app, and AFAIK, both Avahi and Apple's mDNSResponder work on Windows.)
So, what you would basically do is to send an mDNS query to the mDNS multicast group and ask for _myprotocol._udp.local. Then, assuming that your application registers itself with the OS's mDNS service (i.e. Bonjour on macOS, Avahi on Unices, …), you would get back a list of all hosts on the local network that support your protocol.
I'm writing a very simple server-client application in C++, using WinSocks.
When I set client's parameters as: resolveHost ("google.pl") for server's IP and 80 for port, I receive a html (with GET header).
When I run the server first (with port 10000) and then client (port 10000 IP inet_addr("127.0.0.1") it seems to works (I receive something).
But when I change the server's IP in client to inet_addr("188.246.158.171") (my IP for now, I don't have static IP, I've checked my actual IP with some website), it for sure DOES NOT works.
My computer is behind the router - can it be the problem?
If so, can I solve it in the way that don't requite any configuration to router (port forwarding etc.). Also, I don't want to make anything router's model-specific, so I intentionally haven't posted the model of my router ;)
Why I don't want to change configuration?
Because my application will be for "simple people". And simple people won't try to make configuration, and I won't require them to do so.
Also, many applications (on-line games for example) works fine with my router without any configuration - my application cannot be exception (by the example of other applications on my computer, I know it's possible and common to achieve it).
I use Visual Studio 2012, works on Windows 7 x64.
If you run a listening server behind a router, you must configure port forwarding rules on the router if you want outside clients to reach the server through the router. You cannot avoid that. However, if the router supports uPnP (Universal Plug and Play), your server code can configure port forwarding rules programmably, such as with Microsoft's IUPnPNAT interface. Otherwise, you have to use the router's own configuration software (usually an HTTP interface running on the router itself).
You also have to configure ports/permissions on a local firewall, if installed. Some firewalls have APIs for that, such as Microsoft's Firewall.
Online games and other peer-to-peer apps employ several NAT Traversal techniques to get around NATs, firewalls, etc. Hole Punching, Role Reversal, etc. Do some searches, information is readily available.
We want to add a 'collaborative' feature to our application, so our program should be able to automatically discover all other instances of itself that are running on the same local network, without needing any extra configuration from the users.
Our application runs on Windows, so it can use any APIs provided by the OS. We are assuming a network typical for a small business, a couple of Windows PCs, some routers, etc.
Also, will there be problems with anti-viruses, firewalls, and such? We don't want to scare our users.
You can send broadcast packets for that but that only works within a single subnet (actually apparently a "broadcast domain" but it's usually the subnet). If you just try every IP you can think of you might trigger firewall pop-ups that suggest that your software is trying to hack the computer. I think the best way is to use broadcast for the current subnet and offer a user interface for adding other hosts.
I have a solution that acts as client service and does some background work. This application requires some settings (that are read from an xml file) to be done at installation time and which are periodically revised. For convenience (as this service is installed on multiple machines) I wanted to control these settings remotely from a central server application. This works fine if the server and client are inside the LAN but I would like to control these settings even if the client is outside the network or the server is behind a firewall. What could be the solutions to do this?
Clearly, the solution depends on exactly what you want to achieve. But if I understand it right, the reason you have "problems" with a firewall is that you simply access the file that contains the XML over the network using standard network file access. Which is typically (for good reason) blocked by the firewall.
So, the solution then would be to use a standard protocol and a "non-standard service". For example, if the machine is allowed incomming HTTP requests, you could use HTTP-based post messages to update the XML content, either send the entire file as a file upload, or make up your own remote access protocol. If HTTP is not allowed, then you have to look at what other "holes" there are in the firewall, and do something similar with another of the "holes".
The other, less obscure solution, is of course to simply use a remote-desktop or secure shell connection to remotely access the machine. Of course, again, assuming this sort of connection is allowed.
There is no magical "bypass firewall" solution - you have to work within the rules of the firewall in some way.
I need to write a win32 c/c++ application which will be able to determine whether the PC it's running on is connected to one of 2 networks. The first network is the company LAN (which has no internet connection) and the second network is a standalone switch with a single PC connected to it (the PC that the program is running on).
I'm pretty new to network programming but so far I have tried testing to see if a network drive which is held on our LAN can be mapped. This works fine if the PC is connected to the LAN, the drive mapping succeeds so so LAN detection is successful. However, if the PC is connected to the switch, this results in a VERY long timeout which is not a suitable as it will delay the program so much as to make it unusable.
Does anyone have any alternative suggestions?
I'm using c/c++ in VS 6.0
[Update]
Whilst trying a few different ideas and looking at some of the suggestions below I thought I should update with some additional information as many (if not all) of the suggestions I don't think will work.
(1) The aforementioned LAN has no external connections at all, it is completely isolated so no resolving of external DNS or pinging websites is possible.
(2) Hostname, MAC address, IP, Default Gateway, Subnet etc etc (basically everything you see in ipconfig -all) are all manually configured (not dynamic from the router) so checking any of these settings will return the same whether connected to the LAN or the switch.
(3) Due to point (2), any attempts to communicate with the switch seem to be unsuccessful, in fact almost all networking commands (ping, arp etc) seem to fail - I think due to the machine trying to connect to the LAN when it isn't there :-(
One thing I have found which works is pinging the default gateway IP which times out when connected to the switch. This is sort of ok as I can reduce the timeout of ping so it doesn't just hang for ages but it feels like a bit of a hack and I would certainly appreciate any better solutions.
Thanks
As far as TCP/IP is concerned there is no such thing as a LAN on WAN. There are a set of non-internet routable addresses like 192.168.x.x and 10.x.x.x but these are sometimes used by ISP short of IP addresses.
You best bet is to use Asynchronous APIs when making TCP/IP connections. WIN32 defines a whole buch of OVERLAPPED APIs for this purpose. This will prevent your application from grinding to a halt while waiting for a remote connection.
Alternatively put the socket stuff into another thread and then only notify the UI when the operation is done.
I would first try to differentiate between the two using information available locally--that is, from your computer. Does the output of ipconfig /all differ depending on which network you're connected to? If so, exploit that difference if you can.
Is it possible to get the MAC address of the standalone switch? Of the switch that controls the company LAN? That would be a sure way to tell. Unless somebody cloned the MAC address.
If you try using the existence or non-existence of some network service to determine which network you're connected to, you can never be sure. For example, if you failed to map that network drive, all you know is that the network drive isn't available. You can't say for certain that you're not connected to the company LAN. Same is true if you use ping. Lack of response from a particular machine means only that the machine didn't respond.
Various things you can look at for differentiation:
DNS domain name (GetComputerNameEx)
MAC address of gateway (ping it, then GetIpNetTable)
Routing table(do you have a gateway and default route on the company LAN)
WNet discovered network resources (WNetOpenEnum, WNetEnumResource)
Ability to resolve external hostnames (try a 5-10 names like www.google.com, www.microsoft.com and so on, if one resolves you should have internet)
You'll have to decide how many indicators are "enough" to decide you're on one or the other LAN though if tests fail. Then keep retrying until you have a definite result.
http://msdn.microsoft.com/en-us/library/aa366071%28v=VS.85%29.aspx has a lot of network related functions that you can experiment with to create further indicators.