Re: Wireless TCP aborts

Luigi Rizzo wrote:
> On Sun, Mar 07, 2010 at 03:08:38PM -0800, Chuck Swiger wrote:
>> Hi, Tim--
>>
>> On Mar 7, 2010, at 2:16 PM, Tim Kientzle wrote:
>> [ ... ]
>>>  Corrupted MAC on input.
>>>  Disconnecting: Packet corrupt
>>>  rsync: connection unexpectedly closed ... [receiver]
>>>
>>> and then the rsync session is dead.
>>>
>> It's not TCP ... SSH adds it's own layer of data integrity checking ...
>>
> 
> long ago, with the 'iwi' driver, there was the following problem
> leading the the sae problem you are seeing:
> 
> the driver was doing WEP in software, and wrote back the result to
> the original mbuf (actually, cluster). As a result, the first
> transmission of a segment was correct, but in case a rxmt, data
> would be encrypted twice, and the remote ssh end detected the garbage
> and dropped the connection. This was fixed with Sam's help
> around early 2007 if i remember well.
> 
> An easy way to see if it is a similar problem is use ipfw to drop
> some packets e.g.
> 	ipfw add 100 prob 0.1 deny tcp out xmit wi0 // use your interface name

I'll do some experimenting.   Here are some
more details on the current setup in case
this rings any bells for anyone:

   * Sender:  FreeBSD 8-CURRENT r193146, bge driver

bge0: <Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x6001> 
mem 0xe0800000-0xe080ffff irq 17 at device 0.0 on pci63

   * Router:  D-Link 655

   * Receiver:  FreeBSD 9-CURRENT r201154, ath driver

ath0: <Atheros 5424/2424> mem 0x55200000-0x5520ffff irq 18 at device 0.0 
on pci3
ath0: AR2425 mac 14.2 RF5424 phy 7.0

The wireless side is using WPA2-PSK.  Tonight
I'll try hooking up a wired connection to the
receiver and see if that changes anything.

Tim