Gargoyle Forum

Thanks for that encouraging advice.
I've only used "force use..." setting up till now. I'll do a few more tests and tell you what I find. However I suspect the problem may be related to the fact that I start off with a "block all" setting and then build a white list after that.

I disabled the OpenDNS filter rule and tried the Wikipedia filter rule with and without the "Force to Clients use ..." DNS setting enabled.
As you hinted the Wikipedia filter rule worked OK with the "Force to use ..." DNS setting disabled. With "Force Clients to use ..." DNS setting enabled it did not work.
Strangely these DNS settings only have an effect if Whitelist rules are used.

Can you please try version 1.0.14, and see if you still have this problem?

What you report seems a little odd because when I test it doesn't seem to make a difference whether OpenDNS is active or not -- I get the same issue (similar to what you report) either way.

What I'm seeing is that wikipedia has images that aren't hosted on wikipedia.org, but on wikimedia.org. The connections to wikimedia.org are not allowed and (more importantly) these connections are not being shut down cleanly, so the page takes forever to load.

The reason the connections are not being shutdown cleanly is that the block rule applies to all traffic, and (prior to 1.0.14), this was done with a single iptables rule. The problem is that in order to shut down a TCP connection cleanly you need to REJECT with the "tcp-reset" option. Otherwise the connection will just hang. However you can ONLY specify the tcp-reset option for tcp connections, so this can't be used on a more generic rule. As of 1.0.14 there is a rule inserted specifically for TCP connections that will REJECT with tcp-reset, if a TCP connection is being blocked.

Eric wrote:Can you please try version 1.0.14, and see if you still have this problem?...

Will do. However I probably won't be able to try it till next weekend. Before I do I'll run another test using 1.0.13 to see whether including what I call the OpenDNS Filter rule makes any difference.

Eric: BTW thanks for your explanation regarding the "bug". Even though I didn't understand 100% of it I did get the gist of what you were saying.
I have a theory as to why DNS forcing was affecting things the way I described.
I use both Chrome and Firefox on PCs running XP. I can't recall whether it was Chrome or Firefox I was using for my tests but I do recall they were all done on the one PC. I also recall that I was visiting the same sites with and without DNS forcing. So I figure that perhaps XP or the browser knows that it can associate cached web pages with a particular DNS IP address.
I haven't had time to test the theory yet.

Eric wrote:Can you please try version 1.0.14, and see if you still have this problem?

Just finished testing version 1.0.14 with the Wikipedia and OpenDNS White-list filters I referred to earlier. I can happily report that everything works as expected (kills tcp connections to images cleanly etc.). Thank-you Eric.
I'm now playing around with "Xenu Link Sleuth" so I can add a few more sites to my White-list and have everything work as expected.

There appears to be some sort of timing issue for certain rules and pages. For example: http://vimeo.com/user426477* (using full regex) drops out altogether. These sorts of pages pull in a lot of different images and take a while to complete. I'm not sure what is terminating the session, Gargoyle or the Firefox browser.

That's a rather... odd regular expression to be using. Were you trying to match http://vimeo.com/user42647, http://vimeo.com/user426477, http://vimeo.com/user4264777, http://vimeo.com/user42647777, http://vimeo.com/user426477777... etc?

Are you sure you didn't want to use "http://vimeo.com/user426477.*" ?

http://vimeo.com/user426477, http://vimeo.com/user426477/videos, http://vimeo.com/user426477/videos/sort ... mat:detail, http://vimeo.com/user426477/videos/sort:plays, http://vimeo.com/user426477/videos/sort ... rmat:video, etc...

Right, that's "http://vimeo.com/user426477.*", not "http://vimeo.com/user426477*" -- there's a big difference. The dot is important.

You're probably confusing globbing with regular expressions.