netbios-ssn at 192.168.10.106 when opening a Crystal Report 1

[CrystalLion]

I have a client who runs Crystal Reports. It seems that when they open a report, it creates the following activities:

TCP: MEWS2006:4508 192.168.10.106:microsoft-ds SYN_SENT
TCP: MEWS2006:4509 192.168.10.106:netbios-ssn SYN_SENT

There is no reason for any internet activity when simply opening a Crystal report. In fact, when they shut down internet access, the reports open properly.

I have seen indications that this could be related to a vulnerability on port 445 which allows a "bot army" attack.

Before I alarm my client, can anyone tell me more based on the little info I have provided?

Thanks for your help.

 

[LawnBoy]

The addresses you have listed are part of the private IP space and will not route to the internet. This is not internet activity.

Without researching those calls it looks to me like simple machine name announcements to Active Directory and then one to Network Neighborhood.

Is there a machine on your network with that address? (192.168.10.106)


"We must fall back upon the old axiom that when all other contingencies fail, whatever remains, however improbable, must be the truth." - Sherlock Holmes

 

[CrystalLion]

No machine at that address.

All existing reports have the issue. New reports appear not to. I suspect something changed on the client’s network because all reports used to open OK. We upgraded a Progress ODBC driver recently but have done the same at several other customers with no issues.

Report opens quickly if we change from ‘Obtain an IP Automatically’ to specify an IP address with no Gateway.

Any other thoughts?

 

[burtsbees]

What about flushing the dns cache?

Burt

 

[LawnBoy]

All existing reports have the issue. New reports appear not to.

AHA. Your existing reports are attempting to contact a machine at that address, and since it's not there they wait for a timeout.

Indeed, something has changed on the client's network. When those reports were created, there was a machine at that address. Chances are it was the data source.

You may have to open the report and relink it to it's data source. I've seen instances where Crystal extracted info from the ODBC declaration and embedded it in the report.

"We must fall back upon the old axiom that when all other contingencies fail, whatever remains, however improbable, must be the truth." - Sherlock Holmes

 

[CrystalLion]

LawnBoy - your last reply makes the most sense. I will investigate and reply.

Thanks for your quick response.

 

[CrystalLion]

Thanks Lawnboy

Deinstalling and reinstalling the DSN did not work.

Also, I performed Tracert 192.168.10.106 on my own pc to see where it "hops" to and found that it goes out to:

10.120.0.1
gw_fctvplus.net [69.70.179.1] this is my isp
t3-3-3.core2-fr.ma pipelinewirelessus [67.99.80.253]
host 221-117-26-69.axsne.net [69.26.117.221]
host 10-119-26-69.axsne.net [69.26.119.10]
host 29-65-203-65.axsne.net [66.203.65.29]
host 1-96-26-69.axsne.net [69.26.96.1
hops 8 through 30 time out.

Can you help me figure out why an internal IP address is looking out to my ISP, and beyond? Sorry if this sounds elementary, but I am not an IP person.

 

[burtsbees]

What subnets do you have in your LAN? Is there anything NATted in the router translating from that address to your public IP addresses?

Burt

 

[LawnBoy]

There's definitely something screwy here. What is the IP and subnet of the pc you're using?

I'm not an expert at CR but what I've seen is a problem in the report itself, not in the DSN. I've had to open the report, connect to the DSN, and actually pull some data (this happened after the DSN server had changed).


"We must fall back upon the old axiom that when all other contingencies fail, whatever remains, however improbable, must be the truth." - Sherlock Holmes

 

[CrystalLion]

The issue ended up being this. I wrote the report on my own pc. It was comprised of a main report and several subreports. The subreports were imported into the main report as previously existing reports (they were not created as new within the main report). Because they originally resided on my pc, when I emailed the report (and its embedded subreports) to the client, Crystal kept looking for the subreports in their original location within my domain. When Crystal could not find them, it timed out and located them correctly and populated the report with data. To stop this, I saved the subreports on the client's pc as subreportname.rpt, removed them from the main report, reimported them from their new location on the client's system, relinked them, and ran them just fine.

 

[LawnBoy]

Glad you got it sorted out.


"We must fall back upon the old axiom that when all other contingencies fail, whatever remains, however improbable, must be the truth." - Sherlock Holmes