Environment:
We have tested on three systems with both Ubuntu and OpenSUSE. Additionally, we have tested with both VMs and as a core system install.
Software Installed: Installed the latest using the instructions from the user manual.
Issue:
With testing against all three of the SIMTrace modules we purchased we have found the trace appears to lock-up or freeze randomly through processing of the APDUs. Since the phone still functions properly I am assuming that the communication between the SIM and the phone are still intact, it is just an issue with the output to screen/file output. Has anyone else experienced this issue?
We will try and flash the firmware, but since we saw this issue with all of the hardware we purchased we assumed there might be some other issue.
Thank you. Jonathan
Hi Jonathan,
sorry to hear you are having trouble.
On Wed, Mar 14, 2012 at 05:10:35PM -0500, Jonathan Thomas wrote:
With testing against all three of the SIMTrace modules we purchased we have found the trace appears to lock-up or freeze randomly through processing of the APDUs.
Can you please indicate what exactly seems to trigger those freezes? Is there any particular phone model or sim card (or combination thereof)?
What can you see on the simtrace UART at the time of the freeze?
Does the USB device re-enumerate (USB reset) when you observe the freeze?
Does the simtrace program keep running or does it stop?
Regards, Harald
Harald,
Thank you for your response. I will try and summarize what we are seeing based on your questions below.
The word 'freeze' is probably not accurate as the the simtrace application is still running/executing without receiving a termination signal, etc. What we are experiencing is that the output, both with Wireshark and stdout, stops displaying any APDU traffic.
For instance, when I boot up the phone for this first time, the simtrace application will appear to work correctly, but at some point during the reset it will stop displaying APDU traffic. For instance on this run it stops after a response from the SIM:
APDU: (183): 03 00 00 fa b0 00 00 00 2f 06 06 90 00 a0 a4 00 00 02 a4 6f 3a 9f 13 a0 c0 00 00 13 c0 00 00 0d 48 6f 3a 04 00 11 00 22 01 06 01 22 00 6f 06 03 90 00 a0 a4 00 00 02 a4 7f 20 9f 23 a0 c0 00 00 23 c0 00 00 00 00 7f 20 02 00 00 00 00 00 16 33 02 37 04 00 83 8a 83 8a 00 03 00 00 fa b0 00 00 00 00 2f 06 06 90 00 a0 a4 00 00 02 a4 6f 7e 9f 13 a0 c0 00 00 13 c0 00 00 00 0b 6f 7e 04 00 11 00 44 01 06 00 00 00 6f 06 06 90 00 a0 a4 00 00 02 a4 6f 07 9f 13 a0 c0 00 00 13 c0 00 00 00 09 6f 07 04 00 14 00 44 01 06 00 00 00 6f 06 03 90 00 a0 a4 00 00 02 a4 APDU: (7): 6f 07 9f 13 a0 c0 00 APDU: (7): 00 13 c0 00 00 00 09 APDU: (7): 6f 07 04 00 14 00 44 APDU: (7): 01 06 00 00 00 6f 06 APDU: (7): 03 90 00 a0 a4 00 00 APDU: (7): 02 a4 6f 07 9f 13 a0 APDU: (199): c0 00 00 13 c0 00 00 09 6f 07 04 00 14 00 44 01 06 00 00 00 6f 06 03 90 00 a0 b0 00 00 09 b0 08 09 10 10 10 32 54 76 98 90 00 a0 b0 00 00 09 b0 08 09 10 10 10 32 54 76 98 90 00 a0 a4 00 00 02 a4 6f 78 9f 13 a0 c0 00 00 13 c0 00 00 00 02 6f 78 04 00 14 00 44 01 06 00 00 00 6f 06 05 90 00 a0 b0 00 00 02 b0 00 01 90 00 a0 a4 00 00 02 a4 6f 31 9f 13 a0 c0 00 00 13 c0 00 00 00 01 6f 31 04 00 14 00 44 01 06 00 00 00 6f 06 05 90 00 a0 b0 00 00 01 b0 00 90 00 a0 a4 00 00 02 a4 6f 30 9f 13 a0 c0 00 00 13 c0 00 00 96 96 6f 30 04 00 11 00 44 01 06 00 00 00 6f 06 04 90 00 a0 b0 00 00 96 b0 ff ff ff ff
After this point it will no longer display (Wireshark or stdout) any APDU traffic. The board itself shows no indication that there are any issues and the process 'simtrace' is still running. If I restart the phone the only APDU I see is the ATR APDU.
If I now stop the simtrace application and restart the application I will get the same result on boot up of the phone. If I restart the application after the phone has been completely booted then I will see the status messages between the phone and the SIM for some period of time before that traffic also stops displaying to the screen.
After a while I will see this error from the simtrace application: "Error submitting BULK IN urb: No error".
An alternative phone will stop displaying APDUs, but at a different location from the first (this doesn't seem to be consistent):
APDU: (7): 32 05 83 02 6f 42 a5 APDU: (7): 03 80 01 71 8a 01 05 APDU: (7): 8b 03 6f 06 07 80 02 APDU: (7): 00 fa 88 00 90 00 00 APDU: (7): b2 01 04 32 b2 ff ff
Please let me know if I can clarify/focus these issues.
Thanks, Jonathan
On Sun, Mar 18, 2012 at 6:30 AM, Harald Welte laforge@gnumonks.org wrote:
Hi Jonathan,
sorry to hear you are having trouble.
On Wed, Mar 14, 2012 at 05:10:35PM -0500, Jonathan Thomas wrote:
With testing against all three of the SIMTrace modules we purchased we have found the trace appears to lock-up or freeze randomly through processing of the APDUs.
Can you please indicate what exactly seems to trigger those freezes? Is there any particular phone model or sim card (or combination thereof)?
What can you see on the simtrace UART at the time of the freeze?
Does the USB device re-enumerate (USB reset) when you observe the freeze?
Does the simtrace program keep running or does it stop?
Regards, Harald --
- Harald Welte laforge@gnumonks.org http://laforge.gnumonks.org/
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hello,
Your APDU output is garbage because it seems you have broken your host side software or reset the board after you powered up your phone.
I experienced similar issues but it usually worked after fixing a small apdu parsing bug in simtrace tool after following this:
1. phone off 2. reset simtrace board 3. start simtrace application 4. power up phone
Martin On Tue, Mar 20, 2012 at 16:49, Jonathan Thomas lexington1776@gmail.com wrote:
Harald,
Thank you for your response. I will try and summarize what we are seeing based on your questions below.
The word 'freeze' is probably not accurate as the the simtrace application is still running/executing without receiving a termination signal, etc. What we are experiencing is that the output, both with Wireshark and stdout, stops displaying any APDU traffic.
For instance, when I boot up the phone for this first time, the simtrace application will appear to work correctly, but at some point during the reset it will stop displaying APDU traffic. For instance on this run it stops after a response from the SIM:
APDU: (183): 03 00 00 fa b0 00 00 00 2f 06 06 90 00 a0 a4 00 00 02 a4 6f 3a 9f 13 a0 c0 00 00 13 c0 00 00 0d 48 6f 3a 04 00 11 00 22 01 06 01 22 00 6f 06 03 90 00 a0 a4 00 00 02 a4 7f 20 9f 23 a0 c0 00 00 23 c0 00 00 00 00 7f 20 02 00 00 00 00 00 16 33 02 37 04 00 83 8a 83 8a 00 03 00 00 fa b0 00 00 00 00 2f 06 06 90 00 a0 a4 00 00 02 a4 6f 7e 9f 13 a0 c0 00 00 13 c0 00 00 00 0b 6f 7e 04 00 11 00 44 01 06 00 00 00 6f 06 06 90 00 a0 a4 00 00 02 a4 6f 07 9f 13 a0 c0 00 00 13 c0 00 00 00 09 6f 07 04 00 14 00 44 01 06 00 00 00 6f 06 03 90 00 a0 a4 00 00 02 a4 APDU: (7): 6f 07 9f 13 a0 c0 00 APDU: (7): 00 13 c0 00 00 00 09 APDU: (7): 6f 07 04 00 14 00 44 APDU: (7): 01 06 00 00 00 6f 06 APDU: (7): 03 90 00 a0 a4 00 00 APDU: (7): 02 a4 6f 07 9f 13 a0 APDU: (199): c0 00 00 13 c0 00 00 09 6f 07 04 00 14 00 44 01 06 00 00 00 6f 06 03 90 00 a0 b0 00 00 09 b0 08 09 10 10 10 32 54 76 98 90 00 a0 b0 00 00 09 b0 08 09 10 10 10 32 54 76 98 90 00 a0 a4 00 00 02 a4 6f 78 9f 13 a0 c0 00 00 13 c0 00 00 00 02 6f 78 04 00 14 00 44 01 06 00 00 00 6f 06 05 90 00 a0 b0 00 00 02 b0 00 01 90 00 a0 a4 00 00 02 a4 6f 31 9f 13 a0 c0 00 00 13 c0 00 00 00 01 6f 31 04 00 14 00 44 01 06 00 00 00 6f 06 05 90 00 a0 b0 00 00 01 b0 00 90 00 a0 a4 00 00 02 a4 6f 30 9f 13 a0 c0 00 00 13 c0 00 00 96 96 6f 30 04 00 11 00 44 01 06 00 00 00 6f 06 04 90 00 a0 b0 00 00 96 b0 ff ff ff ff
After this point it will no longer display (Wireshark or stdout) any APDU traffic. The board itself shows no indication that there are any issues and the process 'simtrace' is still running. If I restart the phone the only APDU I see is the ATR APDU.
If I now stop the simtrace application and restart the application I will get the same result on boot up of the phone. If I restart the application after the phone has been completely booted then I will see the status messages between the phone and the SIM for some period of time before that traffic also stops displaying to the screen.
After a while I will see this error from the simtrace application: "Error submitting BULK IN urb: No error".
An alternative phone will stop displaying APDUs, but at a different location from the first (this doesn't seem to be consistent):
APDU: (7): 32 05 83 02 6f 42 a5 APDU: (7): 03 80 01 71 8a 01 05 APDU: (7): 8b 03 6f 06 07 80 02 APDU: (7): 00 fa 88 00 90 00 00 APDU: (7): b2 01 04 32 b2 ff ff
Please let me know if I can clarify/focus these issues.
Thanks, Jonathan
On Sun, Mar 18, 2012 at 6:30 AM, Harald Welte laforge@gnumonks.org wrote:
Hi Jonathan,
sorry to hear you are having trouble.
On Wed, Mar 14, 2012 at 05:10:35PM -0500, Jonathan Thomas wrote:
With testing against all three of the SIMTrace modules we purchased we have found the trace appears to lock-up or freeze randomly through processing of the APDUs.
Can you please indicate what exactly seems to trigger those freezes? Is there any particular phone model or sim card (or combination thereof)?
What can you see on the simtrace UART at the time of the freeze?
Does the USB device re-enumerate (USB reset) when you observe the freeze?
Does the simtrace program keep running or does it stop?
Regards, Harald --
- Harald Welte laforge@gnumonks.org http://laforge.gnumonks.org/
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Martin,
Thank you for your response. It doesn't appear that following those steps fixes what does appear to be a APDU parsing issue. Take a look at this set of APDUs and notice that the last APDU should have been:
a0 b2 04 04 26 b2 ff ff
but the a0 was appended to the previous line.
APDU: (9): a0 a4 00 00 02 7f 20 9f 23 APDU: (42): a0 c0 00 00 23 00 00 00 00 7f 20 02 00 00 00 00 00 16 b3 02 37 04 00 83 8a 83 8a 00 03 00 00 fa b0 00 00 00 00 2f 06 06 90 00 APDU: (9): a0 a4 00 00 02 6f c7 9f 13 APDU: (26): a0 c0 00 00 13 00 00 00 98 6f c7 04 00 11 00 44 01 06 01 26 00 6f 06 04 90 00 APDU: (45): a0 b2 01 04 26 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 90 00 APDU: (45): a0 b2 02 04 26 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 90 00 APDU: (45): a0 b2 03 04 26 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 90 00 a0 APDU: (7): b2 04 04 26 b2 ff ff
When you say 'reset' I assume you mean that you physically press the 'Reset' button on the board. Any other helpful hints that might fix/bypass this parsing issue?
Thank you, Jonathan
On Wed, Mar 21, 2012 at 2:44 PM, Martin Paljak martin@martinpaljak.net wrote:
Hello,
Your APDU output is garbage because it seems you have broken your host side software or reset the board after you powered up your phone.
I experienced similar issues but it usually worked after fixing a small apdu parsing bug in simtrace tool after following this:
- phone off
- reset simtrace board
- start simtrace application
- power up phone
Martin On Tue, Mar 20, 2012 at 16:49, Jonathan Thomas lexington1776@gmail.com wrote:
Harald,
Thank you for your response. I will try and summarize what we are seeing based on your questions below.
The word 'freeze' is probably not accurate as the the simtrace application is still running/executing without receiving a termination signal, etc. What we are experiencing is that the output, both with Wireshark and stdout, stops displaying any APDU traffic.
For instance, when I boot up the phone for this first time, the simtrace application will appear to work correctly, but at some point during the reset it will stop displaying APDU traffic. For instance on this run it stops after a response from the SIM:
APDU: (183): 03 00 00 fa b0 00 00 00 2f 06 06 90 00 a0 a4 00 00 02 a4 6f 3a 9f 13 a0 c0 00 00 13 c0 00 00 0d 48 6f 3a 04 00 11 00 22 01 06 01 22 00 6f 06 03 90 00 a0 a4 00 00 02 a4 7f 20 9f 23 a0 c0 00 00 23 c0 00 00 00 00 7f 20 02 00 00 00 00 00 16 33 02 37 04 00 83 8a 83 8a 00 03 00 00 fa b0 00 00 00 00 2f 06 06 90 00 a0 a4 00 00 02 a4 6f 7e 9f 13 a0 c0 00 00 13 c0 00 00 00 0b 6f 7e 04 00 11 00 44 01 06 00 00 00 6f 06 06 90 00 a0 a4 00 00 02 a4 6f 07 9f 13 a0 c0 00 00 13 c0 00 00 00 09 6f 07 04 00 14 00 44 01 06 00 00 00 6f 06 03 90 00 a0 a4 00 00 02 a4 APDU: (7): 6f 07 9f 13 a0 c0 00 APDU: (7): 00 13 c0 00 00 00 09 APDU: (7): 6f 07 04 00 14 00 44 APDU: (7): 01 06 00 00 00 6f 06 APDU: (7): 03 90 00 a0 a4 00 00 APDU: (7): 02 a4 6f 07 9f 13 a0 APDU: (199): c0 00 00 13 c0 00 00 09 6f 07 04 00 14 00 44 01 06 00 00 00 6f 06 03 90 00 a0 b0 00 00 09 b0 08 09 10 10 10 32 54 76 98 90 00 a0 b0 00 00 09 b0 08 09 10 10 10 32 54 76 98 90 00 a0 a4 00 00 02 a4 6f 78 9f 13 a0 c0 00 00 13 c0 00 00 00 02 6f 78 04 00 14 00 44 01 06 00 00 00 6f 06 05 90 00 a0 b0 00 00 02 b0 00 01 90 00 a0 a4 00 00 02 a4 6f 31 9f 13 a0 c0 00 00 13 c0 00 00 00 01 6f 31 04 00 14 00 44 01 06 00 00 00 6f 06 05 90 00 a0 b0 00 00 01 b0 00 90 00 a0 a4 00 00 02 a4 6f 30 9f 13 a0 c0 00 00 13 c0 00 00 96 96 6f 30 04 00 11 00 44 01 06 00 00 00 6f 06 04 90 00 a0 b0 00 00 96 b0 ff ff ff ff
After this point it will no longer display (Wireshark or stdout) any APDU traffic. The board itself shows no indication that there are any issues and the process 'simtrace' is still running. If I restart the phone the only APDU I see is the ATR APDU.
If I now stop the simtrace application and restart the application I will get the same result on boot up of the phone. If I restart the application after the phone has been completely booted then I will see the status messages between the phone and the SIM for some period of time before that traffic also stops displaying to the screen.
After a while I will see this error from the simtrace application: "Error submitting BULK IN urb: No error".
An alternative phone will stop displaying APDUs, but at a different location from the first (this doesn't seem to be consistent):
APDU: (7): 32 05 83 02 6f 42 a5 APDU: (7): 03 80 01 71 8a 01 05 APDU: (7): 8b 03 6f 06 07 80 02 APDU: (7): 00 fa 88 00 90 00 00 APDU: (7): b2 01 04 32 b2 ff ff
Please let me know if I can clarify/focus these issues.
Thanks, Jonathan
On Sun, Mar 18, 2012 at 6:30 AM, Harald Welte laforge@gnumonks.org wrote:
Hi Jonathan,
sorry to hear you are having trouble.
On Wed, Mar 14, 2012 at 05:10:35PM -0500, Jonathan Thomas wrote:
With testing against all three of the SIMTrace modules we purchased we have found the trace appears to lock-up or freeze randomly through processing of the APDUs.
Can you please indicate what exactly seems to trigger those freezes? Is there any particular phone model or sim card (or combination thereof)?
What can you see on the simtrace UART at the time of the freeze?
Does the USB device re-enumerate (USB reset) when you observe the freeze?
Does the simtrace program keep running or does it stop?
Regards, Harald --
- Harald Welte laforge@gnumonks.org http://laforge.gnumonks.org/
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On Wed, Mar 21, 2012 at 21:52, Jonathan Thomas lexington1776@gmail.com wrote:
Martin,
Thank you for your response. It doesn't appear that following those steps fixes what does appear to be a APDU parsing issue. Take a look at this set of APDUs and notice that the last APDU should have been:
a0 b2 04 04 26 b2 ff ff
but the a0 was appended to the previous line.
APDU: (45): a0 b2 03 04 26 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 90 00 a0 APDU: (7): b2 04 04 26 b2 ff ff
Lc is 0x26 which is 38 (dec) yet there are 37 ff-s.
Either your phone/card are OK with faulty APDU-s or the simtrace board "lost" a byte (if that is possible, I don't know)
Best,
Martin
When you say 'reset' I assume you mean that you physically press the 'Reset' button on the board.
Yes.
Any other helpful hints that might fix/bypass this parsing issue?
Thank you, Jonathan
On Wed, Mar 21, 2012 at 2:44 PM, Martin Paljak martin@martinpaljak.net wrote:
Hello,
Your APDU output is garbage because it seems you have broken your host side software or reset the board after you powered up your phone.
I experienced similar issues but it usually worked after fixing a small apdu parsing bug in simtrace tool after following this:
- phone off
- reset simtrace board
- start simtrace application
- power up phone
Martin On Tue, Mar 20, 2012 at 16:49, Jonathan Thomas lexington1776@gmail.com wrote:
Harald,
Thank you for your response. I will try and summarize what we are seeing based on your questions below.
The word 'freeze' is probably not accurate as the the simtrace application is still running/executing without receiving a termination signal, etc. What we are experiencing is that the output, both with Wireshark and stdout, stops displaying any APDU traffic.
For instance, when I boot up the phone for this first time, the simtrace application will appear to work correctly, but at some point during the reset it will stop displaying APDU traffic. For instance on this run it stops after a response from the SIM:
APDU: (183): 03 00 00 fa b0 00 00 00 2f 06 06 90 00 a0 a4 00 00 02 a4 6f 3a 9f 13 a0 c0 00 00 13 c0 00 00 0d 48 6f 3a 04 00 11 00 22 01 06 01 22 00 6f 06 03 90 00 a0 a4 00 00 02 a4 7f 20 9f 23 a0 c0 00 00 23 c0 00 00 00 00 7f 20 02 00 00 00 00 00 16 33 02 37 04 00 83 8a 83 8a 00 03 00 00 fa b0 00 00 00 00 2f 06 06 90 00 a0 a4 00 00 02 a4 6f 7e 9f 13 a0 c0 00 00 13 c0 00 00 00 0b 6f 7e 04 00 11 00 44 01 06 00 00 00 6f 06 06 90 00 a0 a4 00 00 02 a4 6f 07 9f 13 a0 c0 00 00 13 c0 00 00 00 09 6f 07 04 00 14 00 44 01 06 00 00 00 6f 06 03 90 00 a0 a4 00 00 02 a4 APDU: (7): 6f 07 9f 13 a0 c0 00 APDU: (7): 00 13 c0 00 00 00 09 APDU: (7): 6f 07 04 00 14 00 44 APDU: (7): 01 06 00 00 00 6f 06 APDU: (7): 03 90 00 a0 a4 00 00 APDU: (7): 02 a4 6f 07 9f 13 a0 APDU: (199): c0 00 00 13 c0 00 00 09 6f 07 04 00 14 00 44 01 06 00 00 00 6f 06 03 90 00 a0 b0 00 00 09 b0 08 09 10 10 10 32 54 76 98 90 00 a0 b0 00 00 09 b0 08 09 10 10 10 32 54 76 98 90 00 a0 a4 00 00 02 a4 6f 78 9f 13 a0 c0 00 00 13 c0 00 00 00 02 6f 78 04 00 14 00 44 01 06 00 00 00 6f 06 05 90 00 a0 b0 00 00 02 b0 00 01 90 00 a0 a4 00 00 02 a4 6f 31 9f 13 a0 c0 00 00 13 c0 00 00 00 01 6f 31 04 00 14 00 44 01 06 00 00 00 6f 06 05 90 00 a0 b0 00 00 01 b0 00 90 00 a0 a4 00 00 02 a4 6f 30 9f 13 a0 c0 00 00 13 c0 00 00 96 96 6f 30 04 00 11 00 44 01 06 00 00 00 6f 06 04 90 00 a0 b0 00 00 96 b0 ff ff ff ff
After this point it will no longer display (Wireshark or stdout) any APDU traffic. The board itself shows no indication that there are any issues and the process 'simtrace' is still running. If I restart the phone the only APDU I see is the ATR APDU.
If I now stop the simtrace application and restart the application I will get the same result on boot up of the phone. If I restart the application after the phone has been completely booted then I will see the status messages between the phone and the SIM for some period of time before that traffic also stops displaying to the screen.
After a while I will see this error from the simtrace application: "Error submitting BULK IN urb: No error".
An alternative phone will stop displaying APDUs, but at a different location from the first (this doesn't seem to be consistent):
APDU: (7): 32 05 83 02 6f 42 a5 APDU: (7): 03 80 01 71 8a 01 05 APDU: (7): 8b 03 6f 06 07 80 02 APDU: (7): 00 fa 88 00 90 00 00 APDU: (7): b2 01 04 32 b2 ff ff
Please let me know if I can clarify/focus these issues.
Thanks, Jonathan
On Sun, Mar 18, 2012 at 6:30 AM, Harald Welte laforge@gnumonks.org wrote:
Hi Jonathan,
sorry to hear you are having trouble.
On Wed, Mar 14, 2012 at 05:10:35PM -0500, Jonathan Thomas wrote:
With testing against all three of the SIMTrace modules we purchased we have found the trace appears to lock-up or freeze randomly through processing of the APDUs.
Can you please indicate what exactly seems to trigger those freezes? Is there any particular phone model or sim card (or combination thereof)?
What can you see on the simtrace UART at the time of the freeze?
Does the USB device re-enumerate (USB reset) when you observe the freeze?
Does the simtrace program keep running or does it stop?
Regards, Harald --
- Harald Welte laforge@gnumonks.org http://laforge.gnumonks.org/
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Just to clarify: Lost bytes have recently been identified and are now a known firmware problem.
It seems however that nobody has yet found the time to properly fix it. The problem seems to be extended periods of disabled interrupts in the USB code.
Several solutions have been proposed.
I always want to look at it, but then this is only one of way too many issues on my apparently ever-growing todo list. But then, it shouldn't even require me to get it solved anyway ;)
-
Harald Welte -
Jonathan Thomas -
Martin Paljak -
Sylvain Munaut