Airport Extreme, loosing WAN (adsl2 bridged) unnoticed on regular basis
in 2007, I bought an Apple Airport Extreme access point. This is connected with an ADSL modem to my ISP.
I discovered that at irregular intervals, the Internet connection would be lost, but the airport extreme would not discover this (the green led continues staring at me defiantly, even though the logging in the airport extreme would also indicate a line stating the apple ntp server could not be used to synchronize the time (whereas this synchronization is logged working fine some time before [logging states: Severity:5 Clock synchronized to network time server time.euro.apple.com (adjusted +0 seconds).]).
When I switched to ADSL2, these recurring hickups became more regular. Whenever these connection droppings occurred, a reboot (using the airport utility) of the base station (menu item "Base Station", option "Reboot") would fix the problem, after some reboot time (where the switch and airport functionality temporarily becomes unavailable (so network shares are lost, opened network files closed)) the network and the internet connection would become available again.
When replacing the airport extreme with a mac mini (and dhcp client on the mac mini activated), the internet connection (adsl2) becomes available, and is not dropped (for at least 6 days (2 test runs)).
Convinced this experience prooved the airport extreme was faulty, I contacted the apple store. There someone told me that the airport extreme must be faulty, but since the warranty period is over, the price for a repair would equal the price for a new device.
I bought myself a new time capsule, and replaced the airport extreme by it. The Internet is connected to the ADSL2 modem configured with bridging. The Time Capsule is configured to receive a DHCP response at WAN (which in fact is a fixed Internet Address). The Time Capsule also manages the local wifi with hidden ESSID and WPA2 encryption. The dhcp server in the time capsule provides configured addresses to potentially 5 LAN UTP clients, and 7 WIFI clients. Access control lists based on MAC address protects one small step further.
Although I'm happy with the increased switch speed (now 1000/100/10 instead of the 100/10MB), and the included 1TB time machine, the new machine displays the same unwanted behaviour. After about 2 to 4 hours, the Internet connection is lost without the access point discovering this loss. The access point A testrun again with the mac mini shows the mini not loosing connection (the mini however is not providing dhcp addresses to the intranet, which the extreme is).
I now run a script that at an interval tries to contact 5 websites. If all 5 consecutively fail to be contacted, an apple script is launched that will reboot the base station. These actions are logged, and show me the regularity of the failures:
20100101 165524 lost
20100101 170105 reboot
20100101 170556 OK
20100101 200953 lost [3h4m]
20100101 201533 reboot
20100101 202024 OK
20100101 220443 lost [1h45]
20100101 221009 reboot
20100101 221500 OK
20100101 234550 lost
20100101 235131 reboot
20100101 235623 OK
20100101 010000 suspended script
20100102 120000 launched script again
20100102 134558 lost
20100102 135138 erboot
20100102 135633 OK
20100102 161055 lost
20100102 161619 reboot
20100102 162107 OK
20100102 184857 lost
20010102 185437 reboot
20100102 185924 OK
This rebooting however is just a fixer,... always clears the logfile of the airport.
Labels: adsl2, airport extreme, apple, bug, hardware, network, wifi
ScanSoft RealSpeak 3.51 for Linux - problem with Debian ETCH (ext3 ?)
hi,
I updated my (quick-and-dirty) post originally called "
Text To Speech (ScanSoft RealSpeak)". Hoping it would become less obscure.
Today I encountered some problems with another installation (being Debian ETCH, kernel 2.6.18-4, with root ext3)... for which I found
a workaround.
It seems that ScanSoft RealSpeak 3.5.1 does not function (anymore) in this distribution. The
standard application (as used in aforementioned Posting), "hangs" just after outputting "Initialize".
When using
strace it looks like one of the internal functions of RealSpeak looses itself in a loop... always continuing looking into (digging deeper and reaallly deeper!!!) into directory "
." (so actually it's not digging deeper, ... but it's not comming back anyway).
This is probably caused by the (erroneous ? obsolete ?) assumption of the (a) programmer that a
readdir(3) (or but probably not
getdents(1)) will return its first two items being "
." and "
..". Thus not needing to "check" them out, and jumping to number three.
The code seems to go down into all directories of the given
engine directory.
But if the result is not ordered with these
. and
.. upfront, but on some other position 3 (or 4), these
special directory entries seem to be treated like any regular directory and descended into... And if - like all good stories - the story repeats itself (very probable if e.g. we're examining
. as a regular directory, thus
descending into it, actually staying put), this could take a while...
Here some logging:
open("/opt/scansoft/tts/engine/../api/server"...
...
open("/opt/scansoft/tts/engine/../api/./server"...
...
open("/opt/scansoft/tts/engine/../api/././server"...
...
open("/opt/scansoft/tts/engine/../api/./././././././././server"...
...
This snippet can be explained thus:
First when examining
engine directory,
getdir returns
.. on some later-than-second place. This directory is treated as any other directory and since the code is - probably - descending recursively into all directories, looking for all languages available for instance (?), the code examines that directory.
Then Apparently getdir of that directory
.. directory (actually the directory
/opt/scansoft/tts) returns directory
api (being absolutely
/opt/scansoft/tts/api, but by the faulty procedure now considered part of the
engine-tree.
Then second Murphy: the directory
api apparently ahs it's
. reference as first directory entry, (later-than-second place), so the anxious procedure is going there,... . But now we arrive absolutely again in the same spot (directory
api, which again gives
. as directory.... return the same result, and we're off for a nice long trip into
././././././././././... and so onProof for(or making understandable/acceptable of) this assumption ?
Well,
dir -f returns the list of files in order of the filesystem, so I executed that:
and got:
$ ls -af /opt/scansoft/tts/engine
libicudata.so.22 tts4sml.so libicuuc.so.22 dec_encrypt.so ttsengine.so ..
dub . headers libxml4c.so.50 xlit_1252.so
On other distributions/versions/systems (where the ScanSoft software does work), this instruction returns:
$ ls -af /opt/scansoft/tts/engine
. dec_encrypt.so headers dub libxml4c.so.50 xlit_1252.so
.. libicudata.so.22 tts4sml.so libicuuc.so.22 ttsengine.so
Thanks to my collegue Erik Devriendt for helping me finding the origin of the failure.Solution
A clean solution to the problem would be a bugfix by ScanSoft (Nuance now) seems to be in its place...
A
workaround has been composed:
In the process of finding a workaround, I mounted (using sshfs) the engine-directory of a working system over the engine directory of a non-working, and the system functioned...
More fine-tuning of this discovered that especially the
header directory of the working system was important. The other files and directories could be used within the local system (using symlinks).
Anyway... In that process, I tried to compose an image-file and mounting it through loopback. Then I discovered that when an ext2 image was extended with a journal (
tune2fs -j /dev/loop123) to ext3, and subsequently mounted, the directory got scrambled again. Mounting as ext2 did not solve this.
But when using an (ext2) image mounted on the engine directory, the Initialization procedure indeed continued (did not loose itself in that nasty recursion), but apparently the system then did not find the required files..., because the Initialization returned with Error 23 (in api/inc/lh_err.h, we find
TTS_E_NO_MATCH_FOUND 23 . This is the same behaviour as when you request an unknown language-code...
In a last desperate attempt, I created an ext2-image (205M), mounted it as the
/opt/scansoft and reinstalled all (rs-api and rs-<lang> packages).
This worked !!!Although this system now works, I think it more safe just to use another distribution, c.q. version that does not have this problem.
Procedure for workaround:
In this procedure, we assume it being executed by a user with sudo privileges on
dd,
losetup,
mkfs.ext2,
mount,
mkdir,
dpkg, OR execute it in the unsafe way: as superuser.
Create the image-filesystem (first on arbitrary location)
$ img=/opt/scansoft.img;
$ dev=$(/sbin/losetup -f);
$ sudo dd if=/dev/zero of=${img} bs=$(( 1024*1024 )) count=205;
$ sudo /sbin/losetup ${dev} ${img};
$ sudo /sbin/mkfs.ext2 ${dev};
$ mnt=/opt/scansoft;
$ sudo mkdir -p ${mnt};
$ sudo mount ${dev} ${mnt} -t ext2;
$ sudo dpkg -i rs-*.deb;
$ ls -af ${mnt}/tts/engine/headers
. dec_encrypt.so headers dub libxml4c.so.50 xlit_1252.so
.. libicudata.so.22 tts4sml.so libicuuc.so.22 ttsengine.so
Now finaly, test the standard test-program:cd /tmp;
echo "This is a simple test">test.txt;
/opt/scansoft/tts/api/demos/standard/standard 0 0 /opt/scansoft/tts/engine test.txt;
You should now see Initialize
Process
Uninitialize
after which the current directory should hold a standard.pcm file (of filesize > 0).
To allow automatically (and user-requested) mounting (c.q. unmounting) of the ScanSoft system, we added a line to
/etc/fstab:
/opt/scansoft.img /opt/scansoft ext2 loop,ro,users,exec 0 2
Labels: bug, debian etch, ext3, getdir, linux, Nuance, ScanSoft RealSpeak
CAIVIAR capiserver using realspeak
Finally....
The caiviar server source 0.3.5 has some flaws when compiling/using it in relation to Scansoft RealSpeak TTS engine under Linux.
Currently, I can't make the thing connect to a Scansoft TTS-server, but I can use the engine statically linked in.
In what follows, I assumed (change for your needs):
- the installation of scansoft realspeak is in REALSPEAKDIR (mine: /opt/scansoft/tts)
REALSPEAKDIR=/opt/scansoft/tts/
- the caiviar source is in CAIVIARDIR (mine: /tmp/caiviar-0.3.5)
CAIVIARDIR=/tmp/caiviar-0.3.5/
this is what I did:
- fix
${CAIVIARDIR}server/RealSpeak.cpp
I *did* alter more than minimally needed. Most importantly:
- change the
".\\Engine" string you find into the directory needed for your system. (I changed it to "/opt/scansoft/tts/engine"
- replace
tts_language by language
- replace
stdup by strdup
- if needed, change or adjust the code around "
Setting language to" to have YOUR constant(s) (for your specific language).
You should consult ${REALSPEAKDIR}api/inc/lh_ttsso.h (or your RealSpeak documentation) for correct values/constants.
Check after installation (see below) the configuration file (probably /etc/ivr.properties the line stating realspeak.language= should have one of the strings caught by that functionality. (default is "german").
- incorporate RealSpeak includes and objects (of your RealSpeak obtained installation)
cp ${REALSPEAKDIR}api/lib/* ${CAIVIARDIR}server/TTS
cp ${REALSPEAKDIR}api/inc/* ${CAIVIARDIR}server/TTS
- configure and compile caiviar (capiserver)
cd ${CAIVIARDIR} && ./configure --enable_realspeak && make
- install caiviar (capiserver)
cd ${CAIVIARDIR} && sudo make install
- create sysv-init script:
create /etc/init.d/capiserver
#!/bin/bash
# Filename: capiserver
# Version: 1.0
# Author: Dieter Demerre
# Description
# SysV-init script to launch capiserver
#
# usually known as: /etc/init.d/capiserver
#
NAME="CAIVIAR CAPI Server"
CAIVIARCONFIG=/etc/ivr.properties
CAIVIAR_PIDFILE=/var/run/capiserver.init.pid
CAIVIAR=/usr/local/bin/capiserver
if [ ! -x ${CAIVIAR} ]; then
echo -n "\nError: Could not find ${CAIVIAR} executable.\n" >&2
exit 5
fi
test -f ${CAIVIARCONFIG} || echo "WARNING no ${CAIVIARCONFIG} config found\n" >&2
case "$1" in
start) startproc -f -p ${CAIVIAR_PIDFILE} ${CAIVIAR};;
stop) killproc -p $CAIVIAR_PIDFILE -TERM ${CAIVIAR};;
restart) $0 stop ; $0 start;;
*) echo -n "unknown action.\nknown actions are: (start|stop|restart)\n"; exit ;;
esac
link to /etc/init.d/capiserver from the expected sysV runlevel directories (distribution specific, maybe use system-tools to set the links).
for level in 2 3 5;
do
sudo ln -sf ../init.d/capiserver /etc/init.d/rc${level}.d/S99capiserver;
done
Labels: bug, caiviar, compilation, linux, ScanSoft RealSpeak, telephony, TTS
