Error: A TLS packet with unexpected length was received.

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Error: A TLS packet with unexpected length was received.

bay2x1
I am encountering this error with mediaproxy.  Mediaproxy-relay and Mediaproxy-dispatcher is not on the same machine.
Every time I restart mediaproxy-relay on the other computer I got this log error on the machine where mediaproxy-dispatcher is running.  I have check both relay and dispatcher have the same version 2.3.4.

error: Connection with relay at 176.16.100.150 was lost: A TLS packet with unexpected length was received.

Everytime I restart dispatcher I get this log warning

Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: Received SIGTERM, shutting down.
Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: (Port None Closed)
Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: (Port 25061 Closed)
Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: (Port 25060 Closed)
Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: Connection with relay at 176.16.100.150 was closed
Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: Main loop terminated.
Aug  9 20:42:05 phoenix303 media-dispatcher[10816]: Log opened.
Aug  9 20:42:05 phoenix303 media-dispatcher[10816]: warning: startSyslog is being deprecated and will be removed in 1.2.0. Use the start_syslog function instead.
Aug  9 20:42:05 phoenix303 media-dispatcher[10816]: Starting MediaProxy Dispatcher 2.3.4
Aug  9 20:42:05 phoenix303 media-dispatcher[10816]: Twisted is using epollreactor
Aug  9 20:42:06 phoenix303 media-dispatcher[10816]: mediaproxy.dispatcher.RelayFactory starting on 25060
Aug  9 20:42:06 phoenix303 media-dispatcher[10816]: mediaproxy.dispatcher.OpenSIPSControlFactory starting on "'/var/run/mediaproxy/dispatcher.sock'"
Aug  9 20:42:06 phoenix303 media-dispatcher[10816]: mediaproxy.dispatcher.ManagementControlFactory starting on 25

Reply | Threaded
Open this post in threaded view
|

Re: Error: A TLS packet with unexpected length was received.

bay2x1
I haven't resolved this problem.  Further exploration revealed that both relay and dispatcher are working.  The only problem is during the handshake between dispatcher and relay.  The dispatcher is refusing the relay connection.  I have downloaded the sample tls certificates from the svn repository because I believe this might resolve the problem still the problem persists.  I am correct to say that I am using the correct certificates if my CDRTool on Network and Session section is able to connect to the mediaproxy-dispatcher.  I have observed it previously that if I dont have the proper mediaproxy.hostname.com.pem file I encounter this error == Error connecting to tls://hostname.com:25061: (111).  With my current CDRTool configuration I am able to connect to media dispatcher properly.  I am wondering why I am receiving
Error: A TLS packet with unexpected length was received.



bay2x1 wrote
I am encountering this error with mediaproxy.  Mediaproxy-relay and Mediaproxy-dispatcher is not on the same machine.
Every time I restart mediaproxy-relay on the other computer I got this log error on the machine where mediaproxy-dispatcher is running.  I have check both relay and dispatcher have the same version 2.3.4.

error: Connection with relay at 176.16.100.150 was lost: A TLS packet with unexpected length was received.

Everytime I restart dispatcher I get this log warning

Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: Received SIGTERM, shutting down.
Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: (Port None Closed)
Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: (Port 25061 Closed)
Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: (Port 25060 Closed)
Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: Connection with relay at 176.16.100.150 was closed
Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: Main loop terminated.
Aug  9 20:42:05 phoenix303 media-dispatcher[10816]: Log opened.
Aug  9 20:42:05 phoenix303 media-dispatcher[10816]: warning: startSyslog is being deprecated and will be removed in 1.2.0. Use the start_syslog function instead.
Aug  9 20:42:05 phoenix303 media-dispatcher[10816]: Starting MediaProxy Dispatcher 2.3.4
Aug  9 20:42:05 phoenix303 media-dispatcher[10816]: Twisted is using epollreactor
Aug  9 20:42:06 phoenix303 media-dispatcher[10816]: mediaproxy.dispatcher.RelayFactory starting on 25060
Aug  9 20:42:06 phoenix303 media-dispatcher[10816]: mediaproxy.dispatcher.OpenSIPSControlFactory starting on "'/var/run/mediaproxy/dispatcher.sock'"
Aug  9 20:42:06 phoenix303 media-dispatcher[10816]: mediaproxy.dispatcher.ManagementControlFactory starting on 25
Reply | Threaded
Open this post in threaded view
|

Re: Error: A TLS packet with unexpected length was received.

Dan Pascu

On 13 Aug 2009, at 02:21, bay2x1 wrote:

>
> I haven't resolved this problem.  Further exploration revealed that  
> both
> relay and dispatcher are working.  The only problem is during the  
> handshake
> between dispatcher and relay.  The dispatcher is refusing the relay
> connection.  I have downloaded the sample tls certificates from the  
> svn
> repository because I believe this might resolve the problem still the
> problem persists.

I have no idea what certificates those are. You should ask the svn  
repository owner what's up with them. We do not provide any  
certificates in any svn repository.

>  I am correct to say that I am using the correct
> certificates if my CDRTool on Network and Session section is able to  
> connect
> to the mediaproxy-dispatcher.

No. CDRTool uses a single file certificate, while the dispatcher and  
relay use separate certificate and private key files. Read tls/README

>  I have observed it previously that if I dont
> have the proper mediaproxy.hostname.com.pem file I encounter this  
> error ==
> Error connecting to tls://hostname.com:25061: (111).  With my current
> CDRTool configuration I am able to connect to media dispatcher  
> properly.  I
> am wondering why I am receiving
> Error: A TLS packet with unexpected length was received.

That error message appears when a non-TLS client tries to connect to a  
TLS server, or the other way around. One of your endpoints is TCP the  
other TLS.

>
>
>
>
> bay2x1 wrote:
>>
>> I am encountering this error with mediaproxy.  Mediaproxy-relay and
>> Mediaproxy-dispatcher is not on the same machine.
>> Every time I restart mediaproxy-relay on the other computer I got  
>> this log
>> error on the machine where mediaproxy-dispatcher is running.  I  
>> have check
>> both relay and dispatcher have the same version 2.3.4.
>>
>> error: Connection with relay at 176.16.100.150 was lost: A TLS  
>> packet with
>> unexpected length was received.
>>
>> Everytime I restart dispatcher I get this log warning
>>
>> Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: Received SIGTERM,
>> shutting down.
>> Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: (Port None  
>> Closed)
>> Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: (Port 25061  
>> Closed)
>> Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: (Port 25060  
>> Closed)
>> Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: Connection with  
>> relay
>> at 176.16.100.150 was closed
>> Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: Main loop  
>> terminated.
>> Aug  9 20:42:05 phoenix303 media-dispatcher[10816]: Log opened.
>> Aug  9 20:42:05 phoenix303 media-dispatcher[10816]: warning:  
>> startSyslog
>> is being deprecated and will be removed in 1.2.0. Use the  
>> start_syslog
>> function instead.
>> Aug  9 20:42:05 phoenix303 media-dispatcher[10816]: Starting  
>> MediaProxy
>> Dispatcher 2.3.4
>> Aug  9 20:42:05 phoenix303 media-dispatcher[10816]: Twisted is using
>> epollreactor
>> Aug  9 20:42:06 phoenix303 media-dispatcher[10816]:
>> mediaproxy.dispatcher.RelayFactory starting on 25060
>> Aug  9 20:42:06 phoenix303 media-dispatcher[10816]:
>> mediaproxy.dispatcher.OpenSIPSControlFactory starting on
>> "'/var/run/mediaproxy/dispatcher.sock'"
>> Aug  9 20:42:06 phoenix303 media-dispatcher[10816]:
>> mediaproxy.dispatcher.ManagementControlFactory starting on 25
>>
>>
>>
>
>
> -----
> http://opensips.blogspot.com http://opensips.blogspot.com
> --
> View this message in context: http://n2.nabble.com/Error%3A-A-TLS-packet-with-unexpected-length-was-received.-tp3415244p3434560.html
> Sent from the OpenSIPS - Users mailing list archive at Nabble.com.
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


--
Dan




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Error: A TLS packet with unexpected length was received.

bay2x1
How would I be able to determine if the dispatcher or the relay is using TCP or TLS.  I have already disabled in the opensips.cfg the tcp, but I still get the same error.


Dan Pascu wrote
On 13 Aug 2009, at 02:21, bay2x1 wrote:

>
> I haven't resolved this problem.  Further exploration revealed that  
> both
> relay and dispatcher are working.  The only problem is during the  
> handshake
> between dispatcher and relay.  The dispatcher is refusing the relay
> connection.  I have downloaded the sample tls certificates from the  
> svn
> repository because I believe this might resolve the problem still the
> problem persists.

I have no idea what certificates those are. You should ask the svn  
repository owner what's up with them. We do not provide any  
certificates in any svn repository.

>  I am correct to say that I am using the correct
> certificates if my CDRTool on Network and Session section is able to  
> connect
> to the mediaproxy-dispatcher.

No. CDRTool uses a single file certificate, while the dispatcher and  
relay use separate certificate and private key files. Read tls/README

>  I have observed it previously that if I dont
> have the proper mediaproxy.hostname.com.pem file I encounter this  
> error ==
> Error connecting to tls://hostname.com:25061: (111).  With my current
> CDRTool configuration I am able to connect to media dispatcher  
> properly.  I
> am wondering why I am receiving
> Error: A TLS packet with unexpected length was received.

That error message appears when a non-TLS client tries to connect to a  
TLS server, or the other way around. One of your endpoints is TCP the  
other TLS.

>
>
>
>
> bay2x1 wrote:
>>
>> I am encountering this error with mediaproxy.  Mediaproxy-relay and
>> Mediaproxy-dispatcher is not on the same machine.
>> Every time I restart mediaproxy-relay on the other computer I got  
>> this log
>> error on the machine where mediaproxy-dispatcher is running.  I  
>> have check
>> both relay and dispatcher have the same version 2.3.4.
>>
>> error: Connection with relay at 176.16.100.150 was lost: A TLS  
>> packet with
>> unexpected length was received.
>>
>> Everytime I restart dispatcher I get this log warning
>>
>> Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: Received SIGTERM,
>> shutting down.
>> Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: (Port None  
>> Closed)
>> Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: (Port 25061  
>> Closed)
>> Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: (Port 25060  
>> Closed)
>> Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: Connection with  
>> relay
>> at 176.16.100.150 was closed
>> Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: Main loop  
>> terminated.
>> Aug  9 20:42:05 phoenix303 media-dispatcher[10816]: Log opened.
>> Aug  9 20:42:05 phoenix303 media-dispatcher[10816]: warning:  
>> startSyslog
>> is being deprecated and will be removed in 1.2.0. Use the  
>> start_syslog
>> function instead.
>> Aug  9 20:42:05 phoenix303 media-dispatcher[10816]: Starting  
>> MediaProxy
>> Dispatcher 2.3.4
>> Aug  9 20:42:05 phoenix303 media-dispatcher[10816]: Twisted is using
>> epollreactor
>> Aug  9 20:42:06 phoenix303 media-dispatcher[10816]:
>> mediaproxy.dispatcher.RelayFactory starting on 25060
>> Aug  9 20:42:06 phoenix303 media-dispatcher[10816]:
>> mediaproxy.dispatcher.OpenSIPSControlFactory starting on
>> "'/var/run/mediaproxy/dispatcher.sock'"
>> Aug  9 20:42:06 phoenix303 media-dispatcher[10816]:
>> mediaproxy.dispatcher.ManagementControlFactory starting on 25
>>
>>
>>
>
>
> -----
> http://opensips.blogspot.com http://opensips.blogspot.com
> --
> View this message in context: http://n2.nabble.com/Error%3A-A-TLS-packet-with-unexpected-length-was-received.-tp3415244p3434560.html
> Sent from the OpenSIPS - Users mailing list archive at Nabble.com.
>
> _______________________________________________
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


--
Dan




_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Error: A TLS packet with unexpected length was received.

Dan Pascu

On 24 Sep 2009, at 09:33, bay2x1 wrote:

>
> How would I be able to determine if the dispatcher or the relay is  
> using TCP
> or TLS.  I have already disabled in the opensips.cfg the tcp, but I  
> still
> get the same error.
>

They always use TLS. The only place where you can configure it to use  
TCP, is the dispatcher management interface. Also opensips.cfg has  
nothing to do with the mediaproxy applications. Those are configured  
in /etc/init.d/config.ini

>
>
> Dan Pascu wrote:
>>
>>
>> On 13 Aug 2009, at 02:21, bay2x1 wrote:
>>
>>>
>>> I haven't resolved this problem.  Further exploration revealed that
>>> both
>>> relay and dispatcher are working.  The only problem is during the
>>> handshake
>>> between dispatcher and relay.  The dispatcher is refusing the relay
>>> connection.  I have downloaded the sample tls certificates from the
>>> svn
>>> repository because I believe this might resolve the problem still  
>>> the
>>> problem persists.
>>
>> I have no idea what certificates those are. You should ask the svn
>> repository owner what's up with them. We do not provide any
>> certificates in any svn repository.
>>
>>> I am correct to say that I am using the correct
>>> certificates if my CDRTool on Network and Session section is able to
>>> connect
>>> to the mediaproxy-dispatcher.
>>
>> No. CDRTool uses a single file certificate, while the dispatcher and
>> relay use separate certificate and private key files. Read tls/README
>>
>>> I have observed it previously that if I dont
>>> have the proper mediaproxy.hostname.com.pem file I encounter this
>>> error ==
>>> Error connecting to tls://hostname.com:25061: (111).  With my  
>>> current
>>> CDRTool configuration I am able to connect to media dispatcher
>>> properly.  I
>>> am wondering why I am receiving
>>> Error: A TLS packet with unexpected length was received.
>>
>> That error message appears when a non-TLS client tries to connect  
>> to a
>> TLS server, or the other way around. One of your endpoints is TCP the
>> other TLS.
>>
>>>
>>>
>>>
>>>
>>> bay2x1 wrote:
>>>>
>>>> I am encountering this error with mediaproxy.  Mediaproxy-relay and
>>>> Mediaproxy-dispatcher is not on the same machine.
>>>> Every time I restart mediaproxy-relay on the other computer I got
>>>> this log
>>>> error on the machine where mediaproxy-dispatcher is running.  I
>>>> have check
>>>> both relay and dispatcher have the same version 2.3.4.
>>>>
>>>> error: Connection with relay at 176.16.100.150 was lost: A TLS
>>>> packet with
>>>> unexpected length was received.
>>>>
>>>> Everytime I restart dispatcher I get this log warning
>>>>
>>>> Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: Received  
>>>> SIGTERM,
>>>> shutting down.
>>>> Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: (Port None
>>>> Closed)
>>>> Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: (Port 25061
>>>> Closed)
>>>> Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: (Port 25060
>>>> Closed)
>>>> Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: Connection with
>>>> relay
>>>> at 176.16.100.150 was closed
>>>> Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: Main loop
>>>> terminated.
>>>> Aug  9 20:42:05 phoenix303 media-dispatcher[10816]: Log opened.
>>>> Aug  9 20:42:05 phoenix303 media-dispatcher[10816]: warning:
>>>> startSyslog
>>>> is being deprecated and will be removed in 1.2.0. Use the
>>>> start_syslog
>>>> function instead.
>>>> Aug  9 20:42:05 phoenix303 media-dispatcher[10816]: Starting
>>>> MediaProxy
>>>> Dispatcher 2.3.4
>>>> Aug  9 20:42:05 phoenix303 media-dispatcher[10816]: Twisted is  
>>>> using
>>>> epollreactor
>>>> Aug  9 20:42:06 phoenix303 media-dispatcher[10816]:
>>>> mediaproxy.dispatcher.RelayFactory starting on 25060
>>>> Aug  9 20:42:06 phoenix303 media-dispatcher[10816]:
>>>> mediaproxy.dispatcher.OpenSIPSControlFactory starting on
>>>> "'/var/run/mediaproxy/dispatcher.sock'"
>>>> Aug  9 20:42:06 phoenix303 media-dispatcher[10816]:
>>>> mediaproxy.dispatcher.ManagementControlFactory starting on 25
>>>>
>>>>
>>>>
>>>
>>>
>>> -----
>>> http://opensips.blogspot.com http://opensips.blogspot.com
>>> --
>>> View this message in context:
>>> http://n2.nabble.com/Error%3A-A-TLS-packet-with-unexpected-length-was-received.-tp3415244p3434560.html
>>> Sent from the OpenSIPS - Users mailing list archive at Nabble.com.
>>>
>>> _______________________________________________
>>> Users mailing list
>>> [hidden email]
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>> --
>> Dan
>>
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>
> -----
> http://opensips.blogspot.com http://opensips.blogspot.com
> --
> View this message in context: http://n2.nabble.com/Error-A-TLS-packet-with-unexpected-length-was-received-tp3415244p3704412.html
> Sent from the OpenSIPS - Users mailing list archive at Nabble.com.
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


--
Dan




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Error: A TLS packet with unexpected length was received.

bay2x1
I was able to determine that the relay is using TCP.  I am encountering this error on the mediaproxy-relay machine

Sep 24 18:38:44  media-relay[9744]: error: Connection with dispatcher at xxx.xxx.xxx:25061 was lost: TCP connection timed out.
Sep 24 18:38:55 media-relay[9744]: error: Could not decode command/sequence number pair from dispatcher: error
Sep 24 18:39:05 media-relay[9744]: error: Could not decode command/sequence number pair from dispatcher: error
Sep 24 18:39:15 media-relay[9744]: error: Could not decode command/sequence number pair from dispatcher: error

and on the mediaproxy-dispatcher

Sep 24 18:31:46 media-dispatcher[19071]: error: Unknown command on management interface: ping
Sep 24 18:31:56 media-dispatcher[19071]: error: Unknown command on management interface: ping
Sep 24 18:32:06 media-dispatcher[19071]: error: Unknown command on management interface: ping

I have already set the value on the dispatcher config.ini

listen_management = 0.0.0.0

; Whether or not to use TLS on the management interface. Note that the same
; TLS credentials are used for both the relay and the management interface
; connections.
;
; Default value is yes.
;
management_use_tls = yes

; Specify extra checks to be performed on the relay TLS credentials before
; considering the connection with the relay succesful. The passport is
; specified as a list of attribute/value pairs in the form:
;   AN:value[, AN:value...]
; where the attribute name (AN) is one of the available attribute names from
; the X509 certificate subject: O, OU, CN, C, L, ST, EMAIL. The value is a
; string that has to match with the corresponding attribute value from the
; relay certificate. A wildcard (*) can be used in the value at the beginning
; or the end of the string to indicate that the corresponding attribute from
; the relay certificate must end with respectively to start with the given
; string (excluding the wildcard).
; For example using this passport:
;   passport = O:AG Projects, CN:relay*
; means that a connection with a relay will only be accepted if the relay
; certificate subject has organization set to "AG Projects" and the common
; name starts with "relay". To specify that no additional identity checks
; need to be performed, use the keyword None. If passport is None, then only
; the certificate signature is verified agains the certificate authority in
; tls/ca.pem (signature is always verified even when passport is None).
;
; Default value is None.
;
passport = None

; This option is similar to passport above, but applies to the management
; interface connections instead of relay connections. It specifies extra
; checks to be performed on the TLS credentials suplied by an entity that
; connects to the management interface. Please consult passport above for
; a detailed description of the possible values for this option.
;
; If management_use_tls is false, this option is ignored.
;
; Default value is None.
;
management_passport = None

What part did I misconfigure mediaproxy?




Dan Pascu wrote
On 24 Sep 2009, at 09:33, bay2x1 wrote:

>
> How would I be able to determine if the dispatcher or the relay is  
> using TCP
> or TLS.  I have already disabled in the opensips.cfg the tcp, but I  
> still
> get the same error.
>

They always use TLS. The only place where you can configure it to use  
TCP, is the dispatcher management interface. Also opensips.cfg has  
nothing to do with the mediaproxy applications. Those are configured  
in /etc/init.d/config.ini

>
>
> Dan Pascu wrote:
>>
>>
>> On 13 Aug 2009, at 02:21, bay2x1 wrote:
>>
>>>
>>> I haven't resolved this problem.  Further exploration revealed that
>>> both
>>> relay and dispatcher are working.  The only problem is during the
>>> handshake
>>> between dispatcher and relay.  The dispatcher is refusing the relay
>>> connection.  I have downloaded the sample tls certificates from the
>>> svn
>>> repository because I believe this might resolve the problem still  
>>> the
>>> problem persists.
>>
>> I have no idea what certificates those are. You should ask the svn
>> repository owner what's up with them. We do not provide any
>> certificates in any svn repository.
>>
>>> I am correct to say that I am using the correct
>>> certificates if my CDRTool on Network and Session section is able to
>>> connect
>>> to the mediaproxy-dispatcher.
>>
>> No. CDRTool uses a single file certificate, while the dispatcher and
>> relay use separate certificate and private key files. Read tls/README
>>
>>> I have observed it previously that if I dont
>>> have the proper mediaproxy.hostname.com.pem file I encounter this
>>> error ==
>>> Error connecting to tls://hostname.com:25061: (111).  With my  
>>> current
>>> CDRTool configuration I am able to connect to media dispatcher
>>> properly.  I
>>> am wondering why I am receiving
>>> Error: A TLS packet with unexpected length was received.
>>
>> That error message appears when a non-TLS client tries to connect  
>> to a
>> TLS server, or the other way around. One of your endpoints is TCP the
>> other TLS.
>>
>>>
>>>
>>>
>>>
>>> bay2x1 wrote:
>>>>
>>>> I am encountering this error with mediaproxy.  Mediaproxy-relay and
>>>> Mediaproxy-dispatcher is not on the same machine.
>>>> Every time I restart mediaproxy-relay on the other computer I got
>>>> this log
>>>> error on the machine where mediaproxy-dispatcher is running.  I
>>>> have check
>>>> both relay and dispatcher have the same version 2.3.4.
>>>>
>>>> error: Connection with relay at 176.16.100.150 was lost: A TLS
>>>> packet with
>>>> unexpected length was received.
>>>>
>>>> Everytime I restart dispatcher I get this log warning
>>>>
>>>> Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: Received  
>>>> SIGTERM,
>>>> shutting down.
>>>> Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: (Port None
>>>> Closed)
>>>> Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: (Port 25061
>>>> Closed)
>>>> Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: (Port 25060
>>>> Closed)
>>>> Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: Connection with
>>>> relay
>>>> at 176.16.100.150 was closed
>>>> Aug  9 20:42:04 phoenix303 media-dispatcher[10797]: Main loop
>>>> terminated.
>>>> Aug  9 20:42:05 phoenix303 media-dispatcher[10816]: Log opened.
>>>> Aug  9 20:42:05 phoenix303 media-dispatcher[10816]: warning:
>>>> startSyslog
>>>> is being deprecated and will be removed in 1.2.0. Use the
>>>> start_syslog
>>>> function instead.
>>>> Aug  9 20:42:05 phoenix303 media-dispatcher[10816]: Starting
>>>> MediaProxy
>>>> Dispatcher 2.3.4
>>>> Aug  9 20:42:05 phoenix303 media-dispatcher[10816]: Twisted is  
>>>> using
>>>> epollreactor
>>>> Aug  9 20:42:06 phoenix303 media-dispatcher[10816]:
>>>> mediaproxy.dispatcher.RelayFactory starting on 25060
>>>> Aug  9 20:42:06 phoenix303 media-dispatcher[10816]:
>>>> mediaproxy.dispatcher.OpenSIPSControlFactory starting on
>>>> "'/var/run/mediaproxy/dispatcher.sock'"
>>>> Aug  9 20:42:06 phoenix303 media-dispatcher[10816]:
>>>> mediaproxy.dispatcher.ManagementControlFactory starting on 25
>>>>
>>>>
>>>>
>>>
>>>
>>> -----
>>> http://opensips.blogspot.com http://opensips.blogspot.com
>>> --
>>> View this message in context:
>>> http://n2.nabble.com/Error%3A-A-TLS-packet-with-unexpected-length-was-received.-tp3415244p3434560.html
>>> Sent from the OpenSIPS - Users mailing list archive at Nabble.com.
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users@lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>> --
>> Dan
>>
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>
> -----
> http://opensips.blogspot.com http://opensips.blogspot.com
> --
> View this message in context: http://n2.nabble.com/Error-A-TLS-packet-with-unexpected-length-was-received-tp3415244p3704412.html
> Sent from the OpenSIPS - Users mailing list archive at Nabble.com.
>
> _______________________________________________
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


--
Dan




_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Error: A TLS packet with unexpected length was received.

Dan Pascu

On 25 Sep 2009, at 04:11, bay2x1 wrote:

>
> I was able to determine that the relay is using TCP.

The relay _never_ uses TCP.

>  I am encountering this error on the mediaproxy-relay machine
>
> Sep 24 18:38:44  media-relay[9744]: error: Connection with  
> dispatcher at
> xxx.xxx.xxx:25061 was lost: TCP connection timed out.

This only means that it could not connect on the TCP level (TLS works  
on top of TCP, so it needs an established TCP connection before it  
starts negotiating and establishing TLS on top of it).
In your case the first stage (establishing a TCP transport) has failed.

> Sep 24 18:38:55 media-relay[9744]: error: Could not decode command/
> sequence
> number pair from dispatcher: error
> Sep 24 18:39:05 media-relay[9744]: error: Could not decode command/
> sequence
> number pair from dispatcher: error
> Sep 24 18:39:15 media-relay[9744]: error: Could not decode command/
> sequence
> number pair from dispatcher: error
>

make sure the relay and dispatcher version numbers match.

> and on the mediaproxy-dispatcher
>
> Sep 24 18:31:46 media-dispatcher[19071]: error: Unknown command on
> management interface: ping
> Sep 24 18:31:56 media-dispatcher[19071]: error: Unknown command on
> management interface: ping
> Sep 24 18:32:06 media-dispatcher[19071]: error: Unknown command on
> management interface: ping

ping was not meant to be used on the management interface. Unless you  
manually send that command to the management interface for testing, I  
suspect that you somehow got the 2 ports mixed. There are 2 ports used  
by the dispatcher: 25060 used to listen for incoming relay connections  
and communicate with the relays; 25061 is used for the management  
interface, that can be used to obtain information about the dispatcher  
and relays. In your case it sounds as if the relay connected to the  
dispatcher management port (25061) instead of the standard relay port  
(25060)

>
> I have already set the value on the dispatcher config.ini
>
> listen_management = 0.0.0.0
>
> ; Whether or not to use TLS on the management interface. Note that  
> the same
> ; TLS credentials are used for both the relay and the management  
> interface
> ; connections.
> ;
> ; Default value is yes.
> ;
> management_use_tls = yes
>
> ; Specify extra checks to be performed on the relay TLS credentials  
> before
> ; considering the connection with the relay succesful. The passport is
> ; specified as a list of attribute/value pairs in the form:
> ;   AN:value[, AN:value...]
> ; where the attribute name (AN) is one of the available attribute  
> names from
> ; the X509 certificate subject: O, OU, CN, C, L, ST, EMAIL. The  
> value is a
> ; string that has to match with the corresponding attribute value  
> from the
> ; relay certificate. A wildcard (*) can be used in the value at the
> beginning
> ; or the end of the string to indicate that the corresponding  
> attribute from
> ; the relay certificate must end with respectively to start with the  
> given
> ; string (excluding the wildcard).
> ; For example using this passport:
> ;   passport = O:AG Projects, CN:relay*
> ; means that a connection with a relay will only be accepted if the  
> relay
> ; certificate subject has organization set to "AG Projects" and the  
> common
> ; name starts with "relay". To specify that no additional identity  
> checks
> ; need to be performed, use the keyword None. If passport is None,  
> then only
> ; the certificate signature is verified agains the certificate  
> authority in
> ; tls/ca.pem (signature is always verified even when passport is  
> None).
> ;
> ; Default value is None.
> ;
> passport = None
>
> ; This option is similar to passport above, but applies to the  
> management
> ; interface connections instead of relay connections. It specifies  
> extra
> ; checks to be performed on the TLS credentials suplied by an entity  
> that
> ; connects to the management interface. Please consult passport  
> above for
> ; a detailed description of the possible values for this option.
> ;
> ; If management_use_tls is false, this option is ignored.
> ;
> ; Default value is None.
> ;
> management_passport = None
>
> What part did I misconfigure mediaproxy?

Nothing in this config seems out of place. Did you specify the  
dispatchers in the relay section and by any chance you used the wrong  
port with them, like ip:25061 ?

--
Dan




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Error: A TLS packet with unexpected length was received.

bay2x1
I have corrected the wrong port assigned in (25061) in the relay section on my configuration.  I have set the value for dispatcher = 172.16.100.20 (ip of my dispatcher) -- leaving the port blank.  I have already check the version both are version 2.3.4.  I am still stuck in the same error:   A TLS packet with unexpected length was received.  

The only problem I see is that I cant establish the TCP part for the TLS connection. Again I have checked the versions of both mediaproxy relay and dispatcher to be the same 2.3.4 version.

Sep 29 08:44:15 ws20 media-dispatcher[14419]: Main loop terminated.
Sep 29 08:44:15 ws20 media-dispatcher[14481]: Log opened.
Sep 29 08:44:15 ws20 media-dispatcher[14481]: warning: startSyslog is being deprecated and will be removed in 1.2.0. Use the start_syslog function instead.
Sep 29 08:44:15 ws20 media-dispatcher[14481]: Starting MediaProxy Dispatcher 2.3.4

Sep 29 08:44:32 ws17 media-relay[4007]: Main loop terminated.
Sep 29 08:44:36 ws17 media-relay[4261]: Log opened.
Sep 29 08:44:36 ws17 media-relay[4261]: warning: startSyslog is being deprecated and will be removed in 1.2.0. Use the start_syslog function instead.
Sep 29 08:44:36 ws17 media-relay[4261]: Starting MediaProxy Relay 2.3.4
Sep 29 08:44:37 ws17 media-relay[4261]: Set resource limit for maximum open file descriptors to 11000

Is there a command to check what version of mediaproxy i am using?


Dan Pascu wrote
On 25 Sep 2009, at 04:11, bay2x1 wrote:

>
> I was able to determine that the relay is using TCP.

The relay _never_ uses TCP.

>  I am encountering this error on the mediaproxy-relay machine
>
> Sep 24 18:38:44  media-relay[9744]: error: Connection with  
> dispatcher at
> xxx.xxx.xxx:25061 was lost: TCP connection timed out.

This only means that it could not connect on the TCP level (TLS works  
on top of TCP, so it needs an established TCP connection before it  
starts negotiating and establishing TLS on top of it).
In your case the first stage (establishing a TCP transport) has failed.

> Sep 24 18:38:55 media-relay[9744]: error: Could not decode command/
> sequence
> number pair from dispatcher: error
> Sep 24 18:39:05 media-relay[9744]: error: Could not decode command/
> sequence
> number pair from dispatcher: error
> Sep 24 18:39:15 media-relay[9744]: error: Could not decode command/
> sequence
> number pair from dispatcher: error
>

make sure the relay and dispatcher version numbers match.

> and on the mediaproxy-dispatcher
>
> Sep 24 18:31:46 media-dispatcher[19071]: error: Unknown command on
> management interface: ping
> Sep 24 18:31:56 media-dispatcher[19071]: error: Unknown command on
> management interface: ping
> Sep 24 18:32:06 media-dispatcher[19071]: error: Unknown command on
> management interface: ping

ping was not meant to be used on the management interface. Unless you  
manually send that command to the management interface for testing, I  
suspect that you somehow got the 2 ports mixed. There are 2 ports used  
by the dispatcher: 25060 used to listen for incoming relay connections  
and communicate with the relays; 25061 is used for the management  
interface, that can be used to obtain information about the dispatcher  
and relays. In your case it sounds as if the relay connected to the  
dispatcher management port (25061) instead of the standard relay port  
(25060)

>
> I have already set the value on the dispatcher config.ini
>
> listen_management = 0.0.0.0
>
> ; Whether or not to use TLS on the management interface. Note that  
> the same
> ; TLS credentials are used for both the relay and the management  
> interface
> ; connections.
> ;
> ; Default value is yes.
> ;
> management_use_tls = yes
>
> ; Specify extra checks to be performed on the relay TLS credentials  
> before
> ; considering the connection with the relay succesful. The passport is
> ; specified as a list of attribute/value pairs in the form:
> ;   AN:value[, AN:value...]
> ; where the attribute name (AN) is one of the available attribute  
> names from
> ; the X509 certificate subject: O, OU, CN, C, L, ST, EMAIL. The  
> value is a
> ; string that has to match with the corresponding attribute value  
> from the
> ; relay certificate. A wildcard (*) can be used in the value at the
> beginning
> ; or the end of the string to indicate that the corresponding  
> attribute from
> ; the relay certificate must end with respectively to start with the  
> given
> ; string (excluding the wildcard).
> ; For example using this passport:
> ;   passport = O:AG Projects, CN:relay*
> ; means that a connection with a relay will only be accepted if the  
> relay
> ; certificate subject has organization set to "AG Projects" and the  
> common
> ; name starts with "relay". To specify that no additional identity  
> checks
> ; need to be performed, use the keyword None. If passport is None,  
> then only
> ; the certificate signature is verified agains the certificate  
> authority in
> ; tls/ca.pem (signature is always verified even when passport is  
> None).
> ;
> ; Default value is None.
> ;
> passport = None
>
> ; This option is similar to passport above, but applies to the  
> management
> ; interface connections instead of relay connections. It specifies  
> extra
> ; checks to be performed on the TLS credentials suplied by an entity  
> that
> ; connects to the management interface. Please consult passport  
> above for
> ; a detailed description of the possible values for this option.
> ;
> ; If management_use_tls is false, this option is ignored.
> ;
> ; Default value is None.
> ;
> management_passport = None
>
> What part did I misconfigure mediaproxy?

Nothing in this config seems out of place. Did you specify the  
dispatchers in the relay section and by any chance you used the wrong  
port with them, like ip:25061 ?

--
Dan




_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Error: A TLS packet with unexpected length was received.

Dan Pascu

On 29 Sep 2009, at 03:47, bay2x1 wrote:

>
> I have corrected the wrong port assigned in (25061) in the relay  
> section on
> my configuration.  I have set the value for dispatcher =  
> 172.16.100.20 (ip
> of my dispatcher) -- leaving the port blank.  I have already check the
> version both are version 2.3.4.  I am still stuck in the same  
> error:   A TLS
> packet with unexpected length was received.

This error is usually seen when one side speaks only TCP while the  
other speaks TLS. However since the relay and dispatcher only have  
code to speak TLS between them there must be something else you do  
wrong. A network capture may help you shed some light on what is going  
wrong. Are you sure it doesn't still try to connect to the dispatcher  
management port that is configured to use TCP?

>
>
> The only problem I see is that I cant establish the TCP part for the  
> TLS
> connection. Again I have checked the versions of both mediaproxy  
> relay and
> dispatcher to be the same 2.3.4 version.
>
> Sep 29 08:44:15 ws20 media-dispatcher[14419]: Main loop terminated.
> Sep 29 08:44:15 ws20 media-dispatcher[14481]: Log opened.
> Sep 29 08:44:15 ws20 media-dispatcher[14481]: warning: startSyslog  
> is being
> deprecated and will be removed in 1.2.0. Use the start_syslog function
> instead.
> Sep 29 08:44:15 ws20 media-dispatcher[14481]: Starting MediaProxy  
> Dispatcher
> 2.3.4
>
> Sep 29 08:44:32 ws17 media-relay[4007]: Main loop terminated.
> Sep 29 08:44:36 ws17 media-relay[4261]: Log opened.
> Sep 29 08:44:36 ws17 media-relay[4261]: warning: startSyslog is being
> deprecated and will be removed in 1.2.0. Use the start_syslog function
> instead.
> Sep 29 08:44:36 ws17 media-relay[4261]: Starting MediaProxy Relay  
> 2.3.4
> Sep 29 08:44:37 ws17 media-relay[4261]: Set resource limit for  
> maximum open
> file descriptors to 11000
>
> Is there a command to check what version of mediaproxy i am using?

You can check in syslog. As seen above both print their version on  
startup. Otherwise both can be run with --version to print their  
version.

--
Dan




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Error: A TLS packet with unexpected length was received.

bay2x1
Thank you for your time, patience and effort... I really appreciate it...

Correct me if I am wrong
mediaproxy.dispatcher.RelayFactory starting on 25060 --- this the port where mediaproxy-relay will connect and it uses TLS

mediaproxy.dispatcher.ManagementControlFactory starting on 25061 --- this the management port and it uses TCP

I have set the value in my config.ini for mediaproxy
Dispatcher = 172.16.100.20:25060

Can you please enlighten me more on how to do a network capture what tools/utilities/commands do I need to use and what to look for.  
Can wireshark do this?
I am still exploring the Linux OS by the way I am using Fedora Core 10.  


Dan Pascu wrote
On 29 Sep 2009, at 03:47, bay2x1 wrote:

>
> I have corrected the wrong port assigned in (25061) in the relay  
> section on
> my configuration.  I have set the value for dispatcher =  
> 172.16.100.20 (ip
> of my dispatcher) -- leaving the port blank.  I have already check the
> version both are version 2.3.4.  I am still stuck in the same  
> error:   A TLS
> packet with unexpected length was received.

This error is usually seen when one side speaks only TCP while the  
other speaks TLS. However since the relay and dispatcher only have  
code to speak TLS between them there must be something else you do  
wrong. A network capture may help you shed some light on what is going  
wrong. Are you sure it doesn't still try to connect to the dispatcher  
management port that is configured to use TCP?

>
>
> The only problem I see is that I cant establish the TCP part for the  
> TLS
> connection. Again I have checked the versions of both mediaproxy  
> relay and
> dispatcher to be the same 2.3.4 version.
>
> Sep 29 08:44:15 ws20 media-dispatcher[14419]: Main loop terminated.
> Sep 29 08:44:15 ws20 media-dispatcher[14481]: Log opened.
> Sep 29 08:44:15 ws20 media-dispatcher[14481]: warning: startSyslog  
> is being
> deprecated and will be removed in 1.2.0. Use the start_syslog function
> instead.
> Sep 29 08:44:15 ws20 media-dispatcher[14481]: Starting MediaProxy  
> Dispatcher
> 2.3.4
>
> Sep 29 08:44:32 ws17 media-relay[4007]: Main loop terminated.
> Sep 29 08:44:36 ws17 media-relay[4261]: Log opened.
> Sep 29 08:44:36 ws17 media-relay[4261]: warning: startSyslog is being
> deprecated and will be removed in 1.2.0. Use the start_syslog function
> instead.
> Sep 29 08:44:36 ws17 media-relay[4261]: Starting MediaProxy Relay  
> 2.3.4
> Sep 29 08:44:37 ws17 media-relay[4261]: Set resource limit for  
> maximum open
> file descriptors to 11000
>
> Is there a command to check what version of mediaproxy i am using?

You can check in syslog. As seen above both print their version on  
startup. Otherwise both can be run with --version to print their  
version.

--
Dan




_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Error: A TLS packet with unexpected length was received.

Dan Pascu

On 2 Oct 2009, at 02:48, bay2x1 wrote:

>
> Thank you for your time, patience and effort... I really appreciate  
> it...
>
> Correct me if I am wrong
> mediaproxy.dispatcher.RelayFactory starting on 25060 --- this the  
> port where
> mediaproxy-relay will connect and it uses TLS

That is correct.

>
> mediaproxy.dispatcher.ManagementControlFactory starting on 25061 ---  
> this
> the management port and it uses TCP

Partially correct. The management port is indeed 25061, but by default  
it also uses TLS. However this one you can configure to use TCP if you  
want.

>
> I have set the value in my config.ini for mediaproxy
> Dispatcher = 172.16.100.20:25060

Unless you use a port that is not the default (25060) there is no need  
to specify it, it's enough to specify the IP. However it's not  
incorrect if you specify it.

>
> Can you please enlighten me more on how to do a network capture what
> tools/utilities/commands do I need to use and what to look for.
> Can wireshark do this?

Yes it can, however if the communication is TLS, you won't see  
anything meaningful, other than the fact that they exchange packets  
since the communication is encrypted. But if one endpoint uses TCP,  
you will see in clear what it sends in the wireshark trace.

In python-gnutls, in the examples directory are some scripts. Can you  
run twisted-server.py and then twisted-client.py and see if they can  
communicate? Just to rule out problems with the gnutls library.

--
Dan




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Error: A TLS packet with unexpected length was received.

bay2x1
I have run the two script
--------------------------------------------------------
twisted-server.py
New connection from: C=NL,ST=Noord-Hooland,L=Haarlem,O=AG Projects,OU=Development,CN=Valid certificate,EMAIL=test@ag-projects.com
Protocol:      TLS1.1
KX algorithm:  RSA
Cipher:        AES-128-CBC
MAC algorithm: SHA1
Compression:   NULL
---------------------------------------------------------
---------------------------------------------------------
twisted-client.py
received:  echo
---------------------------------------------------------

I think there is no problem with the gnutls library....




Dan Pascu wrote
On 2 Oct 2009, at 02:48, bay2x1 wrote:

>
> Thank you for your time, patience and effort... I really appreciate  
> it...
>
> Correct me if I am wrong
> mediaproxy.dispatcher.RelayFactory starting on 25060 --- this the  
> port where
> mediaproxy-relay will connect and it uses TLS

That is correct.

>
> mediaproxy.dispatcher.ManagementControlFactory starting on 25061 ---  
> this
> the management port and it uses TCP

Partially correct. The management port is indeed 25061, but by default  
it also uses TLS. However this one you can configure to use TCP if you  
want.

>
> I have set the value in my config.ini for mediaproxy
> Dispatcher = 172.16.100.20:25060

Unless you use a port that is not the default (25060) there is no need  
to specify it, it's enough to specify the IP. However it's not  
incorrect if you specify it.

>
> Can you please enlighten me more on how to do a network capture what
> tools/utilities/commands do I need to use and what to look for.
> Can wireshark do this?

Yes it can, however if the communication is TLS, you won't see  
anything meaningful, other than the fact that they exchange packets  
since the communication is encrypted. But if one endpoint uses TCP,  
you will see in clear what it sends in the wireshark trace.

In python-gnutls, in the examples directory are some scripts. Can you  
run twisted-server.py and then twisted-client.py and see if they can  
communicate? Just to rule out problems with the gnutls library.

--
Dan




_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users