Re: [OpenWrt-Devel] Linksys WRT1900ACS router is not booting after flashing custom build

Hi Avijit, > Also I have added myself in this mailing group couple of days back. Not > sure if this is the right forum to ask this question. If nor please > direct me to right forum. this is the OpenWrt developer mailing list. You should better use the forum: https://forum.openwrt.org/ Greetz, C

[OpenWrt-Devel] [PATCH] iwinfo: Complete device IDs for Ubiquiti airOS XM/XW devices

in ART- partitions. Signed-off-by: Vincent Wiemann --- hardware.txt | 103 --- 1 file changed, 98 insertions(+), 5 deletions(-) diff --git a/hardware.txt b/hardware.txt index f36c476..727c607 100644 --- a/hardware.txt +++ b/hardware.txt

[OpenWrt-Devel] [PATCH v2] iwinfo: Complete device IDs for Ubiquiti airOS XM/XW devices

in ART- partitions. Signed-off-by: Vincent Wiemann --- hardware.txt | 103 --- 1 file changed, 98 insertions(+), 5 deletions(-) diff --git a/hardware.txt b/hardware.txt index f36c476..727c607 100644 --- a/hardware.txt +++ b/hardware.txt

Re: [OpenWrt-Devel] qca8k: ipqess: ipq40xx: Kernel Panic on Adding VLAN Sub-Interface to Bridge

Hi Jeff, sounds a bit like https://www.spinics.net/lists/netdev/msg552100.html Regards, Vincent Wiemann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] iwinfo: Complete device IDs for Ubiquiti airOS XM/XW devices

Hi Mathias, I've put you in the CC as you have commit rights for the iwinfo repository. Regards, Vincent Wiemann (CodeFetch) On 16.03.2019 22:32, Vincent Wiemann wrote: > This commit includes all power offsets and subsystem device IDs > for Ubiquiti XM and XW devices. The d

Re: [OpenWrt-Devel] OpenWrt 19.03 plans

mess again. Regards, Vincent Wiemann On 09.04.2019 11:02, Bjørn Mork wrote: > Jo-Philipp Wich writes: > >>> Is there any kind of "official" roadmap/checklist available what "needs" >>> to be done? >> >> not that I am aware of, but from the to

Re: [OpenWrt-Devel] OpenWrt 19.03 plans

Hi Bjørn, Jo-Philipp, Eric, all of you are right, I think. I didn't make clear what I'd like to see OpenWrt achieve. Cuts need to be done when they delay a release too long or when the reasons are not under the OpenWrt developer's control, but when there is the chance that someone is getting motiv

Re: [OpenWrt-Devel] [PATCH v2] iwinfo: Complete device IDs for Ubiquiti airOS XM/XW devices

Can someone merge this, please? On 19.03.2019 20:29, Vincent Wiemann wrote: > Hi Mathias, > > I've put you in the CC as you have commit rights for the iwinfo repository. > > Regards, > > Vincent Wiemann (CodeFetch) > > On 16.03.2019 22:32, Vincent Wiemann wr

[OpenWrt-Devel] Fix TX power handling

gdb developers aware I'd like to do this by myself, but I don't have time for it. Still I can help with the measurements etc. If someone feels capable of doing this, this would be a great improvement and help OpenWrt to keep a stand against vendor locking. Regards, Vincent Wiemann

Re: [OpenWrt-Devel] Fix TX power handling

rdware and not in software. Can you hint me to the source for this lookup table? Regards, Vincent Wiemann On 29.04.2019 08:50, Matthias May wrote: > On 25/04/2019 17:54, Vincent Wiemann wrote: >> First EIRP is by definition ERP + antenna gain - cable loss. > > Hi > Small deta

Re: [OpenWrt-Devel] dnsmasq not leasing after a while. Sometimes more than 5 times a day

Hi Denis, I don't have such problems. Please post your configuration and device setup and try to get some logs. As far as I understand dnsmasq is unresponsible, but still runs?! What do you mean with "restart messages"? Are your devices rebooting? Regards, Vincent Wiemann On

Re: [OpenWrt-Devel] Extending iwinfo to set interface to monitor mode

Great idea, but that needs to happen upstream. As far as I know iwinfo is only used for the hardware gains and ubus stuff in OpenWrt. It would be nice if it could be replaced by iw completely. Regards, Vincent Wiemann On 11.06.19 18:29, Nick wrote: > iw has no c library. So if you want to

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

This does not make sense. For most people it was clear, that 19.07 will have images for ar71xx and ath79. Regards, Vincent Wiemann On 30.07.19 21:40, James Campbell wrote: > Can we not have a way of including unstable stuff in a way the consumers know > it’s un stable ? > > Like a

Re: [OpenWrt-Devel] [PATCH 1/3] kernel: rtl8366_smi: explicitly set phy addr for switch

Hi Serge, thank you very much for this contribution. I can only give some cosmetic advice. I'm not sure about the functionality. On 15.08.19 10:27, Serge Vasilugin wrote: > By default rtl8366_smi use phy addr 0 at mii-bus to access switch registers. > This patch allow to set it explicitly in dts-

Re: [OpenWrt-Devel] [PATCH 2/3] kernel: rtl8367b: add configuration for extended interface 2

On 15.08.19 10:28, Serge Vasilugin wrote: > Both rtl8367b and rtl8367s have two extended interface > rtl8367rb: 5 port + 2*RGMII/MII > rtl8367s:  5 port + SGMII/HSGMI + RGMII/MII > (?)rtl8367sb:  5 port + 2*RGMII/MII > These interfaces correpond to EXT1 and EXT2 (ports 6 and 7 respectivly). > Cur

Re: [OpenWrt-Devel] [PATCH 3/3] kernel: rtl8367b: initial support for Realtek switch rtl8367s

On 15.08.19 10:28, Serge Vasilugin wrote: > From driver point of view no differance between rtl8367b and rtl8367s > if it connected through EXT2 (rgmii only). > So this trivial patch add some identification and initialization only. > SGMII/HSGMII mode for EXT1 is not implemented for the sake of p

Re: [OpenWrt-Devel] Did they check security of OpenWrt?

Hi Rich, the article is a joke. I'm not talking about the researchers, but about citing a statement like: „However, those same firmware binaries did not employ other common security features like ASLR or stack guards, or did so only rarely,“ Look at the source-code of the mentioned vendors. They

Re: [OpenWrt-Devel] Did they check security of OpenWrt?

Hi Rich, On 20.08.19 23:19, Rich Brown wrote: > Yes, but... Virtually all the other vendor's firmware are "Linux distro's" as > well. Stone-age linux distros > And if I understand the CITL scan process, it shows lots of bad build > practices in the vendor firmware source code. So they should

[OpenWrt-Devel] Why don't derive OpenWrt's BSSIDs from MACs?

There is an "official" way to derive BSSIDs from device's MAC addresses. https://community.arubanetworks.com/t5/Controller-Based-WLANs/How-is-the-BSSID-derived-from-the-Access-Point-ethernet-MAC/ta-p/176290 Why doesn't OpenWrt do this? - CodeFetch ___ o

Re: [OpenWrt-Devel] Does "uci commit" really write to flash?

Hi Ronaldo, > I would like to know if an uci commit system really writes to flash > even if there were no modifications to the /etc/config/system file? „uci set“ will only make temporary changes which can be found in /tmp/.uci. That dir acts as some kind of overlay... "uci commit" will write th

Re: [OpenWrt-Devel] Giveaway: Linksys WRT3200ACM units

Hi everyone, has anyone received one of the units, yet? I wonder how long it takes as my experience with TP-Link (who don't really care about free software :D) is that they send their units with UPS Express and it never took more than a week... On 17.01.2017 20:06, Hartmut Knaack wrote: > > OK,

[OpenWrt-Devel] [PATCH] [ar71xx] Add default LED configuration for D-Link DIR-615 rev. C1

This patch adds an entry in the uci-defaults' led-file to configure the WAN and WLAN LEDs by default. Signed-off-by: Vincent Wiemann --- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds @@ -116,6 +116,11 @@ dir-6

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

On 06.09.19 12:44, Bjørn Mork wrote: > Jo-Philipp Wich writes: > >>> Buildbot is already crunching the images and packages, and pretty much >>> all targets are green. So there are no obvious build related issues >>> preventing the release. I have also not noticed any franctic discussion >>> about

Re: [OpenWrt-Devel] nftables: named counters broken on 18.06.4

On 10.09.19 17:20, Salvatore Mesoraca wrote: > Hi, > > I'm experiencing a problem with nftables' named counters with OpenWrt 18.06.4 > on a NetGear R7800. > This is an example of what I get: > > # uname -a > Linux OpenWrt 4.14.131 #0 SMP Thu Jun 27 12:18:52 2019 armv7l GNU/Linux > # nft flush r

Re: [OpenWrt-Devel] nftables: named counters broken on 18.06.4

On 10.09.19 19:06, Salvatore Mesoraca wrote: > On Tue, 10 Sep 2019 at 17:58, Vincent Wiemann > wrote: >> >> >> On 10.09.19 17:20, Salvatore Mesoraca wrote: >>> Hi, >>> >>> I'm experiencing a problem with nftables' named counters

Re: [OpenWrt-Devel] sysupgrade: extending firmware validation

Hi Rafal, better error messages for sysupgrade is a good idea. On 11.09.19 11:26, Rafał Miłecki wrote: > On Wed, 19 Jun 2019 at 16:07, Rafał Miłecki wrote: >> Currently targets can implement platform_check_image() that verifies >> submitted firmware file. It may return a success or failure. >> >

Re: [OpenWrt-Devel] sysupgrade: extending firmware validation

On 11.09.19 13:00, Rafał Miłecki wrote: > On Wed, 11 Sep 2019 at 12:19, Vincent Wiemann > wrote: >> Hi Rafal, >> >> better error messages for sysupgrade is a good idea. > > Hi & let me ask shortly. Did you follow the recent development? Saw my > improvement

Re: [OpenWrt-Devel] nftables: named counters broken on 18.06.4

On 11.09.19 16:25, Salvatore Mesoraca wrote: > On Tue, 10 Sep 2019 at 16:20, Salvatore Mesoraca > wrote: >> >> Hi, >> >> I'm experiencing a problem with nftables' named counters with OpenWrt >> 18.06.4 on a NetGear R7800. >> This is an example of what I get: >> >> # uname -a >> Linux OpenWrt

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

dated). Furthermore a high channel width often results in problems due to lower receiver sensibility. We have better experiences with lower channel widths and sometimes get more throughput with that. Actually I think this does not explain your connection issues as 13 km is not that much. Regards, Vi

Re: [OpenWrt-Devel] [PATCH 19.07] ar71xx: fix sysupgrade to ath79 for wndr3700v2 and wndr3800

be nice to have separate definitions for each model in ath79 even if they share the same board. A migration script in ath79 could help changing the model definition afterwards so that e.g. a Luci Updater could find the proper image. Are there any critical hardware differences between the de

Re: SquashFS mixed errors (decompression failed and others)

Hi Ibrahim, please post the affected model name. It could e.g. be a bad board design which requires the flash to be clocked slower or something. Without knowing the affected board, it is guessing... Best, Vincent On 5/21/21 1:19 PM, Ibrahim Tachijian wrote: Hello, We use approximately 10k IP

Re: SquashFS mixed errors (decompression failed and others)

On 5/21/21 3:58 PM, Koen Vandeputte wrote: On 21.05.21 13:19, Ibrahim Tachijian wrote: Hello, We use approximately 10k IPQ40XX devices and we have noticed that every time we run "sysupgrade -n" we lose approximately 1% of the routers in the process. After further investigation I'm almost co

Re: SquashFS mixed errors (decompression failed and others)

x27;t point you there. It's just a guess... On Fri, May 21, 2021 at 6:16 PM Vincent Wiemann wrote: On 5/21/21 3:58 PM, Koen Vandeputte wrote: On 21.05.21 13:19, Ibrahim Tachijian wrote: Hello, We use approximately 10k IPQ40XX devices and we have noticed that every time we run "sysu

Re: [PATCH v2] ath79: add support for Ubiquiti PowerBeam M (XW)

The information contained in this message and any attachments may be privileged, confidential, propietary, protected by copyright law or by any other means protected from disclosure and must therefore not be publicly disclosed without prior writte

Re: [PATCH v2] ath79: add support for Ubiquiti PowerBeam M (XW)

Hi Russel, On 5/24/21 1:06 AM, Russell Senior wrote: On the PowerBeam M2 (PBE-M2-400) I see "e2 c2" in the same locations, not "e6 c2". That's very interesting... I think the PowerBeam 400 was sold under the NanoBeam series at the beginning. So there might be an entry missing. Is your PowerBe

Re: [PATCH v2] ath79: add support for Ubiquiti PowerBeam M (XW)

On 5/25/21 2:23 AM, Russell Senior wrote: On Mon, May 24, 2021 at 2:51 AM Vincent Wiemann wrote: Hi Russel, On 5/24/21 1:06 AM, Russell Senior wrote: On the PowerBeam M2 (PBE-M2-400) I see "e2 c2" in the same locations, not "e6 c2". That's very interesting...

Re: 'config route' extension for more compact notation

On 5/25/21 11:31 PM, Philip Prindeville wrote: Hi, I'm thinking about something like (taken from my home router): config route option target '103.136.220.0/22' option interface 'wan' option type 'blackhole' config route option target '103.123.116.0/22'

Re: openwrt developer / paid work

low the penguin! //\ Vincent Wiemann V_/_+49-511-582974 * ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: openwrt developer / paid work

On 6/2/21 5:41 AM, Philip Prindeville wrote: On Jun 1, 2021, at 5:27 PM, Embedded Devel wrote: On 6/2/21 3:45 AM, Philip Prindeville wrote: This was advertised as "paid work". I'm still waiting to be paid. keep waiting, you accomplished nothing really, and billed $8,000.00 USD over 2 m

Re: [PATCH uclient] uclient-fetch: allow to overwrite Content-Type header for POST

On 6/3/21 7:57 AM, Andre Heider wrote: This is required by some APIs, e.g. matrix's media upload [0]. [0] https://matrix.org/docs/spec/client_server/latest#post-matrix-media-r0-upload Signed-off-by: Andre Heider --- uclient-fetch.c | 11 +-- 1 file changed, 9 insertions(+), 2 delet

Re: [PATCH uclient] uclient-fetch: allow to overwrite Content-Type header for POST

On 6/3/21 7:57 AM, Andre Heider wrote: This is required by some APIs, e.g. matrix's media upload [0]. [0] https://matrix.org/docs/spec/client_server/latest#post-matrix-media-r0-upload Signed-off-by: Andre Heider --- uclient-fetch.c | 11 +-- 1 file changed, 9 insertions(+), 2 delet

Re: Enabling Wi-Fi on First boot

amera to decode morse code. I was working on using the HTML5 camera API with JavaScript image feature detection to create a platform independent solution. Unfortunately the standard feature detection models are not very good at it. So it needs some work. Best, Vincent Wiemann On 7/7/21 3:26

Using OpenWrt toolchain as external toolchain does not work

Hi Folks, has anyone managed to use OpenWrt's toolchain as external toolchain? E.g. using the toolchain from snapshots: https://downloads.openwrt.org/snapshots/targets/ath79/generic/openwrt-toolchain-ath79-generic_gcc-11.2.0_musl.Linux-x86_64.tar.bz2 I've tried to get it working a year ago and

Using OpenWrt toolchain as external toolchain does not work

Hi Folks, has anyone managed to use OpenWrt's toolchain as external toolchain? E.g. using the toolchain from snapshots: https://downloads.openwrt.org/snapshots/targets/ath79/generic/openwrt-toolchain-ath79-generic_gcc-11.2.0_musl.Linux-x86_64.tar.bz2 I've tried to get it working a year ago and

Re: ath79 / TP-Link CPE510 / tftp: recovery.bin

cly disclosed without prior written consent..#&@#. ,#@&:%++%:&@#. Follow the penguin! #@&:%%010111%%:&@# Vincent Wiemann (°> #@&:%0 0%:&@ //\

Re: [OpenWrt-Devel] wifi/wlan isolation

Hi Hartmut, this is the OpenWrt developer mailing list. Please ask for support on the forum. Best, Vincent On 25.01.20 15:14, e9hack wrote: > Hi, > > I face a strange problem. I have configured 9 wlan's. On two, clients can't > reach each other. I check the settings of > /sys/devices/virtual

[OpenWrt-Devel] ath79: Let the internal switch control the LEDs

Hi, is there any reason why OpenWrt does not let the switch control the LED activity? E.g. with QCA9531 it's just setting the GPIO function register to a specific value and if one wants a more OpenWrt-like blinking pattern configuring the switch registers. Would such a change be accepted? I thi

Re: [OpenWrt-Devel] [PATCH v13] ath10k: add LED and GPIO controlling support for various chipsets

Hi Sebastian, I don't know why it was dropped, but I can say that the LED control code was kind of annoying me. Even when the LED was turned of, it "flickered" when it was set disabled. Unfortunately I didn't have time to look into it, yet. Best, Vincent On 20.05.20 09:39, Sebastian Gottschal

Re: [OpenWrt-Devel] [PATCH v13] ath10k: add LED and GPIO controlling support for various chipsets

Hi Sebastian, On 20.05.20 15:00, Sebastian Gottschall wrote: > > Am 20.05.2020 um 12:40 schrieb Vincent Wiemann: >> Hi Sebastian, >> >> I don't know why it was dropped, but I can say that the LED control code was >> kind of >> annoying me. Even when the

Re: [OpenWrt-Devel] Experimental "release goals" for 19.07.4

On 23.05.20 21:34, Michael Jones wrote: > > > On Sat, May 23, 2020, 13:01 Baptiste Jonglez > wrote:  > > If the initial concept looks good, we can think about automating some of > it: > tag bug reports on Flyspray/Github/Gitlab as blocking for a spec

Re: [OpenWrt-Devel] [PATCH] hostapd: add support for wifi-station and wifi-vlan sections

On 25.05.20 16:46, John Crispin wrote: > With this patch applied it is possible to use multiple PSKs and VIDs on a > single BSS. Nice! So hostapd supports different keys for different stations now? Did you test it? This is particularly interesting for me as I wanted to use different PSKs for diffe

Re: [OpenWrt-Devel] Dumb Wi-Fi client

Hi Enrico, On 20.06.20 23:03, Enrico Mioso wrote: > hello Bjorn, > hello all!! > > I would like to use an Archer C60 as a dumb Wi-Fi client. In particular, I > would like to: > - be able to connect to the WAN port of tthe ethernet switch to access the > LAN network to which the router is connec

Someone working on kernel 5.9?

Hi folks, is anybody working on 5.9, already? I'd like to do some testing with io_uring on ath79 devices, but the features needed require a version > 5.7. Please let me know! Best, Vincent ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org