Patterson Eaglesoft dental practice management software local database connection blocked by default openwrt firewall settings?

Among my other jobs, I run IT for a dental office. We're running a piece of practice management software called Patterson Eaglesoft (version 16 I believe). The server runs on one Windows workstation, and the other workstations run client software that connects to it over the local network. I believe the software is internally using Sybase SQLAnywhere.

I've had an old router running dd-wrt as the office router for a while. I made an attempt to replace it with a newer router running openwrt in order to improve performance and to have updated security, and to run an openvpn server. The firmware on the new router is "openwrt-18.06.1-ar71xx-generic-archer-c7-v4-squashfs-sysupgrade.bin".

The only steps I ran through to get the new openwrt router ready for installation was to set it's WAN connection to use the office's static IP address, to set up a bunch of static DHCP assignments for various devices on the local network, and to set up the openvpn service.

When I swapped the old router for the new, I verified that the internet connection was being shared over both wifi and wired connections, that all computers on the network could access the net and share files to each other, that I could connect to the router from outside the network via openvpn, and that devices on the network that were meant to be assigned particular lan IP addresses were assigned those addresses by the router. All was well.

But then we ran Eaglesoft and it was a catastrophe. I fired up the server on machine 1, then fired up a client on machine 2. Eaglesoft on machine 2 could not find or connect to the database on machine 1 - apparently it uses some sort of auto-discovery process that worked just fine on the previous router. I tried machine 3 and machine 4 and none of them could see that there was a database server on machine 1. I checked that all these machines had been assigned their proper static local addresses on the LAN, and they had. I checked that I could ping machine 1 from the other computers on the LAN, and I could. I dug inside Eaglesoft's folder and found some database utilities that included a command-line function meant to find database servers on the network, and it turned up nothing.

My ignorance will probably shine with this thought -- but I had figured the computers would all be able to communicate to one another completely unimpeded on the LAN because they were all connected to the same big dumb Netgear gigabit switch, and that the router's firewall would only come into play for connections between LAN and WAN. But something in the nearly-default openwrt setup is apparently blocking the Sybase SQLAnywhere auto-discovery process if not the database communication entirely.

I had to swap the old dd-wrt router back in place, and again everything was just fine. I haven't yet been able to figure out what's blocking Eaglesoft clients from communicating or even finding their server on the local network when the openwrt router is in use and am not sure where to start digging. Does this problem ring a bell for anyone? Any thoughts?

Thanks for any help or information.

That is correct.

Are all your machines involved in this eaglesoft thing on Wired connections?

Yup, they're all wired connections.

One thing I can imagine is if the DD-Wrt router wasn't properly handing out DHCP then maybe everyone was using Link-Local addresses and now with DHCP they aren't except this database still is... or something like that?

I'd try wiresharking under the two conditions and see what kind of traffic there is, and how it differs.

If there's an auto-discovery thing it's probably using Broadcast or Multicast packets, so you should be able to plug a laptop into your dumb switch and wireshark these packets.

1 Like

Things to consider:

  • local DNS resolution (in addition to static DHCP leases/ potentially different IP assignments)
  • UPnP (if the software depends on incoming connections from the outside)
  • mDNS/ avahi (Zeroconf/UPnP SSDP)
1 Like

The two computers I'm calling machine 1 and machine 2 here were assigned the IPs 192.168.1.145 and 192.168.1.101 respectively, by both the dd-wrt router and the openwrt router (I've got my servers assigned addresses from 140-145 and office client computers in the lower 100s). I verified these addresses on both, and was able to ping each machine from the other using those IP addresses. So I think both routers are handing out IPs on the LAN. But wiresharking is a great idea -- too bad I've never been good at reading those logs! I'll give it a shot though.

I did just find this page about how SQL Anywhere finds servers, including some information on a 'broadcast' method. Since I couldn't find any information in the Eaglesoft settings regarding a specified IP for a database server, and because it talks of not being able to 'find' the server, I'm guessing this method might be in use. I don't know if it's possible that openwrt is somehow not playing well with whatever form of broadcast discovery SQL Anywhere employs, maybe Zeroconf or some other UDP-based method?

How about subtle naming changes? Did DD-WRT give things a ".lan" name? like "sqlserver.lan" or did it give something else, like "sqlserver.network" or something like that? Maybe the client is looking by name and the new name for the device is slightly different, or maybe the name being broadcast using the broadcast method is slightly different now?

1 Like

That sounds like a good thing to check, given that the SQL Anywhere page I just mentioned says

Clients then send out UDP broadcast packets containing the desired database server name and the corresponding database server responds with UDP packets, telling the client its IP address and port number. The client can then make a TCP connection to the database server.

The name may be key. Weirdly, I never specified the server's name in any Eaglesoft setting, but maybe it cached it, or Patterson's folk set the name at some point if they were called on to perform an update of the software before my time. Just because I haven't found the setting doesn't mean it's not there.

1 Like

Compare when using OpenWrt and DD-WRT:

ipconfig /all & route print

Verify windows firewall settings for OpenWrt.
It can automatically change zone if you alter network settings.
Reboot the switch to resolve potential MAC-address collision issue.

OpenWrt has IPv6 enabled by default, I'm not sure if this is different from your old DD-Wrt router.
You might want to disable router advertisements and DHCPv6 temporarily to see if the issue is related to it.

1 Like