I completly removed ZoneAlarm and re-installed it.
This seems to have fixed things (I HOPE, fingers crossed).

---

I Desire Peace and Justice, Jim Scott (Mod-Ret.)

If this is happening when seti servers are normal (like now) then I am afraid this is remarkably like the now infamous and hopefully nearly solved error 500 again. Two things can be done as a workaround -

1). take out your router and connect directly , get 10 days of WUs, start to crunch, re-connect your router and then before deadlines repeat the router extraction to allow uploads. Ugly but works for some.

2). Find a proxy close to CA and connect through that. Needs constant monitoring (daily) as proxies often just stop.

3). Re-install firewall to see if that was causing a problem.

Both these seem to help. Until such time as the fix is checked in and appears in a stable version then this is about all that can happen. This problem has been analysed to death and Thyme Lawn has produced a fix for what is a HTTP protocol error in boinc. We just need to see that turn up and then there may be a permanent fix.

Version 5.2.15 has been tried but is no better. The fix must be in a later version; I hope so any how.

Hope that helps.

---

Thanks to all who have replied.

After re-attaching while my computer was directly connected to my cable modem, then putting the linksys router back online, BOINC gives me the same errors as before . . . "no scheduler responded."

I am fairly sure now that it is a router problem. I have taken Zonealarm off-line, made sure Windows Firewall is disabled, etc....to no avail.

My linksys router is about 4 years old now, I'm guessing, based on the fact I remember upgrading the firmware "awhile" back, and it's dated Oct. 2003.

I've been trying to upgrade the firmware tonight, but keep getting an error.

I'm gonna turn the pesky beast off and on a couple more times, re-boot, etc., before me-thinks it's time for a new router.

FWIW, I've had a minor problem where certain programs trying to access the internet couldn't find a connection, even though I knew one was there.

The saga continues...

.........Bob

---

me-thinks it's time for a new router.

I don't think it is your router, it is most likely the software problem described. But if you are considering a new router, you might want to consider a D-LINK DI-604 or like model. With their newer firmware updates there is now a feature called "Static DHCP". What it does is allow you to assign one of the dynamic local IP address, like 192.169.1.101 to a specific MAC address of the NIC in a specific computer. This IP address then becomes reserved for that machine. This way if power is lost or a machine rebooted and/or machines added and removed, these "Static DHCP" IP addresses will always be the same machine.

It worked great for solving my problems with keeping SetiQue's history files sorted out and each machines records straight. It might help with your problems and programs that expect a machines IP address not to change.

All four of my windows XP pc's and one linux pc cannot report completed wu's or get new work from S@H only. They all were working and no changes have been made. The one XP 32 bit pc is running Boinc V4.45, one of the xp64 bit is running Boinc 4.45, one XP 64 bit is running 5.2.2 and the other XP 64 bit is running Boinc 5.2.6. None are running an enhanced client. All the linux pc's are running Boinc 5.2.13.The ones running XP 64 bit are only using the windows firewall. The XP 32 bit is running zone alarm pro. I'm only having trouble connecting to S@H. All the other projects are running just fine. Something has changed at Berkeley. There are two many other people reporting a problem connecting to S@H.

---

If you CAN connect normally to other internet sites and are only having trouble contacting the Boinc/Seti servers, I suggest you check the following.

Check for a black hole router located in your path to Berkeley. Microsoft may have a fix in it's knowledge base article about it. It conatains trouble shooting and fixes to locate the problem.

One fix is permanent and requires a registry edit. Hope this helps you guy's out.

If you are successful with this thanks go to Wander Saito for his original post.

---

Boinc....Boinc....Boinc....Boinc....

If you CAN connect normally to other internet sites and are only having trouble contacting the Boinc/Seti servers, I suggest you check the following.

Check for a black hole router located in your path to Berkeley. Microsoft may have a fix in it's knowledge base article about it. It conatains trouble shooting and fixes to locate the problem.

One fix is permanent and requires a registry edit. Hope this helps you guy's out.

If you are successful with this thanks go to Wander Saito for his original post.

Thanks for the PR Don :-)

At first I also though about the possibility of being a bad router, but It wouldn't explain why only 1 of the 3 computers are failing. As I understand it,, they're all behind the same router/firewall/connection. And when they started talking about DHCP, IDENT, etc... as I said before, network is hardly my strongest suit.

As indicated by Jack Gulley, some routers, like mine, can define specific internal IP to a given MAC address, but they can also limit the number of available IPs in that router's pool of addresses in a particular LAN. Maybe, whoever setup Bob W4DFW's net imposed all those limitations. Too bad his machines are hidden. Looks like Jim managed to fix his problem.

Anyway, just a though. Hope this helps. Good luck!

Cheers

---

What it does is allow you to assign one of the dynamic local IP address, like 192.169.1.101 to a specific MAC address of the NIC in a specific computer. This IP address then becomes reserved for that machine. This way if power is lost or a machine rebooted and/or machines added and removed, these "Static DHCP" IP addresses will always be the same machine.

Now THAT would be a great feature!! Just being able to have that is enough reason to upgrade my router. I'm sure I have some parameter set wrong in the router, maybe some port forwarding issue, but I *STILL* can't figure out why my other computer hooked to this router works just fine, but this one doesn't.

I'm falling farther and farther behind not having my 3rd computer crunching data!! <chuckle>

..........Bob

---

What it does is allow you to assign one of the dynamic local IP address, like 192.169.1.101 to a specific MAC address of the NIC in a specific computer. This IP address then becomes reserved for that machine. This way if power is lost or a machine rebooted and/or machines added and removed, these "Static DHCP" IP addresses will always be the same machine.

Now THAT would be a great feature!! Just being able to have that is enough reason to upgrade my router. I'm sure I have some parameter set wrong in the router, maybe some port forwarding issue, but I *STILL* can't figure out why my other computer hooked to this router works just fine, but this one doesn't.

I'm falling farther and farther behind not having my 3rd computer crunching data!! <chuckle>

..........Bob

Bob,

What's on the other side of the Linksys? Cable modem or ???

You mentioned Echolink in an earlier thread. The Echolink protocol is tough because when you connect to another site, the other site has to connect back to you. This is common for VOIP programs, and it'd be a hell of a lot simpler if they'd make a few changes in the protocol, but that's beyond this thread.

BOINC only connects out, so none of the NAT traversal issues apply.

My suspicion is that this is a problem with MTU, and that your particular Linksys isn't handling MTU discovery well. You can prove that by getting Dr. TCP and setting MTU down to 500 or so.

If 500 works, then I'd try something like 1450, and narrow it down from there. If 500 does not work, I'm wrong and we need to look at other issues.

You can find Dr. TCP here.

Let us know what you find....

---

My suspicion is that this is a problem with MTU, and that your particular Linksys isn't handling MTU discovery well. You can prove that by getting Dr. TCP and setting MTU down to 500 or so.

Hi Ned, Bob,

The whole "Black Hole Router" thing that Geek (Don) and I were talking, are all about MTU size packet handling, or at least how some routers fail in handling them properly in some situations.

Reducing the MTU size to handle one particular route can even fix the problem, but it can be harmfull in the long run, since changing it will compromise all TCP/IP based comunications.

Please take a look at the original post I did a couple of weeks ago. Hope it helps.

Regards,
Wander

---

How sweet it is.

The Regedit method 1 fixed all four of my windows 'puters. It works on both XP64 bit and XP Pro 32 bit.

Thanks for all your work.

---

My suspicion is that this is a problem with MTU, and that your particular Linksys isn't handling MTU discovery well. You can prove that by getting Dr. TCP and setting MTU down to 500 or so.

Hi Ned, Bob,

The whole "Black Hole Router" thing that Geek (Don) and I were talking, are all about MTU size packet handling, or at least how some routers fail in handling them properly in some situations.

Reducing the MTU size to handle one particular route can even fix the problem, but it can be harmfull in the long run, since changing it will compromise all TCP/IP based comunications.

Please take a look at the original post I did a couple of weeks ago. Hope it helps.

Regards,
Wander

Wander,

I'm not sure I entirely agree on the MTU setting question.

I suspect that most people having this problem are on a DSL line, and depending on their provider and how the protocols are encapsulated, their wire may not be able to pass a packet over 1480 bytes or so.

If the IP stack allows fragmentation, then a 1500 byte packet gets broken into a (probably) 1480 byte packet and a 20 byte packet, with two headers. They have to be reassembled at the other end. It's better to send 1480 byte packets, save the overhead of fragmentation and reassembly.

If the IP stack sets the "DF" flag, then we have to hope for the proper ICMP messages getting back -- and extra start-up overhead as the MTU is discovered.

... but mostly, if we know that the DSL connection always limits us to 1480, much time is wasted with either fragmentation or MTU discovery, and there is no downside at all to just setting it down a bit and always avoiding the issue.

Of course, your mileage may vary. My statements assume a DSL line that does not suppor the "normal" 1500 byte MTU -- in other words, that there will always be a need to adjust MTU downward by some "discovery" method. If that's true, lowering MTU will always reduce overhead. If not, well, not.

---

Wander,

I'm not sure I entirely agree on the MTU setting question.

I suspect that most people having this problem are on a DSL line, and depending on their provider and how the protocols are encapsulated, their wire may not be able to pass a packet over 1480 bytes or so.

If the IP stack allows fragmentation, then a 1500 byte packet gets broken into a (probably) 1480 byte packet and a 20 byte packet, with two headers. They have to be reassembled at the other end. It's better to send 1480 byte packets, save the overhead of fragmentation and reassembly.

If the IP stack sets the "DF" flag, then we have to hope for the proper ICMP messages getting back -- and extra start-up overhead as the MTU is discovered.

... but mostly, if we know that the DSL connection always limits us to 1480, much time is wasted with either fragmentation or MTU discovery, and there is no downside at all to just setting it down a bit and always avoiding the issue.

Of course, your mileage may vary. My statements assume a DSL line that does not suppor the "normal" 1500 byte MTU -- in other words, that there will always be a need to adjust MTU downward by some "discovery" method. If that's true, lowering MTU will always reduce overhead. If not, well, not.

Hi Ned,

As I said before, I'm no network specialist, so please forgive me for any incorrect information, but let me try to explain it as I understand this (if any you guys net-gurus out there want to "jump in", please).

As I see it, if any computer in the net path cannot deliver the whole packet (regardless its size) AND fails to return a ICMP message indicating such failure, this is enough to cause your machine to timeout. So, I'm really not sure if the MTU size has a direct connection to the DSL line, even though I am a DSL user and I already diagnosed a Black Hole in my path to UCB. An "non-responsive" router can sit anywhere between you and your destination, regardless of the type of connection your machine has to the net. Furthermore, this problem only started to plague me a few weeks after I joined SETI/Boinc.

That said, if you manually set the MTU size to 500 bytes, all your connections will be limited to that amount, even those that can handle a larger packet, which will certainly hurt the efficiency and can hurt performance too (more packets => less efficiency => lower performance, but in all honesty, in real situations, I think we're talking about fractions of a second :-) )

I suggested that by turning on the PMTUBHDetect parameter (or Path MTU Black Hole Detection) in the TCP/IP params, it will enable the protocol itself to determine the largest MTU size the routers in that route can handle, therefore using the biggest possible packet and with the bonus of handling those non-standard non-replying routers. Please note that this method doesn't allow the fragmentation of the packet.

Using the tools provided by DSLReports.com I measured the performance before and after applying the method and it was almost unchanged.

Well, I'm not sure if all this made any sense :-) Just contributing my opinion.

Cheers

---

Is it useful for me to say again that Thyme Lawn found a problem that would cause the boinc cc to fail in the way you and many others have seen it?

I have looked at the code myself and the ethereal traces and what has been found in the code could easily be responsible for what is a HTTP protocol error i.e what we see right now. Code wise certainly a condition exists that is true but not tested and hence the wrong action taken and the connection closed prematurely. So personally I would hold fire on changing the MTU size and asking ISPs/route providers to make sure icmp is enabled to do the right thing around fragmenation and wait for the code change to be checked in and a release made available that contains it.

I am hopeful then that the third of the three errors that have masqueraded as error 500 over the last 11 months will have been resolved and all will work well.

Only my advice to save further heart ache.

EDIT:
Just had message from Dr Anderson. He has checked in a change to correct the problem found. So lets see which version it comes out in and we can try it.

---

Wander,

I'm not sure I entirely agree on the MTU setting question.

I suspect that most people having this problem are on a DSL line, and depending on their provider and how the protocols are encapsulated, their wire may not be able to pass a packet over 1480 bytes or so.

If the IP stack allows fragmentation, then a 1500 byte packet gets broken into a (probably) 1480 byte packet and a 20 byte packet, with two headers. They have to be reassembled at the other end. It's better to send 1480 byte packets, save the overhead of fragmentation and reassembly.

If the IP stack sets the "DF" flag, then we have to hope for the proper ICMP messages getting back -- and extra start-up overhead as the MTU is discovered.

... but mostly, if we know that the DSL connection always limits us to 1480, much time is wasted with either fragmentation or MTU discovery, and there is no downside at all to just setting it down a bit and always avoiding the issue.

Of course, your mileage may vary. My statements assume a DSL line that does not suppor the "normal" 1500 byte MTU -- in other words, that there will always be a need to adjust MTU downward by some "discovery" method. If that's true, lowering MTU will always reduce overhead. If not, well, not.

Hi Ned,

As I said before, I'm no network specialist, so please forgive me for any incorrect information, but let me try to explain it as I understand this (if any you guys net-gurus out there want to "jump in", please).

As I see it, if any computer in the net path cannot deliver the whole packet (regardless its size) AND fails to return a ICMP message indicating such failure, this is enough to cause your machine to timeout. So, I'm really not sure if the MTU size has a direct connection to the DSL line, even though I am a DSL user and I already diagnosed a Black Hole in my path to UCB. An "non-responsive" router can sit anywhere between you and your destination, regardless of the type of connection your machine has to the net. Furthermore, this problem only started to plague me a few weeks after I joined SETI/Boinc.

That said, if you manually set the MTU size to 500 bytes, all your connections will be limited to that amount, even those that can handle a larger packet, which will certainly hurt the efficiency and can hurt performance too (more packets => less efficiency => lower performance, but in all honesty, in real situations, I think we're talking about fractions of a second :-) )

I suggested that by turning on the PMTUBHDetect parameter (or Path MTU Black Hole Detection) in the TCP/IP params, it will enable the protocol itself to determine the largest MTU size the routers in that route can handle, therefore using the biggest possible packet and with the bonus of handling those non-standard non-replying routers. Please note that this method doesn't allow the fragmentation of the packet.

Using the tools provided by DSLReports.com I measured the performance before and after applying the method and it was almost unchanged.

Well, I'm not sure if all this made any sense :-) Just contributing my opinion.

Cheers

Wander,

All of that is basically correct, and I'm not arguing against turning on the MTU blackhole detection.

My statement is that almost everything can handle a 1500 MTU, and the most common exceptions are PPPoE-type connections (typically 1480 for these).

If the machine that limits MTU is far away, then setting your MTU to match is a bad idea.

If the machine that limits MTU is very near (like your DSL connection) then everything is running at 1480 (or whatever the limit is) and setting your connection to that value will never hurt.

-- Ned

[edit]P.S. I suggested setting MTU to 500 or so as a diagnostic. 500 is very small, but if it does not work, MTU is not the problem, and you can pursue other problems.

If 500 does work, then you can try to find the largest possible value that works without error.[/edit]

---

I manually set MTU to 500, and now I can connect without a problem. I checked with DSLreports before and after changing the setting, and my download speed dropped only slightly. I'll experiemnt with the setting until I find the largest value that will work.

.........Bob

Edited to add: I am using a cable modem through RoadRunner

---

Thank you all for all the info on what can help to connect. My troubles all started back when SETI went to 5.x.x and I lost my avatar and found I could not upload a new one. That was no big deal because I could still get WUs. Then around the first of the year I could not connect to get work on all three of my computers. The big clue to solving my problem was seeing the reply to this post talking about port 113 and firewall routers. I just upgraded my Linksys BEFSX41 router to the latest firmware which gave me control over port 113. The IDENT port 113 is now disabled and I have now connected and got new work and uploaded my avatar.

Again...thank you all for helping me connect again.

---

P.S. I suggested setting MTU to 500 or so as a diagnostic. 500 is very small, but if it does not work, MTU is not the problem, and you can pursue other problems.

Setting MTU to 500 is a little low. There is no reason to set MTU lower than 576 which is the standard that all network routers have to live by. It is the standard MTU for dial-up connections and the Internet started there. Other than it not being a round number and it is sort of hard to remember, that is the minimum MTU you would ever have to set.

One of the problems with Windows is that when you once set a MTU value, then it will use it for all connections. Set it to 1500 and guess what happens when you bring up your dial-up for a backup connection. It uses the 1500, not the default 576 for dialup. If you have a little noise on the phone line, even a small error rate will reduce your effective connection speed if the MTU is very large.

A general guide for setting your MTU,
(if it must be set at all, not default)
set the lowest that applies:

Cable or good DSL provider.. 1500
Windows XP's PPPoE support.. 1480
AOL or ISP using AOL network 1400
Dial-up connection.......... 576

P.S. I suggested setting MTU to 500 or so as a diagnostic. 500 is very small, but if it does not work, MTU is not the problem, and you can pursue other problems.

Setting MTU to 500 is a little low. There is no reason to set MTU lower than 576 which is the standard that all network routers have to live by. It is the standard MTU for dial-up connections and the Internet started there. Other than it not being a round number and it is sort of hard to remember, that is the minimum MTU you would ever have to set.

What part of as a diagnostic wasn't clear?

500 isn't a little low, it's very low. If "very low" doesn't work, then there is no reason to mess around with MTU any longer, and you can put it back to the default and move on to the next possible cause.

The nice thing about standards is that there are so many to choose from

---

A general guide for setting your MTU,
(if it must be set at all, not default)
set the lowest that applies:

Cable or good DSL provider.. 1500
Windows XP's PPPoE support.. 1480
AOL or ISP using AOL network 1400
Dial-up connection.......... 576

A much more complete table is in RFC-1191:

RFC 1191                   Path MTU Discovery              November 1990

   Plateau    MTU    Comments                      Reference
   ------     ---    --------                      ---------
              65535  Official maximum MTU          RFC 791
              65535  Hyperchannel                  RFC 1044
   65535
   32000             Just in case
              17914  16Mb IBM Token Ring           ref. [6]
   17914
              8166   IEEE 802.4                    RFC 1042
   8166
              4464   IEEE 802.5 (4Mb max)          RFC 1042
              4352   FDDI (Revised)                RFC 1188
   4352 (1%)
              2048   Wideband Network              RFC 907
              2002   IEEE 802.5 (4Mb recommended)  RFC 1042
   2002 (2%)
              1536   Exp. Ethernet Nets            RFC 895
              1500   Ethernet Networks             RFC 894
              1500   Point-to-Point (default)      RFC 1134
              1492   IEEE 802.3                    RFC 1042
   1492 (3%)
              1006   SLIP                          RFC 1055
              1006   ARPANET                       BBN 1822
   1006
              576    X.25 Networks                 RFC 877
              544    DEC IP Portal                 ref. [10]
              512    NETBIOS                       RFC 1088
              508    IEEE 802/Source-Rt Bridge     RFC 1042
              508    ARCNET                        RFC 1051
   508 (13%)
              296    Point-to-Point (low delay)    RFC 1144
   296
   68                Official minimum MTU          RFC 791

For what it's worth.

---