[asterisk-users] zaptel/ssh interaction

[Greg Woods]

On Sun, 2007-04-15 at 19:07 +0300, Tzafrir Cohen wrote:

> 
> The thing I specifically wondered about is that zaptel on its own causes
> problems (without modules that actually generate spans: ztdummy, wctdm,
> wcfxo, etc.)

You are correct: I can load zaptel by itself and I do not see the
problem. I determined by trial and error that the minimal set of modules
that I need in order for my TDM-31B card to work are wctdm24xxp and
wctdm. Unfortunately, with only these two loaded, I still have the
problem. Is there a way to use this knowledge to my advantage?

> 
> So the problem is with /dev/random (the entropy pool)?

I had wondered whether or not this had something to do with it, if only
because I couldn't think of anything else that would cause only RSA
negotiation to fail while everything else still worked.

> 
> What happens if you replace /dev/random with a link to /dev/urandom ?

I tried that, but it had no effect: same problem.

> 
> What do you get from an strace of the sshd around thetime it hangs?

The problem is not specific to sshd, since outbound ssh exhibits the
same problem. So I tried strace there, and it doesn't help a whole lot.
Here's what the tail of the strace output looks like when it exhibits
the problem:

open("/root/.ssh/known_hosts", O_RDONLY|O_LARGEFILE) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=1484, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7
f3e000
read(4, "portal,192.168.1.251 ssh-rsa AAA"..., 4096) = 1484
close(4)                                = 0
munmap(0xb7f3e000, 4096)                = 0
write(2, "hash mismatch\r\n", 15)       = 15
write(2, "key_verify failed for server_hos"..., 39) = 39
exit_group(255)                         = ?

It reads the known_hosts file, then the next thing it does is crap out.
This means the computational error is occurring somewhere in user space,
due to god knows what that happens earlier. It does open and apparently
successfully read 32 bytes from /dev/urandom previous to this.

Without zaptel, this output looks like:

open("/root/.ssh/known_hosts", O_RDONLY|O_LARGEFILE) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=1484, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7
fde000
read(4, "portal,192.168.1.251 ssh-rsa AAA"..., 4096) = 1484
close(4)                                = 0
munmap(0xb7fde000, 4096)                = 0
write(3, "\0\0\0\f\n\25\0\0\0\0\0\0\0\0\0\0", 16) = 16
write(3, "\6\213\320M\236\315\"\321|\212\327%\252\235\3\251A\261"...,
48) = 48

File descriptor 3 is the previously-opened socket to port 22, and things
proceed normally from there. I'm not saying the evidence of what is
going on isn't in these strace outputs somewhere, I just don't know what
I should look for.

[sound issue]
> Not sure how this is related. Maybe this is aa separate issue.

Could be, but maybe not. I do intend to try pulling the sound card out
of the machine in case what I'm looking at is some sort of driver
conflict. I thought those were a thing of the past, but I remember old
Mac systems having this sort of problem frequently. First I'm going to
try the newer version of the zaptel driver, then (if it will compile) a
newer kernel, because that's easier to try (doesn't require pulling all
the cables and opening the box).

--Greg