I also have another interesting problem with the aforementioned configuration (http://pastebin.com/f28051a5).
When I write the dialog profile size into an AVP, it works fine.
When I write it into a script var, i.e. replace $avp(S:dlg_sz) with $var(dlg_sz), it crashes:
Relaying INVITE from 210.23.22.23 to sip:2122222322@210.23.22.23:5060 [D] Added new dialog for 7709600101 [ONREPLY-ROUTE 1] Provisional reply 100 received. [ONREPLY-ROUTE 1] 200 OK received for 7709600101 [ONREPLY-ROUTE 1] INVITE/200 is part of dialog for 7709600101 Segmentation fault (core dumped)
GDB reveals:
Program received signal SIGSEGV, Segmentation fault. 0xb7e7f2f8 in strncpy () from /lib/i686/nosegneg/libc.so.6 (gdb) where #0 0xb7e7f2f8 in strncpy () from /lib/i686/nosegneg/libc.so.6 #1 0x080a4a07 in set_var_value (var=0x8188d98, value=0xbfae5f28, flags=<value o at script_var.c:122 #2 0xb7d6c4fe in w_get_profile_size (msg=0x81902b8, profile=0xb5ede180 "\034??\ value=0x818b6b8 "@?\030\b", result=0x818b6f8 "N") at dialog.c:668 #3 0x08054f15 in do_action (a=0x818b850, msg=0x81902b8) at action.c:850 #4 0x08053ed2 in run_action_list (a=0x818b5c8, msg=0x81902b8) at action.c:138 #5 0x08056365 in do_action (a=0x818bab8, msg=0x81902b8) at action.c:722 #6 0x08053ed2 in run_action_list (a=0x818b178, msg=0x81902b8) at action.c:138 #7 0x080572c2 in run_top_route (a=0x818b178, msg=0x81902b8) at action.c:118 #8 0xb7de3a64 in reply_received (p_msg=0x81902b8) at t_reply.c:1361 #9 0x08064793 in forward_reply (msg=0x81902b8) at forward.c:507 #10 0x08090d5b in receive_msg ( buf=0x81600e0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 215.22.22.22;branch=z9hG4 08.52.173.18\r\nVia: SIP/2.0/UDP 198.225.86.10:5060;branch=z9hG4bKragjo0207gm0dc p:208.52."..., len=814, rcv_info=0xbfae65d4) at receive.c:203 #11 0x080cccfb in udp_rcv_loop () at udp_server.c:449 #12 0x0806b78d in main (argc=1, argv=0xbfae6764) at main.c:693
It would seem to me that there is some sort of buffer overflow issue that results in the garbage seen above.
Not sure that it makes a difference, but the glibc being linked against is a Xen-safe one that disables TLS functionality. This is all running inside a Xen DomU.
It would seem that the malloc for the script var occasionally fails, which may or may not be central to the issue:
[SWITCH] Relaying BYE from 210.23.22.23 to sip:2122222322@210.23.22.23 (DTAG=706 [SWITCH] [D] No dialog affinity for this BYE Oct 16 05:03:32 [8710] ERROR:core:set_var_value: out of pkg mem! Oct 16 05:03:32 [8710] ERROR:dialog:w_get_profile_size: cannot set svar [SWITCH] [D] Profile size for 7709600101 now: 0 [ONREPLY-ROUTE 2] Received 200 for BYE Relaying INVITE from 210.23.22.23 to sip:2122222322@210.23.22.23:5060 [D] Added new dialog for 7709600101 [ONREPLY-ROUTE 1] Provisional reply 100 received. [ONREPLY-ROUTE 1] 200 OK received for 7709600101 [ONREPLY-ROUTE 1] INVITE/200 is part of dialog for 7709600101 [ONREPLY-ROUTE 1] Dialog profile size is: > [SWITCH] Relaying ACK from 210.23.22.23 to sip:2122222322@210.23.22.23 (DTAG=706 [SWITCH] [D] No dialog affinity for this ACK Segmentation fault (core dumped)
Alex Balashov wrote:
I also have another interesting problem with the aforementioned configuration (http://pastebin.com/f28051a5).
When I write the dialog profile size into an AVP, it works fine.
When I write it into a script var, i.e. replace $avp(S:dlg_sz) with $var(dlg_sz), it crashes:
Relaying INVITE from 210.23.22.23 to sip:2122222322@210.23.22.23:5060 [D] Added new dialog for 7709600101 [ONREPLY-ROUTE 1] Provisional reply 100 received. [ONREPLY-ROUTE 1] 200 OK received for 7709600101 [ONREPLY-ROUTE 1] INVITE/200 is part of dialog for 7709600101 Segmentation fault (core dumped)
GDB reveals:
Program received signal SIGSEGV, Segmentation fault. 0xb7e7f2f8 in strncpy () from /lib/i686/nosegneg/libc.so.6 (gdb) where #0 0xb7e7f2f8 in strncpy () from /lib/i686/nosegneg/libc.so.6 #1 0x080a4a07 in set_var_value (var=0x8188d98, value=0xbfae5f28, flags=<value o at script_var.c:122 #2 0xb7d6c4fe in w_get_profile_size (msg=0x81902b8, profile=0xb5ede180 "\034??\ value=0x818b6b8 "@?\030\b", result=0x818b6f8 "N") at dialog.c:668 #3 0x08054f15 in do_action (a=0x818b850, msg=0x81902b8) at action.c:850 #4 0x08053ed2 in run_action_list (a=0x818b5c8, msg=0x81902b8) at action.c:138 #5 0x08056365 in do_action (a=0x818bab8, msg=0x81902b8) at action.c:722 #6 0x08053ed2 in run_action_list (a=0x818b178, msg=0x81902b8) at action.c:138 #7 0x080572c2 in run_top_route (a=0x818b178, msg=0x81902b8) at action.c:118 #8 0xb7de3a64 in reply_received (p_msg=0x81902b8) at t_reply.c:1361 #9 0x08064793 in forward_reply (msg=0x81902b8) at forward.c:507 #10 0x08090d5b in receive_msg ( buf=0x81600e0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 215.22.22.22;branch=z9hG4 08.52.173.18\r\nVia: SIP/2.0/UDP 198.225.86.10:5060;branch=z9hG4bKragjo0207gm0dc p:208.52."..., len=814, rcv_info=0xbfae65d4) at receive.c:203 #11 0x080cccfb in udp_rcv_loop () at udp_server.c:449 #12 0x0806b78d in main (argc=1, argv=0xbfae6764) at main.c:693
It would seem to me that there is some sort of buffer overflow issue that results in the garbage seen above.
Not sure that it makes a difference, but the glibc being linked against is a Xen-safe one that disables TLS functionality. This is all running inside a Xen DomU.
Hello Alex,
I found a bug in the dialog module, the profile size is integer and the variable was set as string value. Can you get the trunk and test? I will backport afterwards, thanks,
Daniel
On 10/16/08 08:04, Alex Balashov wrote:
It would seem that the malloc for the script var occasionally fails, which may or may not be central to the issue:
[SWITCH] Relaying BYE from 210.23.22.23 to sip:2122222322@210.23.22.23 (DTAG=706 [SWITCH] [D] No dialog affinity for this BYE Oct 16 05:03:32 [8710] ERROR:core:set_var_value: out of pkg mem! Oct 16 05:03:32 [8710] ERROR:dialog:w_get_profile_size: cannot set svar [SWITCH] [D] Profile size for 7709600101 now: 0 [ONREPLY-ROUTE 2] Received 200 for BYE Relaying INVITE from 210.23.22.23 to sip:2122222322@210.23.22.23:5060 [D] Added new dialog for 7709600101 [ONREPLY-ROUTE 1] Provisional reply 100 received. [ONREPLY-ROUTE 1] 200 OK received for 7709600101 [ONREPLY-ROUTE 1] INVITE/200 is part of dialog for 7709600101 [ONREPLY-ROUTE 1] Dialog profile size is: > [SWITCH] Relaying ACK from 210.23.22.23 to sip:2122222322@210.23.22.23 (DTAG=706 [SWITCH] [D] No dialog affinity for this ACK Segmentation fault (core dumped)
Alex Balashov wrote:
I also have another interesting problem with the aforementioned configuration (http://pastebin.com/f28051a5).
When I write the dialog profile size into an AVP, it works fine.
When I write it into a script var, i.e. replace $avp(S:dlg_sz) with $var(dlg_sz), it crashes:
Relaying INVITE from 210.23.22.23 to sip:2122222322@210.23.22.23:5060 [D] Added new dialog for 7709600101 [ONREPLY-ROUTE 1] Provisional reply 100 received. [ONREPLY-ROUTE 1] 200 OK received for 7709600101 [ONREPLY-ROUTE 1] INVITE/200 is part of dialog for 7709600101 Segmentation fault (core dumped)
GDB reveals:
Program received signal SIGSEGV, Segmentation fault. 0xb7e7f2f8 in strncpy () from /lib/i686/nosegneg/libc.so.6 (gdb) where #0 0xb7e7f2f8 in strncpy () from /lib/i686/nosegneg/libc.so.6 #1 0x080a4a07 in set_var_value (var=0x8188d98, value=0xbfae5f28, flags=<value o at script_var.c:122 #2 0xb7d6c4fe in w_get_profile_size (msg=0x81902b8, profile=0xb5ede180 "\034??\ value=0x818b6b8 "@?\030\b", result=0x818b6f8 "N") at dialog.c:668 #3 0x08054f15 in do_action (a=0x818b850, msg=0x81902b8) at action.c:850 #4 0x08053ed2 in run_action_list (a=0x818b5c8, msg=0x81902b8) at action.c:138 #5 0x08056365 in do_action (a=0x818bab8, msg=0x81902b8) at action.c:722 #6 0x08053ed2 in run_action_list (a=0x818b178, msg=0x81902b8) at action.c:138 #7 0x080572c2 in run_top_route (a=0x818b178, msg=0x81902b8) at action.c:118 #8 0xb7de3a64 in reply_received (p_msg=0x81902b8) at t_reply.c:1361 #9 0x08064793 in forward_reply (msg=0x81902b8) at forward.c:507 #10 0x08090d5b in receive_msg ( buf=0x81600e0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 215.22.22.22;branch=z9hG4 08.52.173.18\r\nVia: SIP/2.0/UDP 198.225.86.10:5060;branch=z9hG4bKragjo0207gm0dc p:208.52."..., len=814, rcv_info=0xbfae65d4) at receive.c:203 #11 0x080cccfb in udp_rcv_loop () at udp_server.c:449 #12 0x0806b78d in main (argc=1, argv=0xbfae6764) at main.c:693
It would seem to me that there is some sort of buffer overflow issue that results in the garbage seen above.
Not sure that it makes a difference, but the glibc being linked against is a Xen-safe one that disables TLS functionality. This is all running inside a Xen DomU.
I feel retarded asking this as I'm sure it's abundantly made clear on the web site / dokuwiki, but what's the SVN URI to check out trunk?
Daniel-Constantin Mierla wrote:
Hello Alex,
I found a bug in the dialog module, the profile size is integer and the variable was set as string value. Can you get the trunk and test? I will backport afterwards, thanks,
Daniel
On 10/16/08 08:04, Alex Balashov wrote:
It would seem that the malloc for the script var occasionally fails, which may or may not be central to the issue:
[SWITCH] Relaying BYE from 210.23.22.23 to sip:2122222322@210.23.22.23 (DTAG=706 [SWITCH] [D] No dialog affinity for this BYE Oct 16 05:03:32 [8710] ERROR:core:set_var_value: out of pkg mem! Oct 16 05:03:32 [8710] ERROR:dialog:w_get_profile_size: cannot set svar [SWITCH] [D] Profile size for 7709600101 now: 0 [ONREPLY-ROUTE 2] Received 200 for BYE Relaying INVITE from 210.23.22.23 to sip:2122222322@210.23.22.23:5060 [D] Added new dialog for 7709600101 [ONREPLY-ROUTE 1] Provisional reply 100 received. [ONREPLY-ROUTE 1] 200 OK received for 7709600101 [ONREPLY-ROUTE 1] INVITE/200 is part of dialog for 7709600101 [ONREPLY-ROUTE 1] Dialog profile size is: > [SWITCH] Relaying ACK from 210.23.22.23 to sip:2122222322@210.23.22.23 (DTAG=706 [SWITCH] [D] No dialog affinity for this ACK Segmentation fault (core dumped)
Alex Balashov wrote:
I also have another interesting problem with the aforementioned configuration (http://pastebin.com/f28051a5).
When I write the dialog profile size into an AVP, it works fine.
When I write it into a script var, i.e. replace $avp(S:dlg_sz) with $var(dlg_sz), it crashes:
Relaying INVITE from 210.23.22.23 to sip:2122222322@210.23.22.23:5060 [D] Added new dialog for 7709600101 [ONREPLY-ROUTE 1] Provisional reply 100 received. [ONREPLY-ROUTE 1] 200 OK received for 7709600101 [ONREPLY-ROUTE 1] INVITE/200 is part of dialog for 7709600101 Segmentation fault (core dumped)
GDB reveals:
Program received signal SIGSEGV, Segmentation fault. 0xb7e7f2f8 in strncpy () from /lib/i686/nosegneg/libc.so.6 (gdb) where #0 0xb7e7f2f8 in strncpy () from /lib/i686/nosegneg/libc.so.6 #1 0x080a4a07 in set_var_value (var=0x8188d98, value=0xbfae5f28, flags=<value o at script_var.c:122 #2 0xb7d6c4fe in w_get_profile_size (msg=0x81902b8, profile=0xb5ede180 "\034??\ value=0x818b6b8 "@?\030\b", result=0x818b6f8 "N") at dialog.c:668 #3 0x08054f15 in do_action (a=0x818b850, msg=0x81902b8) at action.c:850 #4 0x08053ed2 in run_action_list (a=0x818b5c8, msg=0x81902b8) at action.c:138 #5 0x08056365 in do_action (a=0x818bab8, msg=0x81902b8) at action.c:722 #6 0x08053ed2 in run_action_list (a=0x818b178, msg=0x81902b8) at action.c:138 #7 0x080572c2 in run_top_route (a=0x818b178, msg=0x81902b8) at action.c:118 #8 0xb7de3a64 in reply_received (p_msg=0x81902b8) at t_reply.c:1361 #9 0x08064793 in forward_reply (msg=0x81902b8) at forward.c:507 #10 0x08090d5b in receive_msg ( buf=0x81600e0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 215.22.22.22;branch=z9hG4 08.52.173.18\r\nVia: SIP/2.0/UDP 198.225.86.10:5060;branch=z9hG4bKragjo0207gm0dc p:208.52."..., len=814, rcv_info=0xbfae65d4) at receive.c:203 #11 0x080cccfb in udp_rcv_loop () at udp_server.c:449 #12 0x0806b78d in main (argc=1, argv=0xbfae6764) at main.c:693
It would seem to me that there is some sort of buffer overflow issue that results in the garbage seen above.
Not sure that it makes a difference, but the glibc being linked against is a Xen-safe one that disables TLS functionality. This is all running inside a Xen DomU.
Hi Alex,
I feel retarded asking this as I'm sure it's abundantly made clear on the web site / dokuwiki, but what's the SVN URI to check out trunk?
Go to this address (http://www.kamailio.org/mos/view/Download/) and search for: "SVN Download"
Saludos JesusR.
Daniel-Constantin Mierla wrote:
Hello Alex,
I found a bug in the dialog module, the profile size is integer and the variable was set as string value. Can you get the trunk and test? I will backport afterwards, thanks,
Daniel
On 10/16/08 08:04, Alex Balashov wrote:
It would seem that the malloc for the script var occasionally fails, which may or may not be central to the issue:
[SWITCH] Relaying BYE from 210.23.22.23 to sip:2122222322@210.23.22.23 (DTAG=706 [SWITCH] [D] No dialog affinity for this BYE Oct 16 05:03:32 [8710] ERROR:core:set_var_value: out of pkg mem! Oct 16 05:03:32 [8710] ERROR:dialog:w_get_profile_size: cannot set svar [SWITCH] [D] Profile size for 7709600101 now: 0 [ONREPLY-ROUTE 2] Received 200 for BYE Relaying INVITE from 210.23.22.23 to sip: 2122222322@210.23.22.23:5060 [D] Added new dialog for 7709600101 [ONREPLY-ROUTE 1] Provisional reply 100 received. [ONREPLY-ROUTE 1] 200 OK received for 7709600101 [ONREPLY-ROUTE 1] INVITE/200 is part of dialog for 7709600101 [ONREPLY-ROUTE 1] Dialog profile size is: > [SWITCH] Relaying ACK from 210.23.22.23 to sip:2122222322@210.23.22.23 (DTAG=706 [SWITCH] [D] No dialog affinity for this ACK Segmentation fault (core dumped)
Alex Balashov wrote:
I also have another interesting problem with the aforementioned configuration (http://pastebin.com/f28051a5).
When I write the dialog profile size into an AVP, it works fine.
When I write it into a script var, i.e. replace $avp(S:dlg_sz) with $var(dlg_sz), it crashes:
Relaying INVITE from 210.23.22.23 to sip:2122222322@210.23.22.23:5060 [D] Added new dialog for 7709600101 [ONREPLY-ROUTE 1] Provisional reply 100 received. [ONREPLY-ROUTE 1] 200 OK received for 7709600101 [ONREPLY-ROUTE 1] INVITE/200 is part of dialog for 7709600101 Segmentation fault (core dumped)
GDB reveals:
Program received signal SIGSEGV, Segmentation fault. 0xb7e7f2f8 in strncpy () from /lib/i686/nosegneg/libc.so.6 (gdb) where #0 0xb7e7f2f8 in strncpy () from /lib/i686/nosegneg/libc.so.6 #1 0x080a4a07 in set_var_value (var=0x8188d98, value=0xbfae5f28, flags=<value o at script_var.c:122 #2 0xb7d6c4fe in w_get_profile_size (msg=0x81902b8, profile=0xb5ede180 "\034??\ value=0x818b6b8 "@?\030\b", result=0x818b6f8 "N") at dialog.c: 668 #3 0x08054f15 in do_action (a=0x818b850, msg=0x81902b8) at action.c:850 #4 0x08053ed2 in run_action_list (a=0x818b5c8, msg=0x81902b8) at action.c:138 #5 0x08056365 in do_action (a=0x818bab8, msg=0x81902b8) at action.c:722 #6 0x08053ed2 in run_action_list (a=0x818b178, msg=0x81902b8) at action.c:138 #7 0x080572c2 in run_top_route (a=0x818b178, msg=0x81902b8) at action.c:118 #8 0xb7de3a64 in reply_received (p_msg=0x81902b8) at t_reply.c: 1361 #9 0x08064793 in forward_reply (msg=0x81902b8) at forward.c:507 #10 0x08090d5b in receive_msg ( buf=0x81600e0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 215.22.22.22;branch=z9hG4 08.52.173.18\r\nVia: SIP/2.0/UDP 198.225.86.10:5060;branch=z9hG4bKragjo0207gm0dc p:208.52."..., len=814, rcv_info=0xbfae65d4) at receive.c:203 #11 0x080cccfb in udp_rcv_loop () at udp_server.c:449 #12 0x0806b78d in main (argc=1, argv=0xbfae6764) at main.c:693
It would seem to me that there is some sort of buffer overflow issue that results in the garbage seen above.
Not sure that it makes a difference, but the glibc being linked against is a Xen-safe one that disables TLS functionality. This is all running inside a Xen DomU.
-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
On Thursday 16 October 2008, Alex Balashov wrote:
I feel retarded asking this as I'm sure it's abundantly made clear on the web site / dokuwiki, but what's the SVN URI to check out trunk?
Hi Alex,
you can checkout from sf.org (can be slow sometimes): https://openser.svn.sourceforge.net/svnroot/openser/trunk
or the read/only mirror, which is fast: http://devel.kamailio.org/svn/trunk
Cheers,
Henning
Hello Alex,
and, if everyone tried to give hints, the command is:
# svn co https://openser.svn.sourceforge.net/svnroot/openser/trunk kamailio
However, what I actually want to say is that the patch is very minimal, see it here: http://openser.svn.sourceforge.net/viewvc/openser/trunk/modules/dialog/dialo...
You probably can fix it in 1.4 very easy and test it there.
Cheers, Daniel
On 10/16/08 20:33, Henning Westerholt wrote:
On Thursday 16 October 2008, Alex Balashov wrote:
I feel retarded asking this as I'm sure it's abundantly made clear on the web site / dokuwiki, but what's the SVN URI to check out trunk?
Hi Alex,
you can checkout from sf.org (can be slow sometimes): https://openser.svn.sourceforge.net/svnroot/openser/trunk
or the read/only mirror, which is fast: http://devel.kamailio.org/svn/trunk
Cheers,
Henning
Daniel,
This has, indeed, appeared to have fixed the issue. Thanks!
-- Alex
Daniel-Constantin Mierla wrote:
Hello Alex,
and, if everyone tried to give hints, the command is:
# svn co https://openser.svn.sourceforge.net/svnroot/openser/trunk kamailio
However, what I actually want to say is that the patch is very minimal, see it here: http://openser.svn.sourceforge.net/viewvc/openser/trunk/modules/dialog/dialo...
You probably can fix it in 1.4 very easy and test it there.
Cheers, Daniel
On 10/16/08 20:33, Henning Westerholt wrote:
On Thursday 16 October 2008, Alex Balashov wrote:
I feel retarded asking this as I'm sure it's abundantly made clear on the web site / dokuwiki, but what's the SVN URI to check out trunk?
Hi Alex,
you can checkout from sf.org (can be slow sometimes): https://openser.svn.sourceforge.net/svnroot/openser/trunk
or the read/only mirror, which is fast: http://devel.kamailio.org/svn/trunk
Cheers,
Henning
On 10/16/08 22:03, Alex Balashov wrote:
Daniel,
This has, indeed, appeared to have fixed the issue. Thanks!
ok, I backported to 1.4
Cheers, Daniel
-- Alex
Daniel-Constantin Mierla wrote:
Hello Alex,
and, if everyone tried to give hints, the command is:
# svn co https://openser.svn.sourceforge.net/svnroot/openser/trunk kamailio
However, what I actually want to say is that the patch is very minimal, see it here: http://openser.svn.sourceforge.net/viewvc/openser/trunk/modules/dialog/dialo...
You probably can fix it in 1.4 very easy and test it there.
Cheers, Daniel
On 10/16/08 20:33, Henning Westerholt wrote:
On Thursday 16 October 2008, Alex Balashov wrote:
I feel retarded asking this as I'm sure it's abundantly made clear on the web site / dokuwiki, but what's the SVN URI to check out trunk?
Hi Alex,
you can checkout from sf.org (can be slow sometimes): https://openser.svn.sourceforge.net/svnroot/openser/trunk
or the read/only mirror, which is fast: http://devel.kamailio.org/svn/trunk
Cheers,
Henning
Has this not been backported into the 1.4.1 tarball available in /pub? I just downloaded an installation and found the bug was still happening.
(Problem was reported when 1.4.0 was current.)
Alex Balashov wrote:
Daniel,
This has, indeed, appeared to have fixed the issue. Thanks!
-- Alex
Daniel-Constantin Mierla wrote:
Hello Alex,
and, if everyone tried to give hints, the command is:
# svn co https://openser.svn.sourceforge.net/svnroot/openser/trunk kamailio
However, what I actually want to say is that the patch is very minimal, see it here: http://openser.svn.sourceforge.net/viewvc/openser/trunk/modules/dialog/dialo...
You probably can fix it in 1.4 very easy and test it there.
Cheers, Daniel
On 10/16/08 20:33, Henning Westerholt wrote:
On Thursday 16 October 2008, Alex Balashov wrote:
I feel retarded asking this as I'm sure it's abundantly made clear on the web site / dokuwiki, but what's the SVN URI to check out trunk?
Hi Alex,
you can checkout from sf.org (can be slow sometimes): https://openser.svn.sourceforge.net/svnroot/openser/trunk
or the read/only mirror, which is fast: http://devel.kamailio.org/svn/trunk
Cheers,
Henning
-
Alex Balashov -
Daniel-Constantin Mierla -
Henning Westerholt -
Jesus Rodriguez