8 Nov
2007
8 Nov
'07
10:37 p.m.
Information on TLS and OpenSER with this specific issues seems to be
scarce.
I have 2 different setups. One with about 130 registrations, one with
about 250. Both with SSLv23 turned on, and TLS is enabled in the phones.
What's odd is after some unknown amount of time, phones start dropping
like files and fail to re-register. (Our registration timer is set at 60
seconds to aid in failover).
What's interesting is it appears that the SSL handshake completely fails
when this starts to happen. The requests from the phones are smaller in
size (733 bytes about 970 for a good one). Suspicion would normally lie
with the phones. They're obviously not doing something right!
Here's the kicker. If I fail over to another OpenSER proxy (we move the
IP over, use the same certs, etc...) everyone comes back up, and
everything is happy for hours, maybe a day, maybe a week, and then it all
starts going downhill again.
I've increased the number of OpenSER children, I've played with the
tcp_persistent_flag. None of these things have stopped the madness.
Anyone have any ideas or thoughts?
--Chris
9 Nov
9 Nov
10:25 a.m.
Chris Heiser schrieb:
Information on TLS and OpenSER with this specific
issues seems to be
scarce.
I have 2 different setups. One with about 130 registrations, one with
about 250. Both with SSLv23 turned on, and TLS is enabled in the phones.
What's odd is after some unknown amount of time, phones start dropping
like files and fail to re-register. (Our registration timer is set at 60
seconds to aid in failover).
Do all the phones register via TLS or only some phones register via DNS?
Do only the phones fail to REGISTER which use TLS or all of them?
Why do you use SSLv23? Using TLS would be the standard.
What's interesting is it appears that the SSL
handshake completely fails
when this starts to happen. The requests from the phones are smaller in
size (733 bytes about 970 for a good one). Suspicion would normally lie
with the phones. They're obviously not doing something right!
What's about debugging the handshake? Use ssldump to debug the
handshake. There should also be some logs in openser's logfile.
regards
klaus
Here's the kicker. If I fail over to another OpenSER proxy (we move the
IP over, use the same certs, etc...) everyone comes back up, and
everything is happy for hours, maybe a day, maybe a week, and then it all
starts going downhill again.
I've increased the number of OpenSER children, I've played with the
tcp_persistent_flag. None of these things have stopped the madness.
Anyone have any ideas or thoughts?
--Chris
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
10:32 a.m.
On Fri, 9 Nov 2007, Klaus Darilion wrote:
That's just it. ssldump shows an initial packet of 733 and it never
handshakes. It just stays angry.
Chris Heiser schrieb:
Phones are configured to use TLS. These are the only ones that drop.
Anything registering over UDP keeps working fine.
Information on TLS and OpenSER with this specific
issues seems to be
scarce.
I have 2 different setups. One with about 130 registrations, one with
about 250. Both with SSLv23 turned on, and TLS is enabled in the phones.
What's odd is after some unknown amount of time, phones start dropping like
files and fail to re-register. (Our registration timer is set at 60
seconds to aid in failover).
Do all the phones register via TLS or only some phones register via DNS? Do
only the phones fail to REGISTER which use TLS or all of them?
Why do you use SSLv23? Using TLS would be the standard.
The same happens with just TLS. I believe SSLv23 was enabled for some
device that didn't do TLS properly.
What's interesting is it appears that the SSL
handshake completely fails
when this starts to happen. The requests from the phones are smaller in
size (733 bytes about 970 for a good one). Suspicion would normally lie
with the phones. They're obviously not doing something right!
What's about debugging the handshake? Use ssldump to debug the handshake.
There should also be some logs in openser's logfile.
regards
klaus
Here's the kicker. If I fail over to another OpenSER proxy (we move the IP
over, use the same certs, etc...) everyone comes back up, and everything is
happy for hours, maybe a day, maybe a week, and then it all starts going
downhill again.
I've increased the number of OpenSER children, I've played with the
tcp_persistent_flag. None of these things have stopped the madness.
Anyone have any ideas or thoughts?
--Chris
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
11:07 a.m.
Chris Heiser schrieb:
On Fri, 9 Nov 2007, Klaus Darilion wrote:
That's just it. ssldump shows an initial packet of 733 and it never
handshakes. It just stays angry.
Can ssldump decode the initial packet (is the bug in this special
initial packet or is the bug in openser decoding this special initial
packet)?
When switching to the backup openser, does it accept the intial packets
with 773 bytes or does the phone change back to "good" initial packets?
klaus
Chris Heiser schrieb:
Phones are configured to use TLS. These are the only ones that drop.
Anything registering over UDP keeps working fine.
Information on TLS and OpenSER with this specific
issues seems to be
scarce.
I have 2 different setups. One with about 130 registrations, one
with about 250. Both with SSLv23 turned on, and TLS is enabled in
the phones. What's odd is after some unknown amount of time, phones
start dropping like files and fail to re-register. (Our registration
timer is set at 60 seconds to aid in failover).
Do all the phones register via TLS or only some phones register via
DNS? Do only the phones fail to REGISTER which use TLS or all of them?
Why do you use SSLv23? Using TLS would be the standard.
The same happens with just TLS. I believe SSLv23 was enabled for some
device that didn't do TLS properly.
What's interesting is it appears that the SSL
handshake completely
fails when this starts to happen. The requests from the phones are
smaller in size (733 bytes about 970 for a good one). Suspicion
would normally lie with the phones. They're obviously not doing
something right!
What's about debugging the handshake? Use ssldump to debug the
handshake. There should also be some logs in openser's logfile.
>
> regards
> klaus
>
>
>>
>> Here's the kicker. If I fail over to another OpenSER proxy (we move
>> the IP over, use the same certs, etc...) everyone comes back up, and
>> everything is happy for hours, maybe a day, maybe a week, and then it
>> all starts going downhill again.
>>
>> I've increased the number of OpenSER children, I've played with the
>> tcp_persistent_flag. None of these things have stopped the madness.
>>
>> Anyone have any ideas or thoughts?
>>
>> --Chris
>>
>> _______________________________________________
>> Users mailing list
>> Users(a)lists.openser.org
>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>
11:09 a.m.
On Fri, 9 Nov 2007, Klaus Darilion wrote:
Chris Heiser schrieb:
I'll have to look into that. What's your suspicion?
On Fri, 9 Nov 2007, Klaus Darilion wrote:
That's just it. ssldump shows an initial packet of 733 and it never
handshakes. It just stays angry.
Can ssldump decode the initial packet (is the bug in this special initial
packet or is the bug in openser decoding this special initial packet)?
When switching to the backup openser, does it accept the intial packets with
773 bytes or does the phone change back to "good" initial packets?
Chris Heiser schrieb:
Phones are configured to use TLS. These are the only ones that drop.
Anything registering over UDP keeps working fine.
Information on TLS and OpenSER with this specific
issues seems to be
scarce.
I have 2 different setups. One with about 130 registrations, one with
about 250. Both with SSLv23 turned on, and TLS is enabled in the phones.
What's odd is after some unknown amount of time, phones start dropping
like files and fail to re-register. (Our registration timer is set at 60
seconds to aid in failover).
Do all the phones register via TLS or only some phones register via DNS?
Do only the phones fail to REGISTER which use TLS or all of them?
Why do you use SSLv23? Using TLS would be the standard.
The same happens with just TLS. I believe SSLv23 was enabled for some
device that didn't do TLS properly.
What's interesting is it appears that the SSL
handshake completely fails
when this starts to happen. The requests from the phones are smaller in
size (733 bytes about 970 for a good one). Suspicion would normally lie
with the phones. They're obviously not doing something right!
What's about debugging the handshake? Use ssldump to debug the handshake.
There should also be some logs in openser's logfile.
klaus
>
> regards
> klaus
>
>
>>
>> Here's the kicker. If I fail over to another OpenSER proxy (we move the
>> IP over, use the same certs, etc...) everyone comes back up, and
>> everything is happy for hours, maybe a day, maybe a week, and then it all
>> starts going downhill again.
>>
>> I've increased the number of OpenSER children, I've played with the
>> tcp_persistent_flag. None of these things have stopped the madness.
>>
>> Anyone have any ideas or thoughts?
>>
>> --Chris
>>
>> _______________________________________________
>> Users mailing list
>> Users(a)lists.openser.org
>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>
1:30 p.m.
Chris Heiser schrieb:
No suspicion - just tracking down the problem
Can ssldump decode the initial packet (is the bug in this special
initial packet or is the bug in openser decoding this special initial
packet)?
When switching to the backup openser, does it accept the intial
packets with 773 bytes or does the phone change back to "good" initial
packets?
I'll have to look into that. What's your suspicion?
6209
days inactive
6210
days old
5 comments
2 participants
participants (2)
-
Chris Heiser -
Klaus Darilion