Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 19 Mar 2006 15:20:52 -0800
From:      Sam Leffler <sam@errno.com>
To:        Darren Pilgrim <darren.pilgrim@bitfreak.org>
Cc:        Max Laier <max@love2party.net>, freebsd-net@freebsd.org
Subject:   Re: New version of iwi(4) - Call for testers
Message-ID:  <441DE754.6020004@errno.com>
In-Reply-To: <441DE5B2.1060202@bitfreak.org>
References:  <E1FL08E-000NLu-00._pppp-mail-ru@f63.mail.ru>	<200603191738.19442.max@love2party.net> <441DE5B2.1060202@bitfreak.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Darren Pilgrim wrote:
> Max Laier wrote:
>> On Sunday 19 March 2006 16:47, dima wrote:
>>>>
>>>> the new version at:
>>>> http://people.freebsd.org/~mlaier/new_iwi/20060315.both.tgz
>  >>
>>> The new driver didn't pass cvsup test at my laptop :(
>>> It fails large file upload either.
>>>
>>> It's definitely a flow control problem. Is taskqueue designed to address
>>> this?
>>
>> We found that this problem is completely unrelated to iwi, but a 
>> general problem with software encryption in net80211.  This should be 
>> fixed with ieee80211_output.c rev. 1.40 and will be MFCed shortly.  
>> Note that this uses m_unshare, which also is not yet in RELENG_6.
> 
> Are you referring to the problem in cvsup tests where it will suddenly 
> stop with a "Network write failure" error?

Yes.  The issue was that when crypto was done in the host it was 
sometimes being done in-place on mbufs still owned by the socket 
(exactly when depended on a lot of things but turning down the mtu 
increased the likelihood).  If this happened and tcp retransmitted the 
previously encrypted data then it would send garbage.

As Max said this was in the net80211 layer and affected all drivers 
depending on the host to do crypto.  It'll get mfc'd this week (re 
permitting).

	Sam




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?441DE754.6020004>