Category Archives: All

Asterisk memtesting reloaded

It was about time to re-test up to date Asterisk versions for memory leakage. As these tests take a rather long time, i will update this post when the 1.4 and 1.6 versions have gone through the test.
The test procedure is the same as in my previous test, incoming SIP calls that send a ringing, wait a little and hang up (no call is ever connected, no RTP is flowing).

Asterisk 1.8.4-rc2

Since my last test, things have improved a lot! Asterisk does not consume 200m+ right from the start and it does not leak that much any more. However it still leaks a bit. After 32M+ calls i stopped the test.

Memory consumption before the test: virt 513m  16m 5940 S

Memory consumption after the test: virt 712m res 192m 6432 S

Asterisk 1.6.2.18-rc1

After pushing 37M+ calls Asterisk stopped processing calls because it ran out of RTP ports (it was using the default RTP port range from 10000 to 20000). “netstat -l -n -p  | grep asterisk -c” shows that 10009 ports are in use by asterisk. Calls fail with:

[Mar 27 12:42:03] ERROR[25983] rtp.c: No RTP ports remaining. Can’t setup media stream for this call.
[Mar 27 12:42:03] WARNING[25983] chan_sip.c: Unable to create RTP audio session: Address already in use

Memory consumption before the test: 476m  14m 5412 S

Memory consumption after the test: 742m 197m 5868 S

Asterisk 1.4.41-rc1

After pushing 10M+ calls Asterisk is processing calls very slowly. The machine has a high load because it is constantly swapping pages to and from disk. Retransmissions start to fail:

[Mar 30 10:58:50] WARNING[10667]: chan_sip.c:2070 retrans_pkt: Maximum retries exceeded on transmission a3621613-d54e-122e-43b7-001aa0314ced for seqno 10401673 (Critical Response) — See doc/sip-retransmit.txt.

Memory consumption before the test: 392m  12m 4396 S

Memory consumption after the test: 1472m 358m 1324 S

Asterisk 1.2.40

During the test Asterisk was complaining about “avoiding initial deadlocks” and “avoiding deadlocks” a lot, but it did not deadlock or go into the famous 100% cpu loop. It just works. :-)

After processing 65M+ calls,  I decided to stop the test as i could not see an increasing memory consumption. The 1.2 branch of Asterisk keeps its place as my favourite branch (when it comes to stability).

Memory consumption before the test:  276m  11m 3464 S

Memory consumption after the test:  460m  79m 3768 S S


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…).


Parrot AR.Drone internals (iBreakIt…)

Now that i am done messing with the software and actually completing a few test flights, I figured it was about time to tear the drone apart. The only thing required is a tiny torx screwdriver (T6X20) which fortunately i had laying around on my desk because we use the same screws to tighten the GSM modules on to our GSM cards.

Once you remove the plastic shielding you can see the mainboard stacked on top of the navboard (which carries the ultrasonic sender/receiver). The front camera is connected with a ribbon cable coming from the right. Above that camera connector is a 7 pin USB header.

Undo 4 little screws and you can remove the navboard (which plugs into the backside of the mainboard with an 8 pin connector…probably serialish). Here you see the mainboard with the camera cable removed and the battery connector ripped out of the shell (to give some space for moving the mainboard). The mainboard has 2 on-circuit wifi antennas (ANT1 and ANT2):

This is the navboard with the ultrasonic sender/receiver pair. The “ugly padding” on the left is probably to shield the right one from receiving the “echo” through vibrations across the pcb (instead of receving the reflected signal through the air). The 8 pin connector connects to the mainboard.

The other side of the navboard:

And the other side of the mainboard:

The drone is really easy to take apart and also to re-assemble. It even does work again. ;-)