Is there a way that, using WinPcap, I can read a packet and if that packet is going to a certain domain name, I can block the packet with a custom HTML page? Like, if I wanted to go to myspace and my program saw that, is there a way I could return HTML saying "Site Blocked"?
WinPcap provides the capability for sending packets, so using this capability you can terminate a tcp session by preparing a packet with the IP address and port numbers of the offending packet with the FIN flag ON and then send the packet to the server so that it closes the session and send it(with modification) to the client to stop it waiting for incoming packets.
Related
Writing a UDP client-server app in C++ (done that lots of times before in many languages in the past 15 years), but somehow this one is not working correctly.
I cannot post actual code nor minimal reproducible app at the moment but I am willing to pay for live help if anyone is available to help solve this quickly with screensharing.
I think this is a particularity with C++ sockets and the way I am using them in this specific app which is quite complex.
Basically the issue is that the packets sent from the server to the client are not received by the client, only when said client is on a separate nat.
When both in same local networking and using their local IP, everything works as expected.
Here is what I am doing :
Client sendto(...) packets through UDP to the server using a specific server host and port 12345 (and keeps sending these non-stop)
On another thread, client bind(...) on port 12345 and "0.0.0.0" and tries to poll() and recvfrom() in a loop (poll always returns 0 here when client is on a separate nat)
Server bind() on port 12345 and "0.0.0.0" then poll() and recvfrom() in a loop
Upon receiving the first UDP message from a client, it starts a thread for sending
UDP messages back to the client on a new socket, using the
sockaddr_in that it got from the recvfrom() to pass in the sendto() commands.
Result : Server perfectly receives ALL messages from all clients, and sends all messages back to all clients, but any client that is not on the same NAT will never receive any messages (poll() always returns 0).
As far as I understand it, when the client sends a UDP message to the server on a specific remote port (12345 in this case), it will punch a hole in its NAT so that it can receive messages back from the remote server on that port...
I tested five different client network configurations :
Local network with the server, using local IP addresses (WORKS)
Local network with the server while client is using a VPN thus going through a remote NAT (DOES NOT WORK)
Local network with the server but client is using the WAN ip address to connect to the server (DOES NOT WORK)
Client at an actual remote network from a friend's connection, behind a router (DOES NOT WORK)
Client going through a wifi hotspot created using my phone (DOES NOT WORK)
For all tests above, the server was correctly receiving all communications from clients.
I also tried forcing the port to 12345 for the sendto() instead of using the sockaddr_in as set from recvfrom(), same issue.
Am I doing anything wrong ?
If you want to help but need to see actual code, I can do that live with screen sharing and I will pay for the help.
Thanks.
Also, if anyone can point me to a great site where I can pay for VERY QUICK help, please let me know, I don't even bother searching google because I really want actual advice from people who tried these services, not ads trying to rip me off...
Only the original receiver socket is allowed to reply to the client, because it's the client request that opens the port in the NAT. So either use the same socket in the server to receive and reply, or get the port that the second server socket was bound to and transfer it with an initial message through the original server port, so that A can send to it and punch the hole.
It looks so strange to create two half duplex sockets when a socket is a full duplex communication object that I'd go with the first option.
i'm having some sync trouble with threads and sockets. I need one thread to recive incoming connections on socket (and remember client data to respond) and other thread to setup frames and send current frame to listed clients. So i was wondering if its possible to (kinda) put my data frames into server socket, so that everyone could just read current frame from socket without server knowing.
Server will just spam its socket with some data and client will get data without server actions. Is this possible? how?
I'm currently doing it pretty messed up way which i dont like:
server is listening on one thread for incoming transmissions and upon reciving such, add client data to list.
on other thread server is sending data to all clients from list.
EDIT:
I want to send data to some kind of buffer from which clients are allowed to read. (client doesnt have to read all messages server sends, just the one buffer contains at the moment of clients request), i dont want server to even notice that clients are reading from buffer if possible.
Right now threads are syncronised using uniqe_lock
What you're describing is probably MultiCast. Specifically, IP MultiCast (I think).
Searching finds a number of useful resources. This one looks concise, and includes coded examples (although I'm not sure how current it is).
If you're only transmitting to a LAN then broadcast will work too.
I need to do some validation testing of a new feed handler I have made. I have some pcap data that I captured from the production network and I would like to have my development feed handler connect to the "replay" of this data and compare the results.
My pcap:
I have a prod application that connects to a data feed, a TCP connection to an external server lets call assume this is 123.456.789.1:1234. This external sever then sends data to my application there is almost no client to server communication the server just sends the client data until the client drops. I have a pcap of all the packets sent to and from port 1234. I got this pcap by mirroring the production port (SPAN) on the switch and attaching tcpdump to an interface plugged in to the mirrored network port. When I look at the PCAP in wireshark it has all the data I would expect.
My problem:
I am in no way a network engineer and I am unsure how I can use this pcap to test my application. What I would like to do is "replay" this stream form the pcap and connect to it with my development application to validate that the data is being handled the same was it was on the prod connection.
I would like to some how "replay" the data sent from 123.456.789.1:12344 on 127.0.0.1:1234 and then connect to 127.0.0.1:1234 with my dev application. I looked at tcpreplay but from the documents I can not seem to figure out if it can do this, I get the feeling that they do not handle the tcp session data, and I could do this if it was a UDP stream, but tcpreplay can not act as the external server. Did I read this wrong or is there another tool that will let me do this?
thanks!
You may want to use netcat if you just want to throw some data back at your tool, and you don't care about what the tool sends.
You would do this by extracting the raw data sent by your tool from the pcap file (this tool may be helpful) and then piping that into netcat.
I’m using Wireshark to monitor telnet server/client transmissions. Occasionally the server's incoming text buffer pulls in multiple instances of the same incoming data string like so:
*1890000000000900000000A00000000B000000000064/\r*1890000000000900000000A00000000B000000000064/\r*1890000000000900000000A00000000B000000000064/\r*1890000000000900000000A00000000B000000000064/\r
When this happens Wireshark says they are retransmissions. TCP wouldn't be responsible for the duplicated data would it? Should I focus more on the client code as the source of duplication?
I might add that this application is communicating over 2.4ghz WiFi with 23 access points. It is a very congested network.
Does Wireshark show any unusually colored entries just before the perceived re-transmission? If wireshark says the packet is a re-transmission, you can assume the server (via TCP) is re-sending it. You can verify this if may appear the client does not send an ACK for that packet initially, or subsequently.
I am curious about raw sockets and and how to create them and would like to implement my own TCP mechanism. I have read some examples and have succeeded with sending both custom made TCP packets and UDP packets with my own written IP header (of course influenced by a lot of examples). I have checked with Wireshark that the packet is reaching its destination, so everything is fine so far.
But regarding TCP packets, to make the full handshake:
Client Server
syn --->
<--- syn ack
ack --->
What do I need from the server´s point of view to get the syn packet so I can send the syn ack back to the client?
To receive packets on a raw socket, just call recv or recvfrom on it. The OS will return you a copy of the next packet addressed to the machine, with headers and all, which should include address info. Watch the destination address, port, and transport protocol, and ignore any that aren't what you were expecting. (Since the point of a raw socket is that there's no built-in notion of ports or anything the OS could use to route packets to sockets, it doesn't know what program to send it to...so every raw socket should receive every packet addressed to the machine. Meaning you might receive lots of crap you have no interest in.)
Once you see a packet addressed to "you", just build a SYN/ACK packet and send it to the address and port listed as the source in the received packet.
Note, though: the OS will often do its own processing of TCP and UDP packets (including sending ICMP "port unreachable" or other responses for ports it doesn't have listeners for)...and doing your own processing on top of that is bound to cause wackiness. If you're going to implement your own flavor of TCP, you might want to use a different protocol number. (Of course, then most clients won't be able to connect to it...you'd have to make a client as well.)