TChart is trying to connect to 205.234.175.175?

[Daniel Ruehmer]

Hello,

a deployed application tries to connect to IP address 205.234.175.175 (after DNS query of crl.usertrust.com, checked with WireShark). Is this "by definition"? I traced it down to TChart.NET2.0

This is annoying in case of a (closed) network with a DNS server not rejecting the request straight away, because there is a timeout to wait before the application starts (around 15 seconds). The same application starts in around 10 seconds if the request is rejected straight away (I have not measured the duration if the request is really going through).

It is also a bit annoying not to know about software "calling home".

Is there anything you can tell me about this behavior?

Cheers
Daniel

[Christopher]

Daniel,

Is there anything you can tell me about this behavior?

I can't reproduce it here and it isn't by design. I ran a test with TeeChart for .NET v2.0.3203.23272 released to the public on 08/10/2008.

There is no known code within TeeChart which tries to connect to the address you specify or to any other. You might like to use Red Gate's Reflector to search TeeChart.dll for .NET framework methods which try to navigate to URLs.

I ran a test using the latest version of WireShark and a simple app using the specified TeeChart.dll. After the capture, I then did an "Edit->Find Packet" and searched for "205.234.175.175" from the top of the file within "Packet details". I found no reference to this address.

Maybe you could try using the version above and running a simple test similar to the one I did. The code I used was very simple:

Code: Select all

  public partial class Form1 : Form
  {
    public Form1()
    {
      InitializeComponent();
      InitializeChart();
    }

    private TChart tChart1;

    private void InitializeChart()
    {
      tChart1 = new TChart();
      tChart1.Dock = DockStyle.Fill;
      this.Controls.Add(tChart1);

      tChart1.Series.Add(typeof(Bar));
      tChart1[0].FillSampleValues();
    }
  }

Can you reproduce the problem using the same version of TeeChart.dll and the code above?

[Daniel Ruehmer]

Hi Chris,

thanks for your fast reply.

I can't reproduce it here and it isn't by design. I ran a test with TeeChart for .NET v2.0.3203.23272 released to the public on 08/10/2008.

...

Can you reproduce the problem using the same version of TeeChart.dll and the code above?

I'm using the same assembly version and yes, I can reproduce it with your code sample. You need to have a DNS server

Here is a screen shot (for 60 days ):

dunno why this image does not display in the preview!

I filtered for DNS and IPs>173.0.0.0.


Following are the URL-strings found in TeeChart.dll (.NET 2.0 V2.0.3203.23272). You can just look for them with a Hex viewer like that in Total Commander.

http://crl.verisign.com/tss-ca.crl
http://ocsp.verisign.com
http://crl.verisign.com/ThawteTimestampingCA.crl
http://www.usertrust.com
http://crl.usertrust.com/UTN-USERFirst-Object.crl
http://www.usertrust.com
http://www.steema.com


I finally found the "source" of those URLs: open the file properties of TeeChart.dll in explorer and look into the tab "Digital signatures" (or similar, as I have a German Windows). Here you can select the Signature and view its details. Now you can see the usertrust URL in the second row. This "technology" seems to insert "calling home" code into products .

Sadly, we can not afford to provide our customers with software, that tries to connect to the internet without notice. So maybe we have to replace TChart by something different (no offense or threat meant here, just an informative fact).

Cheers
Daniel

[Christopher]

Daniel,

I'm using the same assembly version and yes, I can reproduce it with your code sample. You need to have a DNS server

I would be very interested in reproducing this issue here, then I can get on to our Digital Signature provider (verisign) and ask them what is going on.

Can you please tell me what I need to do to reproduce the issue here? I have access to Win2003 Server and WinVista. A list of simple steps I have to take and the tools I need would be very helpful to me!

[Daniel Ruehmer]

Hi Christopher,

you're really quick!

I tested it on a virtual machine (VMware player 2.5) running Windows XP pro SP2 to eliminate side effects. The first incidence of the problem has been on a real test PC though.

Secondly you need a connection to the Internet, where the DNS lets requests through. The DNS address I set within the network settings of the adapter.

Thirdly I added a route via cmd shell (because not already there) as you can see in the screenshot from my last post (route add 0.0.0.0 mask 0.0.0.0 <server IP> metric 30), so that requests can go through.

The Windows Firewall setting is irrelevant to this behavior.

Now I run WireShark, started packet capturing and then run the test application. Stop at occurence of the main window and setting the filter to "dns || (ip.addr > 200.0.0.0)" and you can (possibly) see similar lines as in my screen shot.

I hope this helps you reproducing the behavior. Maybe you'll gain support from your admins.

Cheers
Daniel

[Christopher]

Daniel,

I hope this helps you reproducing the behavior.

Nope

This is what I get:


Any ideas what I could be doing differently? I'm working on WinVista and I have a working internet connection which lets DNS requests through to my DNS servers ...

...what else do I need?

[Christopher]

Daniel,

I'm now on another machine (again WinVista) connected to another network and I also can't see the problematic network traffic. Here's what I get:



Just thought you might be interested.

[Daniel Ruehmer]

Christopher,

I must admit, that it is getting weirder and weirder (I've not tested it with Vista).

I tried it on my development machine (setting the network adapter like in the virtual machine or like in the test PC): nothing
Even if I uninstall TeeChart, remove all "steema" keys in the registry and restart the PC the reaction is instantaneous without any DNS requests.

I went to the test PC again, opened the file properties of the DLL and viewed the details of the certificate: DNS query and it lasts a while.

Even if I try another network connection with the virtual machine the DNS queries occur. Maybe there is a problem with the actuality of certificates, i.e. if the certificate is known to the OS or not? (BTW your certificate ran out on December the 12th 2008).

My "wisdom" ends here , sorry.

I would give you my virtual machine, but I think a) Microsoft would have its say in sharing Windows licenses and b) its about 2GB...

Maybe you try a virtual machine yourself?

Cheers
Daniel

[Christopher]

Daniel,

Maybe there is a problem with the actuality of certificates, i.e. if the certificate is known to the OS or not? (BTW your certificate ran out on December the 12th 2008).

I reckon that could be part of the problem, although don't ask me to explain why

Anyhow, I'll build another update build of TeeChart for .NET v2 with our new certificate and I'll let you know when it's done for you to test.

[Christopher]

Daniel,

Anyhow, I'll build another update build of TeeChart for .NET v2 with our new certificate and I'll let you know when it's done for you to test.

Ok, this is now available. You can find details here.
http://www.teechart.net/support/viewtopic.php?t=9104

Please let me know if that has done the trick!

[Daniel Ruehmer]

Christopher,

much worse!!!

Now on my development machine with no connection to the Internet shows DNS requests for crl.usertrust.com with all the full timeout delay.

Wait a moment! I just figured out, that my second network adapter (a connection to the Internet) was not disabled but just "unplugged". After plugging in the network cable and after the first access to usertrust.com no DNS request was sent anymore (with all the benefit in speed), even after a reboot. Now it is gone on my development PC.

I believe that the connection of the certificate to usertrust.com "installed" somehow a marker that it is valid and asks no more. However on my virtual machine it is still the same (DNS requests are going on).

I granted my virtual machine the right to access the Internet. Displaying the certificate in the DLLs file properties gained access to usertrust.com. Rebooting and unplugging the network cable resulted in a fast response, though plugging in the cable resulted again in DNS requests.

I'm really confused with this behavior. I'm trying now Windows Update on my virtual machine if this solves something, but I don't believe it, because the test PC is up to date...

Cheers,
Daniel

[Christopher]

Daniel,

Displaying the certificate in the DLLs file properties gained access to usertrust.com.

I don't get this behaviour on my machine. This behaviour is totally independent of TeeChart code (agreed?) and is probably one of the keys to understanding the issue.

Here's an image of what I get:

I'm really confused with this behavior. I'm trying now Windows Update on my virtual machine if this solves something, but I don't believe it, because the test PC is up to date...

Ok. So, to summarise: these DNS requests do not appear if 1) the Digital Signature is valid and 2) the machine has a valid internet connection. Would you agree?

Right. I think further investigations should be opened on two fronts:
1) Digital Certificate.
Do you have Steema's Digital Certificate installed on the machine? You can check via "Control Panel -> Internet Options -> Content -> Certificates" If you have, click on the "Advanced" button and check if the "Client Authentication" checkbox is checked. If it is, try unchecking it (also try unchecking this checkbox in the "Intermediate Certification Authorities" tab). You might even like to delete the Steema Digital Certificate to see if that makes a difference.
2) Security
There is the possibility that some security process is causing this unwanted DNS traffic. Some security setting might be causing the security process to double check all Digital Certificates. This process could be an anti-virus process or a spyware/malware detector, either Microsoft built (e.g. Windows Defender) or third party. It may even be a security issue of the .NET Framework itself, although I think this is less likely. Why don't you try turning off all known security processes on your machine?

[Daniel Ruehmer]

Christopher,

summarise: these DNS requests do not appear if 1) the Digital Signature is valid and 2) the machine has a valid internet connection. Would you agree?

1) they do on the virtual machine and the test PC (and did on my development machine)
2) they appeared once but after "unplugging" the timeout is there again

I think further investigations should be opened on two fronts:

1) no, it is not installed on either OS ("Client Authentication" is unchecked, "Intermediate" not found - XP?).
2) No anti virus, Defender etc. on my XP virtual machine. I don't believe in a .NET issue, because it happens on viewing the certificate from the properties dialog.

After the installation of the Windows Updates (SP3, no IE7) it behaves the same (usertrust.com). Even installing your certificate did not do anything. Though the DNS request is gone, but the access to 205.134.175.175 persists. With Internet access the DNS is requested again.

edit:
Maybe you can try to set an unknown DNS in your network settings an see what happens?

Unfortunately now I'm sorry to say that I do not have my boss' permission to invest that lot of time into this problem anymore.

Cheers
Daniel[/b]

[Christopher]

Daniel,

1) they do on the virtual machine and the test PC (and did on my development machine)
2) they appeared once but after "unplugging" the timeout is there again

Just to make sure I understand: so, if your VM and test PC use TeeChart.dll with a valid Digital Certificate and they have a valid internet connection with working DNS servers, the unwanted DNS traffic does not appear? A yes or no answer would help

edit:
Maybe you can try to set an unknown DNS in your network settings an see what happens?

Sure. Image below:


Here I used the "fake" DNS servers 22 22 22 22 and 33 33 33 33. The unwanted traffic of the kind you mention does not appear. This test was run using the TeeChart.dll with the nonvalid (out of date) Digital Certificate.

Unfortunately now I'm sorry to say that I do not have my boss' permission to invest that lot of time into this problem anymore.

Ok. From my side, I think it is clear that the problem is not with the TeeChart.dll. What I could do, if you were interested, is to build an "empty" *.dll and sign it with Steema's Digital Certificate to see if we can reproduce the same behaviour. I think the same behaviour would be seen. A clear indication that the problem is independent of the TeeChart.dll is the fact that you get the unwanted DNS traffic simply by viewing Steema's Digital Certificate in its properties window. The code being run to view the properties window of a *.dll belongs to the Operating System and not to the *.dll in question.

On the other hand, it would be very interesting to know exactly what is causing this behaviour. Fortunately, there is another client who is experiencing the same problem [http://www.teechart.net/support/viewtopic.php?t=9087] ... maybe his boss will let him investigate the issue until we find out what is happening. If only I could reproduce the problem here ... but I can't

[Daniel Ruehmer]

Christopher,

Just to make sure I understand: so, if your VM and test PC use TeeChart.dll with a valid Digital Certificate and they have a valid internet connection with working DNS servers, the unwanted DNS traffic does not appear? A yes or no answer would help

It does appear (meaning no, it doesn't "does not")

Here I used the "fake" DNS servers 22 22 22 22 and 33 33 33 33. The unwanted traffic of the kind you mention does not appear. This test was run using the TeeChart.dll with the nonvalid (out of date) Digital Certificate.

What is the information behind the DNS queries to 22.22.22.22 (cut off on the right hand side in your screen shot)? Is there a crl.usertrust.com (as it would be in my case)?

Ok. From my side, I think it is clear that the problem is not with the TeeChart.dll. What I could do, if you were interested, is to build an "empty" *.dll and sign it with Steema's Digital Certificate...

Indirectly it is, because it is your certificate that's causing the problem when the DLL loads in my application. The "empty" DLL would IMHO cause it too.n Have you asked Verisign about this behavior? That would be an interesting information...

I hope that bairog has more success (good luck)!

Cheers
Daniel