Zbr's days.

About :: TODO :: Blog :: RSS :: Old blog :: Projects :: GIT :: Gallery :: Notes

Fri, 22 Sep 2006

Climbing.

It was interesting and hard training today - I did not climb the whole week, so I was ready for good training, but my first exercises showed, that I loose a form - second traverse over all holds on the first shield only was completed only in one direction, and arms were tired a lot after it. Since Grange decided not to climb, I climbed with local climber Irin. I completed several old traces ("Mini-cooper", trace with dynamic jump, and not so old complex trace over blue holds in central sector which was created recently). She completed severa old traces and then under my guidance tried jumping one, although it was only my "improvement" to remove two holds and make a jump, so she only tried original version. It was very good training after quite big delay, I hope I will return to systematic trainings next week.

/life :: Link / Comments ()

IPsec was changed again in 2.6.18 (and now it is broken).

So I need to run through my IPsec related acrypto changed again.
I've noticed strange thing with current port - incoming connection can be easily established and run quite smooth, while outgoing is very slow and it looks like there are a lot of spurious retransmits all over the place, which definitely does not allow to easily find single point of failure. It looks like XFRM state is destroyed very frequently, and packets are queued until renegatiation happens, but it can be just a mistake though.

It looks like it is 2.6.18 kernel bug and not acrypto, since with default kernel I get the same strange result. Here is tcpdump output between 2.6.18 kernel (192.168.4.78) and 2.6.17-1.2139_FC5smp kernel (192.168.4.79), I try telnet 192.168.4.79 22 after key daemons exchanged keys and this results in quite long response time:

15:15:47.396925 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x027181f9,seq=0x21), length 84
15:15:47.397391 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x0961a360,seq=0x18), length 84
15:15:47.397025 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x027181f9,seq=0x22), length 84
15:15:47.404166 IP 192.168.4.79.ssh > 192.168.4.78.47256: P 2541002438:2541002458(20) ack 1601271418 win 91 
15:15:48.279375 IP 192.168.4.79.ssh > 192.168.4.78.47256: P 0:20(20) ack 1 win 91 
15:15:50.031487 IP 192.168.4.79.ssh > 192.168.4.78.47256: P 0:20(20) ack 1 win 91 
15:15:53.535710 IP 192.168.4.79.ssh > 192.168.4.78.47256: P 0:20(20) ack 1 win 91 
15:16:00.544154 IP 192.168.4.79.ssh > 192.168.4.78.47256: P 0:20(20) ack 1 win 91 
15:16:14.561064 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x0961a360,seq=0x19), length 100
15:16:14.561218 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x027181f9,seq=0x23), length 84
As you see there are unencrypted messages between machines, which I suspect are result of broken behaviour somewhere in XFRM stack. ping works ok though:
15:15:37.919617 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x027181f9,seq=0x1c), length 116
15:15:37.919858 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x0961a360,seq=0x13), length 116
15:15:38.920772 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x027181f9,seq=0x1d), length 116
15:15:38.920823 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x0961a360,seq=0x14), length 116
15:15:39.920823 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x027181f9,seq=0x1e), length 116
15:15:39.920883 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x0961a360,seq=0x15), length 116
15:15:40.920848 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x027181f9,seq=0x1f), length 116
15:15:40.920893 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x0961a360,seq=0x16), length 116
telnet from 2.6.17 to 2.6.18 works ok too:
15:32:57.742011 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x0961a360,seq=0x21), length 84
15:32:57.742173 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x027181f9,seq=0x33), length 84
15:32:57.742278 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x0961a360,seq=0x22), length 84
15:32:57.750256 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x027181f9,seq=0x34), length 100
15:32:57.750329 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x0961a360,seq=0x23), length 84
15:33:01.201502 IP 192.168.4.79 > 192.168.4.78: ESP(spi=0x0961a360,seq=0x24), length 84
15:33:01.201640 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x027181f9,seq=0x35), length 84
15:33:01.201698 IP 192.168.4.78 > 192.168.4.79: ESP(spi=0x027181f9,seq=0x36), length 100
It was definitely introduced somewhere in 2.6.18 release cycle, since 2.6.17 works ok both with acrypto and vanilla kernels. As far as I recall I created initial port of 2.6.18 acrypto after some major changes in XFRM stack and it worked too.

It looks like that problem exists even in 2.6.16 vanilla tree, it really looks broken to me.

/devel/acrypto :: Link / Comments ()