[Cerowrt-devel] TFO crashes cerowrt 3.7.1-1
dave.taht at gmail.com
Fri Jan 4 22:35:37 EST 2013
It's rather fun to explore a new protocol on a friday night!, but this
thread is getting out of hand. I created a bug for it here:
I don't mind if we continue to discuss it here, but do put packet
captures on the bug, please...
I scripted up a few tests that hopefully duplicate what ketan was
trying to do. (ketan?) and put up packet captures of the succesful
tests to an x86_64 box I had handy....
I will put a sacrificial cerowrt box back up with a serial port on it
I noted in the bug above (with more detail)
On a x86_64 path over a 4 hop wifi mesh network, httpping using polipo
as a proxy not only "worked", but roughly halved the time taken by a
~40kbyte http GET.
Typical httpping result, polipo, no TFO
connected to 172.26.3.4:80 (274 bytes), seq=4 time=10.76 ms
Typical result, polipo, useTCPFastopen = true in it's config and
/proc/sys/net/ipv4/tcp_fastopen = 3 on both sides....
connected to 172.26.3.4:80 (274 bytes), seq=4 time=6.61 ms
If the security issues with the idea are resolved (I'm aware of the
prior effort to do this but haven't thought deeply about how TFO
attempts to resolve those issues), and TFO can be deployed, it will be
a win for a wide range of latency sensitive tcp traffic types.
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
More information about the Cerowrt-devel