On Mon, 10 Jun 2019, iam@xxxxxxxxxxx wrote: > So if it doesn't do anything with network stack states, why I don't see > RTT for my SYN_RECV -> ESTABLISHED state changes? > > If this question isn't about conntrack, could you point for better place > to ask this question? I still think that time between SYN_RECV -> > ESTABLISHED should be around RTT.. You should ask it at the netdev mailing list: netdev@xxxxxxxxxxxxxxx. Best regards, Jozsef > 10.06.2019, 14:37, "Jozsef Kadlecsik" <kadlec@xxxxxxxxxxxxxxxxx>: > > On Mon, 10 Jun 2019, iam@xxxxxxxxxxx wrote: > > > >> Got it, so if I'll somehow unload nf_conntrack from kernel, then I'll > >> get natural timings for TCP handshake? Logic of my measurements is right > >> if there is no optimisations from firewall perspective? > > > > Netfilter conntrack has nothing to do with the network stack states, > > timers: it maintains its own internal states, timers only. When loaded in, > > it adds a little time overhead at what you see in the tcpdump recording. > > It won't modify how fast a stack completes the 3way handshake. > > > > Best regards, > > Jozsef > > > >> 10.06.2019, 14:11, "Reindl Harald" <h.reindl@xxxxxxxxxxxxx>: > >> > Am 10.06.19 um 12:51 schrieb iam@xxxxxxxxxxx: > >> >> 10.06.2019, 12:52, "Reindl Harald" <h.reindl@xxxxxxxxxxxxx>: > >> >>> Am 10.06.19 um 10:12 schrieb iam@xxxxxxxxxxx: > >> >>> > >> >>> for conntrack a connection is no longer new after the first *response* > >> >>> packet has been seen, it's that easy and given that the first rule in > >> >>> every chain should be to allow RELATED,ESTABLISHED this is a game changer > >> >> > >> >> is it right that conntrack just override natural behaviour of tcp handshake by immediately changing TCP state to ESTABLISHED right after getting first SYN packet, but in fact connection should be ESTABLISHED only after getting ACK from the client side? > >> >> > >> >> Yes, logic you've described is giving speed for packet processing and "optimized" for conntrack cases, but isn't it wrong to change state before it's really ESTABLISHED? > >> >> > >> >>> it's ESTABLISHED after SYN+ACK and i don't get what annoys you in the > >> >>> fact that something is fast and optimized? > >> >> > >> >> ESTABLISHED after SYN+ACK sent and not after ACK receive and that annoys me > >> > > >> > from a firewall perspective it's enough that you a) accepted the SYN and > >> > b) the backend ACK'ed it and for UDP it's the only option > >> > > >> > if you get no further package back there is no harm anyways > >> > > >> > if you get the ACK back it passes anyways to the backend > >> > so what's the point going it the whole ruleset down? > >> > > >> > when you have thousands of connections per second on a large ruleset > >> > that behavior makes the difference if you survive the load or not > > > > - > > E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlecsik.jozsef@xxxxxxxxxxxxx > > PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt > > Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences > > H-1525 Budapest 114, POB. 49, Hungary > - E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlecsik.jozsef@xxxxxxxxxxxxx PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary
