[OpenWrt-Devel] [PATCH] ramips: set read-only flag to u-boot partition on Xiaomi MiWiFi Mini

Current device profile allows overwriting u-boot partition, setting read-only flag will prevent mtd device unlock and thus accidental partition overwrite. Signed-off-by: Tomislav Požega --- Same fix is required in CC branch. PATCH diff -purN

[OpenWrt-Devel] [PATCH] packages: fix airmon-ng output in multi bssid mode

Create a patch that removes the output of unnecessary interface informations which occur if the radio broadcasts more than one ssid to speed up the operation and provide clean output. Also removes scanProcesses function to get rid of the busybox output garbage. Signed-off-by: Tomislav Požega

[OpenWrt-Devel] [PATCH] ar71xx: fix device names in GL-AR150 and GL-AR300 profiles

Fix names displayed in the main Luci page for GL-AR150 and GL-AR300 devices. Signed-off-by: Tomislav Požega --- Patch diff -pur a/target/linux/ar71xx/base-files/lib/ar71xx.sh b/target/linux/ar71xx/base-files/lib/ar71xx.sh ---

[OpenWrt-Devel] [PATCH] oldpackages: fix mdk3 build issue

Create a patch that fixes an issue with mdk3 package that would break build process with -Werror=format-security message. Closes ticket https://dev.openwrt.org/ticket/20698 Signed-off-by: Tomislav Požega --- Patch diff -purN

Re: [OpenWrt-Devel] [RFD] Future

Looks like a common problem is when devs get paid well, they are coming up with more and more problems, ideas to solve these and waste too much time on unnecessary things. If you only used the time invested in organizing of all these meet-ups to commit all the patches sent to mailing list that

Re: [OpenWrt-Devel] [OpenWrt-Tickets] [OpenWrt] #20685: Weak Wi-Fi signal E1700 (MT7620A)

Hi Can anyone get a reference driver for MT7612E ? On 7 February 2017 at 14:22, Qier LU wrote: > Hi Daniel, > > Thank you for your support! > > Here is Xiaomi mini using LEDE r2244 > > root@lede:~# cat /proc/cpuinfo > system type: MediaTek MT7620A ver:2 eco:6 >

Re: [OpenWrt-Devel] ATH10K VLAN firmware issue

have you tried this one https://forum.lede-project.org/t/new-qca988x-firmware-with-mesh-support/1587 On 21 February 2017 at 14:19, Valo, Kalle wrote: > voncken writes: > > > Do you know if the firmware team planned to fix the VLAN issue on

[OpenWrt-Devel] RT3070 low performance in latest trunk

Hi Tried my RT3070 usb adapter with last available trunk and throughput was very bad, so I looked at txpower to see it was about 15dB less than with stable build. Looks like kernel upgrade broke rt2800usb support for this chipset as with same compat-wireless version it worked fine on kernel

[OpenWrt-Devel] hostapd: Default disable b rates, add legacy_rates

Hi After found out about commit https://git.lede-project.org/?p=lede/nbd/staging.git;a=commit;h=5b42521a9ecbd311920e8fde98bbbf8d70eba5a0 i've read the presentation provided in the link and noticed this enables require_mode g by default. Can you be sure this really disables DSSS/CCK ? I've been

Re: [OpenWrt-Devel] hostapd: Default disable b rates, add legacy_rates

I've not tested airtime efficiency cause i doubt several clients would be enough for detailed test. I've only enabled this for two reasons: mt7620 wireless signal seemed more stable at g only rates and i got sick of seeing b rates in wifi status page that remind of stupid brodacom/realtek

Re: [OpenWrt-Devel] Fix ftp.kernel.org for chaos_calmer branch

re more than welcome to stop trolling. > > Regards, > Zoltan H > > Tom Psyborg wrote: > >> looks like you have to fucking beg before someone commits your opened PR >> >> On 8 March 2017 at 15:13, Nemesis <neme...@ninux.org > neme...@ninux.org>&

[OpenWrt-Devel] [OpenWrt-Users] Compile OpenWRT with channels from 2.3 GHz - 2.7 GHz to Ubiquiti (ar71xx)

Hi Use these patches http://pastebin.com/EqkwFU4h http://pastebin.com/keXddXAn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Fix ftp.kernel.org for chaos_calmer branch

looks like you have to fucking beg before someone commits your opened PR On 8 March 2017 at 15:13, Nemesis wrote: > There's a fix for a very annoying issue that is breaking builds for > chaos calmer, it just needs to be merged: > https://github.com/openwrt/openwrt/pull/413 >

Re: [OpenWrt-Devel] Custom build with reghack on trunk or any branch

you are probably using outdated patch On 20 July 2017 at 21:21, Jenny Cabrera Varona wrote: > this is the info on my device right now, after some changes trying to get > works with 2312-2732MHz > > # iw reg get > country 00: DFS-UNSET > (2302 - 2732 @ 40),

Re: [OpenWrt-Devel] openwrt and lede - remerge proposal V3

On 29 May 2017 at 08:56, John Crispin wrote: > Hi, > > here is a V3 of the remerge proposal, I tried to fold all the comments > people made into it, if anything is missing let me know. > > *) trac > - trac is already readonly, keep content so that search engines can still >

Re: [OpenWrt-Devel] openwrt and lede - remerge proposal V3

> Compared to Flyspray, Trac is a nightmare to administer. It leaks > resources like a sieve and tends to slow down to a crawl under load. > > Regards, > Jo > > Could you be more specific? I don't see how can it leak resources. About slow down, have you ever chekced the server it is hosted on, or

Re: [OpenWrt-Devel] [PATCH 2/2 v2] clk: Add Gemini SoC clock controller

Is it ever going to be added so this endless spam can end? On 8 May 2017 at 22:12, Linus Walleij wrote: > The Cortina Systems Gemini (SL3516/CS3516) has an on-chip clock > controller that derive all clocks from a single crystal, using some > documented and some

Re: [OpenWrt-Devel] [PATCH 1/2 v2] reset: Add DT bindings for the Gemini reset controller

Is it ever going to be added so this endless spam can end? On 8 May 2017 at 22:07, Linus Walleij wrote: > This is a simple reset controller in a single 32bit > register. > > Signed-off-by: Linus Walleij > --- > ChangeLog v1->v2: > - Move the

Re: [OpenWrt-Devel] [PATCH 1/2 v2] clk: Add bindings for the Gemini Clock Controller

Is it ever going to be added so this endless spam can end? On 8 May 2017 at 22:11, Linus Walleij wrote: > This adds device tree bindings and a header for the Gemini SoC > Clock Controller. > > Signed-off-by: Linus Walleij > --- > ChangeLog

Re: [OpenWrt-Devel] [PATCH 2/4] ata: Add DT bindings for the Gemini SATA bridge

Is it ever going to be added so this endless spam can end? On 8 May 2017 at 22:33, Linus Walleij wrote: > On Mon, May 8, 2017 at 12:49 PM, Bartlomiej Zolnierkiewicz > wrote: > > On Saturday, May 06, 2017 02:10:51 PM Linus Walleij wrote: > >

Re: [OpenWrt-Devel] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue...?

god damn it guys, i need new hardware and aliexpress won't just send me one by mistake :P https://forum.lede-project.org/t/archer-c50-2-4ghz-wifi-not-stable/575/6 On 30/05/2018, Daniel Golle wrote: > Hi! > > On Mon, May 28, 2018 at 03:54:33PM +0200, Daniel Golle wrote: >> Hi! >> >> On Mon, May

Re: [OpenWrt-Devel] [PATCH] ar71xx: disable devicetree support

and leave it disabled. whos idea it was anyway to convert ar71xx to DTS? unnecesary complications from my POV On 11 January 2018 at 00:52, Matthias Schiffer < mschif...@universe-factory.net> wrote: > While we'd like to convert ar71xx to DT-based configuration > eventually, we aren't quite there

Re: [OpenWrt-Devel] ar71xx with kernel 4.14 - a few test results

OK, which AP and client devices you used while doing that test? On 23 August 2018 at 16:08, Dirk Brenken wrote: > > Hi Tom, > > I haven't run any special/formal speed tests, just one speedtest.net > measurement with "usual" 209 Mbps Download and 9.9 Mbps Upload > (Unitymedia cable connect) via

Re: [OpenWrt-Devel] [PATCH v3 0/4] base-files: add new backup options

Unrelated to upgrade. I have dnsmasq and ntpd script disabled, i make a backup, then reset my device to defaults or flash some other image without keeping settings. After flashing back image version from which the backup was made and restoring backup, dnsmasq and ntpd are enabled again. So these

Re: [OpenWrt-Devel] [PATCH] add Support For Anonabox

Hi correction: QCA9531 is HoneyBee not Dragonfly On 19/08/2018, ɹɐɯɹǝפ ʇsnƃn∀ wrote: > This commit adds support for the Anonabox Pro WiFi-router. > > SoC: Qualcomm Atheros QCA9531 (Dragonfly) 650MHz > RAM: 128mb > FLASH: 16mb > WiFi: QCA9531 b/g/n > USB: 1x USB 2.0 > > Tested and

Re: [OpenWrt-Devel] RFT: ar71xx/mac80211 update

Why dropping 4.9 support right away?!? I've already tried 4.14 without mac80211 update and got approximately 20Mbps less throughput on wifi than with 4.9. If the 4.18 mac80211 update doesn't bring in some of the peformance lost, I wouldn't even consider 4.14 kernel as a baseline for anything. On

Re: [OpenWrt-Devel] We want to know how to modify Makefile

Hi Browse for openvswitch in git tree history (https://git.openwrt.org/?p=feed/packages.git;a=tree;f=net/openvswitch;hb=refs/heads/openwrt-18.06) and look for changeset of v2.3.1. then simply copy package folder including files, makefile and patches of your desired version to your local buildroot

Re: [OpenWrt-Devel] ar71xx with kernel 4.14 - a few test results

Hi Dirk You say: "works quite fine, both radios are available, no issues at all" but no feedback on how it actually performs... From my test I got throughput of 215Mbps on 2.4GHz wifi with 4.9 After upgraded to 4.14 the throughput dropped to 185-190Mbps. same device same settings and testing

Re: [OpenWrt-Devel] [PATCH] ipq40xx: Add support for IPQ4019 ap-dk07.1-c1

is this correct information? Wireless: 2.4-GHz 802.11ac On 31/08/2018, Ram Chandra Jangir wrote: > * SoC: QCA IPQ4019 > * RAM: 512 MiB > * Flash: 32 MiB of SPI NOR and 128 MiB NAND > * Wireless: 2.4-GHz 802.11ac, and two 5-GHz 802.11ac > * IoT : > CSR8811 radio [ supports BT classic

Re: [OpenWrt-Devel] OpenWrt 19.01 plans

On 30/09/2018, Hans Dedecker wrote: > On Sun, Sep 30, 2018 at 12:53 AM Stefan Lippers-Hollmann > wrote: >> >> Hi >> >> On 2018-09-29, Torbjorn Jansson wrote: >> > checkbox for hw offloading shows up for a fraction of a second when page >> > is >> > loaded but then it disappears. >> > so i take

Re: [OpenWrt-Devel] [PATCH] ath79: add support for GL.iNet GL-AR750S

On 30/12/2018, Christoph Krapp via openwrt-devel wrote: > 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

Re: [OpenWrt-Devel] [RFC] stop accepting 4/32M board patches

This is true. 32mb is misinterpretted as a limitation among several forum/wiki articles while storage space is being the only serious limitation. I have ar71xx running on 32M RAM device, basic configuration with luci-ssl and secondary wifi interface (ath9k_htc), most of the time when i log into

Re: [OpenWrt-Devel] [RFC] stop accepting 4/32M board patches

On 20/12/2018, camden lindsay wrote: > Tom- > Out of curiosity is your device being used as an access point, or as a > router? It is used as a router with NAT between USB WLAN and SoC WLAN networks ___ openwrt-devel mailing list

Re: [OpenWrt-Devel] ar71xx Vs ath79 -- sysupgrade

On 04/12/2018, Henrique de Moraes Holschuh wrote: > > > Em 03/12/2018 21:32, David Bauer escreveu: >> Hello Henrique, >> >> On 03.12.18 19:04, Henrique de Moraes Holschuh wrote: >>> Is there a viable way to "sysupgrade" from ar71xx to ath79? > >> First things first - sysupgrade is possible (be it

Re: [OpenWrt-Devel] [PATCH] ath79: add support for GL.iNet GL-AR750S

On 30/12/2018, Mathias Kresin wrote: > 30/12/2018 12:35, Tom Psyborg: >> On 30/12/2018, Christoph Krapp via openwrt-devel >> wrote: >>> The sender domain has a DMARC Reject/Quarantine policy which disallows >>> sending mailing list messages using the original &

Re: [OpenWrt-Devel] [PATCH] ath79: add support for GL.iNet GL-AR750S

On 30/12/2018, Piotr Dymacz wrote: > Hi Tom, > > On 30.12.2018 15:03, Tom Psyborg wrote: > > [...] > >>>>> If it's possible to update from the stock firmware via a webinterface, >>>>> it's fine. If not, the way via u-boot works as well. >>&g

Re: [OpenWrt-Devel] [PATCH] ath79: add support for GL.iNet GL-AR750S

On 30/12/2018, Mathias Kresin wrote: > 30/12/2018 14:51, Tom Psyborg: >> On 30/12/2018, Mathias Kresin wrote: >>> 30/12/2018 12:35, Tom Psyborg: >>>> On 30/12/2018, Christoph Krapp via openwrt-devel >>>> wrote: >>>>> The sender do

Re: [OpenWrt-Devel] [PATCH] ath79: add support for GL.iNet GL-AR750S

>There is nothing about upgrading U-Boot on the device from this e-mail topic. but there is about upgrading firmware via u-boot and according to the above linked kresin comment that procedure is unreliable On 30/12/2018, Mathias Kresin wrote: > 30/12/2018 15:15, Tom Psyborg: >> O

Re: [OpenWrt-Devel] [PATCH 3/3] mac80211: ath10k: reset chip after supported check

On 01/04/2019, Ben Greear wrote: >> please provide link. i did not get such patch in my inbox > > I forwarded it separately. If that fixes the problem, then I think it has > a decent change of being accepted upstream (as well as into my ath10k-ct > repo). forwarded to where?!? i can't find it

Re: [OpenWrt-Devel] [PATCH 3/3] mac80211: ath10k: reset chip after supported check

On 01/04/2019, Ben Greear wrote: > On 4/1/19 1:32 PM, Tomislav Požega wrote: >> When chip reset is done before the chip is checked if supported >> there will be crash. Previous behaviour caused bootloops on >> Archer C7 v1 units, this patch allows clean device boot without >> excluding ath10k

Re: [OpenWrt-Devel] [PATCH] ramips: Speed up eeprom read/write

So, how enourmous boot speed-up did it achieve? I'd say not much since you read like what 500bytes of eeprom data? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ath79: ar71xx: Upgrade: tl-wr842n-v1 has Wrong BOARDNAME in ar71xx Builds

see what happens when you're too savy on few lines of code that will not reduce image size a bit in the selected target...do it proper and have each device have it's own profile ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org

Re: [OpenWrt-Devel] [PATCH] ath10k: reset chip after supported check

These replies never reached my inbox. Anyway scraped conversation off the mailing list archive and CCing relevant people. >> >>> Can you elaborate more a bit? What kind of crashes are you seeing? >> >>> What does the bootloop look like? Do you have uart connected to >> >>> diagnose? >> >>> >> >>>

Re: [OpenWrt-Devel] [PATCH v2] ramips: Add support for Head Weblink HDRM200

On 03/05/2019, Kristian Evensen wrote: > Head Weblink HDRM200 is a dual-sim router based on MT7620A. The detailed > specifications are: > > - MT7620A (580MHz) > - 64MB RAM > - 16MB of flash (SPI NOR) > - 6x 10/100Mbps Ethernet (MT7620A built-in switch) > - 1x microSD slot > - 1x miniPCIe slot

Re: [OpenWrt-Devel] OpenWrt 19.07 release schedule ?

there seem to exist at least a dozen of critical bugs that one would not like to have as a part of final release, to name a few: Mainline ath10k causes crahes in ipq806x / R7800 -> https://bugs.openwrt.org/index.php?do=details_id=2480 TP-Link CPE210v3 wifi not working ->

Re: [OpenWrt-Devel] [PATCH 2/3] ath79: fix IMAGE_SIZE for common TP-Link definitions

Hi Looks like there were many doubts about image size over the years. One thing that should be considered is use of OEM firmware, either in case of just a single revert after OpenWrt flashing, or multiple reverts/switching between OEM/OpenWrt firmwares. Relevant in this case is config partition

Re: [OpenWrt-Devel] [PATCH 2/3] ath79: fix IMAGE_SIZE for common TP-Link definitions

On 07/08/2019, Adrian Schmutzler wrote: >> -Original Message- >> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On >> Behalf Of Tom Psyborg >> Sent: Mittwoch, 7. August 2019 17:58 >> To: Adrian Schmutzler >> Cc: openwrt-de

Re: [OpenWrt-Devel] Why ath79 has been made source-only on 19.07?

On 30/07/2019, Petr Štetiar wrote: > b) it was decided some time ago, that 19.07 is last release with ar71xx, >nothing about ath79 in 19.07 > > > -- ynezz > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org >

Re: [OpenWrt-Devel] ath79/qca9533rev2: Help needed on missing GPIO on ath9k-phy0

What about ar9533 devices on ath79 that do have working wifi, is that gpio present there? As far as I understand the idea was to use alias gpio chip (starting from 494) on ath79 instead of generic gpio (0-31) but I might be wrong about this. ___

Re: [OpenWrt-Devel] [PATCH] ath79: add support for Ubiquiti LiteBeam AC Gen2

i just checked mac addresses in the first image i built for this device (r10011) and they are correct: eth 18:E8:29:_device_specific wlan5g 18:E8:29:_device_specific wlan2g 1A:E8:29:_device_specific ___ openwrt-devel mailing list

Re: [OpenWrt-Devel] [PATCH] ath79: add support for Ubiquiti LiteBeam AC Gen2

Current changes from Stijn's branch look fine, I've applied them to the master clone from Dec 2nd, built and flashed; mac addresses are correct, ethernet is working as well as both wifi interfaces. On 03/12/2019, Adrian Schmutzler wrote: > LGTM. (Haven't checked the network setup.) :-) > >

Re: [OpenWrt-Devel] Inquery

suck it On 11/12/2019, rqgxfc wrote: > > > Hello Sir ， > > We are a trading company named Shaanxi Hao Zi Guan Materials Co.,Ltd . Now > we are very interested in your products , we will plan to sell your > products in the Chinese market . If you are interested in cooperation, > please send us

Re: [OpenWrt-Devel] Inquery

On 11/12/2019, Daniel Golle wrote: > Hi Tomislav, > > On Wed, Dec 11, 2019 at 11:24:21AM +0100, Tom Psyborg wrote: >> suck it > > As a community, we decided to give our self a set of minimal rules[1]. > And even though it is in the last position, rule #12 "Be nice to

Re: [OpenWrt-Devel] patches from 2018

On 27/10/2019, John Crispin wrote: > Hi, > I'd like to close all patches pending from 2018 in patchwork, there are > ~25 and a quick try on some showed none of the apply anymore. Anyone > have a problem with this ? > John > > ___ > openwrt-devel

Re: [OpenWrt-Devel] patches from 2018

ould clearly define somewhere at the appropriate place > on > the wiki, that for example any open topic on PW/GH/FS platform would > autoclose > after some predefined period of time (it can always be reopened if > requested). > > Say 6-12 months since the last activity in that particula

Re: [OpenWrt-Devel] OpenWrt 19.07 status

On 26/11/2019, Stijn Tintel wrote: > On 26/11/2019 00:34, Hauke Mehrtens wrote: >> It looks like there is a throughput problem with ath10k-ct on QCA9984, >> https://bugs.openwrt.org/index.php?do=details_id=2593 >> there are multiple reports in the Forum. >> >> For me QCA9880 on a BTHH5A with

Re: [OpenWrt-Devel] v5.4 as next kernel

On 31/10/2019, Bjørn Mork wrote: > John Crispin writes: > >> Hi, >> should we use v5.4 as our next kernel ? > > Hello John! > > I am still struggling to understand how the project makes release > decisions. I don't think your question makes sense without considering > target release dates, at

Re: [OpenWrt-Devel] QCA9994 outdoor 13km link

On 25/09/2019, Maxnet Support wrote: > I have attached iw phy phy0 info output. It shows only 2 antennas. Is this > wrong? Qca9994 has 4 chains. > > On 25 Sep 2019, 22:51, at 22:51, supp...@maxnet.al wrote: >>Hi, >> >> >> >> >> >> >>In the beginning i was using 2 dishes on each side. They are

Re: [OpenWrt-Devel] uhttpd/luci/rpcd is broken?

just to add to my previous message: after 14 hours of uptime with both wifi interfaces enabled, but no devices connected to them total available memory fell to 44MB, free 60MB. checked again after it passed 20 hours it was the same so no further decrease. all processes had max 2% of memory

Re: [OpenWrt-Devel] OpenWrt 20.X release plans

On 16/01/2020, Hauke Mehrtens wrote: > Hi, > > I meet with jow about 2 weeks ago and we talked about a lot of OpenWrt > related stuff, one of the topics was the release after 19.07. > > As the 19.07 release is now done, I would like to follow up on this topic. > > We thought that the time between

Re: [OpenWrt-Devel] [PATCH] ath79: ag71xx: use netif_receive_skb_list on 4.19

On 08/01/2020, Rosen Penev wrote: > From: Chuanhong Guo > > This new function make batch processing of network packets possible, > which slightly improves performance. > > Signed-off-by: Chuanhong Guo > Tested-by: Rosen Penev > --- > around a 20mbps improvement is measured on a TP-LINK Archer

Re: [OpenWrt-Devel] OpenWrt 19.07 final timeline

Hi And what about this one? https://bugs.openwrt.org/index.php?do=details_id=2593 Some regulatorty bugs? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWrt 19.07 final timeline

On 26/12/2019, Hauke Mehrtens wrote: > On 12/24/19 8:50 PM, Tom Psyborg wrote: >> Hi >> >> And what about this one? >> https://bugs.openwrt.org/index.php?do=details_id=2593 >> >> Some regulatorty bugs? > > Here is an other one related to ath10k: >

Re: [OpenWrt-Devel] Kernel version for OpenWrt 20.X

On 05/01/2020, m...@adrianschmutzler.de wrote: > Hi, > >> -Original Message- >> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] >> On Behalf Of Hauke Mehrtens >> Sent: Samstag, 4. Januar 2020 18:26 >> To: m...@adrianschmutzler.de; 'OpenWrt Development List' >

Re: [OpenWrt-Devel] uhttpd/luci/rpcd is broken?

On 06/01/2020, e9hack wrote: > After login in uhttpd/luci, the first page times > out and forces new login. A similar thing noticed yesterday: hitting login would just re-open login page, another hit would login but there was no crashes.. ubus memleak found in r11086 seems to be fixed, at least

Re: IEEE802.11w enabled by default

it could be kernel driver bug. try booting other distro, like kali or ubuntu releases from within last few years - e.g. 18.04,19.04,20.04 to see if it ever worked better. On 23/12/2020, Henrique de Moraes Holschuh wrote: > On 22/12/2020 11:31, Tom Psyborg wrote: >> In that case, che

Re: IEEE802.11w enabled by default

In case your client doesn't support mfp, you should configure the setting on router to optional instead of required so non-mfp client can fallback to basic connection type. On 21/12/2020, Henrique de Moraes Holschuh wrote: > On 21/12/2020 17:01, Tom Psyborg wrote: >> Your firm

Re: IEEE802.11w enabled by default

Hi Your firmware does not advertise mfp support, first check if your client device can actually support 802.11w On 21/12/2020, Henrique de Moraes Holschuh wrote: > On 20/12/2020 06:42, Petr Štetiar wrote: >> I would like to let you know, that there was virtual meeting week ago and >> you >>

Re: IEEE802.11w enabled by default

In that case, check router side, client can support it most likely. Try different release or factory firmware On 22/12/2020, Henrique de Moraes Holschuh wrote: > On 21/12/2020 17:13, Tom Psyborg wrote: >> In case your client doesn't support mfp, you should configure the >> se

Re: Compile and install OBS Studio in openwrt.

On 09/02/2021, Alberto Bursi wrote: > > > On 09/02/21 11:45, Hongyi Zhao wrote: >> Hi, >> >> Is it possible for me to compile and install OBS Studio in openwrt, so >> that I can use it as a media server? >> >> Any hints will be highly appreciated. >> >> Regards >> > > OBS Studio is an