Re: How to test wireless problem?

seaweedsteve <seaweedsteve@xxxxxxxxx> hath wroth:

Goes back to the same thing I'm seeing on various pcs; The battle
between the custom management utility and Windows Zero over who is
supposed to be handling it and what state it's supposed to be in
now. I keep seeing this in various forms on various pcs with various
adapters. Maybe I change adapters around too much, testing and all
that.

Not to derail the topic, but I wonder if I'm the only one who sees
this?

Steve

Well, I think you have the right idea, but I have a different
analysis. What I see is the usual "assumption, mother of all
screwups". In this case, it's the assumptions made by the wireless
access point and the wireless client driver. Neither of these expects
the client to just disappear when it goes into hibernate. There's no
magic message such as:
Hey access point. I'm going away for a while.
Save my setup so I can easily reconnect.
Instead, what the access point sees is a client that just disappears.
It has no idea what happened. It doesn't know anything about the
clients desire to hibernate, standby, power save, or crash and hang.
So, it waits for a while, hangs on to the DHCP cache data for 24
hours, but eventually times out the connection.

Eventually, the client comes out of hibernate, standby, reboot, or
whatever and demands that everything be exactly the same before it
went comatose. It tries to continue the previous connection at all
layers from the applications layer (HTTP), to the IP layer (sequence
number), to the MAC layer (connection info). With all 7 layers trying
to continue as before, at least one of them is going to fail. Some
layers will continue pounding on the web server, gateway, access
point, etc. Some, not all, are going to fail.

How the client recovers from these multiple failures is what
determines how well it's going to recover. If the client declares a
disconnect and restarts the connection sequence, then there will be
several seconds delay while it goes through the connection setup. In
theory, that should be all that's necessary to reconnect, but again we
run into assumptions. What if some web service (web server, ftp
server, etc) doesn't quite time out, recognizes the client, and tries
to continue where it left off? The IP stack gets the same IP and
authentication info, but the packet sequence numbers are off. Same
with end to end SSH or VPN encryption packets, and a number of other
possible places for things to screw up. Instead of a new session, you
get a hang or an error message. Bummer.

What's roughly happening is that there's no common signal for a
disconnect between layers at both ends. There is usually a signal
going up the 7 layer stack. For example, if the MAC layer detects a
loss of carrier, it will inform the upwards adjacent IP layer that
there has been a disconnect and it will drop the connection. Upwards
and onwards to the application layer which will also get a disconnect
signal. In some cases, there are also signals going in the downward
direction. However, there is no universal disconnect message, that
propagates to all layers, and initiates a disconnect-reconnect
sequence, on power save, hibernate, or standby, on either the access
point or client. How the system handles such events is in the hands
of multiple vendors, on multiple layers, with multiple and different
assumptions.

Many protocols that were scribbled after the original 802.11 specs
include state tables to handle disconnects gracefully. They're not
simple and are designed to accommodate all known shutdown and restart
states. 802.11g has such a state table but only includes intentional
disconnects and reconnects. There's nothing there for a client or AP
just disappearing and coming back a day later after everything times
out. That leaves it up to the firmware writers and client driver
writers to implement. The compatibility mess with WDS and repeaters,
which are also badly specified, should give you some clue as to their
chances of success. To their credit, I would not have expected the
802.11 authors to have predicted the features required 10 years in
advance.

I hope this helps.

--
Jeff Liebermann jeffl@xxxxxxxxxx
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558
.

Relevant Pages

  • Re: Socket
    ... When you disconnect, TCP detects that the connection was broken. ... i used to sent pong to server when server pinged ... Now on client side when client recived ...
    (microsoft.public.dotnet.faqs)
  • Re: Socket
    ... When you disconnect, TCP detects that the connection was broken. ... i used to sent pong to server when server pinged ... Now on client side when client recived ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Socket
    ... When you disconnect, TCP detects that the connection was broken. ... i used to sent pong to server when server pinged ... Now on client side when client recived ...
    (microsoft.public.dotnet.general)
  • RE: keeping sql connection open
    ... for the duration and the .Net client apps which, as you say, generally take ... connection but also things like 'optimisistic locking' where you don't lock ... the data you fetch or modify on the client. ... With web based applications it makes sense to disconnect after each ...
    (microsoft.public.dotnet.general)
  • Re: OdbcDataReader - Problem closing connection
    ... I have returned a DataReader from my Database layer: ... I had originally thought this closed the underlying DB connection. ... Is there anyway to close the connection from the Client Layer, ... Client layer does not have access to Connection objects? ...
    (microsoft.public.dotnet.languages.csharp)