I sent the following to Franz but as you will see it does not look like
anything to with anything other than how badly screwed up Windows, my
laptop, or me or all three are... so what would you check first given
the following? Does the computer name coming back instead of an IP
address mean make-socket did not find... well, when I forgot to move the
ethernet cable over it rightly complained specifically about the absence
of a network... ah, but there is the local network and the Al Gore
Superhighway. Well, I am too dumb on sockets even to tell the monkets
what to try, any guesses welcome.
kt
The original query to Franz:
"On Tue, Jul 29, 2008 at 6:00 PM, Ken Tilton <·········@gmail.com> wrote:
:Deep in cl-s3, a Lisp interface to Amazon Simple Storage Solution,
inside first the s-http-client package and then the s-sysdeps package,
we have a call to:
0[6]: (ACL-SOCKET:MAKE-SOCKET :REMOTE-HOST "s3.amazonaws.com"
:REMOTE-PORT 80
:TYPE :STREAM
:ADDRESS-FAMILY :INTERNET)
0[6]: returned
#<MULTIVALENT stream socket connected from 192.168.2.160/2833
to 72.21.211.100/80 @ #x21aa6722>
That works fine on one XP machine and one Vista machine, and the distro
I have generated runs on my brother's system, which I think is XP.
But on another XP of mine the call to make-socket goes away for almost a
minute and then returns:
(SOCKET:MAKE-SOCKET :REMOTE-HOST "s3.amazonaws.com"
:REMOTE-PORT 80
:TYPE :STREAM
:ADDRESS-FAMILY :INTERNET)
1[4]: returned
#<MULTIVALENT stream socket connected from smokinjoe/1044 to
s3.amazonaws.com/80 @ #x21affe9a>
"smokinjoe" is the network name (terminology perhaps off) of the laptop.
Anyway, the very long delay is to me a bad sign, and I am wondering if
smokinjoe instead an IP address (again, pardon if my terminology off,
this is not my field) is a reflection or cause or whatever of that.
After this a trace shows the cl-s3 family of code staggering on for a
while before grinding to a hang on some attempted communication, but I
can break out of it (the first time).
Side info: the laptop in question has no problem talking to the
Internet, and again, this code runs fine on three systems I have tried.
I think the problem is obviously with my laptop and not ACL and would
not normally bother you all, but I am wondering what the behavior of
make-socket tells me, if anything. That would help my ongoing digging.
In fact, if you just say, "Oh, that laptop must be badly corrupted" I
will probably just forget the matter. My concern is that I am doing a
roll-out now and wonder how many other people will have the same problem
because of some oddity on their system."
Kenny wrote:
> I sent the following to Franz but as you will see it does not look like
> anything to with anything other than how badly screwed up Windows, my
> laptop, or me or all three are... so what would you check first given
> the following? Does the computer name coming back instead of an IP
> address mean make-socket did not find... well, when I forgot to move the
> ethernet cable over it rightly complained specifically about the absence
> of a network... ah, but there is the local network and the Al Gore
> Superhighway. Well, I am too dumb on sockets even to tell the monkets
> what to try, any guesses welcome.
Quick terms:
s3.amazonaws.com - domain name (gets looked up in DNS)
72.21.207.241 - IP address (resolved from above)
smokinjoe - network node hostname
Since the timing is consistent, I suspect a timeout somewhere in the
network stack.
The address resolution may be borked. In a command shell, type `ping
s3.amazonaws.com` and `ping 72.21.207.241` (or whatever IP the first
ping finds). Note that this address doesn't seem to respond to pings,
so you can kill ping once it resolves the address. Both commands
should take the same time to start; if the first is slower, then it
could be your DNS settings.
Try running `tracert s3.amazonaws.com` to see if one hop between the
laptop and amazon is being slow.
Also compare the DNS section of the "Network settings" (control panel)
against the good machines, try disabling any firewall software, and
possibly even antivirus.
> My concern is that I am doing a roll-out now and wonder how many
> other people will have the same problem because of some oddity on
> their system.
I get that feeling every time someone uses Windows. ;)
Another idea is to attach a C debugger to lispworks and check what
system calls are taking so long.
Wireshark is an excellent packet sniffer.
HTH,
Daniel
D Herring wrote:
> Kenny wrote:
>> I sent the following to Franz but as you will see it does not look
>> like anything to with anything other than how badly screwed up
>> Windows, my laptop, or me or all three are... so what would you check
>> first given the following? Does the computer name coming back instead
>> of an IP address mean make-socket did not find... well, when I forgot
>> to move the ethernet cable over it rightly complained specifically
>> about the absence of a network... ah, but there is the local network
>> and the Al Gore Superhighway. Well, I am too dumb on sockets even to
>> tell the monkets what to try, any guesses welcome.
>
> Quick terms:
> s3.amazonaws.com - domain name (gets looked up in DNS)
> 72.21.207.241 - IP address (resolved from above)
> smokinjoe - network node hostname
>
>
> Since the timing is consistent, I suspect a timeout somewhere in the
> network stack.
>
> The address resolution may be borked. In a command shell, type `ping
> s3.amazonaws.com`
Ok. It says it will talk to s3-1.amazonaws.com and mentions an IP
address. Then times out. The bad news is that it does this on the
machine that /can/ get to S3 as well (and I quickly dove in via the app
to confirm S3 is still up -- they have had issues lately. <g>)
So this is still interesting. HTH do the successful systems get past the
timeout, and why cannot SMOKINJOE do the same?...
>...and `ping 72.21.207.241` (or whatever IP the first
> ping finds).
No surprise I spose, but this too times out.
>.. Note that this address doesn't seem to respond to pings,
> so you can kill ping once it resolves the address. Both commands should
> take the same time to start; if the first is slower, then it could be
> your DNS settings.
>
> Try running `tracert s3.amazonaws.com` to see if one hop between the
> laptop and amazon is being slow.
>
> Also compare the DNS section of the "Network settings" (control panel)
> against the good machines, try disabling any firewall software, and
> possibly even antivirus.
Ah, yes, the classic: what is different? I will eradicate everything,
trembling all the while that whatever it is might be so common amongst
my target audience that it may not be appropriate for real-world
systems. But one working system is administered Seriously, so maybe I
will be OK.
>
>
>> My concern is that I am doing a roll-out now and wonder how many
>> other people will have the same problem because of some oddity on
>> their system.
>
> I get that feeling every time someone uses Windows. ;)
>
> Another idea is to attach a C debugger to lispworks and check what
> system calls are taking so long.
Bartending school sounds like more fun. :)
>
> Wireshark is an excellent packet sniffer.
>
Cool, that came up first in my googlery.
thx for all the good ideas,
kt
Kenny <·········@gmail.com> wrote:
+---------------
| D Herring wrote:
| > The address resolution may be borked. In a command shell, type `ping
| > s3.amazonaws.com`
|
| Ok. It says it will talk to s3-1.amazonaws.com and mentions an IP
| address. Then times out. The bad news is that it does this on the
| machine that /can/ get to S3 as well (and I quickly dove in via the app
| to confirm S3 is still up -- they have had issues lately. <g>)
+---------------
On most versions of Windows I've played with [I don't own any, so I don't
know how universal this is], the "ping" behaves as if you had given it
a "-o" option ["Exit successfully after receiving one reply packet"].
And maybe a "-c5" ["Stop after sending (and receiving) 5 packets"],
or some other small number. Which means that it'll only send a "few"
ICMP ECHO_REQUESTs (then stop sending), and either exit immediately on
the first ICMP ECHO_RESPONSE or else hang for some default timeout and
then exit.
+---------------
| So this is still interesting. HTH do the successful systems get
| past the timeout, and why cannot SMOKINJOE do the same?...
+---------------
Try writing a much smaller test case, say, opening a socket to
some simpler service such as <http://google.com/>, throw a "HEAD"
request at it (see below), and then read the response (which for
that request will just be a redirect, ~300 bytes total, ~520 if
you use "GET" instead of "HEAD"), e.g.:
$ http-get -H http://google.com/
HEAD / HTTP/1.0 \ Written to socket and
Host: google.com >-- also echo'd to terminal.
/
HTTP/1.0 301 Moved Permanently \
Location: http://www.google.com/ \
Content-Type: text/html; charset=UTF-8 \
Date: Wed, 30 Jul 2008 11:07:11 GMT \ Read from socket and
Expires: Fri, 29 Aug 2008 11:07:11 GMT >---
Cache-Control: public, max-age=2592000 / printed on terminal.
Server: gws /
Content-Length: 219 /
Connection: Close /
$
Then try that from each of your three machines. Hopefully it will
work on the first two and hang on the third [meaning the bug *isn't*
a Heisenbug!], and the problem will be simpler to debug.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Wed, 30 Jul 2008 06:14:53 -0500, ····@rpw3.org (Rob Warnock) wrote:
>Kenny <·········@gmail.com> wrote:
>+---------------
>| D Herring wrote:
>| > The address resolution may be borked. In a command shell, type `ping
>| > s3.amazonaws.com`
>|
>| Ok. It says it will talk to s3-1.amazonaws.com and mentions an IP
>| address. Then times out. The bad news is that it does this on the
>| machine that /can/ get to S3 as well (and I quickly dove in via the app
>| to confirm S3 is still up -- they have had issues lately. <g>)
>+---------------
>
>On most versions of Windows I've played with [I don't own any, so I don't
>know how universal this is], the "ping" behaves as if you had given it
>a "-o" option ["Exit successfully after receiving one reply packet"].
>And maybe a "-c5" ["Stop after sending (and receiving) 5 packets"],
>or some other small number. Which means that it'll only send a "few"
>ICMP ECHO_REQUESTs (then stop sending), and either exit immediately on
>the first ICMP ECHO_RESPONSE or else hang for some default timeout and
>then exit.
Windows ping tries 4 times by default.
Usage: ping [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS]
[-r count] [-s count] [[-j host-list] | [-k host-list]]
[-w timeout] target_name
Options:
-t Ping the specified host until stopped.
To see statistics and continue - type
Control-Break;
To stop - type Control-C.
-a Resolve addresses to hostnames.
-n count Number of echo requests to send.
-l size Send buffer size.
-f Set Don't Fragment flag in packet.
-i TTL Time To Live.
-v TOS Type Of Service.
-r count Record route for count hops.
-s count Timestamp for count hops.
-j host-list Loose source route along host-list.
-k host-list Strict source route along host-list.
-w timeout Timeout in milliseconds to wait for each reply.
George
--
for email reply remove "/" from address
On Jul 30, 1:43 am, Kenny <·········@gmail.com> wrote:
> D Herring wrote:
> > Kenny wrote:
> >> I sent the following to Franz but as you will see it does not look
> >> like anything to with anything other than how badly screwed up
> >> Windows, my laptop, or me or all three are... so what would you check
> >> first given the following? Does the computer name coming back instead
> >> of an IP address mean make-socket did not find... well, when I forgot
> >> to move the ethernet cable over it rightly complained specifically
> >> about the absence of a network... ah, but there is the local network
> >> and the Al Gore Superhighway. Well, I am too dumb on sockets even to
> >> tell the monkets what to try, any guesses welcome.
>
> > Quick terms:
> > s3.amazonaws.com - domain name (gets looked up in DNS)
> > 72.21.207.241 - IP address (resolved from above)
> > smokinjoe - network node hostname
>
> > Since the timing is consistent, I suspect a timeout somewhere in the
> > network stack.
>
> > The address resolution may be borked. In a command shell, type `ping
> > s3.amazonaws.com`
>
> Ok. It says it will talk to s3-1.amazonaws.com and mentions an IP
> address. Then times out. The bad news is that it does this on the
> machine that /can/ get to S3 as well (and I quickly dove in via the app
> to confirm S3 is still up -- they have had issues lately. <g>)
>
> So this is still interesting. HTH do the successful systems get past the
> timeout, and why cannot SMOKINJOE do the same?...
>
> >...and `ping 72.21.207.241` (or whatever IP the first
> > ping finds).
>
> No surprise I spose, but this too times out.
as the earlier reply pointed out:
> >.. Note that this address doesn't seem to respond to pings,
Ping was a nice courtesy of a tamer Internet of the past. Most
machines and firewalls are configured to block all ICMP traffic (which
is used for ping among other things) most machines no longer respond
to external ICMP requests. [wouldn't it be nice if the Internet could
just get along, and people wouldn't try to break stuff. alternately
if our programs couldn't be broken so easily too, that would also
work.]
The earlier reply was just trying to see what IP address the name was
resolved to (and make sure that was consistent), which ping tells you
before it tries to send the ping request. The more appropriate way to
identify how your computer is resolving names is to use "nslookup"
which is the *nix program name, I don't know if Windows ships with it,
but cygwin has it.
So you could do:
$>nslookup s3.amazonaws.com
Non-authoritative answer:
Server: xxx.xxx.xxxxxxxx.xxx
Address: xxx.xxx.xxx.xxx
Name: s3-1.amazonaws.com
Address: 72.21.211.100
Aliases: s3.amazonaws.com
(it tells you first who you are talking to for a DNS server (I just
blocked out mine, no need to broadcast that) and then it tells you who
that name server thinks you are referring to on the Internet at
large.)
> > Try running `tracert s3.amazonaws.com` to see if one hop between the
> > laptop and amazon is being slow.
This can tell you more than just slow - look at the paths your
multiple machines are taking. Are they the same?
The other thing not mentioned here is presumably your laptop has
multiple network interfaces? Or potentially connects to the Internet
differently than your other machines?
If so the traffic could be routed differently. For example, when I
VPN into my office, I don't have to route all of my traffic through
the VPN interface. I can set it to send only addresses that are in
work-related IP ranges through the VPN, and other requests can be sent
through the regular network interface directly to their destination
without first having to bounce through the VPN.
SO even on one machine www.google.com can work and s3-1.amazonaws.com
might not. Now these settings like I am talking about should be
regardless of what program you are using. On smokinjoe can you get to
the Amazon page with a web browser? (you said you could get to the
public internet, but weren't specific about where) It's possibly your
connection routes some traffic different, or even just drops some
traffic.
The easy way to compare bulk network settings between windows
computers is to open up an command window and run "ipconfig /all" you
should see all the network interfaces listed, and many of their
properties, like the DNS servers being used. Compare the two
computers.
> Bartending school sounds like more fun. :)
Why tend? when you could bar-hop, or just bar-sit still and drink for
that matter.
good luck,
Kevin
In article <····································@a70g2000hsh.googlegroups.com>,
K Livingston wrote:
> Most machines and firewalls are configured to block all ICMP traffic (which
> is used for ping among other things) most machines no longer respond to
> external ICMP requests.
This is fairly OT, but I just want to point out that if you catch someone doing
this, you should smack them. Lots of people who think they know what they're
doing block ICMP; it turns out, it's _more than just ping_, and you break
important functionality (and in very subtle and hard-to-diagnose ways) when you
do that. Google "path mtu detection blackhole" for more information.
gwillen
D Herring <········@at.tentpost.dot.com> writes:
> Also compare the DNS section of the "Network settings" (control panel)
you can also compare the speed and output of
nslookup s3.amazonaws.com
> against the good machines, try disabling any firewall software, and
> possibly even antivirus.
Also, run a check for spyware on the affected machine. I've seen
spyware that contains transparent proxies that will send your data
through proxies on other continents before reaching its goal (if
something like this happens, it would of course also be visible if you
monitor traffic at your gateway, maybe even if you run netstat -a
in windows).
--
(espen)
thus spoke Kenny <·········@gmail.com>:
> But on another XP of mine the call to make-socket goes away for almost a
> minute and then returns:
> (SOCKET:MAKE-SOCKET :REMOTE-HOST "s3.amazonaws.com"
>:REMOTE-PORT 80
>:TYPE :STREAM
>:ADDRESS-FAMILY :INTERNET)
> 1[4]: returned
>#<MULTIVALENT stream socket connected from smokinjoe/1044 to
> s3.amazonaws.com/80 @ #x21affe9a>
Could use a packet sniffer dump, Kenny.
--
The great peril of our existence lies in the fact that our diet consists
entirely of souls. -- Inuit saying
From: Vilho =?utf-8?B?UsOkaXPDpG5lbg==?=
Subject: Re: paging all socket geniuses
Date:
Message-ID: <87iquot39l.fsf@iki.fi>
Hello,
not familiar with ALisp or cl-s3 (or Windows, thank Supreme Being), but some
quick thoughts:
- is this a recurrent problem? Single events of long delays in
connecting could arise from multiple reasons (e.g. high server load, DNS
delay, ...).
- reference to hostname vs. IP address is not always an indication of
underlying problems. Your system seems to be able to map hostname to
IP address in both cases.
BR,
Vilho
Kenny <·········@gmail.com> writes:
> I sent the following to Franz but as you will see it does not look
> like anything to with anything other than how badly screwed up
> Windows, my laptop, or me or all three are... so what would you check
> first given the following? Does the computer name coming back instead
> of an IP address mean make-socket did not find... well, when I forgot
> to move the ethernet cable over it rightly complained specifically
> about the absence of a network... ah, but there is the local network
> and the Al Gore Superhighway. Well, I am too dumb on sockets even to
> tell the monkets what to try, any guesses welcome.
>
> kt
>
> The original query to Franz:
>
> "On Tue, Jul 29, 2008 at 6:00 PM, Ken Tilton <·········@gmail.com> wrote:
> :Deep in cl-s3, a Lisp interface to Amazon Simple Storage Solution,
> inside first the s-http-client package and then the s-sysdeps package,
> we have a call to:
>
> 0[6]: (ACL-SOCKET:MAKE-SOCKET :REMOTE-HOST "s3.amazonaws.com"
> :REMOTE-PORT 80
> :TYPE :STREAM
> :ADDRESS-FAMILY :INTERNET)
> 0[6]: returned
> #<MULTIVALENT stream socket connected from 192.168.2.160/2833
> to 72.21.211.100/80 @ #x21aa6722>
>
> That works fine on one XP machine and one Vista machine, and the
> distro I have generated runs on my brother's system, which I think is
> XP.
>
> But on another XP of mine the call to make-socket goes away for almost
> a minute and then returns:
>
> (SOCKET:MAKE-SOCKET :REMOTE-HOST "s3.amazonaws.com"
> :REMOTE-PORT 80
> :TYPE :STREAM
> :ADDRESS-FAMILY :INTERNET)
> 1[4]: returned
> #<MULTIVALENT stream socket connected from smokinjoe/1044 to
> s3.amazonaws.com/80 @ #x21affe9a>
>
> "smokinjoe" is the network name (terminology perhaps off) of the
> laptop. Anyway, the very long delay is to me a bad sign, and I am
> wondering if smokinjoe instead an IP address (again, pardon if my
> terminology off, this is not my field) is a reflection or cause or
> whatever of that.
>
> After this a trace shows the cl-s3 family of code staggering on for a
> while before grinding to a hang on some attempted communication, but I
> can break out of it (the first time).
>
> Side info: the laptop in question has no problem talking to the
> Internet, and again, this code runs fine on three systems I have
> tried.
>
> I think the problem is obviously with my laptop and not ACL and would
> not normally bother you all, but I am wondering what the behavior of
> make-socket tells me, if anything. That would help my ongoing
> digging. In fact, if you just say, "Oh, that laptop must be badly
> corrupted" I will probably just forget the matter. My concern is that
> I am doing a roll-out now and wonder how many other people will have
> the same problem because of some oddity on their system."
--
Vilho R�is�nen wrote:
> Hello,
>
> not familiar with ALisp or cl-s3 (or Windows, thank Supreme Being), but some
> quick thoughts:
>
> - is this a recurrent problem? Single events of long delays in
> connecting could arise from multiple reasons (e.g. high server load, DNS
> delay, ...).
The global behavior (a simple hang) has been consistent and unfailing.
Only recently did I dig as deep as the make-socket call, but again every
time i see the same thing: a 30-60second pause at make-socket, which
then returns and the rest of the code chugs on a few more yards before a
final hang.
>
> - reference to hostname vs. IP address is not always an indication of
> underlying problems. Your system seems to be able to map hostname to
> IP address in both cases.
OK. Thx. I am googling now for a packet sniffer....
kt
Kenny <·········@gmail.com> writes:
> Vilho R�is�nen wrote:
>> Hello,
>>
>> not familiar with ALisp or cl-s3 (or Windows, thank Supreme Being), but some
>> quick thoughts:
>>
>> - is this a recurrent problem? Single events of long delays in
>> connecting could arise from multiple reasons (e.g. high server load, DNS
>> delay, ...).
>
> The global behavior (a simple hang) has been consistent and
> unfailing. Only recently did I dig as deep as the make-socket call,
> but again every time i see the same thing: a 30-60second pause at
> make-socket, which then returns and the rest of the code chugs on a
> few more yards before a final hang.
(did not read all responses in this thread ...)
To my experience this has to do with network name resolution. 30 to 60
seconds of delay is typical of a failover from one DNS (domain name
server) to another.
Possible measures:
1. Use another name server as your primary nameserver. This is, of
course, only an option if you have the freedom to do so ...
2. Use directly the ip address for s3.ama... in the socket connect
call. This is obviously only a not so optimal solution ... Whenever
s3.amazon... gets a new name you have to update.
So, yes, it's most likely the laptop's DNS setup.
Best,
Frank
--
Frank Goenninger
frgo(at)me(dot)com
"Don't ask me! I haven't been reading comp.lang.lisp long enough to
really know ..."
Frank "frgo" a.k.a DG1SBG wrote:
> Kenny <·········@gmail.com> writes:
>
>> Vilho R�is�nen wrote:
>>> Hello,
>>>
>>> not familiar with ALisp or cl-s3 (or Windows, thank Supreme Being), but some
>>> quick thoughts:
>>>
>>> - is this a recurrent problem? Single events of long delays in
>>> connecting could arise from multiple reasons (e.g. high server load, DNS
>>> delay, ...).
>> The global behavior (a simple hang) has been consistent and
>> unfailing. Only recently did I dig as deep as the make-socket call,
>> but again every time i see the same thing: a 30-60second pause at
>> make-socket, which then returns and the rest of the code chugs on a
>> few more yards before a final hang.
>
>
> (did not read all responses in this thread ...)
>
> To my experience this has to do with network name resolution. 30 to 60
> seconds of delay is typical of a failover from one DNS (domain name
> server) to another.
>
> Possible measures:
>
> 1. Use another name server as your primary nameserver. This is, of
> course, only an option if you have the freedom to do so ...
>
> 2. Use directly the ip address for s3.ama... in the socket connect
> call. This is obviously only a not so optimal solution ... Whenever
> s3.amazon... gets a new name you have to update.
>
> So, yes, it's most likely the laptop's DNS setup.
>
Thanks for the input. I just compared the DNS stuff between the
non-functioning laptop and the functioning workstation and do not see a
difference. Both have Windows firewall going. I'll keep digging/working
my way back thru the other suggestions (should keep me busy and be an
education <g>).
thx again, kt
Ken wrote:
> Frank "frgo" a.k.a DG1SBG wrote:
>> Kenny <·········@gmail.com> writes:
>>
>>> Vilho R�is�nen wrote:
>>>> Hello,
>>>>
>>>> not familiar with ALisp or cl-s3 (or Windows, thank Supreme Being),
>>>> but some
>>>> quick thoughts:
>>>>
>>>> - is this a recurrent problem? Single events of long delays in
>>>> connecting could arise from multiple reasons (e.g. high server load,
>>>> DNS
>>>> delay, ...).
>>> The global behavior (a simple hang) has been consistent and
>>> unfailing. Only recently did I dig as deep as the make-socket call,
>>> but again every time i see the same thing: a 30-60second pause at
>>> make-socket, which then returns and the rest of the code chugs on a
>>> few more yards before a final hang.
>>
>>
>> (did not read all responses in this thread ...)
>>
>> To my experience this has to do with network name resolution. 30 to 60
>> seconds of delay is typical of a failover from one DNS (domain name
>> server) to another.
>> Possible measures:
>>
>> 1. Use another name server as your primary nameserver. This is, of
>> course, only an option if you have the freedom to do so ...
>>
>> 2. Use directly the ip address for s3.ama... in the socket connect
>> call. This is obviously only a not so optimal solution ... Whenever
>> s3.amazon... gets a new name you have to update.
>>
>> So, yes, it's most likely the laptop's DNS setup.
>>
>
> Thanks for the input. I just compared the DNS stuff between the
> non-functioning laptop and the functioning workstation and do not see a
> difference. Both have Windows firewall going. I'll keep digging/working
> my way back thru the other suggestions (should keep me busy and be an
> education <g>).
Yeah, I learned to listen to this guy:
http://smuglispweeny.blogspot.com/2008/03/tiltons-law-solve-first-problem.html
It was a Pyrrhic victory, but any excuse not to work on networking is
welcome: now nothing works. Internet-wise, I mean. And I imagine if I
had my OS CDs it would be easy to fix, cuz how I levelled the playing
field was to noice that altho ATL.DLL was no longer an issue some other
software i do not run was still whining about some DLL and lawdy it was
some anti-virus software, so I treated this as "the first problem" and
uninstalled it and now (a) my software no longer hangs, it moves right
to announcing the same thing all the other softwre announces: no network.
I'm just sorry I never got to run wire shark!
Thx again everyone,
kt
On Tue, 29 Jul 2008 21:31:11 -0400, Kenny <·········@gmail.com> wrote:
>
>But on another XP of mine the call to make-socket goes away for almost a
>minute and then returns:
>
>(SOCKET:MAKE-SOCKET :REMOTE-HOST "s3.amazonaws.com"
> :REMOTE-PORT 80
> :TYPE :STREAM
> :ADDRESS-FAMILY :INTERNET)
> 1[4]: returned
> #<MULTIVALENT stream socket connected from smokinjoe/1044 to
> s3.amazonaws.com/80 @ #x21affe9a>
>
>"smokinjoe" is the network name (terminology perhaps off) of the laptop.
>Anyway, the very long delay is to me a bad sign, and I am wondering if
>smokinjoe instead an IP address (again, pardon if my terminology off,
>this is not my field) is a reflection or cause or whatever of that.
>
>After this a trace shows the cl-s3 family of code staggering on for a
>while before grinding to a hang on some attempted communication, but I
>can break out of it (the first time).
>
>Side info: the laptop in question has no problem talking to the
>Internet, and again, this code runs fine on three systems I have tried.
>
It sounds like it is an address resolution problem.
Check that the DNS client service is running on the laptop. The
service is a local name cache ... Windows works perfectly well, but
slower, without it.
Check the DNS and WINS settings on the laptop connection to be sure
you don't have erroneous domain suffixes or non-existent servers
listed. If you've moved the laptop from one net to another, there may
be dribbles in there. If there are any deliberate settings in the
"advanced" tabs, they will override the DHCP configuration.
If you're using a domain controller make sure that WINS requests are
not being resolved using DNS - the WINS service has an option to do
that rather than having parallel name databases, but there is a huge
delay when WINS relays a request to DNS. Either If you don't have to
worry about handling 9x or NT machines, you can turn off the WINS
service on the domain controller entirely.
If none of this helps, there are a few other esoteric things to try
before nuking the OS.
George
--
for email reply remove "/" from address
George Neuner wrote:
> On Tue, 29 Jul 2008 21:31:11 -0400, Kenny <·········@gmail.com> wrote:
>
>> But on another XP of mine the call to make-socket goes away for almost a
>> minute and then returns:
>>
>> (SOCKET:MAKE-SOCKET :REMOTE-HOST "s3.amazonaws.com"
>> :REMOTE-PORT 80
>> :TYPE :STREAM
>> :ADDRESS-FAMILY :INTERNET)
>> 1[4]: returned
>> #<MULTIVALENT stream socket connected from smokinjoe/1044 to
>> s3.amazonaws.com/80 @ #x21affe9a>
>>
>> "smokinjoe" is the network name (terminology perhaps off) of the laptop.
>> Anyway, the very long delay is to me a bad sign, and I am wondering if
>> smokinjoe instead an IP address (again, pardon if my terminology off,
>> this is not my field) is a reflection or cause or whatever of that.
>>
>> After this a trace shows the cl-s3 family of code staggering on for a
>> while before grinding to a hang on some attempted communication, but I
>> can break out of it (the first time).
>>
>> Side info: the laptop in question has no problem talking to the
>> Internet, and again, this code runs fine on three systems I have tried.
>>
>
> It sounds like it is an address resolution problem.
>
> Check that the DNS client service is running on the laptop. The
> service is a local name cache ... Windows works perfectly well, but
> slower, without it.
>
> Check the DNS and WINS settings on the laptop connection to be sure
> you don't have erroneous domain suffixes or non-existent servers
> listed. If you've moved the laptop from one net to another, there may
> be dribbles in there. If there are any deliberate settings in the
> "advanced" tabs, they will override the DHCP configuration.
>
> If you're using a domain controller make sure that WINS requests are
> not being resolved using DNS - the WINS service has an option to do
> that rather than having parallel name databases, but there is a huge
> delay when WINS relays a request to DNS. Either If you don't have to
> worry about handling 9x or NT machines, you can turn off the WINS
> service on the domain controller entirely.
>
> If none of this helps, there are a few other esoteric things to try
> before nuking the OS.
>
> George
> --
> for email reply remove "/" from address
Thanks, George, that is a ton of great stuff to try, I wish I could. :)
But when I tried to open up the Networking control panels I was reminded
of a year-ago Bad Hair Day after which they themselves simply refused to
open. Fortunately I now feel justified in waiting until I get a report
from someone with a system in better shape.
Thx again to you and everyone who pitched in on this.
kt
On Jul 30, 8:53 am, Kenny <·········@gmail.com> wrote:
> George Neuner wrote:
> > On Tue, 29 Jul 2008 21:31:11 -0400, Kenny <·········@gmail.com> wrote:
>
> >> But on another XP of mine the call to make-socket goes away for almost a
> >> minute and then returns:
>
> >> (SOCKET:MAKE-SOCKET :REMOTE-HOST "s3.amazonaws.com"
> >> :REMOTE-PORT 80
> >> :TYPE :STREAM
> >> :ADDRESS-FAMILY :INTERNET)
> >> 1[4]: returned
> >> #<MULTIVALENT stream socket connected from smokinjoe/1044 to
> >> s3.amazonaws.com/80 @ #x21affe9a>
>
> >> "smokinjoe" is the network name (terminology perhaps off) of the laptop.
> >> Anyway, the very long delay is to me a bad sign, and I am wondering if
> >> smokinjoe instead an IP address (again, pardon if my terminology off,
> >> this is not my field) is a reflection or cause or whatever of that.
>
> >> After this a trace shows the cl-s3 family of code staggering on for a
> >> while before grinding to a hang on some attempted communication, but I
> >> can break out of it (the first time).
>
> >> Side info: the laptop in question has no problem talking to the
> >> Internet, and again, this code runs fine on three systems I have tried.
>
> > It sounds like it is an address resolution problem.
>
> > Check that the DNS client service is running on the laptop. The
> > service is a local name cache ... Windows works perfectly well, but
> > slower, without it.
>
> > Check the DNS and WINS settings on the laptop connection to be sure
> > you don't have erroneous domain suffixes or non-existent servers
> > listed. If you've moved the laptop from one net to another, there may
> > be dribbles in there. If there are any deliberate settings in the
> > "advanced" tabs, they will override the DHCP configuration.
>
> > If you're using a domain controller make sure that WINS requests are
> > not being resolved using DNS - the WINS service has an option to do
> > that rather than having parallel name databases, but there is a huge
> > delay when WINS relays a request to DNS. Either If you don't have to
> > worry about handling 9x or NT machines, you can turn off the WINS
> > service on the domain controller entirely.
>
> > If none of this helps, there are a few other esoteric things to try
> > before nuking the OS.
>
> > George
> > --
> > for email reply remove "/" from address
>
> Thanks, George, that is a ton of great stuff to try, I wish I could. :)
> But when I tried to open up the Networking control panels I was reminded
> of a year-ago Bad Hair Day after which they themselves simply refused to
> open. Fortunately I now feel justified in waiting until I get a report
> from someone with a system in better shape.
>
> Thx again to you and everyone who pitched in on this.
>
> kt
As is usually the case on the 'net, there's some good and some bad
advice, and details missing. My advice is no different:
1) The best way to check for connectivity to something like S3, or
another HTTP speaker is (as someone above suggested) to make an HTTP
request using curl, wget or even 'telnet s3.amazonaws.com 80'. Ping
and traceroute answer different questions (i.e. whether the listener
or intermediate device blocks icmp *echo request* and blocks or does
not return icmp error messages) On a good day, they are useful
diagnostic tools in the right hands. On a bad day, they are just
confusing.
2) Blocking *all* icmp can be a bad thing, but selectively blocking
icmp subtypes (like loose source routing or echo request) is common
and healthy. It's also off-topic. The Path MTU problem results from
blocking ICMP can't fragment errors, not echo request / response.
3) Address resolution can be a problem, can cause delays, and can be
easily diagnosed. Someone mentioned 'nslookup'. Also check out
'dig'. If your initial socket call pauses for a long time, a packet
sniffer would tell you if the name resolution is taking a long time,
but then again, so would doing a lookup with dig and trying the IP
address directly. I like alien_guy's advice about changing Allegro's
resolver behaviour, but I wouldn't worry about udp being blocked
upstream. Almost all DNS traffic is udp (tcp being used for large
record transfers and other miscellania) and blocking it would bust so
much.
4) There's always a possibility of routing & traffic management
anomalies, but again these are usually red herrings. Large systems
like S3 and others typically have some form of global traffic mgmt in
the form of smart DNS. In one common technique, they look at the IP
address of the recursing DNS resolver making the resolution call,
ascertain approximately where it is, and return the "closest"
instance, or least-loaded, or whatever the cost function might be.
This is also the reason you can perform the same nslookup / dig
several times and get different answers or you can perform the lookup
in Poughkeepsie and get X whilst your friend in Sacramento does the
same and gets Y.
e.g.
skeptomai:~$ nslookup s3.amazonaws.com
Non-authoritative answer:
s3.amazonaws.com canonical name = s3-1.amazonaws.com.
Name: s3-1.amazonaws.com
Address: 72.21.211.129
(09:01:02 <~>) 0 $ nslookup s3.amazonaws.com
Non-authoritative answer:
s3.amazonaws.com canonical name = s3-2.amazonaws.com.
Name: s3-2.amazonaws.com
Address: 207.171.181.225
These are the results from 2 of my machines, one on the west coast of
the US and one in western Canada. These differences are the result of
a global traffic mgmt decision. (For more info, look at Level3, F5's
3DNS product, etc.)
If you do dig up more, or resort to a packet sniffer or whatever,
I'd be willing to take a look to help.
Cheers,
-Chris
On Tue, 29 Jul 2008 21:31:11 -0400, Kenny wrote:
> But on another XP of mine the call to make-socket goes away for almost a
> minute and then returns:
>
> (SOCKET:MAKE-SOCKET :REMOTE-HOST "s3.amazonaws.com"
> :REMOTE-PORT 80
> :TYPE :STREAM
> :ADDRESS-FAMILY :INTERNET)
> 1[4]: returned
> #<MULTIVALENT stream socket connected from smokinjoe/1044 to
> s3.amazonaws.com/80 @ #x21affe9a>
socket:make-socket resolves :remote-host using socket:lookup-hostname.
Try evaluating (socket:lookup-hostname "s3.amazonaws.com") to see if this
is the cause of the timeout.
If it is, you can fiddle with socket:*dns-mode*, which on 8.1 defaults to
'(:ACLDNS :CLIB) which means that it first tries to query using its CL-
only resolver, using the system C resolver as backup. It may be that
Allegro's resolver has a bug so you could try to set *dns-mode* to
'(:clib :acldns) and retry. If both resolvers time out, it may be that
something on your computer(perhaps your firewall) or upstream is blocking
UDP queries - the DNS protocol says that a resolver should first try UDP,
than TCP when querying a server.
On Jul 30, 2:31 am, Kenny <·········@gmail.com> wrote:
> [long pauses, hostnames, numbers]
This will be name lookup timesouts. Almost certainly it is reverse
name lookup timeouts: something is trying to resolve an IP address
into a name, and you're getting a timeout (almost certainly a DNS
timeout) while doing this.
I don't have access to a Windows box (mac person at home, solaris at
work now), but I think they have nslookup.
So, if you get a command prompt on the machine, then you want to test
two things. For a fully qualified name x (s3.amazonaws.com say) do a
forward lookup:
nslookup -q=any x.
Note that full-stop: I mean that.
That should work and come back with some stuff. It may be a CNAME not
an IP address, if it is chase the CNAME down by making the same query
on it. For the above address you end up with a bunch of IP addresses,
one of which is 72.21.203.129.
Now pick that IP address, turn it round and do a pointer lookup:
nslookup -q=ptr 129.203.21.72.in-addr.arpa.
And you should get back a name.
Now try the equivalent reverse lookup for the IP address of the box
itself.
Chances are that one of these will go away for really a long time, and
then come back with some failure indication. If that happens, then
the problem is that DNS is screwed somewhere.
Fixing it is unfortunately out of the scope of this article (it is
probably either the ISP or whatever is telling the machine its DNS
servers, which will generally be the a DHCP server), but you should at
least now have a feel for what the problem is.
--tim
Tim Bradshaw wrote:
> On Jul 30, 2:31 am, Kenny <·········@gmail.com> wrote:
>> [long pauses, hostnames, numbers]
>
> This will be name lookup timesouts. Almost certainly it is reverse
> name lookup timeouts: something is trying to resolve an IP address
> into a name, and you're getting a timeout (almost certainly a DNS
> timeout) while doing this.
>
> I don't have access to a Windows box (mac person at home, solaris at
> work now), but I think they have nslookup.
>
> So, if you get a command prompt on the machine, then you want to test
> two things. For a fully qualified name x (s3.amazonaws.com say) do a
> forward lookup:
>
> nslookup -q=any x.
>
> Note that full-stop: I mean that.
>
> That should work and come back with some stuff. It may be a CNAME not
> an IP address, if it is chase the CNAME down by making the same query
> on it. For the above address you end up with a bunch of IP addresses,
> one of which is 72.21.203.129.
>
> Now pick that IP address, turn it round and do a pointer lookup:
>
> nslookup -q=ptr 129.203.21.72.in-addr.arpa.
>
> And you should get back a name.
That all worked liked a charm.
>
> Now try the equivalent reverse lookup for the IP address of the box
> itself.
I tried doing ipconfig to get my IP address (it looks as if nslookup
uses that by default if no params are entered, but I wnated to confirm)
and I got this error I have had for months now about ATL.DLL not being a
valid Windows whatsit and then ipconfig did nothing, so I really am
tabling this whole investigation (well, I downloaded a new ATL.DLL but
that gave me two and two subdirectories for them and I have an ATL.DLL
right in \windows\system32 (not a subdir) so I decided to hell with it
life is too short) on the basis of this probably not being a problem for
customers and at least I know what to ask them first. :)
You all are the best, I see more extensive help still pouring in, I am
humbled and as soon as I am out of bankruptcy we're all flying to
Jamaica for... the sun. Unfortunately the help I got on this group with
genital hair removal has turned out... well, nuff said on that.
Thx again all, kenny
Kenny escribi�:
>
> I tried doing ipconfig to get my IP address (it looks as if nslookup
> uses that by default if no params are entered, but I wnated to confirm)
> and I got this error I have had for months now about ATL.DLL not being a
> valid Windows whatsit and then ipconfig did nothing, so I really am
> tabling this whole investigation (well, I downloaded a new ATL.DLL but
> that gave me two and two subdirectories for them and I have an ATL.DLL
> right in \windows\system32 (not a subdir) so I decided to hell with it
> life is too short) on the basis of this probably not being a problem for
> customers and at least I know what to ask them first. :)
Did you try regsvr32 C:\Windows\System32\ATL.DLL ?
>
> You all are the best, I see more extensive help still pouring in, I am
> humbled and as soon as I am out of bankruptcy we're all flying to
> Jamaica for... the sun. Unfortunately the help I got on this group with
> genital hair removal has turned out... well, nuff said on that.
>
Sorry, did we forgot to tell you? The wax shouldn't be too hot.
Leandro
Leandro Rios wrote:
> Kenny escribi�:
>>
>> I tried doing ipconfig to get my IP address (it looks as if nslookup
>> uses that by default if no params are entered, but I wnated to
>> confirm) and I got this error I have had for months now about ATL.DLL
>> not being a valid Windows whatsit and then ipconfig did nothing, so I
>> really am tabling this whole investigation (well, I downloaded a new
>> ATL.DLL but that gave me two and two subdirectories for them and I
>> have an ATL.DLL right in \windows\system32 (not a subdir) so I decided
>> to hell with it life is too short) on the basis of this probably not
>> being a problem for customers and at least I know what to ask them
>> first. :)
>
> Did you try regsvr32 C:\Windows\System32\ATL.DLL ?
You guys won't let me quit! Yer the best.
Windows says it cannot do that cuz atl.dll aint whatever, so I tossed in
one of the DLLs I downloaded and ipconfig is now happy. But behavior
looks the same (I just ran the built exe, have to get into development
mode to make sure it is hanging at the same place). I have the exe built
to be debuggable and used the tray icon popup to interrupt the app and
I guess my wildcard handler caught it and the app starts up the rest of
the way and reports the network is unavailable, so that is something.
Just gotta do the packet sniffer thing now and check out all the other
ideas you all offered.
Right now I am trying to get out a fresh release and I have to convince
the software that -x+y+z/z+y-x is one, so maybe tomorrow.
Thx again, all.
>
>>
>> You all are the best, I see more extensive help still pouring in, I am
>> humbled and as soon as I am out of bankruptcy we're all flying to
>> Jamaica for... the sun. Unfortunately the help I got on this group
>> with genital hair removal has turned out... well, nuff said on that.
>>
>
> Sorry, did we forgot to tell you? The wax shouldn't be too hot.
>
I was supposed to melt the wax?
kt