We are trying to create a simulation script where we need to send TCP packet data to the server in way that it appears to be coming from different IP every time.
Basically we need to emulate multiple devices ( with different IP) which are constantly sending data to the server.
The server creates a new connection only for request coming in from a new IP.
What is the best possible way to achieve it ? Is there a way of using proxy servers or some sort of virtualization to accomplish this ?
What you want to use is IP aliasing. This allows you to create virtual network interfaces. Each virtual interface can have one or more IP addresses assigned to it.
This link shows how to do it in Linux.
This link shows how to do it in Windows.
Next your clients need to specify which of your addresses to use. Use getifaddrs() to enumerate the available addresses. Then use the bind() system call on the socket before you do a connect(). This way you can have multiple clients and each one will use a different source IP address. This post has the details.
Related
I need to connect and send request for websocket from different IPs in jmeter to my singalR server. How can I do it. I know in case of HTTP request we can do that in jmeter by creating multiple IP addresses alias on the machine as mentioned in the link https://www.blazemeter.com/blog/how-to-send-jmeter-requests-from-different-ips.
How this process will work for websockets.?
Thanks.
It will not as the possibility to set outgoing IP address needs to be present in the WebSocket plugin you're using.
Currently available solution is to allocate as many machines as IP addresses you need and run JMeter in distributed mode. If a single machine is powerful enough you can kick off several JMeter slave processes there, keep in mind that:
you need to have these IP addresses (or aliases) defined at OS level
you need to bind the slaves to different ports
If you can do Java programming you can add it yourself, the project lives at https://github.com/ptrd/jmeter-websocket-samplers, somewhere here
If you cannot - you can ask the plugin developer to add this feature either via GitHub or try reaching out to him via JMeter Plugins Support Forum
Basically I need to send data from Esp8266 to a server which is created using XAMPP on the laptop.
I have been using the following code on the ESP side
AT+CWJAP="dlink","password"
AT+CIPMUX=1
AT+CIPSTART=4,"TCP","192.168.0.105",80
AT+CIPSEND=4,6
123456 busy s...
AT+CIPCLOSE
My question is whether the IP address which i'm using is the correct IP for the server created using XAMPP? Do I need to send a GET request in order to send data? Do I need to make changes on the server side or just running the apache service is enough for my purpose?
The IP will be different in every network. I assume your network is set up with DHCP in which case the server might get different addresses every time.
There are mDNS libraries for ESP82666 that you can use to lookup the server by its local domain name (for example servername.local). Or you can configure the server to use a static IP.
I am working on some legacy code on Windows for a desktop app in "C.
The client needs to know the geo-location of the user who is running the application.
I have the geo-location code all working (using MaxMind: http://dev.maxmind.com/).
But now I'm looking for help in getting their external IP.
From all the discussions on this topic throughout SO and elsewhere it seems that there is a way to do this by connecting to a "reliable" host (server) and then doing some kind of lookup. I'm not too savvy on WinSock but this is the technology that may be the simplest to use.
Another option is to use WinHttpConnect technology.
Both have "C" interfaces.
Thank you for your support and suggestions.
You can write a simple web service that checks the IP address(es) that the program presents when connecting to that web service.
Look at http://whatismyip.com for an example.
Note that multiple addresses can be presented by the HTTP protocol if there are proxy servers along the route.
You can design your simple web service to get the IP of the client. See
How do I get the caller's IP address in a WebMethod?
and then return that address back to the caller.
Note that in about 15% of cases (my experience metric) the geo location will be way off. The classic example is that most AOL users are routed through a small number of proxy servers. However, there are many other cases where the public IP does not match the user's actual location. Additionally, Geo IP databases are sometimes just wrong.
Edit
It is not possible to detect your external IP address using only in-browser code.
The WebSocket has no provision to expose your external IP address.
https://www.rfc-editor.org/rfc/rfc6455
You need an outside server to tell you what IP it sees.
I like to send packet to a device with only MAC address associated to it and also connecting to my local LAN.
Is there anything in ruby / gem library that I can use to perform such task?
I want to do something like tcpreplay but in ruby instead. Thanks!
MACs are the addresses used on OSI layer 2, the package type you are using on this layer are e.g Ethernet frames. IP Sockets live on layer 3/4, thus if you are using an IP socket, you are sending IP packet.
So if you want to send something "to a MAC address", you need to send raw Ethernet frames which need to be understood on the other side. Given the really low level of this stuff, this is rarely what you really want to do.
Instead, you should try to get the proper IP addresses of the remote device in your local network (technically the broadcast domain) with either a broadcast/reply mechanism or with multicast (which is used e.g. by Bonjour). That way you can always use the much more supported IP layer. For that, your device needs to have an IP address of course. You can establish those with mechanisms like DHCP or address auto configuration for IPv6.
As for your question, I'm not aware of any library for Ruby to send raw Ethernet frames. But given you would need to invent a new protocol besides IP anyway (which is hard, really hard), sending the package is probably the least of your concerns.
I suppose there are a couple of approaches. You didn't say whether you wanted to send an IP packet of some kind, and if so you didn't say which IP protocol. (I can tell you want to send an ethernet frame but ... what encapsulated protocol?)
Anyway, you can open a SOCK_RAW with Ruby, something like:
Socket.open(Socket::PF_INET, Socket::SOCK_RAW, Socket::IPPROTO_RAW)
Another approach might be to just pick a link-local IP and then establish an IP/MAC mapping in your local ARP cache with something like:
system "arp -s host hw_addr"
Then you could communicate with it using more familiar socket ops using the link-local IP address.
You need to be root for all of these things.
Summary: I'm trying to create sockets to pass data between two physical interfaces that exist on the same machine, and Win32 sockets always forwards the traffic directly in the kernel instead of pushing through the physical interfaces. Is there any way to disable this behavior, perhaps through device settings, registry tweaks, routing table shenanigans, or socket options? We're using Windows XP SP3.
Some background. I'm attempting to build some completely automated IP tests to exercise our custom IPv4 equipment. We have a large lab of Windows XP machines, and individual physical ethernet interfaces for each device we're connecting to. Our devices are effectively ethernet routers each with their own IPs.
We need to send data out our lab machines, through our devices, then back into the same computer. We will be sending Unicast and Multicast UDP, TCP, and broadcast IP traffic through the devices.
We want (and likely need) the traffic to originate on the same machine it is destined to.
To do this, we configure two separate NICs each with their own IP on their own subnet, for instance NIC #1 with 10.0.0.1/24 and NIC #2 with 10.0.1.1/24. Our devices then act like simple passthrough routers, and have two interfaces, one on the 10.0.0.0/24 subnet, one on the 10.0.1.0/24 subnet, which they just forward packets back and forth from.
To generate our data, we'd like to be able to use Win32 sockets, since it is well-understood, well-supported, what our customers are using, and would probably be the most rapid approach. Packet injection is probably feasible for UDP and broadcast IP, but very likely not so for TCP. I'd entertain ideas that used packet injection, but would strongly prefer standard Win32 sockets.
As stated in the summary, the packets never leave the machine. I've googled like a madman and I've not found much. Any ideas?
Use Windows' command-line ROUTE utility. You can configure it so any IP packet sent to a specific IP address on a specific Subnet gets sent to another IP/device. For example:
route ADD <NIC_1_IP> MASK <NIC_1_SUBNET> <DEVICE_IP_CONNECTED_TO_NIC_2> METRIC 1
route ADD <NIC_2_IP> MASK <NIC_2_SUBNET> <DEVICE_IP_CONNECTED_TO_NIC_1> METRIC 1
Alternatively, if you know the index numbers of the NIC interfaces, you can specify them instead:
route ADD <NIC_1_IP> MASK <NIC_1_SUBNET> METRIC 1 IF <NIC_2_INTF>
route ADD <NIC_2_IP> MASK <NIC_2_SUBNET> METRIC 1 IF <NIC_1_INTF>
This way, whenever a packet is sent to NIC #1's IP, the packet goes to the device connected to NIC #2, which will then pass it on to NIC #1. And vice versa for packets sent to NIC #2's IP.
For instance, this is a useful technique for allowing WireShark to capture local IP traffic if the PC is connected to a network with a router. Packets from one local IP/Port to another local IP/Port can be bounced off the router back to the PC so they travel through physical interfaces that WireShark can monitor (WireShark will see duplicate copies of each local packet - one outbound and one inbound - but you can filter out the duplicates).
Winsock is always going to bring the packet data up into the kernel space and deal with it there. Thats the whole point to a generic API is that any device is dealt with at the same "layer". If you want to stick with Winsock, I don't believe you can (or would want to) work around this behavior.
You can remove some of the buffer copying with TransmitPackets or TransmitFile, but not between two device interfaces.
That being said, are you having a performance issue with the additional buffer coping that Winsock performs? Security concerns?
How about running the endpoints of your tester inside of distinct virtual machines? Then you need only a single piece of hardware, but you'll have separate TCP/IP stacks that don't know each other are local (and most VM solutions pass the packet straight through the host unchanged, I don't think the host is going to grab the packet and send it straight to another VM unless you configure bridging between VMs... but you'll bind each VM to a different physical network adapter).