EldoS | Feel safer!

Software components for data protection, secure storage and transfer

DTLS Client/Server problem

Also by EldoS: Callback File System
Create virtual file systems and disks, expose and manage remote data as if they were files on the local disk.
#12357
Posted: 02/10/2010 03:38:51
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

Hi,
I'm using SecureBlackbox - version 5.2.124 - Released October 9, 2007. I have a developer license, which I'm using with the DTLS client/server sample.

Problem: DTLS chat seems not to work
This is what I did so far:

1) Change SetLicenseKey to my key in both server and client
2) On server: use the provided cert.pfx as server cert, start listen, uncheck 'use client authentication'
3) On client: enter server's IP, uncheck 'use client authentication',click 'connect'

Connection establishment needs about ~1 minute. First send from client to server 'Hi' takes ~30 secs. Subsequent sends from both ends need ~1 second, seems OK.

Two questions: Why is it that lame at startup? Is there any error tracing/logging possible?

Kind regards
#12358
Posted: 02/10/2010 04:05:09
by Eugene Mayevski (EldoS Corp.)

Looks like it's assemblies that are being loaded slowly. This could happen when .NET Framework attempted to validate the digital signature (Authenticode, not strongname) of the assemblies.

In version 7 we have removed Authenticode signatures from the assemblies so there's no such problem in version 7.


Sincerely yours
Eugene Mayevski
#12359
Posted: 02/10/2010 05:26:03
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

Good guess, but this isn't the case. I have a Wireshark trace of the initial communication sequence. It seems to be a problem with the client, who doesn't understand the server's responses. Let me know, how I can forward the trace to you. TLS, btw, works.

Regards
#12360
Posted: 02/10/2010 06:55:28
by Ken Ivanov (EldoS Corp.)

It is more likely that some negotiation packets are lost somewhere in the network between the client and the server. Please try to do the following:
1) Ensure that UseRetransmissionTimer property is set to true on both client and server sides before connecting,
2) Try to assign different values to TimerValue property (default value is 1000, but it makes sense to try smaller values, e.g. 100, 200, 500),
3) Try to play with DatagramSize property,
4) You can add debug output code to the handlers of OnSend and OnReceive events of the DTLS components to track network packet sends and receives and narrow down the connection stage that causes the delays.
#12361
Posted: 02/10/2010 06:57:06
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

If you don't want to have a look into the pcap, here is the visual analysis of the startup phase (not complete):

http://maps.alphadex.de/eldos/image.jpg

Regards
#12362
Posted: 02/10/2010 07:11:57
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

Quote

It is more likely that some negotiation packets are lost somewhere in the network between the client and the server. Please try to do the following:

Hmm. The same thing happens using localhost, I'm just unable to trace it. Will try your suggestions, but don't have much hope. What does the image tell you?

Regards
#12363
Posted: 02/10/2010 07:15:16
by Ken Ivanov (EldoS Corp.)

I have nothing against pcap's actually.

As far as I understand, the log shows the packets being *sent* to the network (not the ones *received* by the peers). I recommend you to also trace the packets actually *received* by the components to the debug output from the OnReceive event handlers to check that the packets do arrive to their destinations:
Code
Written = socket.ReceiveFrom(Buffer, MaxSize, SocketFlags.None, ref remoteEP);
if (Written > 0)
{
    Console.WriteLine("Received " + Written.ToString() + " bytes, time: " + DateTime.Now.ToLongTimeString());
}
#12364
Posted: 02/10/2010 07:26:40
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

Hmm. It is the orginal DTLS client/sample code from you. Do you see the back and forth of "client hello", "server hello" in the image? I don't think, that we have to deal with delays caused by internal .net problems. There is a clear communication problem between client and server and because the client doesn't acknowledge the server's transmissions, I'm keen to know, how to come close to the cause of the problem.

You'll find another image at http://maps.alphadex.de/eldos/image2.jpg
It shows the merged screenshots of the client (above) and the server (below). The clocks of both machines have been synchronized before the attempt was made.
It shows the initial connection establishment delay very clear.

The problem is fully reproducable.

Regards
#12365
Posted: 02/10/2010 07:39:23
by Eugene Mayevski (EldoS Corp.)

I'd recommend first of all checking SecureBlackbox 7 instead of trying to catch the issue in an old version. Cause even if the problem exists with version 7 (and I doubt), it will be fixed only in the upcoming SecureBlackbox 8. So testing version 5 makes just no sense.


Sincerely yours
Eugene Mayevski
#12366
Posted: 02/10/2010 07:46:11
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

Hi Eugene,
I think I've started testings with the latest version. There the same delay could be watched. Unfortunately I have no valid license key for .7 and I refuse to buy a new license just for bug fixings.

But I will try to reproduce it again. Let you know.

UPDATE: I don't need to start messing with 7. Because it is a demo version, it has an inbuilt delay (as far as I know).

Regards
Also by EldoS: Callback File System
Create virtual file systems and disks, expose and manage remote data as if they were files on the local disk.

Reply

Statistics

Topic viewed 8722 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!