Here’s what I usually do on a fresh server (tested with CentOS 5.x):

# stop unneeded services
chkconfig gpm off
chkconfig yum-updatesd off
chkconfig xfs off
chkconfig autofs off
chkconfig portmap off
chkconfig nfslock off
chkconfig rpcidmapd off
chkconfig hidd off
chkconfig bluetooth off
chkconfig netfs off
chkconfig pcscd off
chkconfig cups off
chkconfig smartd off
chkconfig avahi-daemon off
chkconfig hplip off
chkconfig messagebus off
chkconfig iscsi off
chkconfig iscsid off

# disable graphical login screen
vi /etc/inittab
id:3:initdefault:

# disable SE Linux if necessary
vi /etc/selinux/config
SELINUX=disabled

reboot

• now a single person can start an AG company in Switzerland (previously 3 persons were required)
• GoDaddy.com is not any more a recommended domain hosting (the SOPA thing)

But outgoing connections from a customer LAN are mostly not a problem at all. So, I bring my own small netbook and place it in the customer LAN. This netbook automatically makes an outgoing SSH connection to my central server (a VPS) and pulls an SSH tunnel so that I can access the netbook from outside.

This is a kind of a backdoor, and it makes sense to make your customer completely aware of what you’re doing.

For such purposes, I have a couple of cheapest 10″ netbooks. I’m using Acer AspireOne and some older eMachines netbooks because they were sold cheaply. Most other netbooks would fit too, but one should be careful about Linux compatibility (especially the video drivers might be a problem). They come with 1GB RAM and 160 or 250 GB hard drives. It’s quite trivial to upgrade them to 2GB RAM, although it’s not really necessary. You must only be careful about buying a new SODIMM with exactly the same clocking as the original one.

The netbooks run standard Ubuntu Linux, with SSH daemon enabled. If the user home directory is encrypted, you won’t be able to login with your public SSH keys, so better not encrypt it.

1. On my central VPS, in /etc/ssh/sshd_config I enabled the keepalives. This turns down a connection which is stalled because of network problems. As we’re setting up SSH tunnels with port mapping, the new tunnel will not be set up until the TCP socket is free. With keepalives, SSH daemon will automatically break the connection and free up the socket. Also I enable remote clients to open a listening socket on my central VPS:

ClientAliveInterval 5
ClientAliveCountMax 3
GatewayPorts yes

2. Create a user on the central VPS. “micro02″ is the host name for my micro-agent netbook. The user has /bin/false as a shell, because we don’t want it to do anything on the VPS:

$ grep micro02 /etc/passwd
micro02:x:1002:1003::/home/micro02:/bin/false

3. On micro02, generate the SSH keys for root, and add the public key to the autorized keys for the user “micro02″ on the VPS.

4. Create a DNS entry for callhome purpose. If your central server moves, you won’t have to reconfigure all your agents.

5. Here’s the script /root/ssh_tunnel.sh on the netbook. The infinite loop sets up an SSH connection with port forwarding. There’s a sleep command on purpose: if there’s no routing to the destination, SSH would exit immediately, and we don’t want the loop to hog all our CPU power. Server key checking is disabled, as the server may eventually change, and we don’t want to lose control of our agent.

#!/bin/sh
while true; do
  ssh -NC -o ServerAliveInterval=5 \
    -o UserKnownHostsFile=/dev/null \
    -o StrictHostKeyChecking=no \
    -R '*:2022:127.0.0.1:22' micro02@callhome.mydomain.net
  sleep 5
done

6. Here’s the startup script /etc/init.d/callhome_ssh_tunnel which brings up the tunnel at the computer boot:

#! /bin/sh
#
### BEGIN INIT INFO
# Provides:          k-open_ssh_tunnel
# Required-Start:    $local_fs $remote_fs $network $syslog
# Required-Stop:     $local_fs $remote_fs $network $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      
# Short-Description: SSH tunnel to support.mydomain.com
### END INIT INFO

PATH=/sbin:/bin:/usr/sbin:/usr/bin
DAEMON="/bin/sh /root/ssh_tunnel.sh"
DESC="SSH tunnel to callhome.mydomain.net"
VERBOSE=yes

# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh

# Define LSB log_* functions.
. /lib/lsb/init-functions

OPTIONS=""
#
# Function that starts the daemon/service
#
do_start()
{
        start-stop-daemon --start --background \
                --name ssh_tunnel.sh --exec $DAEMON \
                || return 1
}

case "$1" in
  start)
        [ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
        do_start
        case "$?" in
                0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
                2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
        esac
        ;;
  stop)
        echo not supported
        ;;
esac

exit 0

7. Test the connection script: SSH to port 2022 on your VPS should bring you to the netbook command prompt. Then enable the startup script:

update-rc.d callhome_ssh_tunnel enable

8. In Power Settings, set “do nothing” when the lid is closed.

9. Reboot the netbook and test

10. Disconnect a running netbook from the network, then connect again, and test.

11. Make a backup copy of your scripts. The best is to use Git with a private repository.

In incoming calls the original Caller ID is lost, so we get some garbage in the From: header, and our own user ID in To:.

Add a new file (conf/sip_profiles/external/zadarma.xml) with your SIP account details:

<include>
  <gateway name="zadarma">
    <param name="username" value="XXXXX"/>
    <param name="password" value="XXXXXXXXX"/>
    <param name="extension" value="attendant"/>
    <param name="expire-seconds" value="120"/>
    <param name="register" value="true"/>
    <param name="register-transport" value="udp"/>
    <param name="proxy" value="sip.zadarma.com"/>
    <param name="retry-seconds" value="30"/>
    <param name="caller-id-in-from" value="false"/>
    <param name="ping" value="25"/>
  </gateway>
</include>

Here “attendant” is a valid extension in my public profile. It directs the call to the automatic attendant IVR menu.  The “extension” directive in the SIP profile sets the value as the destination number.

The attendant extension in my public context (conf/dialplan/public/50_users.xml) looks like the following. It transfers the call to the extension 7800 in my default context:

<include>
  <extension name="pub_attendant">
    <condition field="destination_number" expression="^attendant$">
      <action application="transfer" data="7800 XML default"/>
    </condition>
  </extension>
.... (rest of the public profile skipped)

As a result, anyone from around the world is able to access my PBX at local rates.

SIP Broker is a public service where DID providers share their facilities and use a common database for calling SIP destinations. Unfortunately the original company that started SIP Broker is out of business, and it’s unclear who is maintaining the service now. My emails to their support address remain unanswered for the last couple of weeks. But the service works quite fine.

voip-catalog.com and voip-info.org provide lists of DID providers worldwide, including the free ones.

Zadarma is a Russian VoIP provider, and they offer free DID numbers throughout Russia and also worldwide.

Many (if not most) people, including IT engineers, still think that IP Telephony is about saving on long-distance calls. Some of them also know that it’s about saving on desktop cabling.

Actually it’s much more than that.

1. Low entry cost for office telephony.

With the rise of good-quality, open-source telephony products, such as Asterisk, FreeSWITCH, and a bunch of UI tools on top of them, a small or medium business is not any more facing the need to spend $10000+ on an office telephony system.

An IP PBX can be built in-house, with commodity hardware and open-source software components. Even better, one can rent a hosted PBX if the broadband connection permits that. There are also lots of solutions  for non-IT businesses on the market.

2. Global team infrastructure.

It is now quite common even for small businesses to have remote employees across half the globe. Also the local telecommunication infrastructure is not always readily available.  In some countries, international calls are still ridiculously expensive.

Remote workers can use IP phones to connect directly to your IP PBX. But sometimes the Internet connection at home is not good enough, or your team member is not always at their work place. There are still good and low-cost ways to connect.

For example, DIDWW can offer you a PSTN gateway in remote country, and place the incoming calls directly to your IP PBX.  The SIP Broker allows the same service free of charge, with some extra digits to dial to reach you from their gateways.

3. Voice applications.

Most people still know only two or three voice applications: the voice mail, the conference bridges, and the interactive voice menus. Tor those three, the adoption cost has dropped dramatically. Now one can build any of them at the cost of hardware and an engineer’s hourly work.

But there’s more than that.

One can build voice applications which were too expensive or impossible with traditional PBXes.

For example, employees can choose themselves how they are reachable in the best way. They can manage their own reachability and presence. Calls can be sent to multiple IP and PSTN phones at the same time.  On-call support engineers can login themselves and indicate that hotline calls should be directed to them.  Voice mail can be connected to a ticketing system and create new tickets with MP3 attachments.

those are the applications which I have personally implemented. There are certainly more.

• Git is distributed. You have the whole history of the project in your local directory. Also your work is independent from central server availability.
• Branching and merging is in the nature of Git:  whatever new activity you start, you can spin off a new branch and do your commits without disturbing the production code. After testing, you merge your changes into the master branch easily.
• Bigger choice of transport: Git allows to communicate via SSH, HTTP, its own Git protocol, or by simply archiving and copying your repository if there’s no direct connection to the central server. With SSH transport, you can easily work around strict firewall policies: the pull and push commands are somewhat symmetrical, so if you can’t access the central server for pushing, you can probably pull from your work machine to some intermediate location, and then push to the central server. The possibilities are countless.
• You can keep all your server or application configuration in Git repositories. This allows you to restore the configuration quickly after an unsuccessful change, and you’re not dependent on the central server availability.
• You can have as many central servers as you need for your workflow (for example, I use two public repositories for Torrus).

But of course, Git is different, and it needs a bit of learning.  The whole workflow has to be adapted, as well as habits:

• Your commits don’t go to the central server until you explicitly push them.
• There is no such thing as revision number. You have SHA hash strings instead.
• You are encouraged to do more frequent commits, or group them differently. As you do your commits locally without disturbing anyone, you can control the granularity of your commits in a much more flexible way. You can also undo your commits before they are pushed to the central server.

There are many ways to organize your Git repositories:

• If you work alone and your machine is backed up, you may not even need a central repository.
• At Github  you can have unlimited public repositories, or a number of private repositories at a cost.
• Gitorius is a relatively new service, analogous to Github. Also Sourceforge and many other open-source project hosting services offer Git hosting.
• Gitolite is a nice software that allows you to set up your own Git hosting server easily, with SSH key authentication for multiple users, and access rights. Debian and other packages are available.

UPD: some interesting comments at Hacker News

Important! End your text phrase with a dot, otherwise the spoken phrase will sound unfinished.

After you register at their website, you get an Account ID and a login password. The rest is easy. The following example illustrate how to use their services from a Linux or Cygwin command line:

curl https://tts.neospeech.com/rest_1_1.php \
-d method=ConvertSimple \
-d 'email=me@example.com' \
-d accountId=ef******* \
-d loginKey=LoginKey \
-d loginPassword=5**************6 \
-d voice=TTS_JULIE_DB \
-d outputFormat=FORMAT_WAV \
-d sampleRate=8 \
-d text='Press One to answer the call.'

# Output:
# <response resultCode="0" resultString="success"
#  conversionNumber="3" status="Queued" statusCode="1"/>

curl https://tts.neospeech.com/rest_1_1.php \
-d method=GetConversionStatus \
-d conversionNumber=3 \
-d 'email=me@example.com' \
-d accountId=ef******* \
-d loginKey=LoginKey \
-d loginPassword=5**************6

# Output:
# <response resultCode="0" resultString="success" status="Completed" statusCode="4"
#  downloadUrl="https://tts.neospeech.com/audio/a.php/XXXXXXX/XXXXXXX/result_3.wav"/>

curl -O https://tts.neospeech.com/audio/a.php/XXXXXXX/XXXXXXX/result_3.wav

The resulting result_3.wav file is a 8KHz WAV file can be edited in any sound editor (Audacity for example) and you get a nicely spoken phrase for your IVR application.

The paid account offers more goodies,  like more granular control on pronunciation, and also it produces ad-free output.

UPD: make sure you read the NeoSpeech TOS and use your audio files accordingly.

Among other use scenarios, it may be useful in hotels where only one WiFi client device is allowed in a room.

The below scenario is tested with Ubuntu 11.10, and it should work with older versions too. The TP-Link TL-WN821N is used by default, and also a Ralink3070 based adapter was working the same way.

Install additional packages:

apt-get install bridge-utils isc-dhcp-server bind9 iw hostapd iptables-persistent

Insert your Wi-fi USB adapter and check if AP mode is supported:

iw list

On my netbook, the USB adapter got the name wlan1. Create the hostapd configuration as shown below. You need to adapt it to your country code, channel number, SSID, and the password. Also for some unknown reason, 802.11N mode resulted in maximum 15Mbps connection, while the plain 802.11g was working fine at 54Mbps.

cat >/etc/hostapd/hostapd-wlan1.conf <<EOT
country_code=CH
driver=nl80211
interface=wlan1
bridge=br0
hw_mode=g
channel=5
ssid=sushi
wpa=3
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP CCMP
wpa_passphrase=tempura
#ieee80211n=1
#ht_capab=[HT40+][SHORT-GI-20][SHORT-GI-40]

Disable the automatic startup of DHCP and DNS services, as we only need them in Access Point mode:

update-rc.d bind9 disable
update-rc.d isc-dhcp-server disable
/etc/init.d/bind9 stop
/etc/init.d/isc-dhcp-server stop

Configure the IP pool in /etc/dhcp/dhcpd.conf as follows. I took the network 10.157.157.0/24 as quite unlikely to clash with other networks:

# Wifi AP pool
subnet 10.157.157.0 netmask 255.255.255.0 {
        option domain-name-servers 10.157.157.1;
        max-lease-time 7200;
        default-lease-time 600;
        range 10.157.157.50 10.157.157.60;
        option subnet-mask 255.255.255.0;
        option broadcast-address 10.157.157.255;
        option routers 10.157.157.1;
        }

Add the wlan1 configuration to /etc/network/interfaces:

# Do not add "auto wlan1" here. With it, the netbook will look for this # interface on boot-up, and it will take about two extra minutes if the USB card # is not plugged in iface wlan1 inet manual     hostapd /etc/hostapd/hostapd-wlan1.conf
    post-up /etc/init.d/isc-dhcp-server start
    post-up /etc/init.d/bind9 start
    pre-down /etc/init.d/isc-dhcp-server stop
    pre-down /etc/init.d/bind9 stop

#Bridge interface
auto br0
iface br0 inet static
    address 10.157.157.1
    network 10.157.157.0
    netmask 255.255.255.0
    broadcast 10.157.157.255
    bridge-ports wlan1

In /etc/default/isc-dhcp-server , configure DHCP service to listen on br0 interface only:

INTERFACES="br0"

In /etc/sysctl.conf , allow IP forwarding:

net.ipv4.ip_forward=1

Reboot the machine.

Configure udev to bring up the wlan1 interface when the USB card is inserted:

mkdir /etc/txlab
cat >/etc/txlab/wifi_hotspot_init <<EOT
#!/bin/sh
/sbin/ifdown --force wlan1
/bin/sleep 3
/sbin/ifup --force wlan1
EOT

chmod a+x /etc/txlab/wifi_hotspot_init

cat >/etc/udev/rules.d/90-wifi-hotspot.rules <<EOT
# Bring up the Wifi access point
SUBSYSTEM=="net", ACTION=="add", NAME=="wlan1", RUN="/etc/txlab/wifi_hotspot_init"
EOT

Configure iptables to work as NAT gateway between eth0 and wlan1 and br0:

iptables -t nat -A POSTROUTING -s 10.157.157.0/24 -o eth0 -j MASQUERADE
iptables -A FORWARD -s 10.157.157.0/24 -o eth0 -j ACCEPT
iptables -A FORWARD -d 10.157.157.0/24 -m conntrack --ctstate ESTABLISHED,RELATED -i eth0 -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.157.157.0/24 -o wlan0 -j MASQUERADE
iptables -A FORWARD -s 10.157.157.0/24 -o wlan0 -j ACCEPT
iptables -A FORWARD -d 10.157.157.0/24 -m conntrack --ctstate ESTABLISHED,RELATED -i wlan0 -j ACCEPT
# save the rules for persistent use
iptables-save >/etc/iptables/rules.v4

Now insert the Wifi card, and it should immediately start as access point. Use the command “iwconfig” to see the actual status of wifi adapters.

<extension name="gtalk2voip_outbound">
 <condition field="destination_number" expression="^([a-z][0-9a-z-]*\@gtalk2voip.com)$">
  <action application="bridge"
          data="{sip_invite_domain=pub.example.com}sofia/external/$1"/>
 </condition>
</extension>

then the user entry in FreeSWITCH directory would look like this:

<user id="8533">
 <params>
 <param name="dial-string"
        value="loopback/mygtalkusername@gtalk2voip.com/default"/>
 </params>
</user>

Currently Gtalk2voip accepts only Speex@8kHZ  and G.711 codecs.

For outgoing SIP calls to other public domains in the Internet, you want to set your host name in From: address so, that the called party would be able to call back. By default the remote party would see the call as coming from username@<ipaddress>, which is usually not usable for calling back.

The channel variable “sip_invite_domain” does the trick and sets the correct From domain.

So, in “conf/dialplan/default/99_internet_voip_outbound.xml“, the following example sets the From domain name to “pub.example.com” and optionally sets the caller ID from a user variable “public_sip_caller_username”. The matching pattern allows only addresses starting with a letter, because leading digits are usually used for the local dialplan.

<include>
  <extension name="internet_voip_outbound">
    <condition field="${sip_to_uri}" expression="^([a-z][0-9a-z-]*\@[0-9a-z.-]+)$">
      <action application="set" data="internet_destination=$1"/>
    </condition>

    <condition field="${public_sip_caller_username}" expression="^(.+)$" break="never">
      <action application="set" data="effective_caller_id_number=$1"/>
    </condition>

    <condition>
      <action application="bridge"
         data="{sip_invite_domain=pub.dvop.net}sofia/external/${internet_destination}"/>
    </condition>
  </extension>
</include>

1. Torrus, a well-established and mature software for massive SNMP polling and performance monitoring.
2. Gerty, a new project for network automation. Any tasks on the network devices which need any interaction and automation, are targeted by the tool. The first release is expected soon.
3. Mooxu, a new project which is currently in its early design phase. The product will provide a platform for distributed network testing and monitoring (eventually it may replace Torrus).

The slideshow PDF is available at the meeting agenda page, and also a video will be available soon.

The SMS gateway service is ordered from  iNetWorx.

Few quirks in FreeSWITCH that I had to go around:

The channel variables are not automatically propagated through a loopback endpoint. So, if I want to display the correct Caller ID in call forwarding, I need to export the corresponding variable in A-leg. In the public profile for the incoming extension, I need to set

<action application="export" data="outbound_caller_id_number=${ani}"/>

Then, in the PSTN outgoing extension, my provider needs a custom SIP header “X-Number” to point to the caller ID:

<condition field="destination_number" expression="^([01]\d+)$">
      <action application="set" data="sip_h_X-Number=${outbound_caller_id_number}"/>

Then I can create a user which forwards calls to my mobile:

  <user id="7011">
    <params>
      <param name="dial-string" value="loopback/0794070224/default"/>
    </params>
  </user>

It is important to put the context name in the loopback statement. Otherwise, if a call is transferred from another context, FreeSWITCH tries to find the matching pattern in the current context where the transfer is originated.

Another trick which took awhile: I need the voicemail to send emails with a specific From address, and by default it uses <CallerID>@domain as From address. The ticketing system will then try to send a confirmation to the sender.  The thing is, in FreeSWITCH, mod_voicemail has three different places where From address is defined. Two of them are actually documented: “vm-mailfrom” user parameter and “email-from” voicemail profile parameter. The third one is not documented, and it actually takes the higherst priority: in default email template, “voicemail.tpl“, the From line is explicitly defined. And it needs to look through the mod_voicemail sources in order to realize that.

Also the email template allows to set custom email headers, so I inject the customer ID in “X-Hotline-Cust-Id:”, and then the ticketing system moves the new ticket into the corresponding queue.

The XEN server is upgraded to 768MB RAM. Now there’s enough memory for everything: the basic website, the ticketing system, the FreeSWITCH, and also few more things in the future: the SMS gateway and file sharing application.

FreeSWITCH is great, although it takes time to learn everything. Also it comes with a default configuration which contains lots of examples and unused features. It takes about a day to clean up all unneeded parts.

Also quite time-consuming is the debugging of codec negotiations between various endpoints. It requires lots of calls and wiresharking.

FreeSWITCH provides a great capability to build complex IVR dialogues. Also out of the box, it can call multiple endpoints at the same time, and ask them to press a digit to take the call. This allows us to send the hotline emergency calls to as many phones as we like, regardless of their individual timeouts or voicemail. The fiollowing code inside an extension does the trick:

      <action application="set" data="call_timeout=40"/>
      <action application="set" data="group_confirm_file=phrase:press_one_to_answer"/>
      <action application="set" data="group_confirm_key=1"/>
      <action application="set" data="hangup_after_bridge=true"/>
      <action application="bridge" data="${group_call(hunt_$1@${domain_name}+A)}"/>

Pity that there’s no ready-to-use audio file that would tell “press 1 to answer the call“. Out of the stock audio files in FreeSWITCH, I managed to compose “Press 1 to hear screaming monkeys“.  As  my internal colleagues are supposed to hear this when the customer calls… probably I’ll keep that

Here’s the planned workflow for the hotline number:

• Welcome message
• PBX enters an IVR loop that requests the customer PIN
• PBX tries to route the call to the current support engineer for 40 seconds. It rings all available phones, and once picked up, the engineer hears “Press 1 to hear screaming monkeys“. The firs phone where 1 is dialed is taking the call.
• If unsuccessful, forward the call to the Hotline voice mail
• Voicemail takes the recording, and sends it as attachment to the ticketing system in a high-priority queue
• Ticketing system creates a new ticket and sends SMS to all engineers
• Every 15 minutes, the ticketing system sends SMS to all engineers until the ticket is assigned and opened
• If a ticket remains unassigned and unopened for more than 90 minutes, SMS messages are sent to whomever may help

The PBX will keep the current on-call engineer’s ID in FreeSWITCH internal database. Then there will be a self-service IVR menu for them as follows:

• Enter PIN
• Press 1 to assign Max as the on-call engineer
• Press 2 to assign Greg as the on-call engineer
• … and so on

As a result, there will always be a human which receives the calls, unlike the standard FIFO queue which may not have any agents logged in.

Server information: a XEN VPS, hosted at Softronics.ch, Debian 6.0.2 Squeeze, x86_64, 256MB RAM, 15GB disk.

The ticketing system is built with RT: Request Tracker version 4.0.2, so far one of the best ticketing systems, and definitely the best open-source ticketing system.  It’s installed from Debian backports packages, with Apache, mod_fastcgi, and MySQL as data storage. Postfix is used as MTA (The default recommended MTA is Exim, but I have no experience configuring it).

Google Postini is used as the incoming email front-end filter for the ticketing system. They charge per account, and I thought I would need a separate account license for every incoming address on the ticketing system, but it appears that a single account allows an (unlimited?) number of aliases. So, basically one Postini account is sufficient.

SMS gateway service will be used to send notifications to the support engineers. I haven’t yet chosen between IWAY or eCall or something different.

A Swiss PSTN SIP trunk is most probably going to be purchased from FOXFON.

I am going to build the virtual PBX by myself. I have read the books for Asterisk and FreeSWITCH, and I find FreeSWITCH to be much better organized and easier to make what I want.

FreeSWITCH (as well as Asterisk) is very sensitive to the hardware clock precision. People report very poor results with VmWare VPS, as it emulates the hardware clock, and it’s not physically related to the host system’s clock. XEN, on the contrary, provides direct clocking data from the host system, and people report good FreeSWITCH performance under XEN.

I planned to buy a separate VPS for the PBX, and in the meanwhile installed a FreeSWITCH instance on the same VPS where the ticketing system is running. Surprisingly they feel quite OK together in 256MB RAM, although some swapping is involved. FreeSWITCH is launched with higher process priority, and it occupies only 20-25 MB RAM. But I haven’t yet populated the final configuration, and also some additional web services will be set up, so I’ll have to upgrade to a bigger VPS.

The main purpose of the vPBX is to provide enhanced reachability for the on-call engineers. They should be reachable wherever they are, via their mobile phones or SIP accounts. Also the system should be completely autonomous: the next on-call engineer would simply redirect all hotline calls to himself, without involving the supervisor.

If the on-call engineer is not reachable, the PBX takes a voice message and forwards it as attachment to the ticketing system. The ticketing system then notifies all engineers via SMS that there’s a new urgent ticket.

The main challenge is how to treat various availability events on the mobile phones. Especially that they are abroad. It looks like the most reliable is to call all available phones and play “press 1 to answer the phone”, and wait for input. The only difficulty that on touchscreen smartphones the dial pad is hiding after dialing.

UPD: the project name is now Mooxu

Introduction

In many network environments, especially in those of large ISPs or carriers, there’s a need to periodically execute some network tests. For example, an IPTV transport provider would need to make sure that all important multicast streams are available in every part of its edge network. Or a customer support engineer would need to collect byte and packet counters from a particular network port every 5 seconds.

The new software system (Project name: Mooxu) is designed to provide an open-source framework that enables the network operators to build the testing environment for their needs.  Also a number of open-source testing probe modules will be available.

Distributed architecture: the system consists of a central dispatcher, data aggregators, and the probes, and each of them can be located anywhere in the network on as many devices as necessary.

HTTP API: all system components communicate through a well-defined data protocol on top of HTTP transport.

Secure communication: all API clients authenticate themselves with the use of MD5 digests and shared passwords. SSL may be used for content encryption if enough CPU resource is available and data privacy is required.

Non-restrictive licensing: all components are distributed under a non-restrictive license (MIT?) that allows proprietary extensions without any limits.

Modular software design: the core software distribution provides the API and the tools for controlling the test execution and transporting their result data. Also a number of open-source plugin packages implement particular tests for various network technologies.

Dispatcher

The central dispatcher is the only component that is not distributed (although the design must not exclude redundancy and failover schemes).

The dispatcher is responsible for  controlling the test execution: configuring, starting, aborting, reporting the status, and pointing to the data store.

The dispatcher provides two different API’s: the one for the distributed system components, and the other one for northbound  OSS systems.

The dispatcher integrates with any standard HTTP server software, such as Apache.

The dispatcher maintains a database of all remote components and their properties. Each remote component is identified by a unique name and a shared secret.

Each test consists of a set of attributes:

• core attributes: unique test ID, test classname, start time, duration, owner, probe name, data store name, …
• class-specific attributes that define the particular test
• custom attributes that the local system administrator assigns depending on the requirements

Component initialization and configuration

Each remote component (probes and data stores) communicates to the dispatcher and retrieves its configuration.

At the time of roll-out, each component is preconfigured with its unique name, shared password, and the URL of the dispatcher.

Each component is a permanently-running process that controls other processes and tasks. The components contact the dispatcher and refresh their configuration periodically (the refresh period is part of  the configuration supplied by the dispatcher).

Each component reports its local inventory to the dispatcher: the OS type and version, core software and the plugin versions, etc.

Data store

The system requires at least one data store component to save the test result data. Multiple data stores can be distributed across the network, depending on its topology, available bandwidth, and the system requirements.

Data stores also allow data replication and aggregation. For example, a test collects data every 2 seconds, and saves the results every 60 seconds to a local data store. Then the data is transported to the central location every 5 minutes, because the end user does not actually need it more frequently, but it’s important to have a quick response time for better interactivity.

Data stores also receive event notifications from the probes and forward them to an external event aggregator, such as SYSLOG or SNMP trap collector.

The data store runs an HTTP-based  data access API which allows external programs to retrieve the test results.

Probes

A probe is a process that runs on a probe machine.  It does not perform any tests itself, but spawns the test processes and controls their execution. A probe is identified by a unique name, and in theory, multiple probes may run on the same server.

The test processes are also responsible for sending the result data to the data store.

The test processes may generate events which would be dispatched with higher priority to the event management system. This enables the platform to run long-term or permanent tests and generate alarms.

The probe installation consists of the core package, as well as at least one plugin that implements particular tests.

Software implementation

All software components are distributed as GNU Autoconf-based packages, and are installable with the standard Autoconf procedure (./configure && make && make install). This guarantees a uniform installation procedure and easy packaging for any standard UNIX-like OS.

The main programing language for all components is planned to be Perl. The common API is also possible to implement in C and other programming languages, depending on the customer needs.

This tutorial is based on the Gerty project code at Github.

Hint #1: do not apply AC_CONFIG_FILES to your Perl files directly. Use a helper script (setup_tools/substvars.sh.in in Gerty sources) that does the variable substitution. The reason is that for variables which depend on other variable values, AC_CONFIG_FILES expands them as references. For example, @datadir@ is expanded into ${datarootdir}. A little shell script like substvars.sh expands these recursive references into string values which you finally use in your Perl program.

Hint #2: you may list all your .pm files in a Makefile.am, but then you’d have to update it every time you add a new module. It’s quite easy to miss one, especially if your project is actively developing. Instead, you can embed a small shell script into your makefile, and it would copy all .pm files from your lib directory. See lib/Makefile.am in Gerty sources as a working example.

You may start with writing your configure.ac file as usual. Also it’s faster if you copy it from an existing project

You will definitely need AC_PATH_PROG for Perl, as your installer should be able to work with any perl instance on the target system. Also configure.ac in Gerty sources offers a simple checkup for pre-requisite modules. Also it enables to skip those check-ups if you only intend to package, and not to run the software.

Makefile.am is quite standard so far. The one in Gerty inserts a small file called DIST_REVISION: it contains the date and the Git branch information at the moment of “make dist” execution.

The bin/Makefile.am in Gerty illustrates how the executable scripts need to be handled.

Once all configure.ac and Makefile.am files are ready for testing, proceed as follows:

touch AUTHORS ChangeLog INSTALL NEWS README
aclocal
autoconf
automake -a -c

Later you can run “autoreconf” instead of “aclocal && autoconf && automake“. Autoreconf is part of Libtool package.

Now your package is generally ready. You can proceed with “./configure” and “make install” as you usually do with other packages.

Do not forget the .gitignore (or svn:ignore if you like). Autotools would keep some temporary garbage in your project directory, so it’s important to set up a proper .gitignore before making any commits.

If your posts contain non-ASCII data, here starts the tricky part. Perl has some special treatment for UTF-8 strings, and incorrect handling can easily lead to a wrong signature.

At first, I tried to use LWP::Authen::OAuth module, as it provides the simplest interface and hides most of oAuth internal logic. Unfortunately, it doesn’t care much about the stging encodings, and UTF8-formatted strings get corrupted and result in invalid signatures.

Net::OAuth appeared to be a bit more complex, and a bit insufficiently documented, but proved to work correctly with UTF-8 data.

Here’s the piece which finally worked. It took awhile to build this example, as the module documentation cuts some important corners.

use utf8;
use Net::OAuth;
$Net::OAuth::PROTOCOL_VERSION = Net::OAuth::PROTOCOL_VERSION_1_0A;
use HTTP::Request::Common;
use LWP::UserAgent;
use strict;

my $blog = 'example.tumblr.com';

# token and token_secret are previously retrieved via authorization request
my %oauth_api_params =
    ('consumer_key' =>
        'Tte6Jw...............',
     'consumer_secret' =>
        'H6z7...................',
     'token' =>
        'XPcrob...........',
     'token_secret' =>
        'Wz...................',
     'signature_method' =>
        'HMAC-SHA1',
     request_method => 'POST',
);

my $body =
   '<div style="text-align:center">Hello wörld</div>';

# prepare the body for further encode
utf8::decode($body);

my $url = 'http://api.tumblr.com/v2/blog/' . $blog . '/post';

my $request =
    Net::OAuth->request("protected resource")->new
        (request_url => $url,
         %oauth_api_params,
         timestamp => time(),
         nonce => rand(1000000),
         extra_params => {
             'type' => 'text',
             'body' => $body,
         });

$request->sign;

my $ua = LWP::UserAgent->new;
# this is the tricky part which is not documented where it should
my $response = $ua->request(POST $url, Content => $request->to_post_body);

if ( $response->is_success )
{
    my $r = decode_json($response->content);
    if($r->{'meta'}{'status'} == 201)
    {
        my $item_id = $r->{'response'}{'id'};
        print("Added a Tumblr entry\n");
    }
    else
    {
        printf("Cannot create Tumblr entry: %s\n",
                $r->{'meta'}{'msg'});
    }            
}
else
{
    printf("Cannot create Tumblr entry: %s\n",
            $response->as_string);
}

1. Rent a VPS. For example, at TOCICI a minimal VPS costs as little as $33 per year. The following tutorial is tested with Ubuntu 11.04 on such a minimal VPS.

2. Install and configure Lighttpd

aptitude install git-core lighttpd

cat >/etc/lighttpd/conf-available/50-gitrepo.conf <<EOT
server.modules += ( "mod_cgi", "mod_setenv", "mod_rewrite" )
$HTTP["scheme"] == "https" {
  accesslog.filename = "/var/log/lighttpd/access-ssl.log"  
  server.document-root  = "/srv/www/git01.mydomain.net_ssl/"
  alias.url  += ( "/git" => "/usr/lib/git-core/git-http-backend")
  # prevent a request to "/git" from causing a 500 error (no PATH_INFO)
  url.rewrite-once         = ( "^/git$" => "/git/" )
  $HTTP["url"] =~ "^/git" {
        cgi.assign = ( "" => "" )
        setenv.add-environment = (
          "GIT_HTTP_EXPORT_ALL" => "",
          "GIT_PROJECT_ROOT" => "/srv/www/git01.mydomain.net_ssl/"
          )

        $HTTP["url"] =~ "^/git/CUSTOMER01/" {
          auth.backend = "htpasswd"
          auth.backend.htpasswd.userfile = "/etc/lighttpd/CUSTOMER01-htpasswd.user"
          auth.require = ( "" =>
                           ( "method" => "basic",
                             "realm" => "Git",
                             "require" => "valid-user"
                           )
                         )
        }
  }
}
EOT

/usr/sbin/lighty-enable-mod auth accesslog ssl gitrepo
/etc/init.d/lighttpd force-reload
htpasswd -c /etc/lighttpd/CUSTOMER01-htpasswd.user USER01

3. Create Git repositories, and the users would be able to read/write to them via HTTPS with password authentication.

http://bellard.org/jslinux/tech.html

2011-04-14 15:47:21: DEBUG: 40 bytes message received from 62.x.x.x[500] to 2
13.x.x.x[500]
2011-04-14 15:47:21: DEBUG:
30652081 6d92a9ee 00000000 00000000 0b100500 4bd389ff 00000028 0000000c
00000000 0100000e
2011-04-14 15:47:21: DEBUG: malformed cookie received or the initiator's cookies collide.

The ting is, racoon uses AES key length of 128 bit by default, and Checkpoint firewalls use AES-256 (for Phase 1 only 256-bit keys are supported).

The following configuration should fix the problem. Also “sainfo” line shows how to set AES-256 for  Phase 2:

remote 62.x.x.x {
        exchange_mode main;
        proposal {
                encryption_algorithm aes 256;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2;
                lifetime time 1440 minutes;
        }
        generate_policy off;
        nat_traversal force;
}

sainfo address 213.x.x.x[any] any address 62.y.y.y/24[any] any {
        encryption_algorithm aes 256;
        authentication_algorithm hmac_sha1;
        compression_algorithm deflate;
}

It’s cheap: most probably, subsidized by the Thalia book store. It also allows you to copy books via USB or read them directly from a Micr0SD card.

It’s German: the UI at the first run is all in German language, but you can switch to English in settings.

It’s slow… sometimes you have to wait for its reaction. Sometimes it hangs up on large PDF files.

It’s buggy. Also Medion is not really a software business, so all the customer relation and software development is new to them.

The newest firmware R3407 is reported to have problems with PDF files, and also many people could not switch off the device or put it into standby mode.

Bugs found with firmware R2342:

• Russian ePub files are a bit of a problem: symbols in italics are displayed as question marks. HTML and PDF files are displayed as expected
• I couldn’t fix it in Landscape mode. Orientation settings provide 3 options: Auto, Portrait, Landscape. Landscape appears to be equal to Auto: the device is sensitive to its gravity sensor, and tries to re-draw the text as you move around.
• It doesn’t remember the PDF reading settings, and you have to choose them next time you open a PDF.

Useful links:

• Michaels EDV-Blog (in German). Interesting news and test results. Saved me a bit of time in not upgrading to R3407.
• Frank’s Wiki (in English). The guy has hacked the device. You can, in theory, run your own software with it
• OYO on Facebook (in German). The official facebook page, with all announcements from the software developers and user forum.

Cybook Orizon reader seems to be quite nice…

http://github.com/ssinyagin/gerty

/*
 *  IMX27 Big-endian test
 *  File: imx27-betest.S
 *  Stanislav Sinyagin ssinyagin@k-open.com
 */

#ifdef __ARMEB__
#error This file must be compiled in little-endian mode
#endif

         /* Delay a bit */
        .macro DELAY_FOR cycles, reg0
        ldr     \reg0, =\cycles
        subs    \reg0, \reg0, #1
        subne   pc,  pc, #0xc
        .endm
	/* wait for coprocessor write complete */
        .macro CPWAIT reg
        mrc  p15,0,\reg,c2,c0,0
        mov  \reg,\reg
        sub  pc,pc,#4
        .endm

.globl _start
_start:

	/*
	 * set the cpu to SVC32 mode
	 */
	mrs	r0,cpsr
	bic	r0,r0,#0x1f
	orr	r0,r0,#0xd3
	msr	cpsr,r0

	/*
	 * invalidate I/D cache/TLB and drain write buffer
	 */
	mov r0, #0
	mcr p15, 0, r0, c7, c7, 0	/* invalidate I cache and D cache */
	mcr p15, 0, r0, c8, c7, 0	/* invalidate TLBs */
	mcr p15, 0, r0, c7, c10, 4      /* Drain the write buffer */

	/*
	 * disable MMU stuff and caches
	 */
	mrc p15, 0, r0, c1, c0, 0
	bic	r0, r0, #0x00002300	/* clear bits 13, 9:8 (--V- --RS) */
	bic	r0, r0, #0x00000087	/* clear bits 7, 2:0 (B--- -CAM) */
	orr	r0, r0, #0x00000002	/* set bit 2 (A) Align */
	orr	r0, r0, #0x00001000	/* set bit 12 (I) I-Cache */
	mcr p15, 0, r0, c1, c0, 0

	/* initialize the first 64 bytes at 0xA3000000 */
	ldr r0, =0xA3000000
	ldr r1, =16
	ldr r2, =0x11223344
	1:
	str r2, [r0], #4
	subs r1, r1, #1
	bne 1b

	/* Invalidate cache */
tci_loop:
	mrc p15, 0, r15, c7, c14, 3
	bne tci_loop	

	mov r0, #0
	mcr p15, 0, r0, c7, c7, 0	/* invalidate I cache and D cache */
	mcr p15, 0, r0, c8, c7, 0	/* invalidate TLBs */
	mcr p15, 0, r0, c7, c10, 4   /* Drain the write buffer */

	/* set big endian */
	mov r0, #0
	mrc	p15, 0, r0, c1, c0
	orr	r0, r0, #0x80
	mcr	p15, 0, r0, c1, c0
	CPWAIT  r0

	DELAY_FOR 0x4000, r0

	/* We are in big endian mode. */
	ldr r0, =0xA3000000
	mov r2, r0
	mov r1, #0xFF
	strb r1, [r0], #4
	str r1, [r0], #4
	ldrb r1, [r2]
	strb r1, [r0], #4
	str r1, [r0], #4

	/* loop forever */
	1:
	nop
	b 1b

Compiled into a.out:

  arm-linux-as imx27-betest.S

Uploaded into u-boot and executed:

BIOS> setenv ipaddr 192.168.1.5; setenv serverip 192.168.1.40; tftpboot 0xA0000000 a.out; go 0xA0000000
FEC ETHERNET: Link is up - 100/Full
TFTP from server 192.168.1.40; our IP address is 192.168.1.5
Filename 'a.out'.
Load address: 0xa0000000
Loading: #
done
Bytes transferred = 803 (323 hex)
## Starting application at 0xA0000000 ...

Reset the board and examined the memory:

BIOS> md 0xA3000000 20
a3000000: 112233ff 000000ff 11223311 00000011    .3"......3".....
a3000010: 11223344 11223344 11223344 11223344    D3".D3".D3".D3".
a3000020: 11223344 11223344 11223344 11223344    D3".D3".D3".D3".
a3000030: 11223344 11223344 11223344 11223344    D3".D3".D3".D3".
a3000040: 115e2008 121000c0 122008cc 02004084    . ^....... ..@..
a3000050: 11108200 000802c8 20040000 00800088    ........... ....
a3000060: 10101048 0000308c 11c90004 33800088    H....0.........3
a3000070: 12044144 11860108 1100284c 20680588    DA......L(....h
BIOS>

Results:

[0xa3000000]: The byte 0xFF was written into the least significant byte, although, according to big endian mode, it should’ve been written into the most significant byte.

[0xa300000c]: ldrb has read the most significant byte, as it’s supposed to do in big-endian mode.

with the following GCC 4.2.4 arguments (optimization switched off):

/home/armadeus-be/buildroot/build_armv5te/staging_dir/usr/bin/armeb-linux-uclibc
-gcc -g  -O0  -fno-strict-aliasing  -fno-common -ffixed-r8 -msoft-float  -mbig-e
ndian -D__KERNEL__ -DTEXT_BASE=0xAFF00000 -I/home/armadeus-be/buildroot/project_
build_armv5te/apf27/u-boot-1.3.4/include -fno-builtin -ffreestanding -nostdinc -
isystem /home/armadeus-be/buildroot/build_armv5te/staging_dir/usr/bin-ccache/../
lib/gcc/armeb-linux-uclibc/4.2.4/include -pipe  -DCONFIG_ARM -D__ARM__ -march=ar
mv5te -mabi=apcs-gnu -Wall -Wstrict-prototypes -fno-stack-protector -c -o env_co
mmon.o env_common.c

the generated code writes a byte  to some  memory access ([fp, #-13]), and then reads from the same address:

uchar env_get_char (int index)
{
 108:   e1a0c00d        mov     ip, sp
 10c:   e92dd800        push    {fp, ip, lr, pc}
 110:   e24cb004        sub     fp, ip, #4      ; 0x4
 114:   e24dd008        sub     sp, sp, #8      ; 0x8
 118:   e50b0014        str     r0, [fp, #-20]
        uchar c;

        /* if relocated to RAM */
        if (gd->flags & GD_FLG_RELOC)
 11c:   e1a03008        mov     r3, r8
 120:   e5933004        ldr     r3, [r3, #4]
 124:   e2033001        and     r3, r3, #1      ; 0x1
 128:   e20330ff        and     r3, r3, #255    ; 0xff
 12c:   e3530000        cmp     r3, #0  ; 0x0
 130:   0a000004        beq     148 <env_get_char+0x40>
                c = env_get_char_memory(index);
 134:   e51b0014        ldr     r0, [fp, #-20]
 138:   ebfffffe        bl      a0 <env_get_char_memory>
 13c:   e1a03000        mov     r3, r0
 140:   e54b300d        strb    r3, [fp, #-13]
 144:   ea000003        b       158 <env_get_char+0x50>
        else
                c = env_get_char_init(index);
 148:   e51b0014        ldr     r0, [fp, #-20]
 14c:   ebffffbc        bl      44 <env_get_char_init>
 150:   e1a03000        mov     r3, r0
 154:   e54b300d        strb    r3, [fp, #-13]

        return (c);
 158:   e55b300d        ldrb    r3, [fp, #-13]
}
 15c:   e1a00003        mov     r0, r3
 160:   e24bd00c        sub     sp, fp, #12     ; 0xc
 164:   e89da800        ldm     sp, {fp, sp, pc}

here’s the GDB session output. A value of  0×62 was stored by strb command, and a completely different value was returned by ldrb:

(gdb) add-symbol-file u-boot 0xaff00000
add symbol table from file "u-boot" at
	.text_addr = 0xaff00000
(gdb) target remote localhost:3333
start_armboot () at board.c:304
/home/armadeus-be/buildroot/project_build_armv5te/apf27/u-boot-1.3.4/lib_arm/board.c:304:8383:beg:0xaff01630
(gdb) b env_get_char
Breakpoint 1 at 0xaff2b8c8: file env_common.c, line 191.
(gdb) c

Breakpoint 1, env_get_char (index=0) at env_common.c:191
(gdb) del
(gdb) display/i $pc
(gdb) display/x $r3
(gdb) x/w $r11
0xafe9fddc:	0xaff2b8c4
(gdb) x/w 0xafe9fdcc
0xafe9fdcc:	0xaff41404
(gdb) display/w 0xafe9fdcc
(gdb) ni
3: x/xw 2951347660  0xafe9fdcc:	0xaff41404
2: /x $r3 = 0xafe9ffdc
1: x/i $pc  0xaff2b8cc <env_get_char+24>:	ldr	r3, [r3, #4]
(gdb)
3: x/xw 2951347660  0xafe9fdcc:	0xaff41404
2: /x $r3 = 0x1
1: x/i $pc  0xaff2b8d0 <env_get_char+28>:	and	r3, r3, #1	; 0x1
(gdb)
3: x/xw 2951347660  0xafe9fdcc:	0xaff41404
2: /x $r3 = 0x1
1: x/i $pc  0xaff2b8d4 <env_get_char+32>:	and	r3, r3, #255	; 0xff
(gdb)
3: x/xw 2951347660  0xafe9fdcc:	0xaff41404
2: /x $r3 = 0x1
1: x/i $pc  0xaff2b8d8 <env_get_char+36>:	cmp	r3, #0	; 0x0
(gdb)
3: x/xw 2951347660  0xafe9fdcc:	0xaff41404
2: /x $r3 = 0x1
1: x/i $pc  0xaff2b8dc <env_get_char+40>:	beq	0xaff2b8f4 <env_get_char+64>
(gdb)
3: x/xw 2951347660  0xafe9fdcc:	0xaff41404
2: /x $r3 = 0x1
1: x/i $pc  0xaff2b8e0 <env_get_char+44>:	ldr	r0, [r11, #-20]
(gdb)
3: x/xw 2951347660  0xafe9fdcc:	0xaff41404
2: /x $r3 = 0x1
1: x/i $pc  0xaff2b8e4 <env_get_char+48>:	bl	0xaff2b84c <env_get_char_memory>
(gdb)
3: x/xw 2951347660  0xafe9fdcc:	0xaff41404
2: /x $r3 = 0x62
1: x/i $pc  0xaff2b8e8 <env_get_char+52>:	mov	r3, r0
(gdb)
3: x/xw 2951347660  0xafe9fdcc:	0xaff41404
2: /x $r3 = 0x62
1: x/i $pc  0xaff2b8ec <env_get_char+56>:	strb	r3, [r11, #-13]
(gdb)
3: x/xw 2951347660  0xafe9fdcc:	0x62f41404
2: /x $r3 = 0x62
1: x/i $pc  0xaff2b8f0 <env_get_char+60>:	b	0xaff2b904 <env_get_char+80>
(gdb)
3: x/xw 2951347660  0xafe9fdcc:	0x62f41404
2: /x $r3 = 0x62
1: x/i $pc  0xaff2b904 <env_get_char+80>:	ldrb	r3, [r11, #-13]
(gdb)
3: x/xw 2951347660  0xafe9fdcc:	0x62f41404
2: /x $r3 = 0x4
1: x/i $pc  0xaff2b908 <env_get_char+84>:	mov	r0, r3
(gdb)

So,  the byte write operation happened in little endian, and the byte read was done in big endian mode. Looks like a bug in mx27 chip?

(copying the text)
Today I had a need to test a DSL connection in the lab (15 minutes walk from my working place), and I had an idea what could be saving lots of my time: a device consisting of two independent linux systems, connected by some kind of a terminal link.
One box emulates a user’s PC connected to the ADSL modem: sends DHCP requests, gets its address and default gateway there, as well as DNS setings.
The other box is connected to the lab’s LAN where I can access it remotely, and connect to the first one via a serial console.

Another possible use case: a secure jumphost into some remote network. Exposing the box to the Internet and accepting the risk of it being DOSed or even cracked, the managed system is not affected (provided that there’s an additional level of authentication between them).

Another (impossible) kind of use case: connect two cameras and emulate the work of two halves of the human brain

Requirements so far:

• Portable enclosure with external universal power supply

• Two MIPS or ARM CPUs able to work in big endian mode (BE should provide better network performance over LE, especially in IPv6). Ideally the BE/LE mode would be configurable by a jumper for each core. Intel IXP as a candidate for the CPU

• Each core having:
  • CPU power comparable to 400MHz ARM9
  • at least 128MB RAM
  • 128MB flash
  • SD or microSD card slot
  • USB2.0 host
  • Two 10/100 Ethernet NICs. Ideally with 802.1q support on each NIC
  • 5V serial console (DB9 or RJ45 in Cisco pinout)

• USB2.0 OTG ports on each core wired back-to-back to each other.

The end user is responsible to configure the back-to-back USB ports as a Serial or Ethernet connection at their wish (Linux gadget drivers are supposed to allow that out of the box).

Interesting option would be a plastic enclosure box and enough space to place a 3G or Wifi USB dongle inside it. Then at least one internal USB host port is also needed (ideally, two )

The UART control registers receive correct values, I verified this.
So, most probably the UART hardware fails to get those values from a big-endian CPU.

Here’s the link to the u-boot patch to be studied.

UPD: Currently the nand_spl loader is compiled in LE, and then it prepares the u-boot image in the memory and switches to BE mode. Then u-boot starts quite normally, but then it hangs up without printing anything to the serial console. Looks like some initialization code breaks internal memory. Need to solder a JTAG connector for further debugging…

The Armadeus devboard comes without any cables. The LCD and touchscreen are equipped with two cables for connecting to the devboard. The devboard needs a 2.5/5.5 power jack, and the power supply should support at least 12W power draw.

List of part numbers from Conrad.ch:

• 510524 (power supply)
• 526673 (30mm spacer, 4pcs)
• 526630 (10mm spacer, 4pcs)
• 526657 (20mm spacer, 4pcs)
• 526517 (10mm spacer, female/female, 4pcs)
• 529569 (160×100 plate)
• 546645 (200×2.5mm stripes)

Original Armadeus development board with apf27, LCD and touchsreen adapter:

160×100 plate (the holes at the corners look ugly, I know) and the stands (20mm spacer is not shown):

All the parts assembled together:

The 20mm stand is not necessarily needed, but it makes access easier. The pink foam has come as part of the Armadeus package.