I was exploring the ACE frame work and started experimenting its sockets framework. I would like to know if there is a way to spoof the source IP-Address in the IP-Packet using ACE Frame work.
I know this can be done using raw sockets of BSD Sockets. Moreover, I want to know the Local IP-Address of a machine for a particular interface (say eth0, wlan etc).
What I have tried is the following:
ACE_INET_Addr my_addr(1234);
cout<<my_addr.get_host_addr()<<endl;
The get_host_addr() returns the IP-Address of the local machine. But sadly, it prints 0.0.0.0 which is equivalent to INADDR_ANY. So what could be the appropriate solution?
Thank you.
Related
I'm trying to write a function that can get me the IP adress (and the name of the device as bonus) of devices that are in my network, the network is gonna be a direct connection between two computers using Ethernet cable or creating an access point (using wi-fi)
I tried to search about how to do it but it seems like I need to listen to the network or something which seems to be difficult.
hope you can guide me to what I should do or read to get started.
Note: I'm using Windows on both computers.
Edited:
P.S: I need the IP Address so I can send a message to the other computer using winsock in a Client/Server program I wrote.
can't I make the server send its IP to the client or the opposite ?
If your software is running on both machines, you can have one (or both) machines send out a particular broadcast (or, if you prefer, multicast) UDP packet on a specific port. Your program should also be listening on that same port. When it receives that packet (using recvfrom()), recvfrom()'s fifth argument will contain the IP address of the machine that sent the packet, i.e. the IP address you want.
(If OTOH your software is not running on the remote machine, you'll need to use some more general-purpose discovery mechanism such as mDNS or LLDP -- hopefully you won't have to do that, though, as it's a good deal more complicated)
I would like to time how quickly the latency is of a system by sending a packet with the same dest IP as the source IP. Is this relatively simple to do?
How would you custom-build the packets?
Would setting the two IP addresses achieve what I am after?
What is the best timing method?
Any tips/ideas at a low/high level would be greatly appreciated. I intend to use C/C++ on Unix with the boost libraries and libpcap.
EDIT: I should add I will be doing this on a home network, behind a router. I presume the packet will go to the router and come straight back if I were to use 192.168.2.1 (local IP of my system) for the source and dest addresses.
You can just try ping to your own IP. this will produce ICMP packets. There are libraries which also allows you to do the same from an application.
If you want to create packets for yourself you can use socket API. Remember, you can send the source IP address and destination IP address as same, but the port number needs to be different.
For timing you need can use gettimeofday function.
EDIT:
you can ping from your C++ program. See: http://verplant.org/liboping/ or check out some other forum. The reason i emphasized on ping is because it returns right back from the network stack. If you send a UDP packet on the other hand, expecting the application to return and echo, then the processing time of the packet on the listening server gets added.
If you ping to local machine ip (or even lo) it returns without going to switch or next hop router. It will respond even if you remove your eth cable or wifi.
What you are trying to do is implemented in NTP daemon with NTP protocol though.
You don't need a custom package for this. Just create a socket connecting to the same ip-address as the server, and start sending packages. Note that these packages will never leave the network stack, so what you will be measuring is basically how quick the system copies data between user-space and kernel-space.
For the timing, you can use the clock function, it's probably the one most widely used for such things.
I have a compiled client application without the source code. It connects via TCP to my server on port 7777 (this is the destination). I would like to change the application to use a different port and there is no settings on the client to change it easily. This leads me to believe that it is hard-coded into the application.
I have messed around a little bit with it but I am not a professional reverse-engineer and this proves to be too difficult for me to figure out alone. Is what I am trying to accomplish even possible?
How did you compile this without the source code? That question aside.
Look for 7777 (hex 1e61) i.e. 1e followed by 61 (or the other way around) in a binary editor and change it.
This will depend on the platform and the available tools. If you can use strace on your environment, you can process the output and determine where the port is opened, and with that information go back to the binary, disassemble it, locate the function that is making the call, and try to determine how the port number got there.
You can use socat to create a TCP forwarding proxy. From socat examples:
socat TCP4-LISTEN:www TCP4:www.domain.org:www
installs a simple TCP port forwarder. With TCP4-LISTEN it listens on local port "www" until a connection comes in, accepts it, then connects to the remote host (TCP4) and starts data transfer. It will not accept a econd connection.
It is a less flexible approach than using iptables because the socat proxy must run on that server your client connects to.
I am currently working on creating a scalable server design in C++ for a ubuntu server. Is piping across a LAN achievable? What is the best option for speedy inter-LAN communication?
Background Info for those interested:
I'm making a multiplayer game with a friend. It's going to be TCP based. The thing is for linux making a server be multi client seems to mean creating a new process per client or select()ing through a fdset of connected clients. I want to combine these approaches and have a "manager" process that will select through maybe 100 clients and report any changes up the chain to a "taskmaster" process which will then distribute the change to the other manager processes. This will work fine with piping if the managers and taskmasters are on the same box, but if I want to scale it later I need a speedy inter-Lan communication method.
Checkout the netcat application. On one machine, you can run netcat as a server, piping the output to your process:
nc -l -p 1234 | myApp
This will listen on TCP port 1234, and print everything it receives out over stdout.
And on a second machine:
myApp | nc 192.168.1.2 1234
Where 192.168.1.2 is the IP address of the first machine. You'll need to look up the nc man page for the specific details - the above is all from memory.
A stream socket (SOCK_STREAM, combined with AF_UNIX if stricly local or AF_INET if over tcp/ip) is the network equivalent of a bidirectional pipe, with all data ordered.
Just the way you are asking that question, you seem to have the perception that for communication between related processes, pipes is the necessary answer.
The way to think about it is that you need communication between two processes, whether they be a couple of components in your system, client server pair, or whatever. Then you pick a mechanism that works for the given geography. Pipes work if the processes are local. You could also use shared memory queues for a no copy channel. You could also use IP (via sockets) over the loopback interface. To go across the network (WAN or LAN) you pretty much have to use IP.
Lastly, in addition to TCP, consider using UDP as well, because you get builtin message boundaries and easier endpoint management.
LANs typically are Ethernet based networks. This means that any protocol running on your network must be Ethernet based. TCP/IP can and does run on Ethernet networks but pipes and Local sockets are only designed to be an inter-process communication on a single host so is totally not suitable for multi-host applications.
If the various components run on different host, you will need to link them via some TCP/IP based protocol. There are some legacy protocols like IPX and UUCP that run over Ethernet but these have been totally superseded by TCP/IP.
Is there an existing Linux/POSIX C/C++ library or example code for how to rebind a socket from one physical interface to another?
For example, I have ping transmitting on a socket that is associated with a physical connection A and I want to rebind that socket to physical connection B and have the ping packets continue being sent and received on connection B (after a short delay during switch-over).
I only need this for session-less protocols.
Thank you
Update:
I am trying to provide failover solution for use with PPP and Ethernet devices.
I have a basic script which can accomplish 90% of the functionality through use of iptables, NAT and routing table.
The problem is when the failover occurs, the pings continue being sent on the secondary connection, however, their source IP is from the old connection.
I've spoken with a couple of people who work on commercial routers and their suggestion is to rebind the socket to the secondary interface.
Update 2:
I apologise for not specifying this earlier. This solution will run on a router. I cannot change the ping program because it will run on the clients computer. I used ping as just an example, any connection that is not session-based should be capable of being switched over. I tested this feature on several commercial routers and it does work. Unfortunately, their software is proprietary, however, from various conversations and testing, I found that they are re-binding the sockets on failover.
As of your updated post, the problem is that changing the routing info is not going to change the source address of your ping, it will just force it out the second interface. This answer contains some relevant info.
You'll need to change the ping program. You can use a socket-per-interface approach and somehow inform the program when to fail over. Or you will have to close the socket and then bind to the second interface.
You can get the interface info required a couple of ways including calling ioctl() with the SIOCGIFCONF option and looping through the returned structures to get the interface address info.
I do't think that's quite a well-defined operation. the physical interfaces have different MAC addresses, so unless you have a routing layer mapping them (NAT or the like) then they're going to have different IP addresses.
Ports are identified by a triple of <IP addr, Port number, protocol> so if your IP address changes the port is going to change.
What are you really trying to do here?
I'm not at all sure what you're trying to accomplish, but I have a guess... Are you trying to do some kind of failover? If so, then there are indeed ways to accomplish that, but why not do it in the OS instead of the application?
On one end you can use CARP, and on the other you can use interface trunking/bonding (terminology varies) in failover mode.