From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 138B6CA9EAE for ; Tue, 29 Oct 2019 10:57:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E6C592086D for ; Tue, 29 Oct 2019 10:57:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731149AbfJ2K5a (ORCPT ); Tue, 29 Oct 2019 06:57:30 -0400 Received: from s3.sipsolutions.net ([144.76.43.62]:33916 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726175AbfJ2K5a (ORCPT ); Tue, 29 Oct 2019 06:57:30 -0400 Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.92.2) (envelope-from ) id 1iPPBm-00079g-HF; Tue, 29 Oct 2019 11:57:26 +0100 Message-ID: <9086eeae04476adbd957b8d4df0e1a3ba0e7af93.camel@sipsolutions.net> Subject: Re: [PATCH v2] 802.11n IBSS: wlan0 stops receiving packets due to aggregation after sender reboot From: Johannes Berg To: Krzysztof =?UTF-8?Q?Ha=C5=82asa?= Cc: "David S. Miller" , linux-wireless@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Date: Tue, 29 Oct 2019 11:57:24 +0100 In-Reply-To: References: <4725dcbd6297c74bf949671e7ad48eeeb0ceb0d0.camel@sipsolutions.net> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Tue, 2019-10-29 at 11:51 +0100, Krzysztof Hałasa wrote: > Johannes Berg writes: > > > > The problem I can see is that the dialog_tokens are 8-bit, way too small > > > to eliminate conflicts. > > > > Well, they're also per station, we could just randomize the start and > > then we'd delete the old session and start a new one, on the receiver. > > > > So that would improve robustness somewhat (down to a 1/256 chance to hit > > this problem). > > That was what I meant. Still, 1/256 seems hardly acceptable to me - > unless there is some work around (a short timeout or something similar). > Remember that when it doesn't work, it doesn't work - it won't recover > until the sequence catches up, which may mean basically forever. Agree, it just helps in "most" cases to do this. Perhaps we shouldn't do this then so that we find the problem more easily... > Or, maybe the remote station can request de-aggregation first, so the > subsequent aggregation request is always treated as new? > Alternatively, perhaps the remote can signal that it's a new request and > not merely an existing session? I think we should just implement authentication and reset of the station properly, instead of fudging around with aggregation. This is just one possible problematic scenario ... what if the station was reconfigured with a different number of antennas in the meantime, for example, or whatnot. There's a lot of state we keep for each station. > > That's the situation though - the local station needs to know that it > > has in fact *not* seen the same instance of the station, but that the > > station has reset and needs to be removed & re-added. > > Precisely. And it seems to me that the first time the local station > learns of this is when a new, regular, non-aggregated packet arrives. > Or, when a new aggregation request arrives. Well, it should learn about the station when there's a beacon from it, or if not ... we have a patch to force a probe request/response cycle so we have all the capabilities properly. We should upstream that patch, but need to do something to avoid being able to use this for traffic amplification attacks. johannes