Re: Re: [PATCH] ccache: don't use non-ASCII quotes

The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- > I would rather prefer to disable

Re: FRAG Attacks (new vuln for wifi)

On 2021-05-13 01:45, Nick Lowe wrote: >> > Regarding ath10k-ct, what kernel-versions of the ath10k-ct driver need to >> > be patched? >> > Is 4.19 the oldest that owrt will consume? >> I think so. 4.19 is used by OpenWrt 19.07 and I don't think we'll update >> anything older than that. > > So,

Re: FRAG Attacks (new vuln for wifi)

> > Regarding ath10k-ct, what kernel-versions of the ath10k-ct driver need to > > be patched? > > Is 4.19 the oldest that owrt will consume? > I think so. 4.19 is used by OpenWrt 19.07 and I don't think we'll update > anything older than that. So, to summarise, the 4.19, 5.4 and 5.10 branch kerne

[PATCH] openwrt-keyring: Only copy sign key for snapshots

Instead of adding all public signature keys from the openwrt-keyring repository only add the key which is used to sign the master feeds. If one of the other keys would be compromised this would not affect users of master snapshot builds. Signed-off-by: Hauke Mehrtens --- As far as I know the ot

[PATCH DRAFT RFC] upoe: tiny daemon for PoE devices

From: Rafał Miłecki This is a tiny app that reads list of PoE devices and initializes them using built-in drivers. PoE status can be read using ubus. Signed-off-by: Rafał Miłecki --- This is a *** DRAFT *** for how we could handle PoE devices in OpenWrt. Please feel free to comment if this EARL

Re: [PATCH] realtek-poe: add support for PoE on Realtek switches

On 11.05.2021 19:54, John Crispin wrote: On 11.05.21 19:51, Rafał Miłecki wrote: On 11.05.2021 19:46, John Crispin wrote: On 11.05.21 19:45, Rafał Miłecki wrote: I'm really tired of dealing with such hacky solutions. Look at netifd, DSA and LuCI as example. We ended up with something that noon

Re: [PATCH netifd] config: support bridge designed UCI section

On Tue, May 11, 2021 at 7:14 PM Rafał Miłecki wrote: > > From: Rafał Miłecki > > Network layer 2 devices should have their own UCI section types. They > differ so much that each device type requires a custom handling anyway. > Currently there is "type" option used to distinguish them while UCI >

Re: FRAG Attacks (new vuln for wifi)

On 2021-05-12 19:13, Ben Greear wrote: > On 5/12/21 9:00 AM, Felix Fietkau wrote: >> >> Hi, >> >> On 2021-05-12 01:34, Paul D wrote: >>> https://www.fragattacks.com/ >>> >>> https://lore.kernel.org/linux-wireless/20210511180259.159598-1-johan...@sipsolutions.net/ >> I've merged those fixes in o

Re: FRAG Attacks (new vuln for wifi)

On 5/12/21 9:00 AM, Felix Fietkau wrote: Hi, On 2021-05-12 01:34, Paul D wrote: https://www.fragattacks.com/ https://lore.kernel.org/linux-wireless/20210511180259.159598-1-johan...@sipsolutions.net/ I've merged those fixes in openwrt commit 025bd93f36c9. After some testing in master, we shou

Re: FRAG Attacks (new vuln for wifi)

Hi, On 2021-05-12 01:34, Paul D wrote: > https://www.fragattacks.com/ > > https://lore.kernel.org/linux-wireless/20210511180259.159598-1-johan...@sipsolutions.net/ I've merged those fixes in openwrt commit 025bd93f36c9. After some testing in master, we should backport them soon. ath10k-ct will

Re: [PATCH 0/4] RFC: ath79: add support for Mikrotik RB91xG

On 12.05.21 15:09, Bjørn Mork wrote: Koen Vandeputte writes: Hi Bjørn I can confirm the slot can also handle pcie signaling. Got a rb912 board laying on my desk this very moment running an extra ath9k pcie card :-)  (openwrt 19.07) Thanks. Good to be wrong :-) The slot is also advertised

Re: [PATCH 0/4] RFC: ath79: add support for Mikrotik RB91xG

Koen Vandeputte writes: > Hi Bjørn > > I can confirm the slot can also handle pcie signaling. > Got a rb912 board laying on my desk this very moment running an extra > ath9k pcie card :-)  (openwrt 19.07) Thanks. Good to be wrong :-) > The slot is also advertised by MikroTik that it can do that

Re: [PATCH 0/4] RFC: ath79: add support for Mikrotik RB91xG

On 12.05.21 14:47, Bjørn Mork wrote: Koen Vandeputte writes: I've fixed most of the open stuff, with the exception of using a PCIe device in the slot. (checking currently what is wrong there) Are you sure that's supported? This is a slot intended only for LTE modems, isn't it? Looking at t

Re: [PATCH 0/4] RFC: ath79: add support for Mikrotik RB91xG

Koen Vandeputte writes: > I've fixed most of the open stuff, with the exception of using a PCIe > device in the slot. (checking currently what is wrong there) Are you sure that's supported? This is a slot intended only for LTE modems, isn't it? Looking at the picture at https://i.mt.lv/cdn/rb_

ZTE ZXV10-H201L

Hey guys, Im trying to put OpenWrt on my ZTE ZXV10-H201L and after flashing image without vmmc driver device boot's but without WiFi Here is little log trying to reset WiFi root@OpenWrt :/sys/devices/platform/1000.fpi/1e100b10.pinmux/gpiochip0/gpio/wifi# echo 0 > val

Re: [PATCH 0/4] RFC: ath79: add support for Mikrotik RB91xG

Hi Denis, I have high interest in this target device and wanted to provide some assistance if that's ok with you. I've fixed most of the open stuff, with the exception of using a PCIe device in the slot. (checking currently what is wrong there) Changes: - dts cleanup - Enabled USB - Added req

Re: [PATCH] realtek-poe: add support for PoE on Realtek switches

John Crispin [2021-05-11 19:43:09]: > that being said, I have a edgerouter-x(-sfp) on my desk. I already started a > PoC patch to support a more generic approach for PoE that is agnostic of > wheter the HW support is driven via GPIO or a ttyS attached MCU. Then you should consider renaming it to

Re: [PATCH] realtek-poe: add support for PoE on Realtek switches

John Crispin [2021-05-11 17:22:43]: Hi, > package/network/config/realtek-poe/src/main.c | 844 ++ I would prefer to have this as out of tree project, so we could add CI pipeline to it for improved QA. > +struct port_config { > + char name[16]; It would be nice to get rid o