Hello everyone,
I solved my problem, so I tought I give you an update.
> Then finaly I came across the behavior that puzzles me. Asterisk was
> running with two instances over the crosslink and the console screen was
> blanked on the console. So I wanted to press Shift to unblank it, but
> accidently pressed the CapsLock key. When the screen was unblanked and I
> started to type, I realized, that CapLock was on. I pressed it again
> and in this moment, I got a CRC16 error. I thought that was strange and
> pressed it again twice, and there it was again, Packets from the zaptel
> driver to chan_ss7 got lost. The same behavior happens, when I press
> ScollLock or NumLock. The Keyboard runs on interrupt 1 and the TE205P on
> IRQ11, so there shouldn't be any impact when the keyboard uses this
> interrupt.
I got the card interchanged with a new one from my distributor. With the
new card, the problem does not exsists. So the reason for the strange
behavior was a faulty hardware. That's OK, things like that can happen,
but what I cannot understand is, that the tests shipped with the zaptel
source did not detect it.
If I understand correctly patlooptest should reveal problems with bad
cards, but it went through without problems on my faulty card. I think
the problem is, that the error I had only surfaced, when a channel in
the span was completely used (i.e. the complete bandwith of 64kbit is
used by the signaling channel for SS7). I think that patlooptest does
not use the full bandwith of a channel and therefore does not detect the
error and it tests only one (the first) channel of a span. As I am not a
developer and my C knowledge tends to zero, I am not sure, if my claim
is right. But if it is, zaptel IMHO needs a test, that uses the full
bandwith of more than one channel to detect faulty cards.
Best regards,
Kai
--
Kai Militzer WESTEND GmbH | Internet-Business-Provider
Technik CISCO Systems Partner - Authorized Reseller
L?tticher Stra?e 10 Tel 0241/701333-14
km@xxxxxxxxxxx D-52064 Aachen Fax 0241/911879
|