On Tue, Jan 15, 2019 at 11:40:28AM +0200, Lauri Tirkkonen wrote:
> On Tue, Jan 15 2019 10:30:47 +0100, Stefan Sperling wrote:
> > Turns out we need to allow "no data" frames to pass a bit further into
> > ieee80211_input() because they carry sequence numbers and because they
> > are used to toggle
On Tue, Jan 15 2019 10:30:47 +0100, Stefan Sperling wrote:
> Turns out we need to allow "no data" frames to pass a bit further into
> ieee80211_input() because they carry sequence numbers and because they
> are used to toggle power-saving state via IEEE80211_FC1_PWR_MGT in the
> frame header.
>
>
On Tue, Jan 15, 2019 at 12:50:33AM +0200, Lauri Tirkkonen wrote:
> On Mon, Jan 14 2019 16:41:13 +0200, Lauri Tirkkonen wrote:
> > > Indeed, my diff was bad as well. Thanks for spotting these issues.
> > > I hadn't run this diff yet cause I was still building a new snapshot
> > > to test it. Could
On Mon, Jan 14 2019 16:41:13 +0200, Lauri Tirkkonen wrote:
> > Indeed, my diff was bad as well. Thanks for spotting these issues.
> > I hadn't run this diff yet cause I was still building a new snapshot
> > to test it. Could you also test this new version please?
>
> I'm not currently physically
On Mon, Jan 14 2019 15:34:22 +0100, Stefan Sperling wrote:
> > why doesn't SUBTYPE_CF_ACK_CF_POLL have NODATA in the name? it has the
> > NODATA bit set (ie. & 0x40), and "QoS CF-Ack + CF_Poll (no data)" is
> > explicitly listed in 9.2.4.1.9.
>
> Yes, that was a mistake. See this follow-up patch:
On Mon, Jan 14, 2019 at 04:10:36PM +0200, Lauri Tirkkonen wrote:
> On Mon, Jan 14 2019 14:23:44 +0100, Stefan Sperling wrote:
> > Thank you for tracking this problem down.
> >
> > Your diff is not correct. This part introduces a memory leak because
> > the mbuf is not going to be freed anymore:
>
On Mon, Jan 14 2019 14:23:44 +0100, Stefan Sperling wrote:
> Thank you for tracking this problem down.
>
> Your diff is not correct. This part introduces a memory leak because
> the mbuf is not going to be freed anymore:
>
> > @@ -411,6 +412,12 @@ ieee80211_input(struct ifnet *ifp, struct mbuf
On Mon, Jan 14, 2019 at 02:23:44PM +0100, Stefan Sperling wrote:
> I'd like to propose a more general solution:
>
> The diff below improves naming of so far unused frame subtype constants
> and makes it more obvious which subtypes do not carry data, it attributes
> "no data" frames to a more
On Sun, Jan 13, 2019 at 11:50:35PM +0200, Lauri Tirkkonen wrote:
> Hi, (disclaimer: I know basically nothing about 802.11)
>
> I noticed on my AP a high counter on netstat -W "input unencrypted
> packets with wep/wpa config discarded", aka is_rx_unencrypted. After
> investigation it looked like
Hi, (disclaimer: I know basically nothing about 802.11)
I noticed on my AP a high counter on netstat -W "input unencrypted
packets with wep/wpa config discarded", aka is_rx_unencrypted. After
investigation it looked like all of these were frames with type Data,
but with the "No data" bit set in
10 matches
Mail list logo
