[erlang-questions] ssl failed during the time shaking hands

[Bruce Fitzsimons]

Bruce Fitzsimons wrote:
> Jeremy Chow wrote:
>   
>> <snip lots of good analysis>
>>   
>> Apparently,  there are still 142 bytes data stayed at the receive
>> queue. The receiver terminal program hasnot take any data from that
>> queue beacuse the right file descriptor has not been added yet.
>>     
> All on gentoo linux x86, with R11B-5.
>   
Right.

I am closer to the problem, and now understand far too much about ssl, 
openssl, and the twisted brokerage to erlang.

The problem appears to be that the server socket gets a connection which 
it transport_accepts immediately, and then erlang tells it to 
transport_accept again. I think. The other side times out.

Certainly esock.c does not appear to reply to erlang when it is given a 
TRANSPORT_ACCEPT_CMD, which I think is odd. I'm rebuilding esock now 
with a hacked in reply. The erlang side certainly seems to expect a 
reply as it won't move on to the ssl_accept process without one. I've 
been testing with "openssl s_client" to the epmd listen port, and every 
time I connect it goes into the same state. Letting two erlang nodes 
talk to each other chewed up all available FDs after some time. Yurk.

I've not had time to do a diff against previous versions, but something 
appears to have changed as I can't see how this ever works.

I shall let the list know my results, but if anyone with knowledge of 
the erlang ssl code could give me some hints I'd appreciate it. There 
are quite a few layers of indirection...and the varargs usage was cute.

Regards,
Bruce

Debug except below (note the lack of a write_cmd below the 
TRANSPORT_ACCEPT_CMD):

--- cut here
-----------------------------------
ACTIVE_LISTENING - trying to accept on 6
-> PASSIVE_LISTENING
server accepted connection on fd 18
write_ctrl: len = 9
message (hex) : [ 00 00 00 09] [ 0c 00 00 00 06 00 00 00 12]
message (char): [  .  .  .  .] [  .  .  .  .  .  .  .  .  .]
==========LOOP=============
MASKS SET FOR FD:
CONNECTIONS:
 - TRANSPORT_ACCEPT [0x8156408] (fd = 18)
 - TRANSPORT_ACCEPT [0x8155e08] (fd = 17)
 - TRANSPORT_ACCEPT [0x8155808] (fd = 16)
 - TRANSPORT_ACCEPT [0x8155208] (fd = 15)
 - TRANSPORT_ACCEPT [0x8154c08] (fd = 14)
 - TRANSPORT_ACCEPT [0x8154608] (fd = 13)
 - TRANSPORT_ACCEPT [0x8154008] (fd = 12)
 - TRANSPORT_ACCEPT [0x8153a08] (fd = 11)
 - TRANSPORT_ACCEPT [0x8153408] (fd = 10)
 - TRANSPORT_ACCEPT [0x8152e08] (fd = 9)
 - TRANSPORT_ACCEPT [0x8152808] (fd = 8)
 - TRANSPORT_ACCEPT [0x8150ae0] (fd = 7)
 - PASSIVE_LISTENING [0x814fe08] (fd = 6)
Before poll/select: 14 descriptors (total 18)
-----------------------------------
read_ctrl: cc = 6
message (hex) : [ 0a 00 00 00 06 00]
message (char): [  .  .  .  .  .  .]
[TRANSPORT_ACCEPT_CMD] listenfd = 6, flags =
-> ACTIVE_LISTENING
==========LOOP=============
MASKS SET FOR FD: 6 (read)
CONNECTIONS:
 - TRANSPORT_ACCEPT [0x8156408] (fd = 18)
 - TRANSPORT_ACCEPT [0x8155e08] (fd = 17)
 - TRANSPORT_ACCEPT [0x8155808] (fd = 16)
 - TRANSPORT_ACCEPT [0x8155208] (fd = 15)
 - TRANSPORT_ACCEPT [0x8154c08] (fd = 14)
 - TRANSPORT_ACCEPT [0x8154608] (fd = 13)
 - TRANSPORT_ACCEPT [0x8154008] (fd = 12)
 - TRANSPORT_ACCEPT [0x8153a08] (fd = 11)
 - TRANSPORT_ACCEPT [0x8153408] (fd = 10)
 - TRANSPORT_ACCEPT [0x8152e08] (fd = 9)
 - TRANSPORT_ACCEPT [0x8152808] (fd = 8)
 - TRANSPORT_ACCEPT [0x8150ae0] (fd = 7)
 - ACTIVE_LISTENING [0x814fe08] (fd = 6, acceptors = 1)
Before poll/select: 14 descriptors (total 18)

 --- cut here