I sell a server based software product. I know nothing about the Symantec AntiVirus Corporate Edition product but one of my customers has it installed on his network. Can the firewall component of this thing be blocking a JDBC connection attempt by my product across my customer's network and not telling him so?
The connection is being prevented and here are my troubleshooting notes:
Is my JDBC connection code incorrect? No. My software product has been in a few hundred shops now for a few years with no other similar reports so the JDBC connection code is fine. I run the same network setup in my shop (Win 2k server and clients) and no trouble.
DNS issue on my customer's network? No. The user can successfully ping the server machine in a DOS window using server machine name. Network connectivity not the issue.
Network permissions problem? Nope. Full permissions granted to all clients on the user's network.
Server machine is the only one in the user's shop without the Symantec AntiVirus Corporate Edition product. If I attempt the JDBC connection on that machine alone (both my client and server components running on the server machine), all works well.
I think Symantec Antivirus CE won't allow my client app to communicate via JDBC across my user's network. Am I barking up the wrong tree here? If not, how does my customer tweak things in the Symantec product to let my product connect? No info on such in the Symantec docs or in posts.
Norton Antivirus Corporate Edition (NAV CE) is an antivirus product, not a firewall. It will not block connection attempts.
(The non-corporate version is a different kettle of fish, as it proxies ports used for email and instant messaging. This should still not affect the above situation.)
That something works in conditons X, Y and Z for a long time doesn't mean it doesn't have a bug -- there may be trigger factors that haven't been encountered yet.
A ping is (usually) ICMP traffic, which might be allowed through firewalls and routers even when TCP or UDP traffic isn't. It's actually quite common to be able to ping hosts you can't reach through TCP or UDP.
What does permissions have to do with this? Are you using the operating system's file sharing software as your transport, tunnelling JDBC through it? If not, this is irrelevant.
That's a direct connection.
This is almost certainly not the case.
Probably, yes. Do basic troubleshooting first, like trying a telnet connection to the port that the JDBC provider is set up to listen on. If that fails and, as you say, pings work, it's most likely a firewall issue.
Also, you need to distinguish between different types of "can not connect" -- is the connection *refused* or does it *time out*? And what
*details* do the debug logs tell you?
Anyhow, since you're a sales guy, you probably should call in the tech guys from your company who know how the product connects and the best way to troubleshoot it.
The user has Symantec Client FireWall Corp Edition 7.1 installed on all of the client machines. Not being familiar with all of the Symantec products I just assumed the antivirus and firewall were bundled. My bad.
The user is far from me and I'm working with him by phone. He indicates that he sees no way to view a list of items the firewall is filtering. I've never heard of this in a firewall product. I have asked him to try contacting the vendor. He's heard nothing yet. I figured I'd work the groups angle too and one of us would get there.
trouble.
Anything is possible. Myself and another developer here (eminently more skilled than myself) have reviewed the jdbc connection code. Standard connect me to machine blah on port blah. Nothing special. We are certain the problem is not there. Connects fine on this guy's server machine, just not across his network.
Noted. Did not know that. That level of network detail is the abyss to me :)
operating
Two things: I should have elaborated further here, and also I've looked further at the situation in the interim and determined it's not a failed jdbc connect attempt.
My client performs a file operation prior to the attempted jdbc connection. My thought was that it may be failing at that stage somehow due to an access issue. First part true but second part bogus. The client app is indeed throwing while trying to open the file containing machine name and not failing on its attempted jdbc connect (sorry - my bad). It is not due, however, to access settings.
The client app and database app make their homes in the same directory on the server. Nothing would work from across the network at all if permission to the working directory was not granted. Wrong turn on my part.
Here is what I hope is a clearer picture of the failure:
On database server start my server application queries the machine on which it is running for it's name. It then drops a file containing this name in its working directory. The client app is supposed to dig the name out of this file and incorporate it into its connection url (have to use machine name because can't assume static IP's).
The client app throws on the attempt to open the file containing machine name (not exactly sure why just yet. Working on getting debug logs. User is far from me. Working via phone.)
Really no reason not to be able to get at the file though. It's there (user confirmed it's being dropped). As I mentioned, the database server and GUI client apps share the same working directory on the server so it's not a pathing issue. The GUI should always find the file if it's there.
On the hundreds of other network configurations out there in which our app is installed, the file is found and opened. On this guy's server machine the file is found and opened. Across his network it is not. I'm convinced it is a network or firewall issue.
components
Yes, it is. Understand, of course, I misspoke. It is the Symantec client firewall product and not the antivirus product.
communicate
I will have the user try this.
Not the sales guy. I'm the developer. The sales guys are the ones making money ;)
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.