On 29 March 2017 at 19:03, Tim Harvey wrote:
> Greetings,
>
> (resending plaintext - oops)
>
> I'm seeing failures to authenticate with a WPA2 secured AP using ath9k
> based cards on wireless-next:
>
> root@xenial-armhf:~# wpa_passphrase testssid testpass >
> /etc/wpa_supplicant/wpa_supplicant.con
On 03/29/2017 12:47 PM, Hans de Goede wrote:
The rtl8723bs is found on quite a few systems used by Linux users,
such as on Atom systems (Intel Computestick and various other
Atom based devices) and on many (budget) ARM boards such as
the CHIP.
The plan moving forward with this is for the new cle
On Wed, Mar 29, 2017 at 06:21:08PM +0200, Johan Hovold wrote:
> This specifically fixes a NULL-pointer dereference when using the n_nci
> line discipline on one end of a Unix98 pty as well as resource leaks in
> the registration error paths.
I noticed I forgot to actually fix up the error paths, s
On 29-3-2017 22:15, Larry Finger wrote:
> On 03/29/2017 02:36 PM, Dennis New wrote:
>> global
>> country 00: DFS-UNSET
>> (2402 - 2472 @ 92), (N/A, 20), (N/A)
>> (2457 - 2482 @ 92), (N/A, 20), (N/A), PASSIVE-SCAN
>> (2474 - 2494 @ 20), (N/A, 20), (N/A), NO-OFDM, PASSIVE-SC
On 03/29/2017 02:36 PM, Dennis New wrote:
global
country 00: DFS-UNSET
(2402 - 2472 @ 92), (N/A, 20), (N/A)
(2457 - 2482 @ 92), (N/A, 20), (N/A), PASSIVE-SCAN
(2474 - 2494 @ 20), (N/A, 20), (N/A), NO-OFDM, PASSIVE-SCAN
(5170 - 5250 @ 160), (N/A, 20), (N/A), PASSIVE
Hi Poma and Christian,
I thank you so much - this mail is sent from my newly established
wireless connection - works like a charm!!!
Many many thanks to you!
Walter
2017-03-29 18:33 GMT+02:00 poma :
> On 29.03.2017 14:51, walter strametz wrote:
>> Hi - I try to get my D-Link N300 running and co
On Wed, 29 Mar 2017 13:49:06 +0200, Johannes Berg wrote:
> On Wed, 2017-03-29 at 06:28 -0400, Dennis New wrote:
> > On Wed, 29 Mar 2017 09:34:50 +0200, Johannes Berg wrote:
> > > On Fri, 2017-03-24 at 21:32 -0400, Dennis New wrote:
> > > > Ever since I upgraded to the 4.10 kernels (I don't think th
Op 29 mrt. 2017 13:51 schreef "Johannes Berg" mailto:johan...@sipsolutions.net>>:
>
> On Wed, 2017-03-29 at 06:28 -0400, Dennis New wrote:
> > On Wed, 29 Mar 2017 09:34:50 +0200, Johannes Berg wrote:
> > > On Fri, 2017-03-24 at 21:32 -0400, Dennis New wrote:
> > > > Ever since I upgraded to the 4.1
Hi All,
I forgot to add --compose so I could add the cover letter I had
already written, so here it goes:
Hi Greg, all,
I'm hereby submitting the rtl8723bs driver which
Bastien Nocera and Larry Finger have been maintaining at:
https://github.com/hadess/rtl8723bs
For inclusion into staging, li
On 03/29/2017 09:51 AM, Johannes Berg wrote:
The patch appeared to solve my problem, and it seems an improvement
over what is there currently. Whoever wants it to support even more
things can add that in the future?
Yes, that's kinda true. However, it also means that wmediumd (or
similar) wo
Greetings,
(resending plaintext - oops)
I'm seeing failures to authenticate with a WPA2 secured AP using ath9k
based cards on wireless-next:
root@xenial-armhf:~# wpa_passphrase testssid testpass >
/etc/wpa_supplicant/wpa_supplicant.conf
root@xenial-armhf:~# iw reg get
country US: DFS-FCC
> > > wiphy_debug(hw->wiphy,
> > > - "%s (freq=0 idle=%d ps=%d
> > > smps=%s)\n",
> > > + "%s (no-chandef-chan freq=0 idle=%d
> > > ps=%d smps=%s)\n",
> >
> > This seems unrelated?
>
> It can be cut out of the patch. Want me to re-send?
No obje
> The patch appeared to solve my problem, and it seems an improvement
> over what is there currently. Whoever wants it to support even more
> things can add that in the future?
Yes, that's kinda true. However, it also means that wmediumd (or
similar) would have to support the two APIs. It'd be s
On 29.03.2017 14:51, walter strametz wrote:
> Hi - I try to get my D-Link N300 running and compiled the sources on
> github (chunkeey - rtl8192su). Other trials also failed, because the
> driver-source is not compatible with the (newer) kernel.
>
> See more information in the enclosed textfile .
Hello,
On Wednesday, March 29, 2017 2:51:13 PM CEST walter strametz wrote:
> I try to get my D-Link N300 running and compiled the sources on
> github (chunkeey - rtl8192su). Other trials also failed, because the
> driver-source is not compatible with the (newer) kernel.
the 4.4.y kernel is too ol
This specifically fixes a NULL-pointer dereference when using the n_nci
line discipline on one end of a Unix98 pty as well as resource leaks in
the registration error paths.
Device-managed resources is a bad fit for this driver as devices can be
registered from the n_nci line discipline. Firstly,
Make sure to check the tty-device pointer before trying to access the
parent device to avoid dereferencing a NULL-pointer when the tty is one
end of a Unix98 pty.
Fixes: e097dc624f78 ("NFC: nfcmrvl: add UART driver")
Cc: stable # 4.2
Cc: Vincent Cuissard
Signed-off-by: Johan Hovold
---
dri
Commit 7eda8b8e9677 ("NFC: Use IDR library to assing NFC devices IDs")
moved device-id allocation and struct-device initialisation from
nfc_allocate_device() to nfc_register_device().
This broke just about every nfc-device-registration error path, which
continue to call nfc_free_device() that trie
This started out with the observation that the nfcmrvl_uart driver
unconditionally dereferenced the tty class device despite the fact that
not every tty has an associated struct device (Unix98 ptys). Some
further changes were needed in the common nfcmrvl code to fully address
this, some of which al
Use the USB-interface rather than parent USB-device device, which is
what this driver binds to, when registering the nci device.
Note that using the right device is important when dealing with device-
managed resources as the interface can be unbound independently of the
parent device.
Also note
Use the nfc- rather than phy-device in firmware-management code that
needs a valid struct device.
This specifically fixes a NULL-pointer dereference in
nfcmrvl_fw_dnld_init() during registration when the underlying tty is
one end of a Unix98 pty.
Note that the driver still uses the phy device for
Make sure to release the device-node reference when done parsing the
node.
Fixes: e097dc624f78 ("NFC: nfcmrvl: add UART driver")
Cc: Vincent Cuissard
Signed-off-by: Johan Hovold
---
drivers/nfc/nfcmrvl/uart.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/nfc/nfcmrvl/uart.c b/dr
The nci-device was never deregistered in the event that
fw-initialisation failed.
Fix this by moving the firmware initialisation before device
registration since the firmware work queue should be available before
registering.
Note that this depends on a recent fix that moved device-name
initialis
On 03/29/2017 01:46 AM, Johannes Berg wrote:
On Thu, 2017-03-23 at 16:26 -0700, gree...@candelatech.com wrote:
From: Ben Greear
This makes it easier to understand why wmediumd (or similar)
is getting errors when sending frames to the kernel.
Signed-off-by: Ben Greear
---
drivers/net/wireles
On 03/29/2017 01:42 AM, Johannes Berg wrote:
+ if (data->center_freq2)
+ if (nla_put_u32(skb, HWSIM_ATTR_CENTER_FREQ2, data-
center_freq2))
+ goto nla_put_failure;
That could be simplified (but isn't really interesting)
+ * @HWSIM_ATTR_CENTER_FRE
On 03/29/2017 05:20 AM, Hanno Zulla wrote:
Hi,
it was exciting to see
https://marc.info/?l=linux-wireless&m=148735587909056&w=2
So please forgive me for asking about the current state of things.
I cannot divulge any details at present, but there are plans to submit a staging
driver for the
Hi - I try to get my D-Link N300 running and compiled the sources on
github (chunkeey - rtl8192su). Other trials also failed, because the
driver-source is not compatible with the (newer) kernel.
See more information in the enclosed textfile .
Can you help me?
Thx, Walter
Hi - I try to get my D-
From: Johannes Berg
When internal mac80211 TXQs aren't supported, netdev queues must
always started out started even when driver queues are stopped
while the interface is added. This is necessary because with the
internal TXQ support netdev queues are never stopped and packet
scheduling/dropping
On Mittwoch, 29. März 2017 13:53:06 CEST Johannes Berg wrote:
[...]
> > Not sure whether removing it in ieee80211_propagate_queue_wake will
> > have other odd side effects with software queuing. Maybe Michal
> > Kazior can tell us if it is safe to remove it.
>
> No, it's the other way around.
>
>
Hi,
we investigate a possibility to enrich the ALM with information about a
possible delay caused by buffering in all nodes along a mesh path. This
could better reflect the idea of an real "airtime" of a new send frame.
Therefore I'm searching for a general way to get the number of
outstanding fra
> if (local->ops->wake_tx_queue)
> return;
>
> evaluates to true. The rest rest of the function is therefore always
> skipped for ath9k.
Ahh, yes, ok.
> Removing this is enough to fix the problem. And now you will propably
> say "hey, this is not my code". And this is the reas
On Wed, 2017-03-29 at 06:28 -0400, Dennis New wrote:
> On Wed, 29 Mar 2017 09:34:50 +0200, Johannes Berg wrote:
> > On Fri, 2017-03-24 at 21:32 -0400, Dennis New wrote:
> > > Ever since I upgraded to the 4.10 kernels (I don't think this
> > > behavior existed in the 4.8 series), after I startup my
On 03/22/2017 08:43 PM, Arend Van Spriel wrote:
On 21-3-2017 14:44, Rafał Miłecki wrote:
From: Rafał Miłecki
fwsignal is only used by bcdc. Create new protocol interface functions
for core code to perform proto specific (de)initialization. This makes
core agnostic to the protocol which will al
On 03/28/2017 12:43 PM, Arend van Spriel wrote:
From: Franky Lin
Move brcmf_fws_deinit into brcmf_proto_bcdc_detach since it is a bcdc
exclusive feature.
Signed-off-by: Franky Lin
Change-Id: Iefa5db632b92185a49d538b1cd25b7d8be618ce0
Reviewed-on: http://hnd-swgit.sj.broadcom.com:8080/8157
Revi
On 03/28/2017 12:43 PM, Arend van Spriel wrote:
From: Franky Lin
Create a new protocol layer interface brcmf_proto_init_cb for protocol
layer to finish initialzation after core module components(fweh and
etc.) are initialized.
Signed-off-by: Franky Lin
Change-Id: I560d2478a7c09766cf07b20d74b3
On 03/28/2017 12:43 PM, Arend van Spriel wrote:
This series intended for 4.12 includes:
- support for network namespace
- rework fwsignal module
- small fix for suspend error code path
Arend van Spriel (3):
brcmfmac: add support to move wiphy instance into network namespace
brcmfmac: restore
On Mittwoch, 29. März 2017 09:49:21 CEST Johannes Berg wrote:
> > But I could be completely wrong about it. It would therefore be
> > interesting for me to know who would be responsible to start the
> > queues when ieee80211_do_open rejected it for IBSS.
>
> Well, once ieee80211_offchannel_return(
On Mon, 2017-03-27 at 16:53 +0500, Artem S. Tashkinov wrote:
> Hi,
>
> New versions of iwlwifi require the firmware files which have never been
> released by Intel.
>
> Please fix this bummer.
>
> iwlwifi :02:00.0: Direct firmware load for iwlwifi-7265D-26.ucode
> failed with error -2
> iw
Hi Kalle,
Here are some fixes for 4.11. More details in the tag description.
I have sent this out before and kbuildbot didn't find any issues.
Cheers,
Luca.
The following changes since commit 6be3b6cce1e225f189b68b4e84fc711d19b4277b:
ath10k: fix incorrect wlan_mac_base in qca6174_regs (201
I would suggest the following modification of commit messages and
code. Let me know whether this is fine.
-
I would suggest the following edition to the commit message:
Instead of stopping path discovery when a path is established, continue the
attempts to find alternative paths until we
Hi,
it was exciting to see
https://marc.info/?l=linux-wireless&m=148735587909056&w=2
So please forgive me for asking about the current state of things.
Kind regards,
Hanno
On Wed, 29 Mar 2017 09:34:50 +0200, Johannes Berg wrote:
> On Fri, 2017-03-24 at 21:32 -0400, Dennis New wrote:
> > Ever since I upgraded to the 4.10 kernels (I don't think this
> > behavior existed in the 4.8 series), after I startup my laptop
> > (either from cold boot, or from standby), my wlan0
On Mon, 2017-03-06 at 15:54 +0200, Lazar, Alexei Avshalom wrote:
>
> The supported values are:
[...]
Regardless of the documentation, I think this is a bit fishy. Why
bother with this to start with?
We once had two patches (that we ultimately gave up on) doing something
similar but simply lettin
> > This code was designed for regulatory changes, but the WARN_ON()
> > indicates that we got connected on a channel that we think isn't
> > actually usable. We quite possibly should reject that connection
> > there, but it seems to me it should've been rejected elsewhere
> > already...?
>
> But
On Thu, 2017-03-23 at 16:26 -0700, gree...@candelatech.com wrote:
> From: Ben Greear
>
> Modify the receive-from-user-space logic to do length
> and 'is-down' checks before trying to allocate an skb.
>
> And, if we are going to ignore the pkt due to radio idle,
> then do not return an error code
On Thu, 2017-03-23 at 16:26 -0700, gree...@candelatech.com wrote:
> From: Ben Greear
>
> This makes it easier to understand why wmediumd (or similar)
> is getting errors when sending frames to the kernel.
>
> Signed-off-by: Ben Greear
> ---
> drivers/net/wireless/mac80211_hwsim.c | 55
> ++
On Thu, 2017-03-23 at 16:26 -0700, gree...@candelatech.com wrote:
> From: Ben Greear
>
> This message just fills up dmesg and/or kernel logs and does
> not provide any useful information.
>
Agree, applied.
johannes
> + if (data->center_freq2)
> + if (nla_put_u32(skb, HWSIM_ATTR_CENTER_FREQ2, data-
> >center_freq2))
> + goto nla_put_failure;
>
That could be simplified (but isn't really interesting)
> + * @HWSIM_ATTR_CENTER_FREQ2: Configured center-freq-2. Not reported
>
On Mon, 2017-03-27 at 05:53 +0900, Masashi Honma wrote:
> On 2017/03/17 14:59, Masashi Honma wrote:
> > Previously the meshcfg.rssi_threshold did not work with user_mpm=1.
> >
> > Signed-off-by: Masashi Honma
>
> Is there any comment ?
I just applied the other patch "drop new node"
johannes
> But we still needs this patch for a special case on SAE. Some
> hardware can use hardware encryption for mesh SAE. Then the hardware
> has a limitation of key registration. For example, some hardware
> could only save keys for 8 stations. So we need to drop stations
> itself with weak signal ins
What's the outcome of this? I'm tempted to apply the patch since it's
optional anyway ...
johannes
On 29-3-2017 9:46, Johannes Berg wrote:
>
19:23:29 kernel: wlan0: authenticate with 00:11:22:33:44:55
19:23:29 kernel: [ cut here ]
19:23:29 kernel: WARNING: CPU: 0 PID: 18925 at
net/mac80211/mlme.c:287 ieee80211_determine_chantype+0x12e/0x380
>>
>> 28
Hi Sven,
> But I could be completely wrong about it. It would therefore be
> interesting for me to know who would be responsible to start the
> queues when ieee80211_do_open rejected it for IBSS.
Well, once ieee80211_offchannel_return() is called, that should do the
needful and end up in ieee802
> > > 19:23:29 kernel: wlan0: authenticate with 00:11:22:33:44:55
> > > 19:23:29 kernel: [ cut here ]
> > > 19:23:29 kernel: WARNING: CPU: 0 PID: 18925 at
> > > net/mac80211/mlme.c:287 ieee80211_determine_chantype+0x12e/0x380
>
> 284 while (!cfg80211_chandef_usable(sdata
On 29-3-2017 9:34, Johannes Berg wrote:
> On Fri, 2017-03-24 at 21:32 -0400, Dennis New wrote:
>> Ever since I upgraded to the 4.10 kernels (I don't think this
>> behavior existed in the 4.8 series), after I startup my laptop
>> (either from cold boot, or from standby), my wlan0 interface keeps
>>
On Fri, 2017-03-24 at 21:32 -0400, Dennis New wrote:
> Ever since I upgraded to the 4.10 kernels (I don't think this
> behavior existed in the 4.8 series), after I startup my laptop
> (either from cold boot, or from standby), my wlan0 interface keeps
> deauthenticating
> ...
> 19:23:29 kernel: wla
On Tue, 2017-03-28 at 09:11 +0100, Arend van Spriel wrote:
> We got the following use-after-free KASAN report:
>
[...]
Applied.
johannes
57 matches
Mail list logo