How can I create a client UDP socket in C++ so that it can listen on a port which is being listened to by another application? In other words, how can I apply port multiplexing in C++?
I want to listen on only one port
You can do that with a sniffer. Just ignore the packets from different ports.
I might need to stop it from sending out some particular packets, because my program will send it instead of the original application
Okay, here I suggest you to discard sniffers, and use a MITM technique.
You'll need to rely on a PREROUTING firewall rule to divert the packets to a "proxy" application. Assuming UDP, Linux, iptables, and the "proxy" running on the same host, here's what the "proxy" actually needs to do:
1. Add the firewall rule to divert the packets (do it manually, if you prefer):
iptables -t nat -A PREROUTING -i <iface> -p <proto> --dport <dport>
-j REDIRECT --to-port <newport>
2. Bind and listen on <newport>.
3. Relay all the traffic between the 2 endpoints (client, and original destination). If you're running the "proxy" on a different host, use getsockopt with SO_ORIGINAL_DST to retrieve the original destination address.
It might sound tricky, but... yeah, that's because it's a bit tricky :-)
Consult your firewall documentation if my assumption diverges.
This is just packet sniffing like tcpdump or snoop, open up a raw socket and pull everything from the wire and filter as you require. You will probably want to use libpcap to make things a little easier.
Without administrator or super-user privileges you will need the target application to open ports with SO_REUSEADDR and SO_REUSEPORT as appropriate for the platform. The caveat being you can only receive broadcast and multicast packets, unicast packets are delivered to the first open socket.
This is not multiplexing - that term is reserved for handling I/O on multiple channels in the same process and where things like select(2) and poll(2) are most useful.
What you are asking for is multicast. Here is the basic example.
Note that IP reserves a special range of addresses (a.k.a. groups) for multicasting. These get mapped to special ethernet addresses. The listener(s) would have to join the multicast group, while sender does not have to, it just sends as usual.
Hope this helps.
Related
I'm developing an application for WAN data optimisation, including SQUID (using TPROXY redirect) for web caching. The software modifies the TCP options to negotiate parameters with another remote instance of the software (used in the optimisation algorithm). Since SQUID will establish the TCP connection with the requesting browser and the WAN packets may be sent over an IPSec tunnel the software MUST run between these two components.
I've be able configure the system such that SQUID will correctly handle the LAN side request, and on a cache miss send packets into my software (using a TUN/TAP interface), modify the TCP header (and correct the csum) and send it back into the kernel through a second TUN/TAP interface.
For packets being sent into the WAN after a cache miss:
For IPv4 if I sent rp_filter=2 on the first tap (and manually add the ARP entries) the packets are correctly routed
For IPv6 the kernel seems to black hole the TCP SYN sent from SQUID. This is a packet associated with a socket created locally, received back into the (same) kernel to be routed out to the WAN. If I modify the source or destination ports (i.e. make it look like a different socket) of the packet it is correctly routed out the tunnel/interface.
Are there any sysctl parameters / cleverness in iptables that could explain why these packets are dropped and how do I fix it?
I'm using a Linux (Debian based) system on which IP forwarding is enabled (/proc/sys/net/ipv4/ip_forward is set to 1). I can read the incoming packets using a C++ raw sockets program, but I want to modify their content before they are forwarded (using BSD sockets only). This link mentions that I can use an "iptables REDIRECT rule" to send the incoming packets to a port my program is listening on, but I didn't find any information on how exactly this should be done. Mainly, I want to know:
How I should forward the packets after modifying them. Do I have to send them manually from the program to their destination address after they are received and modified?
What I should do in case the program isn't listening on a particular port (e.g. a program concerned with only the IP headers of the packets).
In case it matters receiving and forwarding are done on the same wireless interface. I have to forward packets to, and receive packets from devices on the same WLAN.
I am working on an application that will receive RTP packets from another local service over UDP. Early in the protocol, I receive a message with the IP address from which I'll be receiving these RTP packets, but the port number will be given as 0 (zero) ... I'm to open my UDP socket using an ephemeral port. My response to the given message will contain the actual port I've opened so the sender can know where to direct the packets.
My networking library is an implementation of sockets with boost::asio. Where can I find clear information on how to open such a socket without specifying a non-zero port i.e. use an ephemeral port? Searching the boost docs for "ephemeral" doesn't give me networking results.
Of course, I'm open to seeing an actual example, but finding good documentation would also be just fine.
Thanks.
I would question using ephemeral ports like that, but ... - you can bind your UDP socket to port 0, then use local_endpoint() to retrieve actual port assigned by the OS.
I have a C++ application which accepts TCP connections and then reads the traffic sent to it. It has worked very well until I moved it to a new machine. It seems like winsock never accepts the inbound tcp connection. In my code it never returns from the select statement. I can see using netstat/tcpview that the application is listening on port 14005.
I can connect to this port if I just telnet in locally. However, when someone tries to connect in via an outside IP address the TCP 3 way handshake never finishes. I can see the inbound SYN packet in wireshark. It is going to the correct port, 14005. However my system never sends the SYN-ACK back. This is just something that winsock is suppose to handle right? The machine does have multiple NIC cards, but I'm binding with INADDR_ANY so this shouldn't matter. Is there some way I can dig deeper to see why this handshake never takes place?
per ways to dig deeper: nothing more than wireshark / tshark (which you already use, however if you want to play with packets, look at scapy)
what happens if you reduce headache - only use one nic and network, put the client on the same network (ie, no router or smart switch between), (last resort) disable unneeded network services.
Is there any method in c++/vc++/mfc so that I can verify whether remote machine is on network or not. I don't want to use ping command. I tried to use WSAConnect method but it takes lot of time in searching if remote machine is not on network. In that case application windoe freezes for long time. I need alternate way to verify remote machine netwotk connectivity. Plz help
You can check to see if a host name exists and if DNS can resolve an IP address for it, but this won't tell you if it's online. In order to determine if it's online, you must exchange data with the host. For this to happen the host must be listening on a port, and must send some sort of response.
Generally, the lowest common denominator for hosts is the ICMP packet - aka ping. You can write your own service in C++ to send these UDP packets, and detect a reply.
Some hosts and some routers disable ICMP to appear 'invisible'. If you know that your host accepts connections on a TCP port, you can attempt to create a tcp socket. For example, from a shell you can test using nc
nc -z google.com 80
Connection to google.com 80 port [tcp/http] succeeded!
If you do raw socket programming, you can attempt to connect to a host via, and then call select() with a short timeout.
If you don't want your app to block, use a thread.
If the only issue is that calling WSAConnect locks up your UI, you can try calling it in nonblocking mode.
Call WSAEventSelect to set the socket to nonblocking mode prior to calling WSAConnect. You then call WSAAsyncSelect or WSAEventSelect to check the status of the connection.
MSDN's page on WSAConnect has some remarks about nonblocking mode here.
You can use tracert command. Example:
tracert -w 1000 192.168.0.77
You can check if the machine is connected to a network, but without trying to transmit data to a site residing on the internet I don't think there is a way to check if that network is actually online. For example your end user might as well be connected to a DSL router which is not online at the moment.
You can use arping for it.
Also some smart switch can talk about attached host.