Martin wrote:
Martin wrote:
Lynn W. Taylor wrote:
This is actually pretty encouraging, because it looks like you have a
repeatable test case.
I've just done a search on my logs spanning back to Nov 2008 for
13.240.68.208, and nothing found.
Or do I need to enable http_debug? Where? (If
Lynn W. Taylor wrote:
This is actually pretty encouraging, because it looks like you have a
repeatable test case.
Very curious indeed...
I've just done a search on my logs spanning back to Nov 2008 for
13.240.68.208, and nothing found.
Or do I need to enable http_debug? Where? (If you want
Martin wrote:
Lynn W. Taylor wrote:
This is actually pretty encouraging, because it looks like you have a
repeatable test case.
Very curious indeed...
I've just done a search on my logs spanning back to Nov 2008 for
13.240.68.208, and nothing found.
Or do I need to enable
It's an interesting thought, but you're missing the main point.
LIBCURL was told to connect to boinc2.ssl.berkeley.edu, and it says it
tried to connect to a host at XEROX Corporation.
I can't think of a single way for that to happen, short of a bug.
Since web browsers, mail clients, telnet,
I didn't persue it last time, because I was using an old version of BOINC, and
saw no reason to upgrade at the time - this was 2008 BC (before CUDA). I did
ask if anyone could confirm my observation with a current BOINC, but answer
came there none.
I am, however, glad that I posted on a
This is actually pretty encouraging, because it looks like you have a
repeatable test case.
Your DSL router is acting as a proxy for DNS, or actually running a
resolver (I'll bet it's a stub resolver) which has advantages and
disadvantages.
If you see the odd IP, and you immediately ping the
Richard Haselgrove spotted something interesting a while back, and since
I've been reading code and documentation trying to come up to speed,
it's pretty interesting.
What he saw is here:
http://boinc.berkeley.edu/dev/forum_thread.php?id=3225
At the time, boinc2.ssl.berkeley.edu resolved to
I am going to pick out one element of this... It stands out IF the DNS
administrator has set reverse lookups, then if the user does something
silly on the windows side like ipconfig /displaydns they would get the
appropriate record for
13.240.68.208.in-addr.arpa
Which would point to the
