Re: [PATCH 6/6] wl1251: Set generated MAC address back to NVS data

Pali Rohár writes: > In case there is no valid MAC address kernel generates random one. This > patch propagate this generated MAC address back to NVS data which will be > uploaded to wl1251 chip. So HW would have same MAC address as linux kernel > uses. > > Signed-off-by:

Re: [PATCH 5/6] wl1251: Parse and use MAC address from supplied NVS data

Pali Rohár writes: > This patch implements parsing MAC address from NVS data which are sent to > wl1251 chip. Calibration NVS data could contain valid MAC address and it > will be used instead randomly generated. > > This patch also move code for requesting NVS data from

rtl8187: No multicast

Hi folks, recently, a laptop featuring a rtl8187b usb wifi adapter, precisely, this one: Bus 001 Device 002: ID 0bda:8197 Realtek Semiconductor Corp. RTL8187B Wireless Adapter fell into my hands. I noticed that in my IPv6 enabled home network, the card would not receive any RAs and thus not

pull-request: iwlwifi-next 2017-01-26

Hi Kalle, Here's my first pull-request intended for v4.11. It has a bunch of fixes, cleanups and improvements here and there, as well as a few new features. More details in the tag description. I have sent this out before and kbuildbot didn't find any issues. Please let me know if there are

[PATCH] rtlwifi: rtl_usb: Fix for URB leaking when doing ifconfig up/down

From: Michael Schenk In the function rtl_usb_start we pre-allocate a certain number of urbs for RX path but they will not be freed when calling rtl_usb_stop. This results in leaking urbs when doing ifconfig up and down. Eventually, the system has no available

Re: [PATCH] wireless: define cipher/AKM suites using a macro

On Thu, 2017-01-26 at 17:20 +0100, Johannes Berg wrote: > From: Johannes Berg > > The spec writes cipher/AKM suites as something like 00-0F-AC:9, > but the part after the colon isn't hex, it's decimal, so that > we've already had a few mistakes (in other code, or

[PATCH] wireless: define cipher/AKM suites using a macro

From: Johannes Berg The spec writes cipher/AKM suites as something like 00-0F-AC:9, but the part after the colon isn't hex, it's decimal, so that we've already had a few mistakes (in other code, or unmerged patches) to e.g. write 0x000FAC10 instead of 0x000FAC0A. Use a

Re: IPv6-UDP 0x0000 checksum

On Thu, 2017-01-26 at 07:27 -0800, Eric Dumazet wrote: > > if (!uh->check && !udp_sk(sk)->no_check6_rx) { > udp6_csum_zero_error(skb); > goto csum_error; > } Yeah, I'd found no_check6_rx already, was still trying

Re: IPv6-UDP 0x0000 checksum

On Thu, 2017-01-26 at 07:24 -0800, Eric Dumazet wrote: > On Thu, 2017-01-26 at 15:49 +0100, Johannes Berg wrote: > > > Unfortunately, I haven't been able to actually test this yet. I > > also > > didn't find the code that would drop frames with CSUM 0 either, so > > I'm > > thinking - for now -

Re: IPv6-UDP 0x0000 checksum

On Thu, 2017-01-26 at 07:24 -0800, Eric Dumazet wrote: > On Thu, 2017-01-26 at 15:49 +0100, Johannes Berg wrote: > > > Unfortunately, I haven't been able to actually test this yet. I also > > didn't find the code that would drop frames with CSUM 0 either, so I'm > > thinking - for now - that if

Re: IPv6-UDP 0x0000 checksum

On Thu, 2017-01-26 at 15:49 +0100, Johannes Berg wrote: > Unfortunately, I haven't been able to actually test this yet. I also > didn't find the code that would drop frames with CSUM 0 either, so I'm > thinking - for now - that if all the csum handling is skipped, dropping > 0 csum frames would

[PATCH] wlcore: print the sdio buffer after reading it

fix an issue where we printed the sdio buffer before actually read it. Signed-off-by: Guy Mishol --- drivers/net/wireless/ti/wlcore/sdio.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/net/wireless/ti/wlcore/sdio.c

Re: IPv6-UDP 0x0000 checksum

On Thu, 2017-01-26 at 06:45 -0800, Eric Dumazet wrote: > On Thu, 2017-01-26 at 14:49 +0100, Johannes Berg wrote: > > > Oops, sorry - receive. We can only indicate "CHECKSUM_UNNECESSARY", > > nothing more advanced right now, but right now we'd indicate that > > if > > the packet had 0x in the

Re: IPv6-UDP 0x0000 checksum

On Thu, 2017-01-26 at 14:49 +0100, Johannes Berg wrote: > Oops, sorry - receive. We can only indicate "CHECKSUM_UNNECESSARY", > nothing more advanced right now, but right now we'd indicate that if > the packet had 0x in the checksum field, but should've had 0x. > > On TX I believe we

Re: IPv6-UDP 0x0000 checksum

On Thu, 2017-01-26 at 05:44 -0800, Eric Dumazet wrote: > On Thu, 2017-01-26 at 14:27 +0100, Johannes Berg wrote: > > Hi, > > > > It looks like right now we may have a hardware bug and accept > > 0x as > > valid, when the outcome of the calculation is 0x. > > > > What do you think we

Re: IPv6-UDP 0x0000 checksum

On Thu, 2017-01-26 at 14:27 +0100, Johannes Berg wrote: > Hi, > > It looks like right now we may have a hardware bug and accept 0x as > valid, when the outcome of the calculation is 0x. > > What do you think we should do about this? > > We could ignore the issue entirely, since 0 wasn't

IPv6-UDP 0x0000 checksum

Hi, It looks like right now we may have a hardware bug and accept 0x as valid, when the outcome of the calculation is 0x. What do you think we should do about this? We could ignore the issue entirely, since 0 wasn't ever supposed to be sent anyway - but then we don't drop frames that we

Re: [PATCH 3/4] ath9k: check for deaf rx path state

Hi Felix, On Thursday, January 26, 2017 11:26:03 AM CET Felix Fietkau wrote: > On 2017-01-26 11:15, Simon Wunderlich wrote: > > Hey, > > > > On Thursday, January 26, 2017 11:02:53 AM CET Felix Fietkau wrote: > >> On 2017-01-26 10:50, Simon Wunderlich wrote: > >> > Hey Felix, > >> > > >> > On

Re: [PATCH 3/4] ath9k: check for deaf rx path state

On 2017-01-26 11:15, Simon Wunderlich wrote: > Hey, > > On Thursday, January 26, 2017 11:02:53 AM CET Felix Fietkau wrote: >> On 2017-01-26 10:50, Simon Wunderlich wrote: >> > Hey Felix, >> > >> > On Wednesday, January 25, 2017 5:36:53 PM CET Felix Fietkau wrote: >> >> Various chips occasionally

Re: [PATCH 3/4] ath9k: check for deaf rx path state

Hey, On Thursday, January 26, 2017 11:02:53 AM CET Felix Fietkau wrote: > On 2017-01-26 10:50, Simon Wunderlich wrote: > > Hey Felix, > > > > On Wednesday, January 25, 2017 5:36:53 PM CET Felix Fietkau wrote: > >> Various chips occasionally run into a state where the tx path still > >> appears

Re: [PATCH 3/4] ath9k: check for deaf rx path state

On 2017-01-26 10:50, Simon Wunderlich wrote: > Hey Felix, > > > On Wednesday, January 25, 2017 5:36:53 PM CET Felix Fietkau wrote: >> Various chips occasionally run into a state where the tx path still >> appears to be working normally, but the rx path is deaf. >> >> There is no known register

Re: [PATCH 3/4] ath9k: check for deaf rx path state

Hey Felix, On Wednesday, January 25, 2017 5:36:53 PM CET Felix Fietkau wrote: > Various chips occasionally run into a state where the tx path still > appears to be working normally, but the rx path is deaf. > > There is no known register signature to check for this state explicitly, > so use

Re: [RFC 3/3] cfg80211: Share Channel DFS state across wiphys of same DFS domain

On Wed, 2017-01-25 at 17:01 +0530, Vasanthakumar Thiagarajan wrote: > Sharing DFS channel state across multiple wiphys (radios) could > be useful with multiple radios on the system. When one radio > completes CAC and marks the channel available another radio > can use this information and start

Re: [RFC 2/3] cfg80211: Disallow moving out of operating DFS channel in non-ETSI

> +static bool cfg80211_off_channel_oper_allowed(struct wireless_dev > *wdev) > +{ > + if (!cfg80211_beaconing_iface_active(wdev)) > + return true; > + > + if (!(wdev->chandef.chan->flags & IEEE80211_CHAN_RADAR)) > + return true; That could use some locking

Re: [RFC 1/3] cfg80211: Make pre-CAC results valid only for ETSI domain

> + /* Should we apply the grace period during beaconing > interface > +  * shutdown also? > +  */ > + cfg80211_sched_dfs_chan_update(rdev); It might make some sense, say if hostapd crashes and you restart it automatically or something? >  

Re: [PATCH 1/2] mac80211: use helper function to access ieee802_1d_to_ac[]

On Tue, 2017-01-24 at 16:42 +0100, Amadeusz Sławiński wrote: > cleanup patch to make use of ieee80211_ac_from_tid() to retrieve ac > from > ieee802_1d_to_ac[] Applied. johannes