Very Frequent router log entries

Hi,

The following entry is appearing in a new router VERY frequently. Because of the port I am wondering if it has something to do with email but the connection message can appear every 5sec or so and fills up the router log many times per day. Router is a D-Link. The IP resolves to wsip-174-78-110-160.pn.at.cox.net and does not seem to be blacklisted.

This server is owned by http://ww2.cox.com/ company. The port is https and it looks like somebody from your local network is using some software for IP TV or IP telephone or similar.
Check your clients for this type of the software.

I would expect Skype then being left open on a system left on. Would that make sense? But would this level of log activity be genrated only when it is logged in? There was certainly nobody actually using the service at the times the log fill. I would have expected an entry here and there but not so frequently.

Related...
1) This event is an "info" event and I do not need the logs filling up so frequently. Can I safely filter out these types of events or is there "info" that is really much more than info - if you know what I mean...
2) May I ask how you would know this is related to VOIP etc? The company seems to provide TV, internet services to its customers but why would this relate to IP TV or phone?

I only guess based on dns name starting with wsip - SIP is VoIP technology.
The clients of these programs are communicating even the user does'nt use it.
Because they use peer to peer technology.
In D-Link you can choose what you need to log - but real functionality is based on model you have.

WatchGuard is currently running a beta program for our new macOS Host Sensor for our Threat Detection and Response service. We're looking for more macOS users to help provide insight and feedback to help us make the product even better. Please sign up for our beta program today!

This should be functionality of the application - you must find what application is doing this connection.
On D-Link side - in event log find IP address of the computer with this connection
If you find the computer run in cmd on this computer:
netstat -n -b > c:\comm.txt
In this file you can find name of the application what is making this connection. And then we can discuss why
this application make connect every 5 sec.....

That all makes sense.
Am familiar with NETSTAT and sometimes pipe it to an output file too when I need a record.

I am at this location periodically and will see if I can catch it happening although, right now I have not seen any clear corelation to a system that is responsible for it which is the root of my enquiry, I suppose. If I can find that - I expect the rest will be fairly easy...

I looked through my applications, etc. on one of my computers. Meanwhile, I did some research on the web.

It appears to be an issue with SOME D-Link DIR-655 routers.

A number of the users weighing in on the topic are computer consultants or technicians and had multiple units of this model. For them the issue was not universal to this unit. That is, with multiple units in the field and with multiple ISPs, not all units exhibited this issue.

One killed the issue by reverting to an earlier firmware (1.21). Another tried reverting to firmware 1.20, but the issue persisted for them.

Some thought the communications with the Cox server is related to the securespot™ services feature of the router. Of those that tried turning off securespot (nobody reported using it anyway) not all saw the problem go away.

Regardless of the real cause, the traffic appears to originate from this model of the router itself. No other router was mentioned in my somewhat brief research. Of those that had contacted D-Link support, the universally received the equivalent of a blank stare on the issue. Support did not seem to know what was the cause of the issue. Granted, anybody that might have been successful in addressing the issue with D-Link support would be less likely to post inquiries about it on open forums.

I took a twofold approach:

I disabled SecureSpot (I don't use it anyway).

Menu securespot via "ADVANCED", then "SECURESPOT"

Uncheck "Enable securespot™ services" and click "Save Settings"

I blocked web access to that IP address.

Menu securespot via "ADVANCED", then "WEBSITE FILTER"

Make sure that "Configure Website Filter below" is set to "DENY..." (that is the default or factory setting).

Enter 174.78.110.160 in the first available box under "Website URL/Domain".

Click "Save Settings".

I stayed with the latest firmware.

After performing the above my logs no longer have my logs filled with accesses to that router.

This info seems very useful. Thanks for sharing it. I had turned off Securespot as well but thought the entries may have been resultant of something else when it did not change. Will recheck my settings (dunno if I re-enabled when test did not change it) and check into blocking.

Would have expected that the block would, itself, have generated log notices advising if the block but if it worked - that's all that matters.

I just checked and I have not received a single log entry for this since making the two changes. It has been several days and it used to fill the log (pushing out an e-mail) every 3.5 to 4 hours. It has not needed to close out and e-mail a log since that time four days ago.

I have NOT enabled Access Control and the Website Filter still functions on my unit. I have no entries in my logs for this issue since the fix.

As to why Access Control v. Website Filter, the latter is all that I wanted and needed to do to kill access to that server (and it does not matter which host tries to access that server). Access Control is much more complex and has other impacts that I did not wish to create.

Well, Tom... Guess I'm slower than you so I owe a bigger apology. Glad they did not close this!

Securespot had been disabled as I expected it was the cause. For some reason the entries continued for awhile afterwards. However, they did eventually slow down significantly and/or disappear without a specific block being put in place so I can only gather that it was the cause of the issue.

I believe there may be firmware update available as well so I will be doing that regardless (not far behind, maybe 1 release).

Featured Post

WatchGuard is currently running a beta program for our new macOS Host Sensor for our Threat Detection and Response service. We're looking for more macOS users to help provide insight and feedback to help us make the product even better. Please sign up for our beta program today!