This question is a (sort of) follow-up to Intercepting/Rerouting TCP SYN packets to C++ program in linux.
The question is: If SYN or any other TCP packet is modified (say the source IP address/port is changed) before it is sent to the network (i.e. on the source), what effect will it have on TCP reliability (for example if the packet is lost)?
The effect will be exactly the same as for not modified packet - the network stack will timeout and re-try, and eventually give up, and return with ETIMEDOUT from connect(2).
Related
As socks5 rfc says,
A UDP association terminates when the TCP connection
that the UDP ASSOCIATE request arrived on terminates.
I wonder, doesn't "the TCP connection that the UDP ASSOCIATE request arrived on" just terminate when it timeouts? As there is no more data need to be sent in that TCP connection.
Should the client send meaningless data in that TCP connection just to keep it alive while it need the UDP association?
I wonder, doesn't "the TCP connection that the UDP ASSOCIATE request arrived on" just terminate when it timeouts?
No. The TCP connection is kept alive as a signal that the proxied UDP socket is still valid. Without it the client has no way of knowing whether the server is still reachable or whether the UDP socket is still allocated.
Similarly, without the TCP connection the server has no other way of knowing whether the client is still connected.
Should the client send meaningless data in that TCP connection just to keep it alive while it need the UDP association?
There's no need to send meaningless data. Just keep the connection alive. TCP has a built-in keepalive mechanism which can be turned on.
Edit: It's worth pointing out that the default TCP keepalive times on both Linux and Windows is fairly long. See this question on ways of tweaking it for specific sockets.
I have a simple program which uses sockets, listens on specific port (1883) and receives data from client's socket.
I compare received data with Wireshark - it works well.
There are a lot of other TCP packets around MQTT packet in Wireshark.
There is an example:
1) mosquitto_pub -t test -m test
2) In Wireshark, it looks like:
TCP packet
TCP packet
MQTT packet
TCP packet
TCP packet
3) But my program first receives MQTT packet and I'm asking; why doesn't it receive the first two TCP packets as well?
I don't mind that, I wanna receive only MQTT packet, but it seems weird to me and I'd like to know a reason.
I also have a filter in Wireshark, tcp.port on 1883.
How do we know port is listening?
Is there possible to know that port is listening, even if they do not respond?
i.e. when I just bind socket in some programs, but I really do not send ACK back.
1: Packet is received and analyzed.
2: If packet fit meets, ACK is send back.
Like if I can program this thing, or it's networks card HW that is responsible for ACK.
How do we know port is listening?
Your local stack knows. An application needs to register the port.
Is there possible to know that port is listening, even if they do not respond?
If there's no reponse to a SYN sent out the host may be unreachable, the destination port not listening, or the SYN filtered.
i.e. when I just bind socket in some programs, but I really do not send ACK back.
You don't have to worry about SYN and ACK, that's handled by the OS's IP stack. Just set up a listener on destination and then connect the socket from source. If the socket opens you can start talking through the pipe.
Like if I can program this thing, or it's networks card HW that is responsible for ACK.
ACKs are part of the TCP transport protocol handled by the OS's IP stack.
You can find out the list of sockets and connections using netstat command. Use netstat -a and grep for the port in question. You can find out if there is a socket listening on the port you want.
In this introduction article: http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/overview.html
It states that reasons for TCP keep alive are:
Preventing disconnection due to network inactivity
Detect dead peers
So in my application, there is a busy TCP socket. Packets are frequently sent back and forth between the two peers - so there is a good amount of packets with ACK flag set.
The application protocol uses other means for dead peer detection.
Is TCP keepalive still necessary for the case above?
No. TCP keepalive is practically a 0 byte-long tcp packet. If you can be sure on your app protocol, it is unneeded.
First of all, is there any problem with using both UDP and TCP on the same server?
Secondly, can I use the same port number?
Yes, you can use the same port number for both TCP and UDP. Many protocols already do this, for example DNS works on udp/53 and tcp/53.
Technically the port pools for each protocol are completely independent, but for higher level protocols that can use either TCP or UDP it's convention that they default to the same port number.
When writing your server, bear in mind that the sequence of events for a TCP socket is much harder than for a UDP socket, since as well as the normal socket and bind calls you also have to listen and accept.
Furthermore that accept call will return a new socket and it's that socket that you'll then have to also poll for receive events. Your server should be prepared to continue accepting connections on the original socket whilst simultaneously servicing multiple clients each of which will be triggering receive events on their own sockets.
Firstly,there is no problem using both tcp and udp on the server.
Secondly,we can have both UDP and TCP requests on same port ,because each request is identified by a quintuple contained by source IP ,Destination IP, Source Port, Destination Port, PROTOCOL(as protocol can be TCP or UDP).