I want to develop test application (something like IpSec, but much simple) that implement enacapsulating all IP packets of "PC" in some "another packets" with encription. This "another packets" are sent to another computer (smth like "proxy") that unpack original IP packets and send them to their original destination. Then this "proxy" receive packets for "PC" and decript them, incapsulate and send to "PC" and etc. Application must support working with NAT. I know that IPSec with NAT works only using NAT traversal therefore "another packets" will be udp, i.e. I'll encapsulate Ip in UDP with some encription.
I realize that winpcap not really that I need for develop such application.
Can I develop such application without special hardware, using only soft? What kind of tools should I use (maybe I need to write own driver)?
Ok, If you want to encapsulate your data into ip packets, then that is one thing.
here you say you wan t to encapsulate IP packets
considering OSI layers : wiki
As IP packets are layer 2
you wan't to reimplement layer 2.
I think it is something you can only find in drivers, and therefore hard dependent.
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 certain application running on my computer. The same application can run on many computers on a LAN or different places in the world. I want to communicate between them. So I basically want a p2p system. But I will always know which computers(specific IP address) will be peers. I just want peers to have join and leave functionality. The single most important aim will be communication speed and time required. I assume simple UDP multicast (if anything like that exists) between peers will be fastest possible solution. I dont want to retransmit messages even if lost. Should I use an existing p2p library e.g. libjingle,etc. or just create some basic framework from scratch as my needs are pretty basic?
I think you're missing the point of UDP. It's not saving any time in a sense that a message gets faster to the destination, it's just you're posting the message and don't care if it arrives safely to the other side. On WAN - it will probably not arrive on the other side. UDP accross networks is problematic, as it can be thrown out by any router on the way which is tight on bandwidth - there's no guarantee of delivery for it.
I wouldn't suggest using UDP out of the topology under your control.
As to P2P vs directed sockets - the question is what it is that you need to move around. Do you need bi/multidirectional communication between all the peers, or you're talking to a single server from all the nodes?
You mentioned multicast - that would mean that you have some centralized source of data that transmits information and all the rest listen - in this case there's no benefit for P2P, and multicast, as a UDP protocol, may not work well accross multiple networks. But you can use TCP connections to each of the nodes, and "multicast" on your own, and not through IGMP. You can (and should) use threading and non-blocking sockets if you're concerned about sending blocking you, and of course you can use the QoS settings to "ask" routers to rush your sockets through.
You can use zeromq for support all network communication:
zeromq is a simple library encapsulate TCP and UDP for high level communication.
For P2P you can use the different mode of 0mq :
mode PGM/EPGM for discover member of P2P on your LAN (it use multicast)
mode REQ/REP for ask a question to one member
mode PULL/PUSH for duplicate one resource on the net
mode Publish/subscribe for transmission a file to all requester
Warning, zeromq is hard to install on windows...
And for HMI, use green-shoes ?
i think you should succeed using multicast,
unfortunately i do not know any library,
but still in case you have to do it from scratch
take a look at this:
http://www.tldp.org/HOWTO/Multicast-HOWTO.html
good luck :-)
I would like to send data between two ethernet interfaces that are connected with a crossover cable in Linux. The two ethernet interfaces are on the same box. I defined the ethernet interfaces to have different static ip addresses (1.2.3.4 and 5.6.7.8) and have been using sockets to send bytes from one IP address to the other. I want to emphasize that I want the data to leave the box one interface of the box and get received on the other interface of the same box. One consequence of this is that unplugging the cable would prevent communication between the client and server on the same box.
The kernel is smarter than me I guess and decides it doesn't need to send information out on the wire and routes the data directly between the sockets internally, thus negating the test. I have tried to use SO_BINDTODEVICE to force the client to send data out of a particular interface, but the server never sees it. I am really stuck and this doesn't seem like it should be this difficult.
There are two entries in the route -n table
Dest Gateway Genmask flags metric use interface
1.2.3.0 0.0.0.0 255.255.255.0 U 0 0 eth0
5.6.7.0 0.0.0.0 255.255.255.0 U 0 0 eth1
You can not communicate using IP between 1.2.3.4/24 to 5.6.7.8/24 without going though a router. The problem is that IP can only talk to other computers in the same network segment. To calulate the network address you need to do a logic AND between both the interface address and the subnet mask. This will give you the network addresses. If the two network addresses are different then a router will be required. In your example you will have network address 1.2.3.0 and 5.6.7.0. Because these are different it will will to send data.
More importantly most network stacks are smart enough to see that if both interfaces are on the same computer it will not send the data all the way to the phyical interface. It will probably only send the message though the IP stack. But again it would need to be vaild address for it to work.
You should even be able to test a similar setup using just loopback network devices. (virtual network cards.)
Try using the following two IP addresses:
192.168.64.1
192.168.64.2
I'm not sure this is the problem, but 1.2.3.4 and 5.6.7.8 aren't on the same subnet. (Because when you apply the mask to each one, you don't get the same network address, as the Dest column is showing you.)
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.