Asterisk incontinence, leaking all that memory…

During the last week i spent quite some time testing several Asterisk versions in terms of memory usage. My test scenario involves an Asterisk server which receives SIP calls from a call generator (based on sofia-sip) and runs a very simple dialplan:

exten => _+.,1,Wait(15)
exten => _+.,n,Ringing
exten => _+.,n,Wait(10)
exten => _+.,n,Hangup

The call generator will terminate the call right after receiving the Ringing. It is configured to use 1000 SIP channels and has a caps limit of 100. With this dialplan however a caps value of about 66 can be reached. All tests were done “signalling only” without any RTP being transmitted.

This test generates about 1 to 2 MBit/s of IP traffic. Here are the results:

Asterisk 1.4.37-rc1:

Asterisk starts dropping calls and fails to respond on numerous INVITEs after processing about 3.5M calls. SIP registrations time out.

Memory consumption before the test:  virt 392m  res 12m 4396 S
Memory consumption after the test: virt 1125m res 320m 1472 S

Asterisk 1.6.2.14-rc1

After processing more than 5M calls Asterisk is still running fine, the memory usage is not increasing beyond 1094m res 131m 5412 S. This is a good sign for not leaking memory.

Memory consumption before the test: virt 455m  res 13m 4940 S
Memory consumption after the test: virt 637m  res 94m 5412 S

Asterisk 1.8.0

Right after the start it is using 204m of memory! That is almost 20x as much as 1.4 or 1.6 used!

After around 300k calls Asterisk segfaulted and left a 1.2 GB core file, because it could not allocate memory:

#2  0×0000000000523131 in __ast_str_helper (buf=0x7faca3d93948, max_len=8192, append=<value optimized out>,     fmt=0×552938 “Memory Allocation Failure in function %s at line %d of %s\n”, ap=0x7faca3d93900) at strings.c:72

Memory consumption before the test:  virt 717m res 204m 5700 S
Memory consumption after  the test:  none (killed by signall 11)

Executive summary (memory consumption):

Asterisk 1.4 –> BAD

Asterisk 1.6 –> GOOD

Asterisk 1.8 –> WORST


DroneProxy for Parrot AR.DRone first parachute test

I have started to work on DroneProxy some time ago to work around bugs in the firmware of the drone. Basically it is a transparent proxy for the UDP AT command packets arriving on port 5556. The packets are parsed to keep track of the sequence number. If no packets are received for 1500 ms the proxy will start sending “landing” commands with increasing sequence numbers (until somebody plugs the battery…).


Let’s get serial!

During my telnet visits to the Parrot AR.Drone i wondered what all the serial ports (/dev/ttyPA0..2) are for. And now I know which one is used by what and where i can find them on the board.

The pinout for a USB cable can be found at the official Parrot website….here.

/dev/ttyPA0 is used by the bootloader and the kernel and can be found on the “USB” port (Pin 4 is RX and Pin 6 is TX) and greets us with:

Restarting system.
Parrotboot for target MYKONOS, built on Apr 21 2010
NAND: layer initialization
NAND: found 8 bits nand 0xf1
UBI: layer initialization (version 1)
UBI: found volume with id 2147479551
UBI: found volume with id 0
UBI: found volume with id 2
UBI: failed to open volume with ID 1 (Bad file handle)
Attempt booting on UBI volume with ID 0…
Booting Linux…

This serial interface should allow us to attach a GPS module (with a TTL level serial interface) directly, without the need of a new kernel! GPS here we come! :-)

/dev/ttyPA1 is used to interface with the motor controllers. There must be some de-multiplexer between the serial port and the 4 motor controllers. I actually managed to randomly start a motor by typing garbage into this.

/dev/ttyPA2 connects to the navboard and continously spits out navdata from all sensors.


The Parrot AR.Drone GPL saga continues….

After Parrot finally released the GPL sources for their kernel changes it was time to dig into the firmware some more. Last week i was taking a closer look at the closed source control binary which has the innovative name “program.elf”.

It turns out that the binary dynamically links to libiw (from the wireless_tools) which is a GPL licensed library. You can easily check this yourself by telneting into the drone:

strings program.elf | grep iw
libiw.so.29
iw_sockets_open
iw_get_basic_config
iw_set_basic_config
iw_in_key_full

Antoine Ferran (from Parrot) confirmed this fact on the next morning:

The libiw is dynamically linked with the program but it is a mistake.
Libiw is not needed anymore: it is a remnant of a previous test version.
Any calls to libiw has been removed from the current build that will be released soon.

You can find the complete discussion here.

I am pretty confident that they will not get away with that and will have to release the source code. Actually that could be a really good way for Parrot to get help from the community to fix all of the critical bugs in the current firmware (“fly-away” syndrom, random crashes, ….) and make a much better product! :-)