#10 mi_datagram: request for symetric udp socket implementation

trunk
closed
modules (91)
7
2015-01-20
2008-10-14
Ovidiu Sas
No

The mi_datagram module works fine with unix sockets, but it doesn't work
with udp socket:

The UDP commands are received and handled by the module, but no UDP reply
is issued.

Here's how to send a udp command to the server:
echo -ne :which:\\n\\n | nc -w 1 -u <host> <port>

The debug logs are showing the command being processed but there's no reply
sent back.

Here's the debug output for a received ":which:\n\n" UDP packet:

Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_server: received :which:
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_server: mi_buf is :which: and we have received 9 bytes
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:identify_command: the command starts here: which:
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:identify_command: the command is which
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:identify_command: dtgram->len is 9
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:identify_command: dtgram->len is 1
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_server: we have a valid command
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_server: after identifing the command, the received datagram is
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_server: the command has no params
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_server: done parsing the mi tree
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_server: command process (which)succeded
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <get_statistics>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <reset_statistics>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <uptime>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <version>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <pwd>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <arg>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <which>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <ps>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <kill>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <debug>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <list_blacklists>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <t_uac_dlg>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <t_uac_cancel>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <t_hash>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <t_reply>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <dlg_list>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <dlg_list_ctx>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <dlg_end_dlg>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <profile_get_size>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <profile_list_dlgs>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <lcr_reload>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <lcr_dump>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <cr_reload_routes>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <cr_dump_routes>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <cr_replace_host>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <cr_deactivate_host>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <cr_activate_host>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <cr_add_host>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <cr_delete_host>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <rl_stats>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <rl_set_pipe>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <rl_get_pipes>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <rl_set_queue>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <rl_get_queues>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <rl_set_pid>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <rl_get_pid>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <rl_push_load>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <rl_set_dbg>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <trusted_reload>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <trusted_dump>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <address_reload>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <address_dump>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <subnet_dump>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <allow_uri>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <set_gflag>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <reset_gflag>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <is_gflag>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <get_gflags>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <ul_rm>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <ul_rm_contact>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <ul_dump>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <ul_flush>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <ul_add>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <ul_show_contact>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <dp_reload>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_write_node: writing the name <> and value <dp_translate>
Oct 14 13:27:10 ims o[7343]: DBG:mi_datagram:mi_datagram_server: the response: 200 OK get_statistics reset_statistics uptime version pwd arg which ps kill debug list_blacklists t_uac_dlg t_uac_cancel t_hash t_reply dlg_list dlg_list_ctx dlg_end_dlg profile_get_size profile_list_dlgs lcr_reload lcr_dump cr_reload_routes cr_dump_routes cr_replace_host cr_deactivate_host cr_activate_host cr_add_host cr_delete_host rl_stats rl_set_pipe rl_get_pipes rl_set_queue rl_get_queues rl_set_pid rl_get_pid rl_push_load rl_set_dbg trusted_reload trusted_dump address_reload address_dump subnet_dump allow_uri set_gflag reset_gflag is_gflag get_gflags ul_rm ul_rm_contact ul_dump ul_flush ul_add ul_show_contact dp_reload dp_translate has been sent in 646 octets

The output of the ngrep command:
# ngrep -qt -d any port 8888
interface: any
filter: (ip or ip6) and ( port 8888 )

U 2008/10/14 13:27:10.655282 10.11.10.148:33342 -> 10.11.10.63:8888
:which:..

Regards,
Ovidiu Sas

Discussion

  • Bogdan-Andrei Iancu

    • priority: 5 --> 7
    • assigned_to: nobody --> bogdan_iancu
    • status: open --> open-invalid
     
  • Bogdan-Andrei Iancu

    Hi Ovidiu,

    Are you sure your client work ok? Because I just tries with opensipctl (unixsock interface) and it works ok:

    $:~/work/opensips/sip_server/trunk/scripts$ ./opensipsctl unixsock which
    get_statistics
    reset_statistics
    uptime
    version
    pwd
    arg
    which
    ps
    kill
    debug
    list_blacklists
    ul_rm
    ul_rm_contact
    ul_dump
    ul_flush
    ul_add
    ul_show_contact
    nh_enable_ping
    nh_enable_rtpp
    nh_show_rtpp
    t_uac_dlg
    t_uac_cancel
    t_hash
    t_reply
    trusted_reload
    trusted_dump
    address_reload
    address_dump
    subnet_dump
    allow_uri
    dlg_list
    dlg_list_ctx
    dlg_end_dlg
    profile_get_size
    profile_list_dlgs

    Regards,
    Bogdan

     
  • Ovidiu Sas

    Ovidiu Sas - 2008-10-15

    Hello Bogdan,

    The unixsock variant works ok. Only the udp socket variant doesn't work. As I mentionned in the initial post, in the udp socket variant I see the command being received and processed, but no reply is sent out.

    It is very easy to test this using netcat:
    echo -ne :which:\\n\\n | nc -w 1 -u <host> <port>

    This was confirmed also by other users in the mailing list.

    Regards,
    Ovidiu

     
  • Bogdan-Andrei Iancu

    • status: open-invalid --> open-accepted
     
  • Bogdan-Andrei Iancu

    Tested with UDP also and still works:

    U 127.0.0.1:33450 -> 127.0.0.1:4343
    :ps:..
    #
    U 127.0.0.1:33449 -> 127.0.0.1:33450
    200 OK.Process:: ID=0 PID=1369 Type=attendant.Process:: ID=1 PID=1370 Typ
    e=SIP receiver udp:90.84.252.183:5060 .Process:: ID=2 PID=1371 Type=SIP re
    ceiver udp:90.84.252.183:5060 .Process:: ID=3 PID=1372 Type=timer.Process:
    : ID=4 PID=1373 Type=MI Datagram.Process:: ID=5 PID=1374 Type=MI XMLRPC.P
    rocess:: ID=6 PID=1375 Type=MI FIFO.Process:: ID=7 PID=1376 Type=TCP rece
    iver.Process:: ID=8 PID=1377 Type=TCP receiver.Process:: ID=9 PID=1378 Ty
    pe=TCP main.

    (used ngrep -d any . host 127.0.0.1)
    Pushing commands with your nc line.

    Regards,
    Bogdan

     
  • Bogdan-Andrei Iancu

    • status: open-accepted --> open-invalid
     
  • Ovidiu Sas

    Ovidiu Sas - 2008-10-15

    Hello Bogdan,

    Re-tested this and it is working ... but there is a small catch/issue here:
    when the reply is sent back, the src port of the udp mi reply doesn't match the destination port of the udp mi request.

    in your example:
    :ps:
    [33450] -> [4343]

    200 OK
    [33449] -> [33450]

    It would be nice to have a symmetric udp exchange (just like for SIP: receiving on port 5060 and sending from port 5060).
    Some apps do not like receiving replies from a different port.

    Regards,
    Ovidiu

     
  • Bogdan-Andrei Iancu

    Hi Ovidiu,

    I agree - it will be better - please open a feature request and somebody will take care of this.

    Thanks and regards,
    Bogdan

     
  • Bogdan-Andrei Iancu

    • status: open-invalid --> closed-invalid
     
  • Bogdan-Andrei Iancu

    • labels: 1134770 --> modules
    • milestone: 869102 -->
     
  • Ovidiu Sas

    Ovidiu Sas - 2008-10-16
    • summary: mi_datagram: broken udp socket --> mi_datagram: request for symetric udp socket implementation
    • status: closed-invalid --> open
     
  • Ovidiu Sas

    Ovidiu Sas - 2008-10-16

    This is now a feature request for symmetric udp exchange.

     
  • Bogdan-Andrei Iancu

    Hi Ovidiu,

    the symmetric replying is now on SVN. I did some basic tests, but if you could run some more test for both UDP and unixsock, will be really helpful .

    Thanks and regards,
    Bogdan

     
  • Bogdan-Andrei Iancu

    • milestone: --> trunk
    • status: open --> closed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks