On Thu, May 22, 2008 at 5:36 PM, Philip A. Culver
<pculver@bostonatlantic.net> wrote:
quoted text
> the AP but it still kills the connection and file transfer.  On the remote
> side of the file push, scp would respond "Received disconnect from
> 192.168.2.253: 2: Corrupted MAC on input." The dmesg trace is as follows:

Well, I tried replicating this today.  I definitely get stalls when
pushing a lot of data, and a fair number of dropped packets.  However
with the latest code I do not get disconnects from the AP -- even
while a scp connection is stalled I can browse the net more or less
successfully.  I didn't see the 'Corrupted MAC' error but I'm not sure
I have ssh logging that to syslog.

It would be interesting to trace the packets to see whether the source
MAC is wrong on the local side.

quoted text
> [ 2289.719217] KERNEL: assertion (flags & MSG_PEEK) failed at net/ipv4/tcp.c
> (1201)
> [ 2289.720613] recvmsg bug: copied D6E83810 seq D6E83DB8

Strange, we have a packet in the receive queue whose sequence number
is higher than the current high-water mark?  I don't know the network
stack well enough to know why.  Maybe something is stomping on that
skb.

-- 
Bob Copeland %% www.bobcopeland.com
_______________________________________________
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel