Hello Sven, your change makes me wonder: 'what is the actual problem you are trying to solve'?
the reason I'm asking is that latency is just one factor, which contributes to TCP connection performance. The other factor (and perhaps more important) is to guess amount of retransmitted data. Processes (a.k.a. endpoints), which communicate over TCP can experience significant delay once TCP packets starts to be dropped. Those dropped TCP packets contribute to delay experienced in the more significant way, than 'network latency' in sense of roundtrip. I'm not much experienced firewall administrator, the only firewall I run is APU box at my home, hence I'm sorry if my question sounds naive. So basically what sort of problem in network you hope to diagnose with PF? And also don't get me wrong: I like your idea to extend PF to enable firewall to provide better picture of what happens on network. I just want to point out that sampling network latency (round-trip) might not be sufficient. thanks and regards sashan On Thu, Dec 17, 2020 at 02:44:41PM -0500, Sven F. wrote: > Dear readers, > > pfctl -vv -ss shows detailed information on states. > I would like to improve the information provided about specific TCP > connections, > regarding the latency of the network. > An obvious way seems to be to measure the time to get ACKs back. > Another way would be to use packets timestamps. > > I patched my kernel to extract this information and > log it, before trying to report it to the userland. > I did not use timestamps, because I am not sure how i could do that. > If you have any advice on that, it would be welcome. > Moreover the patch is a prototype, > So I would appreciate any feedback on my diff (attached): > Currently the code is using a LABEL to trigger the measure, > of course, later it should be a keyword like "latency" in the rules. > For example : > match proto tcp to port 80 latency > Or something else. > This would be discuss after choosing a method for latency computation, > > Maybe there is a better way to extract network TCP latencies information > ( i would like to avoid running in promiscuous, but if a current > packaged software does it well... ) > but I did not come across it. > Please share if you know of a better way to tackle this. > > > Happy holidays !
