Doesn't block unless you update at startup

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Disable option "Update at Startup"
2. Start PeerBlock
3. Attempt to ping 3.0.0.0

What is the expected output? What do you see instead?
- Should see ip-address show up as Blocked in the PeerBlock UI, ping
command should display "General Failure"; instead ip-address shows up as
Allowed, and ping command times out.

Reproducible on Vista 32-bit, and Win7 64-bit; probably everyone else, too.

Original issue reported on code.google.com by peerbloc...@gmail.com on 26 Jul 2009 at 5:00

[GoogleCodeExporter]

After debuging a bit, it only seems to start blocking when it reaches this line 
in 
updatelist.cpp

TRACEV("[UpdateThread] [_Process]    called curl_multi_info_read");

Original comment by nightstalkerz on 26 Jul 2009 at 8:33

[GoogleCodeExporter]

Hmm, that routine should be called just to read in the downloaded list(s).  If
anything, I'd think that we're not sending the proper IOCTL to the driver 
telling it
to start blocking except as part of the Update-handling code.  

Original comment by peerbloc...@gmail.com on 26 Jul 2009 at 10:01

[GoogleCodeExporter]

Patched around this on a temporary basis; r69 hardcodes the "Update at Startup" 
value
to true, and disables the option within the UI.  This is just to get a stable 
public
release out the door, we'll look into the root cause of the problem after 0.9.1 
gets
released.

Original comment by peerbloc...@gmail.com on 29 Jul 2009 at 1:09

• Added labels: Milestone-Release1.0
• Removed labels: Milestone-Release0.9.1

[GoogleCodeExporter]

Retargetting for PeerBlock 1.1

Original comment by peerbloc...@gmail.com on 29 Sep 2009 at 3:56

• Added labels: Milestone-Release1.1
• Removed labels: Milestone-Release1.0

[GoogleCodeExporter]

Original comment by peerbloc...@gmail.com on 30 Sep 2009 at 4:20

• Added labels: Milestone-1.1
• Removed labels: Milestone-Release1.1

[GoogleCodeExporter]

Original comment by peerbloc...@gmail.com on 4 Nov 2009 at 10:05

[GoogleCodeExporter]

Looks like this issue was inadvertently resolved sometime over the course of 
the last
150 or so changes - the latest test build released to our internal test team 
has not
shown any signs of this bug.  I'm going to tentatively mark this bug as fixed 
for
now, will either reopen it or add a new bugs to track any instances of it that 
are
seen on people's specific machines.  As some of the other bugs have shown, 
there are
still a few unknown "edge cases" in which PeerBlock doesn't block during start 
on
some people's computers (usually XP-based machines), but hopefully the general 
case
has been fixed.

This fix will be included in the next Beta Release, which should be coming out 
in two
or three weeks.  The next Stable Release, PeerBlock 1.1, will also of course 
include
this when it comes out in a few months.

Original comment by peerbloc...@gmail.com on 6 Nov 2009 at 6:02

• Changed state: Fixed

[GoogleCodeExporter]

Using r209 on Vista 32bit and disabling update startup, the problem still 
persists.

It will show allowed connections fine but will not block anything.

Will try on a XP machine sometime this week to see it it's just my machine 
configuration or in general.

Original comment by nightstalkerz on 8 Nov 2009 at 4:08

[GoogleCodeExporter]

No, it happens on my machine also. Win 7 32bit.

Original comment by XhmikosR on 8 Nov 2009 at 6:54

[GoogleCodeExporter]

Re-opening this issue.  Seems like it's still happening on about 50% of 
machines -
just none of mine, and none of the earlier testers'.  It's being actively worked
right now, so hopefully we'll be able to truly resolve it soon.

Original comment by peerbloc...@gmail.com on 8 Nov 2009 at 11:34

• Changed state: Started

[GoogleCodeExporter]

Seems I have some problems with it as well on Win7 x64. Hope you can find the 
problem!

Original comment by Praese...@gmail.com on 9 Nov 2009 at 4:39

[GoogleCodeExporter]

Still broken for me in 1.0+ r211 BETA
Vista32

Original comment by wopeg...@tfea.co.cc on 19 Nov 2009 at 1:26

[GoogleCodeExporter]

The exact line after which blocking is enabled is around 578 in updatelists.cpp:

// blocking not working
while(curl_multi_perform(multi, &running)==CURLM_CALL_MULTI_PERFORM);
// blocking starts working

This suggests to me it's a firewall conflict (although I have tried disabling 
the
firewall) or some kind of permission/winsock handle that is not obtained for 
peer
block until curl activates it.

Or else other events are occurring in different threads at the time this loop 
is active.

Original comment by wopeg...@tfea.co.cc on 19 Nov 2009 at 3:05

[GoogleCodeExporter]

Found the bug:

preconnect_func() in updatelists

blocking doesn't start working until g_filter->setranges() is called
the list passed to setranges must have at least one entry

Hack fix:

execute this code when autoupdates are disabled:
if(g_filter) {
    p2p::list allow;
    allow.insert(p2p::range(L"Auto-allow hack", 0, 0));
    allow.optimize(true);
    g_filter->setranges(allow, false);
}

Original comment by wopeg...@tfea.co.cc on 19 Nov 2009 at 3:44

[GoogleCodeExporter]

That's the strange thing - we're only using libcurl to download new updates, 
and even
if we don't do that we still appear to be setting up the same blocking stuff.  
We're
still passing the same IOCTL to pbfilter.sys (which is performing the actual
blocking), still telling it to start blocking etc.

That said, PeerBlock blocks all the time on my test machines, regardless of 
whether
you update at startup or not, so it's difficult for me to chase this down.  I'm 
still
working on instrumenting pbfilter.sys (so that people hitting this can at least 
use
dbgview.exe to collect tracelog style output from it), but hopefully we'll have 
some
more data as to what's going on from the driver-level soon.

Thanks for helping look into this - if you're interested in continuing, I'd say 
you'd
probably be best off adding additional DbgPrint() statements to pbfilter.sys, 
and
running dbgview.exe to see what's going on internally in that driver during 
"update
at startup" versus "don't update at startup" scenarios.

Original comment by peerbloc...@gmail.com on 19 Nov 2009 at 3:45

[GoogleCodeExporter]

Wow, AWESOME - thank you ever so much!  Guess you found it while I was working 
on
typing up / submitting my last response...

That totally makes sense now, as it's the driver-interaction that I was 
expecting to
find.  Thank you VERY much for your time looking into this!!  I'll generate a 
test
version tonight and push it out to our Internal Test Team, then hopefully 
release a
new Beta Release containing this fix (or one like it) shortly thereafter.

Original comment by peerbloc...@gmail.com on 19 Nov 2009 at 3:49

[GoogleCodeExporter]

You're very welcome, it's a great project. If it's not against your policies 
I'd love
to see a "wopeg" comment in the code/changelog.

Original comment by wopeg...@tfea.co.cc on 19 Nov 2009 at 5:07

[GoogleCodeExporter]

Absolutely!  What I do is put the name of the patch-submitter in square brackets
(i.e. "[XhmikosR]" or "[night_stalker_z]") as the code-commit comment, and of 
course
will thank you profusely in the official "What's new?" section of the release 
post. 
I'll also add you in our credits, at least as a "some patches contributed 
by..." type
person, unless you're interested in joining our Dev Team as a more official
contributor.  (I've sent you an email about that, we'd love to have you on the 
team
if you're up for it!)  I'm a firm believer in giving credit where credit's 
due...

One note:  I do consider all code contributed to be owned by the PeerBlock 
Project,
meaning "PeerBlock, LLC", the company we needed to have registered in order to 
buy
that code-signing certificate.  My wife is actually an IP Lawyer and has 
*strongly*
recommended this, to avoid any sort of problems for PeerBlock down the line . . 
. and
being as how I'm married to her, it's tough for me to ignore her "advice".  =;) 
 I
try to leave all names out of the code itself - including myself - and instead 
simply
update the copyright header to reference PeerBlock, LLC, with contributors 
mentioned
in the Credits section of our docs/site/readme/etc.  I'd hope you wouldn't take 
issue
with this, but if you do let me know and I'll make sure to have someone 
re-implement
your change without looking at it ("clean-room" style), or something.

Original comment by peerbloc...@gmail.com on 19 Nov 2009 at 5:23

[GoogleCodeExporter]

Looks like that patch worked - included in Beta Release r223, and seems to be 
working
well on all machines.  Thanks again, "wopeg"!

Original comment by peerbloc...@gmail.com on 23 Nov 2009 at 5:12

• Changed state: Fixed

[GoogleCodeExporter]

I don't think the issue has been completely resolved yet. I'm using the beta 
release
r223 and I've just started seeing this bug after upgrading to Win 7 x64. I was
previously using Win XP SP3 and never experienced this. It occurs when 
0.0.0.0:68
communicates with 255.255.255.255:67. After chasing down the program that had 
port 68
open it was "svchost -k LocalServiceNetworkRestricted" which is started by the 
Win 7
"HomeGroup Provider" service. Hope that is some help. I do have auto-update 
disabled
and IP 255.255.255.255 is supposed to be blocked by the Bogon list.

Great work by the way! 

Original comment by entropyk...@googlemail.com on 25 Jan 2010 at 9:12

[GoogleCodeExporter]

Yes the same for me... I'm using r484 beta version and this issue seems not to 
be resolved! Ant suggestion?

Original comment by fraz.fra...@gmail.com on 29 Oct 2010 at 8:06

[GoogleCodeExporter]

Hi, I was having a similar problem. Peerblock was failing to block ip's, and  i 
was receiving the error message on PB start up

"PeerBlock is unable to load the packet filtering driver.
This could happen if PeerBlock crashed and didn't have a chance to unload the 
driver, or if the pbfilter.sys can't be found

win32_error
CreateFile
2
The system cannot find the file specified"

It turned out that malwarebytes ip filter was interfering with PB, which makes 
sense as both MWB and PB use the same driver apparently. So, disabled MWB  ip 
filter = PB functioning again. 

Its all discussed at the malwarebytes forum 

http://forums.malwarebytes.org/lofiversion/index.php?t44701.html

I know it is not exactly the same problem, but I thought the PB team might like 
to know, if they don't already.

btw great project 

keep up the good work  

Original comment by andrezad...@gmail.com on 23 Nov 2010 at 9:12

[GoogleCodeExporter]

Same problem also with version 1.1 (downloaded today). :(

Original comment by fraz.fra...@gmail.com on 24 Nov 2010 at 5:11