We have plenty of people that use the Bsecure feature and enjoy it added parental controls and other security enhancements. If your router is continuing to use the bsecure DNS servers for resolution, send me a packet capture as well as a screen shot of your WAN settings page. If Securespot is disabled then the router will only use the DNS servers listed on the WAN page.
IF this is not the behavior you are seeing PM me and I'll personally handle your unit myself.
How does one go about doing this? Securespot is disabled but I still get redirects to the login page. Nothing whatsoever shows up in the router's log that suggests anything to do with securespot is occurring. (which is somewhat disconcerting, if this isn't being logged what else isn't?)
I've never dealt with individual packets before so I wouldn't know how to capture one or what, exactly, that would look like (or what it's supposed to look like).
Knowing how Google handles f*kups like this makes me wonder why other companies have such a difficult time with it. When Google releases something or discovers a major problem the first thing they do is stick a bunch of engineers in a room with the sole task of fixing the issues that come up. This "war room," as they're called, tends to consist of between five and fifteen people who know the software intimately and they work until the issues have been fixed. This is a highly efficient process that seems to get most problems solved within a few hours of the initial identification of the problem (not the initial report, but when the problem has been confirmed as a problem). Were this a Google router chances are there would have been a solution provided long before 90% of us noticed it. (that's not to say that Google gets every problem fixed right away, but you can be almost guaranteed that, if it's a major problem on their end and you're not one of the first few people to encounter it they have already set at least 5 engineers to work on it, minor problems tend to take longer to fix, but this is understandable as they have a lower priority). This idea is very similar to (and possibly based on) how some open source projects work.
Apparently D-Link prefers the Microsoft method: If a problem occurs, ignore it. If the problem continues to occur, announce that there is no problem. If the problem still continues secretly put a couple low-paid (or, better yet, unpaid) intern engineers on it and see if they can fix it. If your low-cost engineers can't fix it put your better engineers on it, under no circumstances should the public be made aware that you are working on the officially non-existent problem. Six to twelve months later, when you have a workable, but mostly untested, solution announce that there's a solution to the previously unrecognized problem. Stop all work on this problem and, if/when it recurs start the process from the beginning. Also start from the beginning if the patch introduced other problems, under no circumstances should engineers ever communicate with each other, especially if they are, or have been, working on the same or similar issues or projects, that's what managers are for.
Personally I think Google's method works better and keeps people coming back for more. Microsoft's method actively drives customers away and only works because most customers don't know about, or are scared of, the alternatives.
Author
Topic: Blocking DIR-655.bsecure.com blocks Internet address resolution! (Read 58739 times)