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 _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users