Error: I'm afraid this is the first I've heard of a "html." flavoured Blosxom. Try dropping the "/+html." bit from the end of the URL.
New HIFN driver release.
This release forces HIFN driver to invoke crypto callbacks in
softirq context instead of hardirq one because of network stack, which
performs whole data processing either in process or bottom-half context.
One can find new driver in archive.
It will be included into 2.6.25 kernel tree via
cryptodev git tree. #
HIFN driver has been imported into cryptodev-2.6 tree.
Driver will be added either into 2.6.24 or 2.6.25 tree eventually.
I've also added a patch to export DES key extension to catch weak keys
and use it in HIFN driver. Now it is ready.
Interested reader can find updated HIFN driver in archive. #
Misalignment access handling has been implemented in HIFN driver. New version has been released.
Although it contains some obscure for the reader comments,
like
/* * Temporary of course... * Kick author if you will catch this one. */ printk(KERN_ERR "%s: dlen: %u, nbytes: %u," "slen: %u, offset: %u.\n", __func__, dlen, nbytes, slen, offset); printk(KERN_ERR "%s: please contact author to fix this " "issue, generally you should not catch " "this path under any condition but who " "knows how did you use crypto code.\n" "Thank you.\n", __func__); BUG();This should not happen in real life, but in theory it is probably possible condition, so I added a bug and above prints.
tcrypt.c,
except DES weak test (hardware can not distinguish weak keys).I think HIFN driver is the most complex one I ever wrote.
I already implemented at least two different designs of misaligned access handling
code - both were not good enough (basically did not work in some or other cases),
now I'm working on third one - this should be damn good, but not very fast - no one
promised fast access, when you put each byte of the word to be encrypted
in different page. It will be limited enough to say, that if there is more than
predefined number of pages, then caller sucks. And it will be complex. It is complex
already.
Actually HIFN driver can handle most of the misaligned access just fine: if data is word aligned
(some times two words aligned) and size of the data provided is more
than two bytes (one word, or two words in some cases), in other cases copy is needed.
Neither IPsec, nor dm-crypt provides such packets. Protocol just does not allow that,
but some obscure crypto users can have such stupid idea in mind, so we have to copy...
Crap.
But it will be ready this week!
And right now I will move to development shop - I've done
enough at paid work and for HIFN driver for today, so let's change the business... #
Misaligned access in crypto stack and HIFN driver.
It is possible, that provided to crypto processor data
is misaligned or split between pages so that each page contains
not block size aligned chunk. In this case data has to be relocated.
Linux crypto stack provides data to underlying crypto processing driver
in scatterlists, which is essentially array of pages and appropriate
size/offset information. Thus it is possible that each page in scatterlist
has to be relocated. I will create a 'cache' of preallocated pages,
which will be used as a temporary storage for crypto data, if cache is empty,
crypto processing function will allocate new pages in its context, and then
copy data from misaligned page into given page and process it. In interrupt,
when the fact, that all pages have been processed, is confirmed,
new data will be copied back to requested destination buffer (if needed,
for example if source buffer is misaligned, but destination is ok,
second copy is not required), this can also be postponed to process context
via workqueue, but that will introduce additional latency,
which is quite noticeble (as I tested in
acrypto
crypto stack). #
Linux crypto stack issues.
It was not designed for async operations at all - all helpers,
I described
previously, do not work in async context, i.e. when several chunks of the same request
can be encrypted in parallel, since blkcipher_walk* interfaces
provides the same destination buffer for all parts of the same request.
So, to handle misaligned data I have to develop own helpers for HIFN driver. #
HIFN driver addons and crypto stack issues.
I decided to rewrite crypto session setup in HIFN
driver to allow multiple scatter-gather lists (which are
now transformed into pages) in single crypto session
(even though with multiple descriptor slots being used).
Main goal for this step is to allow encryption
of buffers, which are split into number of pages,
where each chunk is not block size aligned (for example
one page contains 2 bytes and another one 14 for single
datablock of 16 bytes). Second revision of driver does not
support such blocks yet.
To simplify this I started to use generic linux crypto
helpers blkcipher_walk_* from block ciphers.
But they do not allow to be called in interrupt context,
although all allocations are performed like they happen
in atomic context.
Rougly code looks like this (error processing ommitted):
struct blkcipher_walk walk;
blkcipher_walk_init(&walk, dst, src, nbytes);
blkcipher_walk_virt(desc, &walk);
while ((nbytes = walk.nbytes)) {
u8 *iv = encrypt();
memcpy(walk.iv, iv, ivsize);
nbytes &= blocksize - 1;
err = blkcipher_walk_done(desc, &walk, nbytes);
}
Above struct blkcipher_walk contains source and destination
page addresses, appropriate sizes and offsets. Variable desc
is a struct blkcipher_desc pointer, which contains
original parameters of crypto request. #
HIFN 795x driver for Linux kernel 2.6 is ready.
I've fixed CBC processing bug, added software queue (which I consider
a serious ugly hack in existing kernel async crypto stack implementation),
added support for DES and 3DES algorithms (all are limited to blocksized chunks),
fixed indent and watchdog setup.
Everything I wanted to complete is ready in this driver, so I even updated
TODO list a bit.
One can find patch against the latest git in archive. #
HIFN driver is ready.
There is number of nitpicks though, but overall it works. Slightly tested
with tcrypt testing module, here is related output. Chunks
with 'fail' label requires additional work - although decryption works ok in driver
(reverse hifn_test() operations for example), tcrypt
decryption tests (with 'chunking' which I need to check what is it in tcrypt module) fail.
I will investigate this further tomorrow. Patch against the latest
2.6 git tree is available in archive.
[ 628.851890] testing ecb(aes) encryption [ 628.857498] hifn_cra_init: tfm: ffff81003a8739c8, dev: hifn0 [ffff81003dd7c2c8]. [ 628.865046] test 1 (128 bit key): [ 628.868505] hifn_setkey: tfm: ffff81003a8739c8, ctx: ffff81003a873a08, dev: hifn0 [ffff81003dd7c2c8], len: 16. [ 628.878679] hifn_setup_crypto: req: ffff81003a873f20, tfm: ffff81003a8739c8, ctx: ffff81003a873a08, keylen: 16. [ 628.888943] hifn_setup_session: start [ 628.892652] cmd: i=1, u=0, k=1 [ 628.895752] src: i=1, u=1, k=0 [ 628.898852] dst: i=1, u=1, k=0 [ 628.901952] res: i=1, u=0, k=1 [ 628.905054] hifn0: iv: 0000000000000000 [0], key: ffff81003a873a08 [16], mode: 0, op: 1, type: 0. [ 628.913996] hifn0: 1 dmacsr: 8898888c, dmareg: 22322023, res: 00100000 [2], i: 1.2.2.1, u: 2.2.2.2. [ 628.923104] hifn0: ring cleanup 1: i: 2.2.2.2, u: 1.2.2.1, k: 1.0.0.1. [ 628.929676] hifn0: ring cleanup 2: i: 2.2.2.2, u: 0.2.2.0, k: 2.0.0.2. [ 628.937082] 69c4e0d86a7b0430d8cdb78070b4c55a [ 628.942302] pass [ 628.944280] test 2 (192 bit key): [ 628.947732] hifn_setkey: tfm: ffff81003a8739c8, ctx: ffff81003a873a08, dev: hifn0 [ffff81003dd7c2c8], len: 24. [ 628.957917] hifn_setup_crypto: req: ffff81003a873f20, tfm: ffff81003a8739c8, ctx: ffff81003a873a08, keylen: 24. [ 628.968159] hifn_setup_session: start [ 628.971870] cmd: i=2, u=0, k=2 [ 628.974969] src: i=2, u=2, k=0 [ 628.978069] dst: i=2, u=2, k=0 [ 628.981169] res: i=2, u=0, k=2 [ 628.984271] hifn0: iv: 0000000000000000 [0], key: ffff81003a873a08 [24], mode: 0, op: 1, type: 1. [ 628.993214] hifn0: 1 dmacsr: 8898888c, dmareg: 22322023, res: 00100000 [3], i: 1.3.3.1, u: 3.3.3.3. [ 629.002321] hifn0: ring cleanup 1: i: 3.3.3.3, u: 1.3.3.1, k: 2.0.0.2. [ 629.008894] hifn0: ring cleanup 2: i: 3.3.3.3, u: 0.3.3.0, k: 3.0.0.3. [ 629.016167] dda97ca4864cdfe06eaf70a0ec0d7191 [ 629.021398] pass [ 629.023376] test 3 (256 bit key): [ 629.026827] hifn_setkey: tfm: ffff81003a8739c8, ctx: ffff81003a873a08, dev: hifn0 [ffff81003dd7c2c8], len: 32. [ 629.037001] hifn_setup_crypto: req: ffff81003a873f20, tfm: ffff81003a8739c8, ctx: ffff81003a873a08, keylen: 32. [ 629.047247] hifn_setup_session: start [ 629.050956] cmd: i=3, u=0, k=3 [ 629.054055] src: i=3, u=3, k=0 [ 629.057158] dst: i=3, u=3, k=0 [ 629.060258] res: i=3, u=0, k=3 [ 629.063359] hifn0: iv: 0000000000000000 [0], key: ffff81003a873a08 [32], mode: 0, op: 1, type: 2. [ 629.072302] hifn0: 1 dmacsr: 8898888c, dmareg: 22322023, res: 00100000 [4], i: 1.4.4.1, u: 4.4.4.4. [ 629.081408] hifn0: ring cleanup 1: i: 4.4.4.4, u: 1.4.4.1, k: 3.0.0.3. [ 629.087980] hifn0: ring cleanup 2: i: 4.4.4.4, u: 0.4.4.0, k: 4.0.0.4. [ 629.095353] 8ea2b7ca516745bfeafc49904b496089 [ 629.100581] pass [ 629.102558] [ 629.102558] testing ecb(aes) encryption across pages (chunking) [ 629.110232] [ 629.110233] testing ecb(aes) decryption [ 629.115822] hifn_cra_init: tfm: ffff81003a873f20, dev: hifn0 [ffff81003dd7c2c8]. [ 629.123369] test 1 (128 bit key): [ 629.126833] hifn_setkey: tfm: ffff81003a873f20, ctx: ffff81003a873f60, dev: hifn0 [ffff81003dd7c2c8], len: 16. [ 629.136996] hifn_setup_crypto: req: ffff81003a8739c8, tfm: ffff81003a873f20, ctx: ffff81003a873f60, keylen: 16. [ 629.147271] hifn_setup_session: start [ 629.150976] cmd: i=4, u=0, k=4 [ 629.154076] src: i=4, u=4, k=0 [ 629.157176] dst: i=4, u=4, k=0 [ 629.160277] res: i=4, u=0, k=4 [ 629.163379] hifn0: iv: 0000000000000000 [0], key: ffff81003a873f60 [16], mode: 0, op: 0, type: 0. [ 629.172322] hifn0: 1 dmacsr: 8898888c, dmareg: 22322023, res: 00100000 [5], i: 1.5.5.1, u: 5.5.5.5. [ 629.181428] hifn0: ring cleanup 1: i: 5.5.5.5, u: 1.5.5.1, k: 4.0.0.4. [ 629.188000] hifn0: ring cleanup 2: i: 5.5.5.5, u: 0.5.5.0, k: 5.0.0.5. [ 629.195404] 00112233445566778899aabbccddeeff [ 629.200642] pass [ 629.207471] test 2 (192 bit key): [ 629.210924] hifn_setkey: tfm: ffff81003a873f20, ctx: ffff81003a873f60, dev: hifn0 [ffff81003dd7c2c8], len: 24. [ 629.221079] hifn_setup_crypto: req: ffff81003a8739c8, tfm: ffff81003a873f20, ctx: ffff81003a873f60, keylen: 24. [ 629.231323] hifn_setup_session: start [ 629.235034] cmd: i=5, u=0, k=5 [ 629.238135] src: i=5, u=5, k=0 [ 629.241235] dst: i=5, u=5, k=0 [ 629.244336] res: i=5, u=0, k=5 [ 629.247437] hifn0: iv: 0000000000000000 [0], key: ffff81003a873f60 [24], mode: 0, op: 0, type: 1. [ 629.256379] hifn0: 1 dmacsr: 8898888c, dmareg: 22322023, res: 00100000 [6], i: 1.6.6.1, u: 6.6.6.6. [ 629.265486] hifn0: ring cleanup 1: i: 6.6.6.6, u: 1.6.6.1, k: 5.0.0.5. [ 629.272059] hifn0: ring cleanup 2: i: 6.6.6.6, u: 0.6.6.0, k: 6.0.0.6. [ 629.279309] 00112233445566778899aabbccddeeff [ 629.284545] pass [ 629.286543] test 3 (256 bit key): [ 629.290001] hifn_setkey: tfm: ffff81003a873f20, ctx: ffff81003a873f60, dev: hifn0 [ffff81003dd7c2c8], len: 32. [ 629.300171] hifn_setup_crypto: req: ffff81003a8739c8, tfm: ffff81003a873f20, ctx: ffff81003a873f60, keylen: 32. [ 629.310424] hifn_setup_session: start [ 629.314131] cmd: i=6, u=0, k=6 [ 629.317231] src: i=6, u=6, k=0 [ 629.320330] dst: i=6, u=6, k=0 [ 629.323430] res: i=6, u=0, k=6 [ 629.326532] hifn0: iv: 0000000000000000 [0], key: ffff81003a873f60 [32], mode: 0, op: 0, type: 2. [ 629.335473] hifn0: 1 dmacsr: 8898888c, dmareg: 22322023, res: 00100000 [7], i: 1.7.7.1, u: 7.7.7.7. [ 629.344573] hifn0: ring cleanup 1: i: 7.7.7.7, u: 1.7.7.1, k: 6.0.0.6. [ 629.351146] hifn0: ring cleanup 2: i: 7.7.7.7, u: 0.7.7.0, k: 7.0.0.7. [ 629.358529] 00112233445566778899aabbccddeeff [ 629.363762] pass [ 629.365742] [ 629.365743] testing ecb(aes) decryption across pages (chunking) [ 629.373421] [ 629.373422] testing cbc(aes) encryption [ 629.379011] hifn_cra_init: tfm: ffff81003a8739c8, dev: hifn0 [ffff81003dd7c2c8]. [ 629.386560] test 1 (128 bit key): [ 629.390012] hifn_setkey: tfm: ffff81003a8739c8, ctx: ffff81003a873a08, dev: hifn0 [ffff81003dd7c2c8], len: 16. [ 629.400170] hifn_setup_crypto: req: ffff81003a873f20, tfm: ffff81003a8739c8, ctx: ffff81003a873a08, keylen: 16. [ 629.410430] hifn_setup_session: start [ 629.414143] cmd: i=7, u=0, k=7 [ 629.417241] src: i=7, u=7, k=0 [ 629.420342] dst: i=7, u=7, k=0 [ 629.423442] res: i=7, u=0, k=7 [ 629.426543] hifn0: iv: 0000000000000000 [0], key: ffff81003a873a08 [16], mode: 1, op: 1, type: 0. [ 629.435484] hifn0: 1 dmacsr: 8898888c, dmareg: 22322023, res: 00100000 [8], i: 1.8.8.1, u: 8.8.8.8. [ 629.444585] hifn0: ring cleanup 1: i: 8.8.8.8, u: 1.8.8.1, k: 7.0.0.7. [ 629.451156] hifn0: ring cleanup 2: i: 8.8.8.8, u: 0.8.8.0, k: 8.0.0.8. [ 629.458574] 3b629d77f45eff9817c5849f9a0aba71 [ 629.463817] fail [ 629.465795] test 2 (128 bit key): [ 629.469246] hifn_setkey: tfm: ffff81003a8739c8, ctx: ffff81003a873a08, dev: hifn0 [ffff81003dd7c2c8], len: 16. [ 629.479405] hifn_setup_crypto: req: ffff81003a873f20, tfm: ffff81003a8739c8, ctx: ffff81003a873a08, keylen: 16. [ 629.489649] hifn_setup_session: start [ 629.493359] cmd: i=8, u=0, k=8 [ 629.496458] src: i=8, u=8, k=0 [ 629.499558] dst: i=8, u=8, k=0 [ 629.502661] res: i=8, u=0, k=8 [ 629.505760] hifn0: iv: 0000000000000000 [0], key: ffff81003a873a08 [16], mode: 1, op: 1, type: 0. [ 629.514704] hifn0: 1 dmacsr: 8898888c, dmareg: 22322023, res: 00100000 [9], i: 1.9.9.1, u: 9.9.9.9. [ 629.523810] hifn0: ring cleanup 1: i: 9.9.9.9, u: 1.9.9.1, k: 8.0.0.8. [ 629.530383] hifn0: ring cleanup 2: i: 9.9.9.9, u: 0.9.9.0, k: 9.0.0.9. [ 629.537784] bd0cb8b2220fab0cf10079d1b48ffde82b8bae025030fb5245010d5b7f1fc8c4 [ 629.546619] fail [ 629.548600] [ 629.548601] testing cbc(aes) encryption across pages (chunking) [ 629.556264] [ 629.556265] testing cbc(aes) decryption [ 629.561849] hifn_cra_init: tfm: ffff81003a873f20, dev: hifn0 [ffff81003dd7c2c8]. [ 629.569412] test 1 (128 bit key): [ 629.572868] hifn_setkey: tfm: ffff81003a873f20, ctx: ffff81003a873f60, dev: hifn0 [ffff81003dd7c2c8], len: 16. [ 629.583026] hifn_setup_crypto: req: ffff81003a8739c8, tfm: ffff81003a873f20, ctx: ffff81003a873f60, keylen: 16. [ 629.593270] hifn_setup_session: start [ 629.596981] cmd: i=9, u=0, k=9 [ 629.600081] src: i=9, u=9, k=0 [ 629.603181] dst: i=9, u=9, k=0 [ 629.606283] res: i=9, u=0, k=9 [ 629.609384] hifn0: iv: 0000000000000000 [0], key: ffff81003a873f60 [16], mode: 1, op: 0, type: 0. [ 629.618327] hifn0: 1 dmacsr: 8898888c, dmareg: 22322023, res: 00100000 [10], i: 1.10.10.1, u: 10.10.10.10. [ 629.628039] hifn0: ring cleanup 1: i: 10.10.10.10, u: 1.10.10.1, k: 9.0.0.9. [ 629.635131] hifn0: ring cleanup 2: i: 10.10.10.10, u: 0.10.10.0, k: 10.0.0.10. [ 629.643103] 8d95a3b9e1823aeaff452dc6b285c73c [ 629.648346] fail [ 629.650323] test 2 (128 bit key): [ 629.653776] hifn_setkey: tfm: ffff81003a873f20, ctx: ffff81003a873f60, dev: hifn0 [ffff81003dd7c2c8], len: 16. [ 629.663960] hifn_setup_crypto: req: ffff81003a8739c8, tfm: ffff81003a873f20, ctx: ffff81003a873f60, keylen: 16. [ 629.674202] hifn_setup_session: start [ 629.677914] cmd: i=10, u=0, k=10 [ 629.681186] src: i=10, u=10, k=0 [ 629.684460] dst: i=10, u=10, k=0 [ 629.687734] res: i=10, u=0, k=10 [ 629.691008] hifn0: iv: 0000000000000000 [0], key: ffff81003a873f60 [16], mode: 1, op: 0, type: 0. [ 629.699951] hifn0: 1 dmacsr: 8898888c, dmareg: 22322023, res: 00100000 [11], i: 1.11.11.1, u: 11.11.11.11. [ 629.709663] hifn0: ring cleanup 1: i: 11.11.11.11, u: 1.11.11.1, k: 10.0.0.10. [ 629.716946] hifn0: ring cleanup 2: i: 11.11.11.11, u: 0.11.11.0, k: 11.0.0.11. [ 629.725063] 23a975b74c30c4d6ce38d6dcf0f57be6101112131415161718191a1b1c1d1e1f [ 629.733895] fail#
Problems with HIFN driver development for cryptoapi.
Actually it is more serious problem.
Existing crypotapi is very software-centric, i.e. it does
not have any hardware context nad thus should not initialize it
per request. In hardware (at least in HIFN) each crypto request must
be programmed into device's ROM and registers, so when
user creates a new crypto request (read: new crypto user requests
operations creating crypto TFM structure), it is only assigned
with software context, which contains besides other fields,
crypto functions (encrypt/decrypt/setkey), but does not contain
pointer to crypto device (since software does not need it,
it can store and initialize itself in setkey time).
Another crypto devices (padlock and geode) do not have such problems,
since padlock just uses the same software approach, but with different
asm instructions, and geode has only one device, which has global
pointer accessed from crypto processing functions. #
Second release of the HIFN crypto driver for 2.6 cryptoapi.
Added a lot of cryptoapi bindings.
Driver now supports AES, 3DES and DES ciphers with all four crypto modes
(ECB, CBC, CFB and OFB).
My cat has pissed on my domestic slippers when he saw that.
And believe me, he does know, how to distinguish between good and other code.
Well, I do not have a cat, but if I would, he would definitely
piss on my slippers.
Anyway, patch can be found in archive. #
Preliminary HIFN 795x (7955/7956) crypto accelerator chip driver for mainstream 2.6 tree.
I've just released a preliminary HIFN 795x driver
for mainstream crypto api stack. Driver is based on
my work for acrypto
asynchronous crypto stack, where it worked correctly,
but this one was only compile teted, since I do not have
hardware right now. Will do all tests when it arrives.
I've sent to linux-crypto@ for comments mostly about cryptoapi bindings, since
there are several issues (I was not agree with when Herbert designed them),
which I might implement wrong in the driver.
Due to problems with interrupt storms and possible adapter freeze
(sorry, but HIFN spec I have really sucks, so likely it is programming
error, but who knows) I added special watchdog, which fires if after
predefined timeout sessions which are supposed to be completed are not.
In that case callback is invoked with -EBUSY error.
Neither implementation I checked (OpenBSD, Linux OCF) does not support it,
but it helped me greatly in acrypto days.
Patch is quite big (61k) and contains a lot of debug stuff,
but it is only preliminary work.
So far, patch against 2.6.21 can be downloaded from archive. #
Acrypto is officially closed.
Yes, I close acrypto
project after more than two years of maintenance.
The reason is simple - I could not convince Linux kernel community
to include acrypto into mainline (neither James Morris - previous crypto
maintainer, nor Herbert Xu - current one, did not want to include
such massive subsystem into the tree), although I did not tried too hard.
I continued to support it
as out-of-the-tree package until kernel does not support async API.
This day has come - Herbert Xu proposed
a new async interface to synchronous by design Linux cryptoapi.
It looks good (although I do consider it as a hack on top of synchronous software-only crypto api -
my opinion has not changed after discussion with Herbert more than a year ago :) and
lacks a lot of acrypto features (crypto routing, load balancing, autotuning,
prio queues and so on), but something can be added if required.
I decided that dropping acrypto and focus on async cryptoapi is at least some progress in that area.
I plan to start porting HIFN 795x driver from acrypto to cryptoapi soon, it should not
take too long to complete. #
New acrypto release for 2.6.20 kernel.
Acrypto
allows to handle crypto requests asynchronously in hardware.
Acrypto
supports following features:
New HIFN 795x crypto accelerator driver release.
It includes API changes related to mainline work struct update
and changes related to acryto naming (by Markus Kammerst).
New version available from acrypto
homepage. #
2.6.19 kernel acrypto release.
Acrypto
allows to handle crypto requests asynchronously in hardware.
Acrypto
supports following features:
New acrypto release for 2.6.19 kernel tree.
Changes from 2.6.18 are small enough, but my testing machine is not functional yet,
so I will start testing tomorrow and then will announce release in mail lists. #
New combined acrypto release.
It fixes small glitch in OCF <-> acrypto bridge.
Thanks to Yakov Lerner (author of the module) for fixing it.
Patch is available in archive. #
New asynchronous crypto layer (acrypto) release.
I'm pleased to announce asynchronous crypto layer (acrypto)
release for 2.6.18 kernel tree. Acrypto allows to handle crypto requests
asynchronously in hardware.
With this release of combined patchset for 2.6.18 I drop feature
extensions for 2.6.16 and 2.6.17 trees and move them into maintenance
state.
Combined patchset (190k) and drivers for various acrypto providers can
be found on project's homepage. #
Acrypto has been ported to 2.6.18.
Combined patchset includes:
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: