Trivial established protocol for sending a single string message? - networking

I have two machines M1, M2 on a network, with processes P1, P2 running on each of these machines. (The process is a C++-compiled executable, but perhaps that's not very significant.) These processes can also open, listen and connect on ports if necessary.
I want P1 to send a single string to P2 - not super-short nor super-long (say, 1 KB to 100 KB). The string is made up of printable ASCII characters, nothing extraordinary.
Now, I can have P2 keep an open a TCP port and listen on it, and P1 connect to it using TCP, send the message, and close the connection - and this will work.
My question is: Is there an formally-established, extremely-simple protocol that is basically just what I described? It would be much simpler than TFTP, for example.

Related

How to monitor simple bi-directional TCP socket traffic (Telnet) in the middle of two endpoints?

I'm debugging an IOT protocol between two essentially black boxes on my local network talking over a telnet connection. On either end, I can specify the IP address and port. I'd like to observe / record the data exchanged between the client and server.
I'm thinking a proxy running on my Mac laptop might work. I've done some research and experimentation with nc (BSD netcat). I can only figure out a working one-way pipe, and thus the protocol exchange does not happen between A and B.
Telnet TCP server (A) <===============> TCP Client (B)
Telnet TCP server (A) <===\ /==> TCP Client (B)
\ /
\ /
Proxy/Intercept (C) *
Using a feature in the server device (A), I can have two telnet connections active. Using this, I've been able to see the server's (A) responses to whatever Client (B) is commanding, but I cannot see the Client (B) commands. ~80% of the responses are a code meaning invalid command received, but a few are reasonable responses for what this thing should be doing. I can also note that that data rate is only about 4 Bytes / second, so I'd be happy to just watch this exchange live in a terminal.
To clarify: I can power-cycle the client (B), and it will re-establish a socket connection to the IP address and port of my choosing, so I'm not really thinking about a sniffing / Wireshark type solution.
I guess I'm hoping for a relatively straightforward solution run in the shell using existing standard tools. I suppose a small program could be written in Python or something to do this, but I hope that's overkill.

TCP Connection For Devices in same network

When two devices D1 and D2(on different networks) have processes P1 and P2 running respectively on them then if P1 wants to get data from P2 then -
P1 establishes TCP connection with P2 .
P1 sends SYN packet.
P2 sends SYN-ACK packet.
P1 answers with ACK packet, concluding the three-way TCP connection establishment.
After this HTTP request is sent over this TCP connection.
Lets say D1 and D2 are on the same network, will this process be faster and why.
The less time it takes for P1's message to reach P2 and vice versa, the faster this process will be. That time depends on a variety of factors, among them is the physical distance between the machines and the number and capacity of networking equipment and links along the way.
Since machines in a local network are typically close, with little networking equipment between them, a connection between should faster than if the machines are further apart.
Of course one could imagine scenarios in which that's not the case, but those would be atypical edge cases.

TCP RST on TELNET - Packet builder

I'm having some troubles building my TCP RST packet. I've a LAN with 3 pc's connected, the host, victim and the attacker.
Im trying to break up the connection that exists between my Host and my Victim over a TELNET connection, using my Attacker to send an TCP RST packet with the NetWag software. I know the source and destination port numbers and ip's but when i send the packet, with Wireshark i can see that it was received by de Victim, but the connection doesn't go down.
Does the problem is in the Sequence and/or Ack numbers?
P.s. both firewalls are shut down.
Yes, the sequence numbers are very important. Packets out of sequence essentially are ignored. In fact, the sequence number used to start at 1 and increment from there but that was later changed to start with a random number to help prevent the very thing you are trying to do.
NOTE: you also have to ensure that the packets are correctly formatted such as having a correct checksum otherwise they will be ignored anyway.

Recover port from Boost Asio udp::endpoint

I am programming a server and client program to communicate between a windows PC using the Boost libraries and a Linux ARM beagleboard using the asio stand alone libraries. I have for a while had successful UDP communication between the two devices but now I want to recover the port from the endpoint the server discovers when the client connects. The way the client connects is via query:
udp::resolver resolver(io_service);
udp::resolver::query query_tx(udp::v4(), hostIP, "43210");
udp::endpoint receiver_endpoint_tx = *resolver.resolve(query_tx);
where host IP is a string and this works fine. Upon debugging though I notice that when i check the value returned by:
receiver_endpoint_tx.port()
This returns 51880. Now don't jump the guns and yell out network byte order and host byte order. I AM AWARE. The strange part is that this number 51880 sometimes is a different number and when i check what the server has stored in its endpoint it is a completely different number: 21743. Now I know I must be doing something wrong with the byte orders but i tried:
//unsigned long port_long = boost::asio::detail::socket_ops::host_to_network_long(receiver_endpoint_tx.port());
//unsigned long port_short = boost::asio::detail::socket_ops::host_to_network_short(receiver_endpoint_tx.port());
And they do not give me back my original port: 43210. Neither does network to host. So what am i missing and how can I on both ends recover my 43210 port? Obviously it must be there somewhere because they are successfully communicating.
Thanks in advance, sorry if noob mistake :)
Fistly, UDP is connectionless, there is no connection.
I'm not sure if I understand you correctly, but it sound too me like you want to bind to specific port numbers. If you want the client to send a packet from port x to port y on the server, and the server should respond from port y to port x, then you need to bind the sockets to the desired ports. Alternatively you can use the constructor to bind. Not doing so will result in the OS using ephemeral ports.
Further, to get the remote endpoint that a packet was received from the async_receive_from takes the sender_endpoint reference parameter. When the read handler is called, you can retrieve host and port from it.

UDP Hole punching: one Symmitric and another non-symmetric NAT

I am trying to implement P2P with Hole Punching. Here is the flow:
Both Peers(P1,P2) will send 1 packet to server(S).
Server(S) replies back to both telling others IP:PORT
P1 and P2 receive this UDP packet knowing other's external/public ip:port.
P1,P2 start sending packet to other peers public IP:PORT.
Once peers receive other peer's packet, I assume the hole is punched and will give this socket to my Application.
I tested this on different routers, here is the outcome:
When P1 and P2 both are on non-symmetric-NAT (Full/Restricted cone),
I don't face any problem.
When P1=Non-Symmetric and P2=Symmetric:
-----router-1 (Symmetric-NAT) + router-2 (non-Symmtric) = Success
---- router-3 (Symmetric-NAT) + router-2 (non-Symmtric) = *Failure*
Until 4th Step its fine. But in 5th step, no peer receives the packet of other peer. I was expecting that at-least *'peer behind non-Symmetric NAT' will receive the packet of other.*
Anybody has any idea whats happening?
There is a paper here
Basically they use two servers S1 and S2.
By looking at the outbound ports they are often able to predict what outbound port would be used when P1 sends a packet to P2 and vice versa.
Apparently many routers just use incrementing/decrementing or some skip size
There is no guarantee of predicting the correct port. They end up sending a bunch of packets to different ports hoping that one will get through.
I have a different idea how to approach it, I'll need to find a symmetric-NAT to test it out :)

Resources