Re: [OpenSIPS-Devel] eyeBeam NAT ping packets
Hello Ovidiu, Thanks for the fix. In regards to the pings from eyeBeam - how do you want to reply to some dummy packages you do not understand ? Best regards Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/30/2013 01:28 AM, Ovidiu Sas wrote: I checked the code before my initial post and I wasn't sure if the 20 was the length of the whole UDP packet or just the payload. It turns out that it is the payload and those packets from eyeBeam were indeed discarded. The trouble packets were in fact sent by a Grandstream device and those were stun packets. After I enabled the stun module, the error logs were gone. I enhanced the error logs to print the source IP and port of those un-parsable messages. It helps in troubleshooting live systems :) With respect to those eyeBeam packets, we could indeed reply to them instead of dropping them. Regards, Ovidiu Sas On Mon, Oct 21, 2013 at 6:27 AM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hi guys, The UDP stack in OpenSIPS silently discards any packages less than 20 bytes. See the MIN_UDP_PACKET in config.h . Are your pings longer than 20 ?!? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/19/2013 02:47 AM, Saúl Ibarra Corretgé wrote: On Oct 18, 2013, at 11:14 AM, Ovidiu Sas o...@voipembedded.com wrote: I forgot to mention in my previous e-mail that those ping packets are over UDP, which seems like a bug in eyeBeam. Anyway, the end result is that opensips logs are polluted. Over TCP, it seems that those packets are properly handled by opensips. It's UDP that is having issues. Oh. I guess OpenSIPS should reply with CRLF like if it was TCP. Be gentle in what you accept… :-) Regards, -- Saúl Ibarra Corretgé AG Projects ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] eyeBeam NAT ping packets
The eyeBeam dummy packet is not that dummy. It's a 4 byte packet: CRLFCRLF. This is just like the TCP ping packet. We could reply with CRLF, as Saul suggested. See SIP outbound :http://tools.ietf.org/html/rfc5626#section-3.5.1 -ovidiu On Wed, Oct 30, 2013 at 7:07 AM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hello Ovidiu, Thanks for the fix. In regards to the pings from eyeBeam - how do you want to reply to some dummy packages you do not understand ? Best regards Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/30/2013 01:28 AM, Ovidiu Sas wrote: I checked the code before my initial post and I wasn't sure if the 20 was the length of the whole UDP packet or just the payload. It turns out that it is the payload and those packets from eyeBeam were indeed discarded. The trouble packets were in fact sent by a Grandstream device and those were stun packets. After I enabled the stun module, the error logs were gone. I enhanced the error logs to print the source IP and port of those un-parsable messages. It helps in troubleshooting live systems :) With respect to those eyeBeam packets, we could indeed reply to them instead of dropping them. Regards, Ovidiu Sas On Mon, Oct 21, 2013 at 6:27 AM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hi guys, The UDP stack in OpenSIPS silently discards any packages less than 20 bytes. See the MIN_UDP_PACKET in config.h . Are your pings longer than 20 ?!? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/19/2013 02:47 AM, Saúl Ibarra Corretgé wrote: On Oct 18, 2013, at 11:14 AM, Ovidiu Sas o...@voipembedded.com wrote: I forgot to mention in my previous e-mail that those ping packets are over UDP, which seems like a bug in eyeBeam. Anyway, the end result is that opensips logs are polluted. Over TCP, it seems that those packets are properly handled by opensips. It's UDP that is having issues. Oh. I guess OpenSIPS should reply with CRLF like if it was TCP. Be gentle in what you accept… :-) Regards, -- Saúl Ibarra Corretgé AG Projects ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel -- VoIP Embedded, Inc. http://www.voipembedded.com ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] eyeBeam NAT ping packets
I see here: This approach can only be used with connection-oriented transports such as TCP or SCTP So, maybe the package is not dummy, but it is wrongly used (over UDP) :) Of course, technically can be done (to answer); the question is if it make sense and if it is sane. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/30/2013 05:56 PM, Ovidiu Sas wrote: The eyeBeam dummy packet is not that dummy. It's a 4 byte packet: CRLFCRLF. This is just like the TCP ping packet. We could reply with CRLF, as Saul suggested. See SIP outbound :http://tools.ietf.org/html/rfc5626#section-3.5.1 -ovidiu On Wed, Oct 30, 2013 at 7:07 AM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hello Ovidiu, Thanks for the fix. In regards to the pings from eyeBeam - how do you want to reply to some dummy packages you do not understand ? Best regards Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/30/2013 01:28 AM, Ovidiu Sas wrote: I checked the code before my initial post and I wasn't sure if the 20 was the length of the whole UDP packet or just the payload. It turns out that it is the payload and those packets from eyeBeam were indeed discarded. The trouble packets were in fact sent by a Grandstream device and those were stun packets. After I enabled the stun module, the error logs were gone. I enhanced the error logs to print the source IP and port of those un-parsable messages. It helps in troubleshooting live systems :) With respect to those eyeBeam packets, we could indeed reply to them instead of dropping them. Regards, Ovidiu Sas On Mon, Oct 21, 2013 at 6:27 AM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hi guys, The UDP stack in OpenSIPS silently discards any packages less than 20 bytes. See the MIN_UDP_PACKET in config.h . Are your pings longer than 20 ?!? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/19/2013 02:47 AM, Saúl Ibarra Corretgé wrote: On Oct 18, 2013, at 11:14 AM, Ovidiu Sas o...@voipembedded.com wrote: I forgot to mention in my previous e-mail that those ping packets are over UDP, which seems like a bug in eyeBeam. Anyway, the end result is that opensips logs are polluted. Over TCP, it seems that those packets are properly handled by opensips. It's UDP that is having issues. Oh. I guess OpenSIPS should reply with CRLF like if it was TCP. Be gentle in what you accept… :-) Regards, -- Saúl Ibarra Corretgé AG Projects ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] eyeBeam NAT ping packets
That was my observation too (in one of my previous replies to Saul). The thing is, if we reply to it, we can make the client's firewall happy and we no longer need to perform server keep-alives. I have mixed feelings about it :) -ovidiu On Wed, Oct 30, 2013 at 12:12 PM, Bogdan-Andrei Iancu bog...@opensips.org wrote: I see here: This approach can only be used with connection-oriented transports such as TCP or SCTP So, maybe the package is not dummy, but it is wrongly used (over UDP) :) Of course, technically can be done (to answer); the question is if it make sense and if it is sane. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/30/2013 05:56 PM, Ovidiu Sas wrote: The eyeBeam dummy packet is not that dummy. It's a 4 byte packet: CRLFCRLF. This is just like the TCP ping packet. We could reply with CRLF, as Saul suggested. See SIP outbound :http://tools.ietf.org/html/rfc5626#section-3.5.1 -ovidiu On Wed, Oct 30, 2013 at 7:07 AM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hello Ovidiu, Thanks for the fix. In regards to the pings from eyeBeam - how do you want to reply to some dummy packages you do not understand ? Best regards Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/30/2013 01:28 AM, Ovidiu Sas wrote: I checked the code before my initial post and I wasn't sure if the 20 was the length of the whole UDP packet or just the payload. It turns out that it is the payload and those packets from eyeBeam were indeed discarded. The trouble packets were in fact sent by a Grandstream device and those were stun packets. After I enabled the stun module, the error logs were gone. I enhanced the error logs to print the source IP and port of those un-parsable messages. It helps in troubleshooting live systems :) With respect to those eyeBeam packets, we could indeed reply to them instead of dropping them. Regards, Ovidiu Sas On Mon, Oct 21, 2013 at 6:27 AM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hi guys, The UDP stack in OpenSIPS silently discards any packages less than 20 bytes. See the MIN_UDP_PACKET in config.h . Are your pings longer than 20 ?!? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/19/2013 02:47 AM, Saúl Ibarra Corretgé wrote: On Oct 18, 2013, at 11:14 AM, Ovidiu Sas o...@voipembedded.com wrote: I forgot to mention in my previous e-mail that those ping packets are over UDP, which seems like a bug in eyeBeam. Anyway, the end result is that opensips logs are polluted. Over TCP, it seems that those packets are properly handled by opensips. It's UDP that is having issues. Oh. I guess OpenSIPS should reply with CRLF like if it was TCP. Be gentle in what you accept… :-) Regards, -- Saúl Ibarra Corretgé AG Projects ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel -- VoIP Embedded, Inc. http://www.voipembedded.com ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] eyeBeam NAT ping packets
I also have mixed feelings on thisQuestion : is the practice of using CRLF pinging via UDP a used one across UACs ?? or you just came across a corner/isolated case ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/30/2013 06:18 PM, Ovidiu Sas wrote: That was my observation too (in one of my previous replies to Saul). The thing is, if we reply to it, we can make the client's firewall happy and we no longer need to perform server keep-alives. I have mixed feelings about it :) -ovidiu On Wed, Oct 30, 2013 at 12:12 PM, Bogdan-Andrei Iancu bog...@opensips.org wrote: I see here: This approach can only be used with connection-oriented transports such as TCP or SCTP So, maybe the package is not dummy, but it is wrongly used (over UDP) :) Of course, technically can be done (to answer); the question is if it make sense and if it is sane. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/30/2013 05:56 PM, Ovidiu Sas wrote: The eyeBeam dummy packet is not that dummy. It's a 4 byte packet: CRLFCRLF. This is just like the TCP ping packet. We could reply with CRLF, as Saul suggested. See SIP outbound :http://tools.ietf.org/html/rfc5626#section-3.5.1 -ovidiu On Wed, Oct 30, 2013 at 7:07 AM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hello Ovidiu, Thanks for the fix. In regards to the pings from eyeBeam - how do you want to reply to some dummy packages you do not understand ? Best regards Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/30/2013 01:28 AM, Ovidiu Sas wrote: I checked the code before my initial post and I wasn't sure if the 20 was the length of the whole UDP packet or just the payload. It turns out that it is the payload and those packets from eyeBeam were indeed discarded. The trouble packets were in fact sent by a Grandstream device and those were stun packets. After I enabled the stun module, the error logs were gone. I enhanced the error logs to print the source IP and port of those un-parsable messages. It helps in troubleshooting live systems :) With respect to those eyeBeam packets, we could indeed reply to them instead of dropping them. Regards, Ovidiu Sas On Mon, Oct 21, 2013 at 6:27 AM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hi guys, The UDP stack in OpenSIPS silently discards any packages less than 20 bytes. See the MIN_UDP_PACKET in config.h . Are your pings longer than 20 ?!? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/19/2013 02:47 AM, Saúl Ibarra Corretgé wrote: On Oct 18, 2013, at 11:14 AM, Ovidiu Sas o...@voipembedded.com wrote: I forgot to mention in my previous e-mail that those ping packets are over UDP, which seems like a bug in eyeBeam. Anyway, the end result is that opensips logs are polluted. Over TCP, it seems that those packets are properly handled by opensips. It's UDP that is having issues. Oh. I guess OpenSIPS should reply with CRLF like if it was TCP. Be gentle in what you accept… :-) Regards, -- Saúl Ibarra Corretgé AG Projects ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] eyeBeam NAT ping packets
I came across this one by accident while dealing with STUN packets. The thing is that those CRLFCRLF packets are discarded silently and therefor is difficult to evaluate how often are they used. -ovidiu On Wed, Oct 30, 2013 at 1:18 PM, Bogdan-Andrei Iancu bog...@opensips.org wrote: I also have mixed feelings on thisQuestion : is the practice of using CRLF pinging via UDP a used one across UACs ?? or you just came across a corner/isolated case ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/30/2013 06:18 PM, Ovidiu Sas wrote: That was my observation too (in one of my previous replies to Saul). The thing is, if we reply to it, we can make the client's firewall happy and we no longer need to perform server keep-alives. I have mixed feelings about it :) -ovidiu On Wed, Oct 30, 2013 at 12:12 PM, Bogdan-Andrei Iancu bog...@opensips.org wrote: I see here: This approach can only be used with connection-oriented transports such as TCP or SCTP So, maybe the package is not dummy, but it is wrongly used (over UDP) :) Of course, technically can be done (to answer); the question is if it make sense and if it is sane. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/30/2013 05:56 PM, Ovidiu Sas wrote: The eyeBeam dummy packet is not that dummy. It's a 4 byte packet: CRLFCRLF. This is just like the TCP ping packet. We could reply with CRLF, as Saul suggested. See SIP outbound :http://tools.ietf.org/html/rfc5626#section-3.5.1 -ovidiu On Wed, Oct 30, 2013 at 7:07 AM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hello Ovidiu, Thanks for the fix. In regards to the pings from eyeBeam - how do you want to reply to some dummy packages you do not understand ? Best regards Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/30/2013 01:28 AM, Ovidiu Sas wrote: I checked the code before my initial post and I wasn't sure if the 20 was the length of the whole UDP packet or just the payload. It turns out that it is the payload and those packets from eyeBeam were indeed discarded. The trouble packets were in fact sent by a Grandstream device and those were stun packets. After I enabled the stun module, the error logs were gone. I enhanced the error logs to print the source IP and port of those un-parsable messages. It helps in troubleshooting live systems :) With respect to those eyeBeam packets, we could indeed reply to them instead of dropping them. Regards, Ovidiu Sas On Mon, Oct 21, 2013 at 6:27 AM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hi guys, The UDP stack in OpenSIPS silently discards any packages less than 20 bytes. See the MIN_UDP_PACKET in config.h . Are your pings longer than 20 ?!? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 10/19/2013 02:47 AM, Saúl Ibarra Corretgé wrote: On Oct 18, 2013, at 11:14 AM, Ovidiu Sas o...@voipembedded.com wrote: I forgot to mention in my previous e-mail that those ping packets are over UDP, which seems like a bug in eyeBeam. Anyway, the end result is that opensips logs are polluted. Over TCP, it seems that those packets are properly handled by opensips. It's UDP that is having issues. Oh. I guess OpenSIPS should reply with CRLF like if it was TCP. Be gentle in what you accept… :-) Regards, -- Saúl Ibarra Corretgé AG Projects ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel -- VoIP Embedded, Inc. http://www.voipembedded.com ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
