Hello all.
I've been doing some experimentation with both CVS HEAD and 0.9.6 of SER and version 1.1.0 of OpenSER.
It appears that there is a TCP bug in SER which has been fixed in OpenSER. I've seen various posts in the past on the serdev and the serusers lists regarding this issue but with no definitive solution. Are there any plans to merge some of the great work of the OpenSER developers back into SER, such as this fix for TCP?
Below is the logfile I receive when I try to place a call from a UDP to a TCP device using CVS HEAD of SER. The same routing logic in ser.cfg works perfectly in openser.cfg.
Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: ERROR: tcp_blocking_connect: poll error: flags 18 Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: ERROR: tcp_blocking_connect: SO_ERROR (113) No route to host Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: ERROR: tcpconn_connect: tcp_blocking_connect failed Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: ERROR: tcp_send: connect failed Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: msg_send: ERROR: tcp_send failed Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: ERROR: t_forward_nonack: sending request failed Aug 17 19:03:33 sg1test /usr/sbin/ser[32534]: ERROR: sl_reply_error used: Unfortunately error on sending to next hop occurred (477/SL)
Does anyone have any ideas on how to get this fixed in CVS HEAD of SER? I've tried some backporting of the changes to the tcp_* files from OpenSER to SER but have not had any luck as of yet as I'm not fully sure of how the code is supposed to be handling each case. This is to say that I'm just looking at code differences without really understanding how the code is supposed to work.
I'm happy to do anything I can to help get this resolved in SER's CVS HEAD.
Thanks! -Curt
On Aug 17, 2006 at 19:37, Curt Moore tgrman21@gmail.com wrote:
Hello all.
I've been doing some experimentation with both CVS HEAD and 0.9.6 of SER and version 1.1.0 of OpenSER.
It appears that there is a TCP bug in SER which has been fixed in OpenSER. I've seen various posts in the past on the serdev and the serusers lists regarding this issue but with no definitive solution. Are there any plans to merge some of the great work of the OpenSER developers back into SER, such as this fix for TCP?
The great work in openser tcp is just applying selective patches from ser. Looking through the cvs log there are only 2 small changes that do not come from ser: bind before connect (with debatable usefulness, you can make a case for it or against it and I am on the "against" side) and the possibility to set the timers individually for each tcp connection (they claim it helps for nat traversal and usrloc (?)). Disclaimer: I do not want to imply that openser developer do not do great work :-) It just happens that tcp is the wrong example, since 99.9999% from the code is from ser.
Below is the logfile I receive when I try to place a call from a UDP to a TCP device using CVS HEAD of SER. The same routing logic in ser.cfg works perfectly in openser.cfg.
Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: ERROR: tcp_blocking_connect: poll error: flags 18 Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: ERROR: tcp_blocking_connect: SO_ERROR (113) No route to host Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: ERROR: tcpconn_connect: tcp_blocking_connect failed Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: ERROR: tcp_send: connect failed Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: msg_send: ERROR: tcp_send failed Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: ERROR: t_forward_nonack: sending request failed Aug 17 19:03:33 sg1test /usr/sbin/ser[32534]: ERROR: sl_reply_error used: Unfortunately error on sending to next hop occurred (477/SL)
This looks like a tcp connect error and not like a ser bug. Are you sure the ip routing is properly set on your host? Are you sure this is not the other way arround (openser binds on an interface before connecting and that's how you could get this error, ser on the other hand doesn't do this, so it should work in all the cases)?
Could you send me ser.cfg and a detailed description on what exactly are you doing when you get this error (so that I can reproduce it myself)? The whole ser log, a packet dump (both tcp and udp) and the outputs of /sbin/ifconfig and /sbin/route will also help.
Does anyone have any ideas on how to get this fixed in CVS HEAD of SER? I've tried some backporting of the changes to the tcp_* files from OpenSER to SER but have not had any luck as of yet as I'm not fully sure of how the code is supposed to be handling each case. This is to say that I'm just looking at code differences without really understanding how the code is supposed to work.
I'm happy to do anything I can to help get this resolved in SER's CVS HEAD.
Thanks, Andrei
Andrei Pelinescu-Onciul wrote: ...
ser. Looking through the cvs log there are only 2 small changes that do not come from ser: bind before connect (with debatable usefulness, you can make a case for it or against it and I am on the "against" side) and the
Hi Andrei!
What is the case against it? IIRC this was necessary to use a certain local IP address for outgoing TCP connections. (Which is a MUST in certain firewall scenarios).
regards Klaus
On 8/19/06, Andrei Pelinescu-Onciul andrei@iptel.org wrote:
On Aug 17, 2006 at 19:37, Curt Moore tgrman21@gmail.com wrote:
Hello all.
I've been doing some experimentation with both CVS HEAD and 0.9.6 of SER and version 1.1.0 of OpenSER.
It appears that there is a TCP bug in SER which has been fixed in OpenSER. I've seen various posts in the past on the serdev and the serusers lists regarding this issue but with no definitive solution. Are there any plans to merge some of the great work of the OpenSER developers back into SER, such as this fix for TCP?
The great work in openser tcp is just applying selective patches from ser. Looking through the cvs log there are only 2 small changes that do not come from ser: bind before connect (with debatable usefulness, you can make a case for it or against it and I am on the "against" side) and the possibility to set the timers individually for each tcp connection (they claim it helps for nat traversal and usrloc (?)). Disclaimer: I do not want to imply that openser developer do not do great work :-) It just happens that tcp is the wrong example, since 99.9999% from the code is from ser.
I did not want that to sound like I meant that the SER developers are not also doing a great job. :-)
Below is the logfile I receive when I try to place a call from a UDP to a TCP device using CVS HEAD of SER. The same routing logic in ser.cfg works perfectly in openser.cfg.
Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: ERROR: tcp_blocking_connect: poll error: flags 18 Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: ERROR: tcp_blocking_connect: SO_ERROR (113) No route to host Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: ERROR: tcpconn_connect: tcp_blocking_connect failed Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: ERROR: tcp_send: connect failed Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: msg_send: ERROR: tcp_send failed Aug 17 19:03:33 testbox /usr/sbin/ser[32534]: ERROR: t_forward_nonack: sending request failed Aug 17 19:03:33 sg1test /usr/sbin/ser[32534]: ERROR: sl_reply_error used: Unfortunately error on sending to next hop occurred (477/SL)
This looks like a tcp connect error and not like a ser bug. Are you sure the ip routing is properly set on your host? Are you sure this is not the other way arround (openser binds on an interface before connecting and that's how you could get this error, ser on the other hand doesn't do this, so it should work in all the cases)?
This could explain what's going on. The server does have 2 interfaces but I'm only binding to 1 of the IP addresses, which happens to be a virtual IP address on the interface, if that matters. On that IP I'm using both TCP and UDP on port 5060.
Could you send me ser.cfg and a detailed description on what exactly are you doing when you get this error (so that I can reproduce it myself)? The whole ser log, a packet dump (both tcp and udp) and the outputs of /sbin/ifconfig and /sbin/route will also help.
My setup is a SER server acting as a UDP/TCP SIP proxy, which relays SIP messages, via dispatcher, to a farm of Asterisk servers using SIP UDP. If a TCP UA sends a message to SER, it will correctly forward it using UDP to one of the Asterisk servers. The problem arises whenever Asterisk sends a SIP UDP message back to SER for forwarding to the TCP UA. The problem is that upon trying to relay the TCP message, SER will produce the TCP errors described above. It sounds like the binding issue you described above.
I'll send the debug info off-list.
Thanks for your help.
-Curt