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

[Vincent Wiemann]

> Press CTRL+B to enter SafeLoader: 1

Have you tried that?

On 11/12/21 9:09 AM, Bastian Bittorf wrote:

After flashing trunk to some devices, i'am affected
from the lzma-loader/GCC11 issue. It was possible in
the past to use the standard recovery procedure, but
it seems NOT possible anymore, maybe because of
the changed partition layout?

The bootloader says:
Incorrect File.
Writting error.

Anyway: does somebody know how to access the bootloader?
The password 'admin' or 'tpl' is not accepted and
images are also not accepted.

I'am happy for any hint - thanks a lot,
bye, bastian!




TP-LINK SafeLoader (Build time: Jun 12 2015 - 09:49:53)
CPU: 560MHz AHB: 225MHz DDR: 64MB
Performing LED check..  PASS
Press CTRL+B to enter SafeLoader: 1
Flash Manufacturer: Unknown(0xc8)
Flash Device ID: Unknown(0x4017)
Data flash init failed.
open user-config failed.
open user-config failed.
Error: Kernel did not takeover charge of WatchDog last time!

enet0 port4 up

TFTP server address is 192.168.0.100; our address is 192.168.0.254
Get filename 'recovery.bin'.
#
#
Done.
Bytes transferred = 5204617, 1373 Kbytes/sec
Incorrect File.
Writting error.
Allocated memory for elf segment ok: addr: 0x8006, size 0x16cc
Loading .text @ 0x8006 (5836 bytes)

Starting kernel



OpenWrt kernel loader for AR7XXX/AR9XXX
Copyright (C) 2011 Gabor Juhos 
Looking for OpenWrt image... found at 0xbf043000
Decompressing kernel...

(hangs here)

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel



--
*
The information contained in this message and any
attachments may be privileged, confidential,
proprietary, protected by copyright law or by any
other means protected from disclosure and must
therefore not be publicly disclosed without prior
written consent..#&@#.
,#@&:%++%:&@#.
Follow the penguin!   #@&:%%010111%%:&@#
  Vincent Wiemann   (°> #@&:%0  0%:&@
 //\   #@&:%0  0%:
   +49-511582974V_/_ #@&:%0  100%
*

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Using OpenWrt toolchain as external toolchain does not work

[Vincent Wiemann]

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 haven't got any hints since:
https://github.com/openwrt/openwrt/pull/3733

Best,

Vincent

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Using OpenWrt toolchain as external toolchain does not work

[Vincent Wiemann]

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 haven't got any hints since.

Best,

Vincent

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Enabling Wi-Fi on First boot

[Vincent Wiemann]

Hi,

this thread seams to be a follow-up of:
https://github.com/openwrt/openwrt/pull/2408

The end result was that we could let the status LED signal a randomly
generated PSK in morse code. There are several apps like
"Morse code reader" for Android which can use a mobile phone's
camera 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 AM, Luiz Angelo Daros de Luca wrote:

Hello,

I would enable wifi during the first boot. Maybe we could disable it
after a couple of minutes if nothing happens.
I would not use an unprotected network, like OpenWrt, as someone could
sniff the new password (we also have no https://).
But an OpenWrt/OpenWrt could work.

If you have a working OpenWrt and want to do a clean setup through
wifi, one solution would be to apply a simple "enable wifi"
configuration
together with the new image. Luci does not allow but CLI sysupgrade
does have the option "-f conf.tgz". OpenWrt could provide a standard
enable-wifi.tgz and a way to flash a firmware with configuration from LuCI.

Some devices block the user from using the router to access the
internet until some basic things are set, like admin and wifi
password.
They normally redirect all http traffic to the router. It would be
nice to have something similar to force the user to set a password.
However, it will never get merged if that setup applies to everything
as it would break many provisioning. It might be overkill but maybe it
looks like a new image flavor...

My 2 cents,

---
  Luiz Angelo Daros de Luca
 luizl...@gmail.com

Em ter., 6 de jul. de 2021 às 21:43, Alberto Bursi
 escreveu:




On 06/07/21 22:57, Michael Richardson wrote:


Alberto Bursi  wrote:
  > "unique" per-device passwords like most vendors are doing are low 
security
  > and relatively easy to brute force once someone has disassembled the 
firmware
  > and learned the algorithm used to generate them. They rely on obscurity 
for
  > most of their security, which is not really a thing for an open source
  > project.

If they devices are shipped with such derivable passwords, then they violate
the California (now US) regulations, and also the come UK ones.
We can do better, and we are doing better.


Yeah, like most devices are also paying lip service to the other US laws
about not allowing "custom firmware" on the device because that could
make it go against radio power/emission regulations.
One thing is the law, one thing is actually enforcing it besides asking
nicely to the OEMs and trusting their "boy scout's word" that it's all
secure.



  > They are also completely useless for DYI users that are just flashing a
  > couple devices.
  > With much less effort you can just ship a pre-made wifi config file 
with your
  > own settings and passwords, and that's what many are already doing.

Many devices have USB ports, and I'd suggest having a standard names .json
file that can be fed into uci in some way.  I think that this solves a lot
problems.  Have to make sure that vfat support is included in the base image
because... users.


And the idea mill keeps going. Not specifically just you but I've seen
these discussions run in circles so many times at this point that I'm a
bit jaded.
Imho this proposal does open more problems than it solves, and it is
non-trivial to implement, and it adds bloat in firmware images so people
will be unhappy.
And it is not universal, a lot of devices don't have USB ports.



The best idea I've seen so far is to just add the feature to add a
custom wifi config (possibly more than just wifi) in the image builder
website frontend framework thing made by Spooren (aparcar on github)
https://github.com/aparcar/asu
So that the user can generate an image with custom config from a point
and click interface, and when the device does the first boot it will
come up with an already configured wifi and network and whatnot.

This avoids bloating images, does not add any new attack vectors in the
device firmware, keeps the wifi security freaks happy as no wifi is
enabled by default, while still being friendly to the end user.

The only thing that could go wrong is that the user screws up the config
and locks himself out, device reset will not change the configs he
integrated, but I think Fallback mode can to be modified to always use
"openwrt default configs (i.e. 192.168.1.1 IP and device default ports
for LAN/WAN, no wifi enabled)" instead of whatever the user has shipped.
So that if the user does something wrong they can still get into
fallback mode and then reflash a new firmware with the right configs.

Not saying this is easier to develop or faster or whatev

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

[Vincent Wiemann]

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 deletions(-)

diff --git a/uclient-fetch.c b/uclient-fetch.c
index 282092e..176fd37 100644
--- a/uclient-fetch.c
+++ b/uclient-fetch.c
@@ -44,6 +44,7 @@
  static const char *user_agent = "uclient-fetch";
  static const char *post_data;
  static const char *post_file;
+static const char *content_type = "application/x-www-form-urlencoded";
  static struct ustream_ssl_ctx *ssl_ctx;
  static const struct ustream_ssl_ops *ssl_ops;
  static int quiet = false;
@@ -346,13 +347,13 @@ static int init_request(struct uclient *cl)
check_resume_offset(cl);
  
  	if (post_data) {

-   uclient_http_set_header(cl, "Content-Type", 
"application/x-www-form-urlencoded");
+   uclient_http_set_header(cl, "Content-Type", content_type);
uclient_write(cl, post_data, strlen(post_data));
}
else if(post_file)
{
FILE *input_file;
-   uclient_http_set_header(cl, "Content-Type", 
"application/x-www-form-urlencoded");
+   uclient_http_set_header(cl, "Content-Type", content_type);
  
  		input_file = fopen(post_file, "r");

if (!input_file)
@@ -484,6 +485,7 @@ static int usage(const char *progname)
"  --user-agent | -USet HTTP user agent\n"
"  --post-data=STRING  use the POST method; send STRING 
as the data\n"
"  --post-file=FILEuse the POST method; send FILE as 
the data\n"
+   "  --content-type=STRING   use STRING as Content-Type for 
the POST method\n"
"  --spider | -s   Spider mode - only check file 
existence\n"
"  --timeout=N | -T N  Set connect/request timeout to N 
seconds\n"
"  --proxy=on | -Y on  Enable interpretation of proxy 
env vars (default)\n"
@@ -544,6 +546,7 @@ enum {
L_USER_AGENT,
L_POST_DATA,
L_POST_FILE,
+   L_CONTENT_TYPE,
L_SPIDER,
L_TIMEOUT,
L_CONTINUE,
@@ -561,6 +564,7 @@ static const struct option longopts[] = {
[L_USER_AGENT] = { "user-agent", required_argument, NULL, 0 },
[L_POST_DATA] = { "post-data", required_argument, NULL, 0 },
[L_POST_FILE] = { "post-file", required_argument, NULL, 0 },
+   [L_CONTENT_TYPE] = { "content-type", required_argument, NULL, 0 },
[L_SPIDER] = { "spider", no_argument, NULL, 0 },
[L_TIMEOUT] = { "timeout", required_argument, NULL, 0 },
[L_CONTINUE] = { "continue", no_argument, NULL, 0 },
@@ -632,6 +636,9 @@ int main(int argc, char **argv)
case L_POST_FILE:
post_file = optarg;
break;
+   case L_CONTENT_TYPE:
+   content_type = optarg;
+   break;
case L_SPIDER:
no_output = true;
break;



Oh sorry, ignore my last mail. I've misunderstood what you're doing
here. Still a bit sleepy. Looks fine...

Best,

Vincent

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

[Vincent Wiemann]

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 deletions(-)

diff --git a/uclient-fetch.c b/uclient-fetch.c
index 282092e..176fd37 100644
--- a/uclient-fetch.c
+++ b/uclient-fetch.c
@@ -44,6 +44,7 @@
  static const char *user_agent = "uclient-fetch";
  static const char *post_data;
  static const char *post_file;
+static const char *content_type = "application/x-www-form-urlencoded";
  static struct ustream_ssl_ctx *ssl_ctx;
  static const struct ustream_ssl_ops *ssl_ops;
  static int quiet = false;
@@ -346,13 +347,13 @@ static int init_request(struct uclient *cl)
check_resume_offset(cl);
  
  	if (post_data) {

-   uclient_http_set_header(cl, "Content-Type", 
"application/x-www-form-urlencoded");
+   uclient_http_set_header(cl, "Content-Type", content_type);
uclient_write(cl, post_data, strlen(post_data));
}
else if(post_file)
{
FILE *input_file;
-   uclient_http_set_header(cl, "Content-Type", 
"application/x-www-form-urlencoded");
+   uclient_http_set_header(cl, "Content-Type", content_type);
  
  		input_file = fopen(post_file, "r");

if (!input_file)
@@ -484,6 +485,7 @@ static int usage(const char *progname)
"  --user-agent | -USet HTTP user agent\n"
"  --post-data=STRING  use the POST method; send STRING 
as the data\n"
"  --post-file=FILEuse the POST method; send FILE as 
the data\n"
+   "  --content-type=STRING   use STRING as Content-Type for 
the POST method\n"
"  --spider | -s   Spider mode - only check file 
existence\n"
"  --timeout=N | -T N  Set connect/request timeout to N 
seconds\n"
"  --proxy=on | -Y on  Enable interpretation of proxy 
env vars (default)\n"
@@ -544,6 +546,7 @@ enum {
L_USER_AGENT,
L_POST_DATA,
L_POST_FILE,
+   L_CONTENT_TYPE,
L_SPIDER,
L_TIMEOUT,
L_CONTINUE,
@@ -561,6 +564,7 @@ static const struct option longopts[] = {
[L_USER_AGENT] = { "user-agent", required_argument, NULL, 0 },
[L_POST_DATA] = { "post-data", required_argument, NULL, 0 },
[L_POST_FILE] = { "post-file", required_argument, NULL, 0 },
+   [L_CONTENT_TYPE] = { "content-type", required_argument, NULL, 0 },
[L_SPIDER] = { "spider", no_argument, NULL, 0 },
[L_TIMEOUT] = { "timeout", required_argument, NULL, 0 },
[L_CONTINUE] = { "continue", no_argument, NULL, 0 },
@@ -632,6 +636,9 @@ int main(int argc, char **argv)
case L_POST_FILE:
post_file = optarg;
break;
+   case L_CONTENT_TYPE:
+   content_type = optarg;
+   break;
case L_SPIDER:
no_output = true;
break;



That's a very hacky solution. I think you should solve this using a CGI-
script instead.

Best,

Vincent

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: openwrt developer / paid work

[Vincent Wiemann]

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 
months and we are no further now then we were when you started. If youd like I 
can do a line count of changes from start to finish, the previous developer 
accomplished more in 10 hours, and hes been paid. And we already hired a new 
one prior to these emails. It seems like you dont know OpenWRT as well as you 
claim. This is all Im going to say publicly about it. This was a business to 
business deal and has no recourse being on a public mailing list, trying to 
accomplish what? embarrass us? Wount work, If it embarrasses anyone, it will be 
you. Also remember, There is an NDA in place you signed, be very careful.




8k is not much for a freelancing expert. That's 40 hours...

One must consider the big amount of time one has to put into
staying in tune with the developments which is in my case 90%
of my work and the more specialized one is the more an hour must
cost to cover the time without proper jobs.

Furthermore software development is psychically draining which needs
compensation. So if you think that's too much, you may think about
either learning it yourself or whether your revenue is too low.

You could also think about outsourcing your work to third-world-
countries, but they will possibly fool you.

There's an anecdote about that in Germany:
A machine in a factory crashed and the engineer who designed it
was in retirement. They needed to bring him back from retirement.
When he came to the factory, he took a piece of chalk, made a mark
and left after 5 minutes.
He sent an invoice with a very high price. So the company asked for
a listing of costs. He replied:
Piece of chalk - 1 Mark
Knowing where to do the mark - 5 Mark

That's reality... You can't expect experts to do your slave labor.
By the way... If you build up on open source software, what are you
expecting? Imagine you'd have to build the software from ground up.
Hiring open source developers is the cheapest thing you can get
products to the market with...
There are just so many wannabe start-up sucker companies with bad
attitudes towards the engineers. They all go bankrupt.



Line counts don’t take into consideration the amount of time to bring up 
software on a new platform that’s supposed to be portable but in fact isn’t.

If you’re going to solicit in a public forum, then it should be known that the 
terms advertised were not in fact accurate.

Yes, there’s an NDA.  Nothing strategic or proprietary has been disclosed.

And any civil legal proceedings would enter into the public record.  And 
pursing legal action internationally would cost you more than I’ve billed.

I think you need to be even more careful.

-Philip



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: openwrt developer / paid work

[Vincent Wiemann]

On 6/1/21 10:45 PM, Philip Prindeville wrote:

This was advertised as "paid work".  I'm still waiting to be paid.




On Apr 1, 2021, at 5:52 AM, Embedded Devel  wrote:

need someone to fix an application we have, was fully functional some 10 years 
ago.

can provide a vm, with git repo sources of app and remote access to the ap

we believe its a small issue that someone could resolve quickly.

possible to turn into larger project for the right person


Thanks



Never fall for the dumbed down matrix slaves. They never pay.
„Some say they are the devil.“ said the GNU and OX agreed };-)
With their revenues they do holidays and do more slavery.
In the best/worst case they copy Apple. #SupportMikeRoweSoft

„If the order is mediocrity: Hail Chaos which bringeth forth good
fruit of repentance!“ said the illuminate of Ismeat
(Hack-fleisch of Maat and Isfet)

When you understand it, you are illuminated and eligible for
initiation for which you need to realize that others fail to
which enlightens you more about the hidden reality of mediocrity.

https://www.youtube.com/watch?v=ewRjZoRtu0Y

--
*
 _o)   Follow 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: 'config route' extension for more compact notation

[Vincent Wiemann]

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'
 option interface 'wan'
 option type 'blackhole'

config route
 option target '130.44.212.0/22'
 option interface 'wan'
 option type 'blackhole'

etc.  Kudos to you if you spotted these as being ByteDance TikTok servers in 
China which US subscribers aren't supposed to have their traffic sent to, but 
(surprise!!!) it still is anyway.

A nicer (more compact) notation might be:

config route
list target '103.123.116.0/22'
 list target '103.136.220.0/22'
list target '130.44.212.0/22'
 option interface 'wan'
 option type 'blackhole'

So, how about a change to config/route where, if it doesn't find 'option 
target', then it searches for 'list target' instead, and populates an ipset 
instead, using that for the match criteria?

We could probably do something similar for config/rule in the firewall, for the 
src_ip, src_port, dst_ip, dst_port, etc. using 'list' instead of 'option', and 
ipsets to compactly match multiple addresses, ports, etc.

But then, firewall would depend on ipset functionality being baked in.  On 
x86_64, this isn't big:

-rw-r--r--   1 philipp  philipp   823 May 10 22:15 
bin/targets/x86/64/packages/kmod-ipt-ipset_5.4.110-1_x86_64.ipk
-rw-r--r--   1 philipp  philipp  2036 Mar 19 16:57 
bin/packages/x86_64/base/ipset_7.6-1_x86_64.ipk

What do you all think?

-Philip



I like the idea of baking in ipset, but it would be very strange to have
a blackhole route which creates an ipset filter.

It would avoid user confusion if we stick to the approach here:
https://openwrt.org/docs/guide-user/firewall/fw3_configurations/fw3_config_ipset

Best,

Vincent

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

[Vincent Wiemann]

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... I think the PowerBeam 400 was sold under the
NanoBeam series at the beginning. So there might be an entry missing.
Is your PowerBeam old?


It was purchased circa 2015. It is clearly marked PowerBeam M2 on the
sticker, along with "M/N: PBE-M2-400", although the FCCID suggests
some overlap with NanoBeam (SWX-NBM2HP).



Thank you for that information. We've also purchased a PowerBeam in 2015
where on the sticker it says PowerBeam, but the box stated NanoBeam...

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

[Vincent Wiemann]

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 PowerBeam old?



Vincent> While I think there shouldn't be different DTS files for them,
Vincent> there is a script missing that respects the antenna and
Vincent> external PA gain of these devices.

-ENOPATCH



Maybe we should add it to the wiki instead.


Best,

Vincent

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

[Vincent Wiemann]

uot; "1"
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/02_network 
b/target/linux/ath79/generic/base-files/etc/board.d/02_network
index 4133b9d7d3..6e31cdac69 100644
--- a/target/linux/ath79/generic/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/generic/base-files/etc/board.d/02_network
@@ -85,6 +85,7 @@ ath79_setup_interfaces()
ubnt,picostation-m|\
ubnt,powerbeam-5ac-500|\
ubnt,powerbeam-5ac-gen2|\
+   ubnt,powerbeam-m-xw|\
ubnt,powerbridge-m|\
ubnt,rocket-m|\
ubnt,unifiac-lite|\
diff --git a/target/linux/ath79/image/generic-ubnt.mk 
b/target/linux/ath79/image/generic-ubnt.mk
index 733d803d7a..5948e059e8 100644
--- a/target/linux/ath79/image/generic-ubnt.mk
+++ b/target/linux/ath79/image/generic-ubnt.mk
@@ -328,6 +328,14 @@ define Device/ubnt_powerbeam-5ac-gen2
  endef
  TARGET_DEVICES += ubnt_powerbeam-5ac-gen2
  
+define Device/ubnt_powerbeam-m-xw

+  $(Device/ubnt-xw)
+  DEVICE_MODEL := PowerBeam M
+  DEVICE_PACKAGES += rssileds
+  SUPPORTED_DEVICES += loco-m-xw
+endef
+TARGET_DEVICES += ubnt_powerbeam-m-xw
+
  define Device/ubnt_powerbridge-m
$(Device/ubnt-xm)
SOC := ar7241



--
*
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
written consent.

 _o)   Follow 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: SquashFS mixed errors (decompression failed and others)

[Vincent Wiemann]

On 5/23/21 10:21 AM, Ibrahim Tachijian wrote:

Is your firmware (sysupgrade) bigger than 16MB?


No, the sysupgrade file is currently 13MB.


So maybe it has to do with switching to 4-address-mode...

What is this exactly?


The 4-"byte"-address mode is used on 32 MiB flash chips.
We had similar issues with other 32 MiB devices in the past
which were fixed at some point by Felix Fietkau.


My guess is that the error already happens when reading the flash.

At least we know that the flash is not being written to incorrectly
since after a reboot the flash is intact and does not produce any
errors. It's simply random if the system boots into this "faulty
state" or not (happens approx 1-2% of the time).

Does anyone maybe know how I can re-read the squashfs partition and
verify the integrity while the system is booted to see if I encounter
the squashfs errors.
I'm really at a loss here - no idea where to even look into diagnosing
the issue.



I guess the reset line of the flash chip is not hold long enough so
that it is in an unclean state. I think the reset duration during
booting needs to be increased. But I don't know the code and can'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 "sysupgrade -n" we lose approximately 1% of the
routers in the process.
After further investigation I'm almost confident that it is not the
sysupgrade process that is the culprit - so what I did was that I put
one test router into a reboot loop.

This is what I do;

Boot the router in a fresh state after a newly installed image.
The image contains a reboot loop that consists of a shell script that
runs every minute.

The shell script tries to run a php-script which simply echoes "Hello
World". If the php-script exists normally then we reboot the router.

However the php-script exists abnormally then the router stops and
does nothing other than informing me that there was a bus-error making
php not able to process the hello world script.

When this process runs the router reboots approximately 50 times
before it boots into a state which is faulty where I see bus-errors
when I try to run php scripts for example.


Looking into dmesg you can see some errors such as,

[10985.209438] SQUASHFS error: squashfs_read_data failed to read block
0x3a803e
[11045.218685] SQUASHFS error: xz decompression failed, data probably
corrupt
[11045.218731] SQUASHFS error: squashfs_read_data failed to read block
0x3a803e
[11105.228157] SQUASHFS error: xz decompression failed, data probably
corrupt
[11105.228203] SQUASHFS error: squashfs_read_data failed to read block
0x3a803e

or

[26218.687905] SQUASHFS error: Unable to read page, block 1b99a, size
10234
[26221.057472] SQUASHFS error: Unable to read data cache entry [1b99a]
[26221.057551] SQUASHFS error: Unable to read page, block 1b99a, size
10234
[26221.062926] SQUASHFS error: Unable to read data cache entry [1b99a]
[26221.069742] SQUASHFS error: Unable to read page, block 1b99a, size
10234
[26224.460239] SQUASHFS error: Unable to read data cache entry [1b99a]
[26224.460320] SQUASHFS error: Unable to read page, block 1b99a, size
10234

or

[62745.801178] SQUASHFS error: squashfs_read_data failed to read block
0x732ae2
[62773.347234] SQUASHFS error: xz decompression failed, data probably
corrupt
[62773.347281] SQUASHFS error: squashfs_read_data failed to read block
0x732ae2
[62790.132661] SQUASHFS error: xz decompression failed, data probably
corrupt
[62790.132706] SQUASHFS error: squashfs_read_data failed to read block
0x732ae2
[62790.216746] SQUASHFS error: xz decompression failed, data probably
corrupt
[62790.216792] SQUASHFS error: squashfs_read_data failed to read block
0x732ae2
[62800.810525] SQUASHFS error: xz decompression failed, data probably
corrupt
[62800.810570] SQUASHFS error: squashfs_read_data failed to read block
0x732ae2
[62828.336267] SQUASHFS error: xz decompression failed, data probably
corrupt



Now, you would assume that the squashfs-partition is broken - but if
this was the case then a reboot should not help. It does.
Rebooting the router after it boots in this faulty state fixes the issue.

So approximately 1-2% of my reboots make the router go into this
faulty state.

I am clueless on how to further investigate this issue. For now my
work around is restarting the router via a bash script should it
notice there are bus-errors or i/o errors.

Thanks


In the next kernel bump, following patch is also present:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.38=2ed1d90162a0c0683ecbe0c4802187fa22d641c3


I think it's worth a shot to retry the tests once it's bumped.

Koen



My guess is that the error already happens when reading the flash.
Is your firmware (sysupgrade)

Re: SquashFS mixed errors (decompression failed and others)

[Vincent Wiemann]

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 confident that it is not the
sysupgrade process that is the culprit - so what I did was that I put
one test router into a reboot loop.

This is what I do;

Boot the router in a fresh state after a newly installed image.
The image contains a reboot loop that consists of a shell script that
runs every minute.

The shell script tries to run a php-script which simply echoes "Hello
World". If the php-script exists normally then we reboot the router.

However the php-script exists abnormally then the router stops and
does nothing other than informing me that there was a bus-error making
php not able to process the hello world script.

When this process runs the router reboots approximately 50 times
before it boots into a state which is faulty where I see bus-errors
when I try to run php scripts for example.


Looking into dmesg you can see some errors such as,

[10985.209438] SQUASHFS error: squashfs_read_data failed to read block 
0x3a803e
[11045.218685] SQUASHFS error: xz decompression failed, data probably 
corrupt
[11045.218731] SQUASHFS error: squashfs_read_data failed to read block 
0x3a803e
[11105.228157] SQUASHFS error: xz decompression failed, data probably 
corrupt
[11105.228203] SQUASHFS error: squashfs_read_data failed to read block 
0x3a803e


or

[26218.687905] SQUASHFS error: Unable to read page, block 1b99a, size 
10234

[26221.057472] SQUASHFS error: Unable to read data cache entry [1b99a]
[26221.057551] SQUASHFS error: Unable to read page, block 1b99a, size 
10234

[26221.062926] SQUASHFS error: Unable to read data cache entry [1b99a]
[26221.069742] SQUASHFS error: Unable to read page, block 1b99a, size 
10234

[26224.460239] SQUASHFS error: Unable to read data cache entry [1b99a]
[26224.460320] SQUASHFS error: Unable to read page, block 1b99a, size 
10234


or

[62745.801178] SQUASHFS error: squashfs_read_data failed to read block 
0x732ae2
[62773.347234] SQUASHFS error: xz decompression failed, data probably 
corrupt
[62773.347281] SQUASHFS error: squashfs_read_data failed to read block 
0x732ae2
[62790.132661] SQUASHFS error: xz decompression failed, data probably 
corrupt
[62790.132706] SQUASHFS error: squashfs_read_data failed to read block 
0x732ae2
[62790.216746] SQUASHFS error: xz decompression failed, data probably 
corrupt
[62790.216792] SQUASHFS error: squashfs_read_data failed to read block 
0x732ae2
[62800.810525] SQUASHFS error: xz decompression failed, data probably 
corrupt
[62800.810570] SQUASHFS error: squashfs_read_data failed to read block 
0x732ae2
[62828.336267] SQUASHFS error: xz decompression failed, data probably 
corrupt




Now, you would assume that the squashfs-partition is broken - but if
this was the case then a reboot should not help. It does.
Rebooting the router after it boots in this faulty state fixes the issue.

So approximately 1-2% of my reboots make the router go into this 
faulty state.


I am clueless on how to further investigate this issue. For now my
work around is restarting the router via a bash script should it
notice there are bus-errors or i/o errors.

Thanks


In the next kernel bump, following patch is also present:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.38=2ed1d90162a0c0683ecbe0c4802187fa22d641c3 



I think it's worth a shot to retry the tests once it's bumped.

Koen



My guess is that the error already happens when reading the flash.
Is your firmware (sysupgrade) bigger than 16MB?
So maybe it has to do with switching to 4-address-mode...

Best,

Vincent

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: SquashFS mixed errors (decompression failed and others)

[Vincent Wiemann]

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 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 confident that it is not the
sysupgrade process that is the culprit - so what I did was that I put
one test router into a reboot loop.

This is what I do;

Boot the router in a fresh state after a newly installed image.
The image contains a reboot loop that consists of a shell script that
runs every minute.

The shell script tries to run a php-script which simply echoes "Hello
World". If the php-script exists normally then we reboot the router.

However the php-script exists abnormally then the router stops and
does nothing other than informing me that there was a bus-error making
php not able to process the hello world script.

When this process runs the router reboots approximately 50 times
before it boots into a state which is faulty where I see bus-errors
when I try to run php scripts for example.


Looking into dmesg you can see some errors such as,

[10985.209438] SQUASHFS error: squashfs_read_data failed to read block 0x3a803e
[11045.218685] SQUASHFS error: xz decompression failed, data probably corrupt
[11045.218731] SQUASHFS error: squashfs_read_data failed to read block 0x3a803e
[11105.228157] SQUASHFS error: xz decompression failed, data probably corrupt
[11105.228203] SQUASHFS error: squashfs_read_data failed to read block 0x3a803e

or

[26218.687905] SQUASHFS error: Unable to read page, block 1b99a, size 10234
[26221.057472] SQUASHFS error: Unable to read data cache entry [1b99a]
[26221.057551] SQUASHFS error: Unable to read page, block 1b99a, size 10234
[26221.062926] SQUASHFS error: Unable to read data cache entry [1b99a]
[26221.069742] SQUASHFS error: Unable to read page, block 1b99a, size 10234
[26224.460239] SQUASHFS error: Unable to read data cache entry [1b99a]
[26224.460320] SQUASHFS error: Unable to read page, block 1b99a, size 10234

or

[62745.801178] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2
[62773.347234] SQUASHFS error: xz decompression failed, data probably corrupt
[62773.347281] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2
[62790.132661] SQUASHFS error: xz decompression failed, data probably corrupt
[62790.132706] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2
[62790.216746] SQUASHFS error: xz decompression failed, data probably corrupt
[62790.216792] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2
[62800.810525] SQUASHFS error: xz decompression failed, data probably corrupt
[62800.810570] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2
[62828.336267] SQUASHFS error: xz decompression failed, data probably corrupt



Now, you would assume that the squashfs-partition is broken - but if
this was the case then a reboot should not help. It does.
Rebooting the router after it boots in this faulty state fixes the issue.

So approximately 1-2% of my reboots make the router go into this faulty state.

I am clueless on how to further investigate this issue. For now my
work around is restarting the router via a bash script should it
notice there are bus-errors or i/o errors.

Thanks





___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Someone working on kernel 5.9?

[Vincent Wiemann]

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
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

[Vincent Wiemann]

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 connectes as a client, directly
>   e.g.: when I do dhcp o n WAN, the oruter does DHCP on the wlan network
> - connect to the LAN ports of the device to talk to the device itself.

This is not a dumb WLAN client. A WLAN client does ordinarily just have one MAC 
address (the address of the WLAN interface).
Thus you can't just bridge the WAN port with the WLAN client network. You 
either have to NAT the traffic or use WDS (3-address-mode) or
ARPNAT. Both WDS and ARPNAT are not standard-compliant and the access point 
needs to support it. Have a look at the Wiki for that.

> The router has both 2.4 GHZ and 5 GHZ radios, and I would like to be able to 
> use both transparently (e.g.: it should just work, connecting with the right 
> one, or both).
> 
> If possible then, i would like to be able to connect to multiple known 
> networks, but this is optional.
> 
> Can you give me some hints on a good setup? Or may I just use wireless client 
> and let the device do the NAT?

If that's okay for you that's the easiest way to go. Use Multiwan if you want 
to use multiple networks.

> 
> Sorry Bjorn for the direct CC but I know you experienced with ath79 
> snapshots and maybe DS, if applicable in this case...
> 


Best,

Vincent

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

[Vincent Wiemann]

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 different 802.11s mesh links (for trust on first use).
But as far as I could see hostapd was not able to use per-station PSKs at
that time. If yes, could you try to cover that case?

Best,

Vincent

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

[Vincent Wiemann]

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 specific
> release, use "milestones", automatically find commits that satisfy a 
> goal, etc.
> 
> 
> 
> I find it very confusing that there are so many different places for bugs to 
> live and be tracked.
> 
> What's going on with gitlab? Is that going to be the source of truth for 
> OpenWRT? Or will we always have 3 different bug trackers?
> 


The outcome of the discussions was quite clear. Gitlab will likely become the 
"source of truth" mirroring/merging everything as you said.
You can still create issues on Github/Flyspray and you'll find all of them on 
Gitlab.
But that still needs a lot of work. It would be great if you could participate 
in the evaluation process if you are familiar with Gitlab.
https://github.com/openwrt/openwrt/pull/2218

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

[Vincent Wiemann]

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 LED was turned of, it "flickered" when it was set 
>> disabled.
>> Unfortunately I didn't have time to look into it, yet.

> the led code will just be used if you set a trigger. otherwise it doesnt 
> touch the gpios.
> the code itself was written to make use of the led's builtin to several 
> routers. if you dont set a led trigger, nothing will happen
> 

Thank you for your quick response... I'll try to reproduce the issue without 
your patch.
Maybe it's unrelated and a firmware-specific issue (official QCA9887).

One thing I've seen with your patch is that if I set the ath10k GPIO "steady 
on" it sometimes
(quite randomly) turns it off for a fraction of a second. It happens about 3 
times a minute.
It's not a big deal. But maybe it's related to the flickering
I've observed and possibly also a firmware issue...

Best,

Vincent


>> Best,
>>
>> Vincent
>>
>> On 20.05.20 09:39, Sebastian Gottschall wrote:
>>> this code is not in use in its original form for ipq4019.
>>> i have seen that his patch is also dropped from ath.git but is still in use 
>>> by openwrt.
>>> could somone clarify the state here and why it was dropped?
>>> the original patch i wrote does exclude the soc chipsets, but the patch was 
>>> later reorganized and some part have been rewritten
>>> so i'm not sure if it covers the scenario mentioned here, which i did take 
>>> care of
>>>
>>> Sebastian
>>>
>>> Am 26.02.2019 um 10:16 schrieb Sven Eckelmann:
>>>> On Friday, 6 April 2018 17:17:55 CET Kalle Valo wrote:
>>>>> From: Sebastian Gottschall 
>>>>>
>>>>> Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based
>>>>> chipsets with on chipset connected led's using WMI Firmware API.  The LED
>>>>> device will get available named as "ath10k-phyX" at sysfs and can be 
>>>>> controlled
>>>>> with various triggers.  adds also debugfs interface for gpio control.
>>>>>
>>>>> Signed-off-by: Sebastian Gottschall 
>>>>> Reviewed-by: Steve deRosier 
>>>>> [kvalo: major reorg and cleanup]
>>>>> Signed-off-by: Kalle Valo 
>>>> This patch was imported to OpenWrt in commit 61d57a2f88b9 ("mac80211: 
>>>> ath10k
>>>> add leds support") and broke the 11s support for IPQ4019 and QCA4019 (5GHz)
>>>> firmware versions 10.4-3.5.3-00053, 10.4-3.5.3-00057, 10.4-3.6-00140:
>>>>
>>>>   [  221.620803] ath10k_pci :01:00.0: wmi command 36967 timeout, 
>>>> restarting hardware
>>>>   [  221.744056] ieee80211 phy0: Hardware restart was requested
>>>>   [  225.130829] ath10k_pci :01:00.0: failed to receive control 
>>>> response completion, polling..
>>>>   [  226.170824] ath10k_pci :01:00.0: Service connect timeout
>>>>   [  226.170871] ath10k_pci :01:00.0: failed to connect htt (-110)
>>>>   [  226.252248] ath10k_pci :01:00.0: Could not init core: -110
>>>>
>>>> This was tested on an A62 with following wireless config:
>>>>
>>>>   config wifi-device 'radio0'
>>>>   option type 'mac80211'
>>>>   option channel '36'
>>>>   option hwmode '11a'
>>>>   option path 
>>>> 'soc/4000.pci/pci:00/:00:00.0/:01:00.0'
>>>>   option htmode 'VHT80'
>>>>   option disabled '0'
>>>>   option country US
>>>>    config wifi-device 'radio1'
>>>>   option type 'mac80211'
>>>>   option channel '11'
>>>>   option hwmode '11g'
>>>>   option path 'platform/soc/a00.wifi'
>>>>   option htmode 'HT20'
>>>>   option disabled '0'
>>>>   option country US
>>>>    config wifi-device 'radio2'
>>>>   option type 'mac80211'
>>>>   option channel '149'
>>>>   option hwmode '11a'
>>>>   option path 'platform/soc/a80.wifi'
>>>>   option htm

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

[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 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 Gottschall wrote:
> this code is not in use in its original form for ipq4019.
> i have seen that his patch is also dropped from ath.git but is still in use 
> by openwrt.
> could somone clarify the state here and why it was dropped?
> the original patch i wrote does exclude the soc chipsets, but the patch was 
> later reorganized and some part have been rewritten
> so i'm not sure if it covers the scenario mentioned here, which i did take 
> care of
> 
> Sebastian
> 
> Am 26.02.2019 um 10:16 schrieb Sven Eckelmann:
>> On Friday, 6 April 2018 17:17:55 CET Kalle Valo wrote:
>>> From: Sebastian Gottschall 
>>>
>>> Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based
>>> chipsets with on chipset connected led's using WMI Firmware API.  The LED
>>> device will get available named as "ath10k-phyX" at sysfs and can be 
>>> controlled
>>> with various triggers.  adds also debugfs interface for gpio control.
>>>
>>> Signed-off-by: Sebastian Gottschall 
>>> Reviewed-by: Steve deRosier 
>>> [kvalo: major reorg and cleanup]
>>> Signed-off-by: Kalle Valo 
>>
>> This patch was imported to OpenWrt in commit 61d57a2f88b9 ("mac80211: ath10k
>> add leds support") and broke the 11s support for IPQ4019 and QCA4019 (5GHz)
>> firmware versions 10.4-3.5.3-00053, 10.4-3.5.3-00057, 10.4-3.6-00140:
>>
>>  [  221.620803] ath10k_pci :01:00.0: wmi command 36967 timeout, 
>> restarting hardware
>>  [  221.744056] ieee80211 phy0: Hardware restart was requested
>>  [  225.130829] ath10k_pci :01:00.0: failed to receive control 
>> response completion, polling..
>>  [  226.170824] ath10k_pci :01:00.0: Service connect timeout
>>  [  226.170871] ath10k_pci :01:00.0: failed to connect htt (-110)
>>  [  226.252248] ath10k_pci :01:00.0: Could not init core: -110
>>
>> This was tested on an A62 with following wireless config:
>>
>>  config wifi-device 'radio0'
>>  option type 'mac80211'
>>  option channel '36'
>>  option hwmode '11a'
>>  option path 
>> 'soc/4000.pci/pci:00/:00:00.0/:01:00.0'
>>  option htmode 'VHT80'
>>  option disabled '0'
>>  option country US
>>   config wifi-device 'radio1'
>>  option type 'mac80211'
>>  option channel '11'
>>  option hwmode '11g'
>>  option path 'platform/soc/a00.wifi'
>>  option htmode 'HT20'
>>  option disabled '0'
>>  option country US
>>   config wifi-device 'radio2'
>>  option type 'mac80211'
>>  option channel '149'
>>  option hwmode '11a'
>>  option path 'platform/soc/a80.wifi'
>>  option htmode 'VHT80'
>>  option disabled '0'
>>  option country US
>>   config wifi-iface 'mesh0'
>>  option device 'radio0'
>>  option ifname 'mesh0'
>>  option network 'nwi_mesh0'
>>  option mode 'mesh'
>>  option mesh_id 'TestMesh'
>>  option mesh_fwding '1'
>>  option encryption 'none'
>>   config wifi-iface 'mesh1'
>>  option device 'radio1'
>>  option ifname 'mesh1'
>>  option network 'nwi_mesh1'
>>  option mode 'mesh'
>>  option mesh_id 'TestMesh'
>>  option encryption 'none'
>>    config wifi-iface 'mesh2'
>>  option device 'radio2'
>>  option ifname 'mesh2'
>>  option network 'nwi_mesh2'
>>  option mode 'mesh'
>>  option mesh_id 'TestMesh'
>>  option mesh_fwding '1'
>>  option encryption 'none
>>
>> Kind regards,
>> Sven
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

[Vincent Wiemann]

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 think it could save some CPU cycles/power.

Best,

CodeFetch

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] wifi/wlan isolation

[Vincent Wiemann]

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/net/br-xxx/lower_wlanxyz/brport/hairpin_mode. On my 5GHz 
> wifi, hairpin_mode is set to 1 only for wlan0. For wlan0-1 and wlan0-2 is 
> still at 0. On my 2.4GHz, hairpin_mode is set to 1 on all 6 wlan's. 
> 
> How can I solve this?
> 
> Regards,
> Hartmut
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

[Vincent Wiemann]

Hi,


On 01.10.19 12:07, Adrian Schmutzler wrote:
> Hi,
> 
>> -Original Message-
>> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On 
>> Behalf Of Petr Štetiar
>> Sent: Dienstag, 1. Oktober 2019 06:50
>> To: m...@adrianschmutzler.de
>> Cc: openwrt-devel@lists.openwrt.org
>> Subject: Re: [OpenWrt-Devel] [PATCH 19.07] ar71xx: fix sysupgrade to ath79 
>> for wndr3700v2 and wndr3800
>>
>> m...@adrianschmutzler.de  [2019-09-30 22:58:22]:
>>
>> Hi,
>>
>>> ar71xx has so many similar cases like this, which nobody ever cared about,
>>
>> well this case was properly reported and I got simply interested because of
>> the proposed `sysupgrade -F` "fix" in that bug report.
>>
>>> maybe it would be easier to just deal with this in ath79 by setting
>>> SUPPORTED_DEVICES?
>>
>> I've looked at this option first, then seen different NETGEAR_KERNEL_MAGIC 
>> and
>> NETGEAR_HW_ID for those device and I've thought, that fixing it with
>> SUPPORTED_DEVICES would just make the mess worse.
> 
> I see the point, I just wasn't expecting an attempt to fix this in the very 
> last days of ar71xx.
> 
> Nevertheless, to support older devices, you would still have to add the 
> "wndr3700" string to wndr3700v2 and wndr3800 in ath79 ...
> 
>>
>>> On the other hand, if you really think it's worth it,
>>
>> I think, that we should avoid promoting `sysupgrade -F` as a standard upgrade
>> procedure for the obvious reasons.
> 
> Definitely. However, I just added the "correct" name in ath79 for such cases, 
> i.e. TP-Link WDR3600 having
> SUPPORTED_DEVICES += tl-wdr4300
> etc.
> 
> I will have a look whether similar fixes to yours for the TP-Link devices 
> with similar setup are reasonable or not ...
> 
> Best
> 
> Adrian
> 
>>
>> -- ynezz

I think both of your approaches work well together.
A similar case where I have trouble with this scenario are the Ubiquiti AirMax 
devices.
At the moment different models with different antennas share common model 
definitions
which makes it hard to e.g. introduce antenna_gain-definitions in DTS.
Thus it would 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 devices in question?
Why do they need to be treated differently in OpenWrt?
If not the best thing could just be to do changes in ath79 only as Adrian 
suggested.

Regards,

Vincent Wiemann

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

[Vincent Wiemann]

Hi Klevis,

have you tried it with a short distance?
If you did you should better ask Ben Greear directly.

By the way ath10k gen 2 chipsets don't work very well with long distance links 
without a
special feature which implementation is only available to companies like 
Ubiquiti and very few
people who have an own reverse-engineered implementation.
It works on IPQ401X, QCA9886 and QCA9888 based chips only.

And it is not possible to set a coverage class for gen 2 devices, yet as far as 
I know due to missing
documentation and implementation (correct me if that information is outdated).
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,

Vincent Wiemann

On 20.09.19 18:30, supp...@maxnet.al wrote:
> Hello everyone,
> 
> I am trying to setup a custom made outdoor link with Apu2d2 board devices and 
> QCA9994 cards from compex. After i installed openwrt and ath10k ct driver, 
> kmod ath10k and board-2.bin the device can run a 80MHz channel in WDS AP. The 
> problem is that it won't run as station or station wds. It can scan
> the SSIDs but won't connect them. 
> 
> Any suggestion?
> 
> Thank you!
> Klevis
> 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

[Vincent Wiemann]

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 4.14.131 #0 SMP Thu Jun 27 12:18:52 2019 armv7l GNU/Linux
>> # nft flush ruleset
>> # nft add table inet filter
>> # nft add counter inet filter mycounter
>> # nft add chain inet filter output { type filter hook output priority 0 \; }
>> # nft add rule inet filter output counter name mycounter
>> Error: Could not process rule: No such file or directory
>> add rule inet filter output counter name mycounter
>> ^^^
>> # nft list ruleset
>> table inet filter {
>> counter mycounter {
>> packets 0 bytes 0
>> }
>>
>> chain output {
>> type filter hook output priority 0; policy accept;
>> }
>> }
>>
>> Running the failing command using strace I can tell that the ENOENT error is 
>> received from the kernel via Netlink.
>> It's similar to what I get if I try to reference a non-existent counter, but 
>> "mycounter" exists.
>> If I remove "name mycounter" from the command line, it works. Of course it 
>> creates an anonymous counter.
>> The message sent via Netlink looks correct, so I think that the problem 
>> resides in kernel.
>>
>>
>> On a PC with 4.15 the same command sequence works flawlessly:
>>
>> # nft flush ruleset
>> # nft add table inet filter
>> # nft add counter inet filter mycounter
>> # nft add chain inet filter output { type filter hook output priority 0 \; }
>> # nft add rule inet filter output counter name mycounter
>> # nft list ruleset
>> table inet filter {
>> counter mycounter {
>> packets 0 bytes 0
>> }
>>
>> chain output {
>> type filter hook output priority 0; policy accept;
>> counter name "mycounter"
>> }
>> }
>>
>> Any ideas?
> 
> Solved.
> For future reference:
> The kernel was missing CONFIG_NFT_OBJREF, without this option you can
> create named counters, but you can't actually use them.


This sounds like a bug/unexpected behavior.It should not be possible to create 
named references without the kernel supporting
it or at least it should give a clear error message.
It would be nice if you could report this to the netfilter mailing list.

Best,

Vincent

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

[Vincent Wiemann]

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
> improvements & pending patches?
> 

Sorry, I see... Your changes look good.
Why did you reply to your own "outdated" email?
Please post an update for knowing the current state next time when
you break the thread chain. It was not clear that you've already
implemented most of it.

>>> What I still want to implement:
>>> 1) Usable "ubus call system sysupgrade" without /sbin/sysupgrade

Isn't this covered by your patches already?

>>> 2) LuCI using new validation info

Please keep https://github.com/openwrt/luci/pull/3009
in mind when doing that.

Best,

Vincent

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

[Vincent Wiemann]

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.
>>
>> I'm looking for more complex implementation/solution. I'd like
>> firmware validation to provide more info like:
>> 1) Is firmware valid
>> 2) What makes firmware invalid if anything
>> 3) Is that possible to force firmware installation
>>
>> Having such info available would make user feedback much more
>> friendly. I'd like luci to use that new info & display a proper
>> error/warning to a user if needed.
>>
>> Some possible validation failures:
>> 1) Firmware not matching device model
>> 2) File too big to get flashed
>> 3) Checksum invalid (corrupted file)
>> 4) Signature missing (can be dangerous to flash it)

This needs to be implemented in sysupgrade so that it's available
to every script that uses it and third-party firmware without LuCI.
.

>> luci could display warnings and then offer an option to flash a
>> firmware anyway. 

Please don't offer a functionality for flashing firmware via the web-interface
when the firmware validation fails.
Someone who understands whether it is a good idea to force the flashing
is always able to use SSH and force the sysupgrade manually.
People would try to revert to stock firmware and such things with the
web-interface's flashing forcing option. This will get us a lot of tears.

>> Or display a critical error and don't offer such
>> option at all. In any case that should be much more meaningful than a
>> single error message.

From my perspective Luci should print the errorthat sysupgrade shows in STDERR 
and maybe translate it.

>> I also thought we may want to start signing OpenWrt firmwares one day.

There was a proposal for that using usign some weeks ago and a RFC on Github.

>> My question is: what do you find the best way of implementing it?
>>
>> A simple return code of bash script won't be sufficient (too many data
>> to pass, even if we decide to use some bit flags). I was thinking
>> about providing validation result using JSON. Should that be some
>> standalone app or a ubus deamon? How could we handle target-specific
>> validation steps?

Just print an error message in sysupgrade to STDERR.
Don't do overcomplicated solutions. You're on linux.
If you want to write a ubus-wrapper I'm fine with that, too,
but don't put to much effort in it. Simple solutions are best here.

> Over the last few weeks I've implemented many sysupgrade improvements.
> There are 2 patches under review right now.
> 
> What I still want to implement:
> 1) Usable "ubus call system sysupgrade" without /sbin/sysupgrade

Do you mean putting the functionality into a library which
can be called by ubus and /sbin/sysupgrade or just writing a ubus-wrapper?
If you intend to write a library, this should be done in C.

> 2) LuCI using new validation info
> 
> The later may take me quite some time as I have close to zero LuCI experience.

LuCI will be the simplest thing here.

> 
> Does anyone have any other suggestions for extra improvements?
> 
> --
> Rafał



Vincent

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

[Vincent Wiemann]

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 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 ruleset
>>> # nft add table inet filter
>>> # nft add counter inet filter mycounter
>>> # nft add chain inet filter output { type filter hook output priority 0 \; }
>>> # nft add rule inet filter output counter name mycounter
>>> Error: Could not process rule: No such file or directory
>>> add rule inet filter output counter name mycounter
>>> ^^^
>>> # nft list ruleset
>>> table inet filter {
>>> counter mycounter {
>>> packets 0 bytes 0
>>> }
>>>
>>> chain output {
>>> type filter hook output priority 0; policy accept;
>>> }
>>> }
>>>
>>> Running the failing command using strace I can tell that the ENOENT error 
>>> is received from the kernel via Netlink.
>>> It's similar to what I get if I try to reference a non-existent counter, 
>>> but "mycounter" exists.
>>> If I remove "name mycounter" from the command line, it works. Of course it 
>>> creates an anonymous counter.
>>> The message sent via Netlink looks correct, so I think that the problem 
>>> resides in kernel.
>>>
>>>
>>> On a PC with 4.15 the same command sequence works flawlessly:
>>>
>>> # nft flush ruleset
>>> # nft add table inet filter
>>> # nft add counter inet filter mycounter
>>> # nft add chain inet filter output { type filter hook output priority 0 \; }
>>> # nft add rule inet filter output counter name mycounter
>>> # nft list ruleset
>>> table inet filter {
>>> counter mycounter {
>>> packets 0 bytes 0
>>> }
>>>
>>> chain output {
>>> type filter hook output priority 0; policy accept;
>>> counter name "mycounter"
>>> }
>>> }
>>>
>>> Any ideas?
>>>
>>> Thank you,
>>>
>>> Salvatore
>>>
>>
>> Try to set mycounter into quotation marks.
> 
> I tried, it makes no difference.
> Thank you for your time.
> 

Please reply to the mailing list next time.

I don't see any OpenWrt-specific patches which could have altered the
behavior. So it is likely an upstream Linux issue.

The error message:
> Error: Could not process rule: No such file or directory

is strange. Thus I assumed it is a parsing issue.

Best,

Vincent

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

[Vincent Wiemann]

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 ruleset
> # nft add table inet filter
> # nft add counter inet filter mycounter
> # nft add chain inet filter output { type filter hook output priority 0 \; }
> # nft add rule inet filter output counter name mycounter
> Error: Could not process rule: No such file or directory
> add rule inet filter output counter name mycounter
> ^^^
> # nft list ruleset
> table inet filter {
>         counter mycounter {
>                 packets 0 bytes 0
>         }
> 
>         chain output {
>                 type filter hook output priority 0; policy accept;
>         }
> }
> 
> Running the failing command using strace I can tell that the ENOENT error is 
> received from the kernel via Netlink.
> It's similar to what I get if I try to reference a non-existent counter, but 
> "mycounter" exists.
> If I remove "name mycounter" from the command line, it works. Of course it 
> creates an anonymous counter.
> The message sent via Netlink looks correct, so I think that the problem 
> resides in kernel.
> 
> 
> On a PC with 4.15 the same command sequence works flawlessly:
> 
> # nft flush ruleset
> # nft add table inet filter
> # nft add counter inet filter mycounter
> # nft add chain inet filter output { type filter hook output priority 0 \; }
> # nft add rule inet filter output counter name mycounter
> # nft list ruleset
> table inet filter {
>         counter mycounter {
>                 packets 0 bytes 0
>         }
> 
>         chain output {
>                 type filter hook output priority 0; policy accept;
>                 counter name "mycounter"
>         }
> }
> 
> Any ideas?
> 
> Thank you,
> 
> Salvatore
> 

Try to set mycounter into quotation marks.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

[Vincent Wiemann]

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 specific major bugs blocking the release, so it looks pretty good
>>> at the moment.
>>
>> there are various LuCI bugs which need to be addressed first.
> 
> Is there a list of release blocking bugs anywhere?  I guess we are more
> than a few who would be interested in looking at unknown code, if we
> knew fixing it was critical for a release.

I assume OpenWrt's policy is similar to the Linux kernel, but as far
as I know it's undocumented.
From my perspective mostly critical bugs in the bug tracker.

> It would also be nice to know the release policy.  I.e., what makes a
> bug critical enough to block the release? 

When a default feature or important platform breaks.

> When is a buggy
> feature/platform/whatever dropped from the release instead of waiting
> for a fix?

When nobody is working on it or it takes too long.

> I believe Debian has had great success with explicit release
> goals and absolute time limits.

Encourage people to fix blocking issues and mark them as blocking/critical.
Setting an absolute time limit is not a good idea for a FOSS project as
it does not increase pressure on anyone like in a working situation and should
be a last resort only.
I think Debian is not the best example... At some point they lost many of their
developers to Ubuntu (maybe because they were used to be treated as employees 
;-D)

> Documenting workarounds is also an option, especially for optional
> features in release candidates.

This will likely frustrate users and is a last resort only.
Documenting issues is also work. Better try to fix it first.

> I can understand that major LuCI
> breakage still is considered unacceptable, but I can't really imagine
> that there are that lots of such bugs?
> 
> And documenting known issues in a release candidate will attract even
> more attention to bug fixing for the final release.  It's a win-win.

That's a good idea for non-critical issues.

> 
> 
> Bjørn
> 

It seems there really needs to be a clear, documented way of OpenWrt handling
releases.

One blocking issue I know of is the migration from ar71xx to ath79.
It's unclear whether to only release ar71xx (which lacks devices
added in the last year) or both.
Another thing is the change of the sysupgrade metadata format.
Personally I think OpenWrt is near a releasable state.

Vincent

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

[Vincent Wiemann]

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 do their magic with the Linux kernel's master and maybe they 
(unlikely) find vulnerabilities.

> Can anyone speak to whether OpenWrt builds use any/all of those techniques 
> called out to provide additional security? OpenWrt's modern kernel provides a 
> bunch of security. That may be good enough, even if builds don't use all 
> those techniques. And if we have implemented them, we can further 
> differentiate ourselves from vendor firmware...Thanks.

As Dmitry said OpenWrt is a state-of-the-art Linux distro and CVEs are 
addressed timely.
See https://openwrt.org/docs/guide-developers/security

- Stack Guards

Issues mostly fixed in Kernel 4.12.

- ASLR

On the ToDo, but takes up to 30% more space for executables.

- RELRO

Full RELRO used by default

- Fortify SRC

Conservative mode used by default

- Non-Exec Stack

That's a matter of the Linux kernel and I don't know of any configuration 
options for that.
As far as I know, it's activated by default on all platforms for which there is 
proper support
(x86-64 IA-32 SPARC PowerPC). I think there is no support for ARM and MIPS.
Regards,

Vincent

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

[Vincent Wiemann]

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 patch clairity.
> It may be simple but without test device...
> 
> Signed-off-by: Serge Vasilugin 
> 
> --- a/target/linux/generic/files/drivers/net/phy/rtl8367b.c
> +++ b/target/linux/generic/files/drivers/net/phy/rtl8367b.c
> @@ -588,6 +588,20 @@
>  {0x133E, 0x000E}, {0x133F, 0x0010},
>  };
> 
> +static const struct rtl8367b_initval rtl8367c_initvals0[] = {
> +    {0x13c2, 0x}, {0x0018, 0x0f00}, {0x0038, 0x0f00}, {0x0058, 0x0f00},
> +    {0x0078, 0x0f00}, {0x0098, 0x0f00}, {0x1d15, 0x0a69}, {0x2000, 0x1340},
> +    {0x2020, 0x1340}, {0x2040, 0x1340}, {0x2060, 0x1340}, {0x2080, 0x1340},
> +    {0x13eb, 0x15bb}, {0x1303, 0x06d6}, {0x1304, 0x0700}, {0x13E2, 0x003F},
> +    {0x13F9, 0x0090}, {0x121e, 0x03CA}, {0x1233, 0x0352}, {0x1237, 0x00a0},
> +    {0x123a, 0x0030}, {0x1239, 0x0084}, {0x0301, 0x1000}, {0x1349, 0x001F},
> +    {0x18e0, 0x4004}, {0x122b, 0x641c}, {0x1305, 0xc000}, {0x1200, 0x7fcb},
> +    {0x0884, 0x0003}, {0x06eb, 0x0001}, {0x00cf, 0x}, {0x00d0, 0x0007},
> +    {0x00ce, 0x48b0}, {0x00ce, 0x48b0}, {0x0398, 0x}, {0x0399, 0x0007},
> +    {0x0300, 0x0001}, {0x03fa, 0x0007}, {0x08c8, 0x00c0}, {0x0a30, 0x020e},
> +    {0x0800, 0x}, {0x0802, 0x}, {0x09da, 0x0017}, {0x1d32, 0x0002},
> +};
> +
>  static int rtl8367b_write_initvals(struct rtl8366_smi *smi,
>    const struct rtl8367b_initval *initvals,
>    int count)
> @@ -699,31 +713,38 @@
>  static int rtl8367b_init_regs(struct rtl8366_smi *smi)
>  {
>  const struct rtl8367b_initval *initvals;
> +    u32 chip_num;
>  u32 chip_ver;
>  u32 rlvid;
>  int count;
>  int err;
> 
>  REG_WR(smi, RTL8367B_RTL_MAGIC_ID_REG, RTL8367B_RTL_MAGIC_ID_VAL);
> +    REG_RD(smi, RTL8367B_CHIP_NUMBER_REG, _num);
>  REG_RD(smi, RTL8367B_CHIP_VER_REG, _ver);
> -
>  rlvid = (chip_ver >> RTL8367B_CHIP_VER_RLVID_SHIFT) &
>  RTL8367B_CHIP_VER_RLVID_MASK;
> 
> -    switch (rlvid) {
> -    case 0:
> -    initvals = rtl8367r_vb_initvals_0;
> -    count = ARRAY_SIZE(rtl8367r_vb_initvals_0);
> +    if( chip_num == 0x6367 || chip_num == 0x0597 || chip_num == 0x0276) {

Add space after "if" and remove space after "("

> +    initvals = rtl8367c_initvals0;
> +    count = ARRAY_SIZE(rtl8367c_initvals0);
> +    } else {
> +    printk("check chip_num=0x%x ver=0x%x...\n", chip_num, chip_ver);

Use dev_info instead of printk and say "checking" instead of "check"

> +    switch (rlvid) {
> +    case 0:
> +    initvals = rtl8367r_vb_initvals_0;
> +    count = ARRAY_SIZE(rtl8367r_vb_initvals_0);
>  break;

Wrong indentation for break

> 
> -    case 1:
> -    initvals = rtl8367r_vb_initvals_1;
> -    count = ARRAY_SIZE(rtl8367r_vb_initvals_1);
> +    case 1:
> +    initvals = rtl8367r_vb_initvals_1;
> +    count = ARRAY_SIZE(rtl8367r_vb_initvals_1);
>  break;

Wrong indentation for break

> 
> -    default:
> -    dev_err(smi->parent, "unknow rlvid %u\n", rlvid);
> -    return -ENODEV;
> +    default:
> +    dev_err(smi->parent, "unknow rlvid %u\n", rlvid);
> +    return -ENODEV;
> +    }
>  }
> 
>  /* TODO: disable RLTP */
> @@ -983,6 +1004,17 @@
>  RTL8367B_PORT_MISC_CFG_EGRESS_MODE_ORIGINAL <<
>  RTL8367B_PORT_MISC_CFG_EGRESS_MODE_SHIFT);
> 
> +    /*
> + * Enable for each phy port.
> + */
> +    for (i = 0; i < 5; i++) {
> +    int data;
> +    rtl8367b_read_phy_reg(smi, i, 0, );
> +    data &= 0xF7FF;
> +    data |= 0x200;
> +    rtl8367b_write_phy_reg(smi, i, 0, data);
> +    }
> +
>  return 0;
>  }
> 
> @@ -1501,20 +1533,26 @@
>  "chip mode");
>  return ret;
>  }
> -
> -    switch (chip_ver) {
> -    case 0x1000:
> -    chip_name = "8367RB";
> -    break;
> -    case 0x1010:
> -    chip_name = "8367R-VB";
> -    break;
> -    default:
> -    dev_err(smi->parent,
> -    "unknown chip num:%04x ver:%04x, mode:%04x\n",
> -    chip_num, chip_ver, chip_mode);
> -    return -ENODEV;
> -    }
> +    if(chip_num == 0x6367 || chip_num == 0x0597 || chip_num == 0x0276) {

Space missing after "if"

> +    chip_name = "8367C";
> +    } else

Remove newline after "else" and lower indentation of switch statement by one 
level for better readability

> +    switch (chip_ver) {
> +    case 0x1000:
> +    chip_name = "8367RB";
> +    break;
> +    case 0x1010:
> +    chip_name = "8367R-VB";
> +    break;
> +    case 0x0070: /* just hint - with wrong phy_id always read 0x0070 */
> +    dev_err(smi->parent,
> 

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

[Vincent Wiemann]

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).
> Current driver don't support EXT2 configuration but notexisting EXT0 (port 5).
> This patch allow to configure EXT2 in dts-file:
> 
> rtl8367rb {
>     compatible = "realtek,rtl8367b";
>     cpu_port = <7>;
>     realtek,extif2 = <1 0 1 1 1 1 1 1 2>; /* configuration for EXT2 */
>     mii-bus = <>;
>     phy_id = <29>;
> };
> 
> This patch is independent of the rtl8366_smi patch (set switch phy address)
> and may be helpful for device with rtl8367rb connected through EXT2.
> 
> Signed-off-by: Serge Vasilugin 
> 
> --- a/target/linux/generic/files/drivers/net/phy/rtl8367b.c
> +++ b/target/linux/generic/files/drivers/net/phy/rtl8367b.c
> @@ -137,19 +137,30 @@
> 
>  #define RTL8367B_CHIP_DEBUG1_REG    0x1304
> 
> +/* extif2 setup register */
> +#define RTL8367B_CHIP_DEBUG2_REG    0x13e2
> +
>  #define RTL8367B_DIS_REG    0x1305
>  #define   RTL8367B_DIS_SKIP_MII_RXER(_x)    BIT(12 + (_x))

One space too much after "define". Please use TABs for indentation before 
values.

>  #define   RTL8367B_DIS_RGMII_SHIFT(_x)    (4 * (_x))
>  #define   RTL8367B_DIS_RGMII_MASK    0x7
> 
> -#define RTL8367B_EXT_RGMXF_REG(_x)    (0x1306 + (_x))
> +/* extif2 digital interface select */
> +#define RTL8367B_DIS2_REG    0x13c3
> +#define    RTL8367B_DIS2_SKIP_MII_RXER_SHIFT    4
> +#define    RTL8367B_DIS2_SKIP_MII_RXER    0x10
> +#define    RTL8367B_DIS2_RGMII_SHIFT    0
> +#define    RTL8367B_DIS2_RGMII_MASK    0xF
> +/* extif2 delay config register == 0x13c5 */
> +#define RTL8367B_EXT_RGMXF_REG(_x)    ((_x) == 2 ? 0x13c5 : 0x1306 + 
> (_x))
>  #define   RTL8367B_EXT_RGMXF_DUMMY0_SHIFT    5
>  #define   RTL8367B_EXT_RGMXF_DUMMY0_MASK    0x7ff
>  #define   RTL8367B_EXT_RGMXF_TXDELAY_SHIFT    3
>  #define   RTL8367B_EXT_RGMXF_TXDELAY_MASK    1
>  #define   RTL8367B_EXT_RGMXF_RXDELAY_MASK    0x7
> 
> -#define RTL8367B_DI_FORCE_REG(_x)    (0x1310 + (_x))
> +/* extif2 digital interface force register == 0x13c4 */
> +#define RTL8367B_DI_FORCE_REG(_x)    ((_x) == 2 ? 0x13c4 : 0x1310 + (_x))
>  #define   RTL8367B_DI_FORCE_MODE    BIT(12)
>  #define   RTL8367B_DI_FORCE_NWAY    BIT(7)
>  #define   RTL8367B_DI_FORCE_TXPAUSE    BIT(6)
> @@ -754,8 +844,9 @@ static int rtl8367b_extif_set_mode(struc
>  switch (mode) {
>  case RTL8367_EXTIF_MODE_RGMII:
>  case RTL8367_EXTIF_MODE_RGMII_33V:
> -    REG_WR(smi, RTL8367B_CHIP_DEBUG0_REG, 0x0367);
> +    REG_WR(smi, RTL8367B_CHIP_DEBUG0_REG, 0x0767);
>  REG_WR(smi, RTL8367B_CHIP_DEBUG1_REG, 0x);
> +    REG_WR(smi, RTL8367B_CHIP_DEBUG2_REG, 0x01fd);
>  break;
> 
>  case RTL8367_EXTIF_MODE_TMII_MAC:
> @@ -785,9 +876,14 @@ static int rtl8367b_extif_set_mode(struc
>  return -EINVAL;
>  }
> 
> -    REG_RMW(smi, RTL8367B_DIS_REG,
> -    RTL8367B_DIS_RGMII_MASK << RTL8367B_DIS_RGMII_SHIFT(id),
> -    mode << RTL8367B_DIS_RGMII_SHIFT(id));
> +    if(id < 2)
> +    REG_RMW(smi, RTL8367B_DIS_REG,
> +    RTL8367B_DIS_RGMII_MASK << RTL8367B_DIS_RGMII_SHIFT(id),
> +    mode << RTL8367B_DIS_RGMII_SHIFT(id));
> +    else
> +    REG_RMW(smi, RTL8367B_DIS2_REG,
> +    RTL8367B_DIS2_RGMII_MASK << RTL8367B_DIS2_RGMII_SHIFT,
> +    mode << RTL8367B_DIS2_RGMII_SHIFT);
> 
>  return 0;
>  }
> @@ -931,6 +1027,10 @@ static int rtl8367b_setup(struct rtl8366
>  err = rtl8367b_extif_init_of(smi, 1, "realtek,extif1");
>  if (err)
>  return err;
> +
> +    err = rtl8367b_extif_init_of(smi, 2, "realtek,extif2");
> +    if (err)
> +    return err;
>  } else {
>  err = rtl8367b_extif_init(smi, 0, pdata->extif0_cfg);
>  if (err)
> 
> ---
> serge
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

[Vincent Wiemann]

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-file:
> 
> rtl8367 {
>     compatible = "realtek,rtl8367b";
>     phy_id = <29>; /* switch address at mii-bus */
>     realtek,extif2 = <1 0 1 1 1 1 1 1 2>;
>     mii-bus = <>;
>     cpu-port = <7>;
> }
> 
> Use default 0 address if not set.
> Backward compatibility tested on tplink archer c2 v1 (rtl8367rb switch)
> 
> Signed-off-by: Serge Vasilugin 
> 
> --- a/target/linux/generic/files/drivers/net/phy/rtl8366_smi.c
> +++ b/target/linux/generic/files/drivers/net/phy/rtl8366_smi.c
> @@ -256,7 +256,7 @@ static int __rtl8366_smi_read_reg(struct rtl8366_smi 
> *smi, u32 addr, u32 *data)
> 
>  int __rtl8366_mdio_read_reg(struct rtl8366_smi *smi, u32 addr, u32 *data)
>  {
> -    u32 phy_id = MDC_REALTEK_PHY_ADDR;
> +    u32 phy_id = smi->phy_id;
>  struct mii_bus *mbus = smi->ext_mbus;
> 
>  BUG_ON(in_interrupt());
> @@ -293,7 +293,7 @@ int __rtl8366_mdio_read_reg(struct rtl8366_smi *smi, u32 
> addr, u32 *data)
> 
>  static int __rtl8366_mdio_write_reg(struct rtl8366_smi *smi, u32 addr, u32 
> data)
>  {
> -    u32 phy_id = MDC_REALTEK_PHY_ADDR;
> +    u32 phy_id = smi->phy_id;
>  struct mii_bus *mbus = smi->ext_mbus;
> 
>  BUG_ON(in_interrupt());
> @@ -1558,6 +1558,12 @@ int rtl8366_smi_probe_of(struct platform_device *pdev, 
> struct rtl8366_smi *smi)
>  goto try_gpio;
>  }
> 
> +    of_property_read_u32(np, "phy_id", >phy_id);
> +    if(smi->phy_id < 0) {
> +    smi->phy_id = MDC_REALTEK_PHY_ADDR;
> +    }

Please add a newline here.

> +    dev_info(>dev,
> +    "switch phy addr=%d\n", smi->phy_id);

Please add a newline here.

>  return 0;
> 
>  try_gpio:
> --- a/target/linux/generic/files/drivers/net/phy/rtl8366_smi.h
> +++ b/target/linux/generic/files/drivers/net/phy/rtl8366_smi.h
> @@ -64,6 +64,7 @@ struct rtl8366_smi {
>  u8    dbg_vlan_4k_page;
>  #endif
>  struct mii_bus    *ext_mbus;
> +    int phy_id;

u32 here?

>  };
> 
>  struct rtl8366_vlan_mc {
> ---
> serge
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 

Regards,

Vincent

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

[Vincent Wiemann]

I remember it was decided that:
1. 19.07 will be the last release where image generation is turned on for 
ar71xx (oldstable-style).
2. Because of that nor more pull-requests for ar71xx were accepted but fixes.
3. 19.07 will be the last release where image generation is turned on for tiny 
devices
   and 32 MB RAM devices.
4. Pull-requests for Tiny ath79 devices will still be accepted if they're clean.
5. There will be no kernel updates for ar71xx (which was later withdrawn), 
because
   the next release should contain ath79 and people should be emphasized to 
port them to ath79

So now you have emphasized people to port devices to ath79 and you've even 
stopped them from
working on ar71xx more than once and now you want to release the next stable 
version only with something
that nobody was allowed to do maintenance on/which is basically 18.06 with a 
slightly newer kernel?
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 19.07 canary 
> 
> On Tue, 30 Jul 2019 at 20:22, Andreas Ziegler  <mailto:m...@andreas-ziegler.de>> wrote:
> 
> 
> Dmitry Tunin schrieb am 30.07.19 um 14:29:
> > Are you taking in account that many devices added during the last year
> > as ath79 won't be supported by a stable release.
> > Master is no good now for normal use. That will mean that for the next
> > year or so many users will require custom 19.07 builds.
> > That doesn't sound very good.
> >
> > Initially ath79 was expected in 19.07, but it appeared that not all
> > devices have been ported from ar71xx. So we are not ready to drop
> > ar71xx, but we are ready to support ath79.
> 
> to me, this is the only big negative thing here.
> everyone was told, that new devices have to go into ath79 - and now we
> will have a new release, lacking binaries for many many new devices
> because new device support in ar71xx was not welcome.
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org <mailto:openwrt-devel@lists.openwrt.org>
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

[Vincent Wiemann]

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 do automatically switching or
> stuff like this, I directly would have to use nl80211.
> Would be nice to split iw into a libiw and cmd iw or something like this.
> 
> Bests,
> Nick
> 
> On 21.05.19 19:34, John Crispin wrote:
>>
>> On 21/05/2019 17:44, Nick wrote:
>>> If I extend iwinfo to allow setting interfaces into monitor mode, will
>>> it be excepted?
>>> Or is iwinfo just for getting information for an interface?
>>>
>>> I use libiwinfo for abstraction for my own daemons.
>>>
>>> Bests,
>>> Nick
>>
>>
>> iwinfo is designed for introspection of the interfaces rather than
>> configuration. you should use the iw tool for that
>>
>>     John
>>
>>
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

[Vincent Wiemann]

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 27.05.19 13:43, Denis Periša wrote:
> Hi all,
> 
> This "bug" is following me for some time now.. a year at least. I'm hoping 
> day after day that someone might find reason and fix it. I've set a script 
> that checks dnsmasq and restarts it.
> 
> -->
>          if ! ( dhcping -q -h 00:99:99:99:99:99 -s 10.0.0.1 ) #Jos jedna 
> provjera
>                         then
>                                 echo "DEAD dnsmasq! - `date` " >> 
> /scripts/CRASH.log
>                                 killall dnsmasq
>                                 sleep 2
>                                 dnsmasq;
>  .>.>>>> etc... CUT ---
> 
> two checks to be sure... and I get a lot of restart messages. different nodes.
> I run this via cron every half hour.
> 
> Anyone have similar problem?
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Fix TX power handling

[Vincent Wiemann]

Hi Matthias,

thank you for the hint. That's funny, because someone from the German Federal 
Network Agency
said that when radios have multiple antennas, the aggregated EIRP of the 
antenna array must not exceed the
EIRP limits of a single antenna, but I've assumed this is done in hardware 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 detail: Don't forget the antenna array gain.
> 
> So EIRP as:
> Antenna Port Power
> + Antenna Gain
> + Antenna Array Gain
> - Cable Loss
> 
> The Array Gain as a simple lookup table:
> 1 Antenna: 0
> 2 Antennas: 3
> 3 Antennas: 5
> 4 Antennas: 6
> 
> BR
> Matthias
> 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Fix TX power handling

[Vincent Wiemann]

Hi,

I've stumbled across problems with the transmission output power of OpenWrt
routers quite often.
E.g. https://bugs.openwrt.org/index.php?do=details_id=1289=4
which I still have to look into in greater detail.
OpenWrt's handling of TX power, antenna and PA gains needs to be revised
thoroughly.

There is a iw patch in OpenWrt that is being used for setting the antenna gain.
There was one try of nbd to upstream this change in 2013:
https://www.spinics.net/lists/linux-wireless/msg111944.html

I'd like to make some things clear here and hope that there will be a new
attempt to getting this upstreamed.
First EIRP is by definition ERP + antenna gain - cable loss.
And ERP is radio chip output + PA chip gain - (board's signal path loss which 
is likely
irrelevant due to golden device calibration).

If there is a regulatory limit of the antenna gain that (whyever) means that no 
antennas
with a higher gain are allowed - this does not really make sense.
It certainly does not mean that you can exceed the EIRP
by the antenna gain as this would reduce the definition of EIRP to absurdity.
If the regulatory domain values aren't plausible (because why in the world 
should
there be a limit to the antenna gain when there is a EIRP limit already?),
we should not work around that, because otherwise nobody will see the mistake -
It is a problem of the regdb then, which likely needs to introduce a new 
regulatory
definition for maximum ERP and maximum antenna gain for affected regions, which
would still don't really make sense, but maybe laws are just weird in this 
regions.

Second e.g. most TP-Link routers don't use the ART's antenna gain field.
Instead they use the TX gain field (which should have been used for defining an
external PA chip's gain instead). I assume that they did it to circumvent 
problems
with the regdb...

Finally some device's (Ubiquiti XM/XW) external PA chip gain is defined in stock
firmware depending on the subvendor device ID of the radio chip.
These definitions are being defined in:
https://git.openwrt.org/?p=project/iwinfo.git;a=blob;f=hardware.txt
I've filed a patch which adds all PA gains of Ubiquiti XM/XW devices to iwinfo 
which
I've extracted from the stock firmware, but it seems to be ignored until now:
https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg46175.html

AFAIK OpenWrt does not make use of these values, yet leading to a much higher
EIRP than allowed if these values are not manually adjusted.

Thus to my best knowledge what has to be done is:
1. add options for external PA gain in iw and nl80211 code
2. display antenna gain and PA gain in iw
3. check if ath9k code sets PA gain and antenna gain correctly and
   if not, fix it
4. for devices whose PA gain does not seem to be defined in ART like
   Ubiquiti XM/XWs, add a hotplug script to OpenWrt that sets
   the correct PA gains from iwinfo using iw.
5. for devices whose antenna gain neither seems to be defined in ART's
   antenna gain nor it's TX gain field, add a hotplug script to OpenWrt
   that sets the correct antenna gains manually on a model basis using iw.
6. take measurements to check if the ERP meets expectations
7. upstream all these changes and make regdb 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

___
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

[Vincent Wiemann]

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 wrote:
>> This commit includes all power offsets and subsystem device IDs
>> for Ubiquiti XM and XW devices. The device ID is wildcarded.
>> Consistency has been tested among all Ubiquiti platforms.
>> These values seem to be PA gains and likely do not include
>> antenna gains. I expect the antenna gains to be defined 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
>> @@ -17,6 +17,99 @@
>>  0x 0x 0x 0xc1055  0  "Ubiquiti" "NanoStation Loco5"
>>  0x 0x 0x 0xc202   10  0  "Ubiquiti" "Bullet2"
>>  0x 0x 0x 0xc2055  0  "Ubiquiti" "Bullet5"
>> +0x168c 0x 0x0777 0xe0026  0  "Ubiquiti" "airOS XM"
>> +0x168c 0x 0x0777 0xe0033  0  "Ubiquiti" "airOS XM"
>> +0x168c 0x 0x0777 0xe0055  0  "Ubiquiti" "NanoStation M5" /* 
>> airOS XM */
>> +0x168c 0x 0x0777 0xe0065  0  "Ubiquiti" "airOS XM"
>> +0x168c 0x 0x0777 0xe0096  0  "Ubiquiti" "NanoStation Loco M9" 
>> /* airOS XM */
>> +0x168c 0x 0x0777 0xe012   10  0  "Ubiquiti" "NanoStation M2" /* 
>> airOS XM */
>> +0x168c 0x 0x0777 0xe0353  0  "Ubiquiti" "NanoStation M3" /* 
>> airOS XM */
>> +0x168c 0x 0x0777 0xe0a22  0  "Ubiquiti" "NanoStation Loco M2" 
>> /* airOS XM */
>> +0x168c 0x 0x0777 0xe0a51  0  "Ubiquiti" "NanoStation Loco M5" 
>> /* airOS XM */
>> +0x168c 0x 0x0777 0xe1026  0  "Ubiquiti" "airOS XM"
>> +0x168c 0x 0x0777 0xe1055  0  "Ubiquiti" "Rocket M5" /* airOS XM 
>> */
>> +0x168c 0x 0x0777 0xe112   10  0  "Ubiquiti" "airOS XM"
>> +0x168c 0x 0x0777 0xe1153  0  "Ubiquiti" "airOS XM"
>> +0x168c 0x 0x0777 0xe1a33  0  "Ubiquiti" "airOS XM"
>> +0x168c 0x 0x0777 0xe1a55  0  "Ubiquiti" "PowerBridge M5" /* 
>> airOS XM */
>> +0x168c 0x 0x0777 0xe1b2   10  0  "Ubiquiti" "airOS XM"
>> +0x168c 0x 0x0777 0xe1b33  0  "Ubiquiti" "airOS XM"
>> +0x168c 0x 0x0777 0xe1b55  0  "Ubiquiti" "Rocket M5" /* airOS XM 
>> */
>> +0x168c 0x 0x0777 0xe1b65  0  "Ubiquiti" "airOS XM"
>> +0x168c 0x 0x0777 0xe1b96  0  "Ubiquiti" "Rocket M9" /* airOS XM 
>> */
>> +0x168c 0x 0x0777 0xe1c2   10  0  "Ubiquiti" "airOS XM"
>> +0x168c 0x 0x0777 0xe1c33  0  "Ubiquiti" "Rocket M3" /* airOS XM 
>> */
>> +0x168c 0x 0x0777 0xe1c55  0  "Ubiquiti" "Rocket M5 GPS" /* 
>> airOS XM */
>> +0x168c 0x 0x0777 0xe1c55  0  "Ubiquiti" "airOS XM"
>> +0x168c 0x 0x0777 0xe1d2   10  0  "Ubiquiti" "Rocket M2 Titanium" /* 
>> airOS XM/XW */
>> +0x168c 0x 0x0777 0xe1d33  0  "Ubiquiti" "airOS XM"
>> +0x168c 0x 0x0777 0xe1d55  0  "Ubiquiti" "airOS XM/XW"
>> +0x168c 0x 0x0777 0xe1d96  0  "Ubiquiti" "airOS XM"
>> +0x168c 0x 0x0777 0xe1e33  0  "Ubiquiti" "airOS XM"
>> +0x168c 0x 0x0777 0xe1e55  0  "Ubiquiti" "airOS XM"
>> +0x168c 0x 0x0777 0xe202   12  0  "Ubiquiti" "Bullet M2" /* airOS XM 
>> */
>> +0x168c 0x 0x0777 0xe2056  0  "Ubiquiti" "Bullet M5" /* airOS XM 
>> */
>> +0x168c 0x 0x0777 0xe2121  0  "Ubiquiti" "AirGrid M2" /* airOS 
>> XM */
>> +0x168c 0x 0x0777 0xe2151  0  "Ubiquiti" "AirGrid

Re: [OpenWrt-Devel] OpenWrt 19.03 plans

[Vincent Wiemann]

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 motivated to do it,
delay it. After a due date, cut it and release the rest with a lack for
a specific feature and other people might get motivated, but that is the
last resort.

Personally I think one release a year is enough, except when there are
critical security issues which deserve an own release, but that is another
topic.

Regards,

Vincent

On 10.04.2019 06:04, Eric Luehrsen wrote:
> Or that is $0.023647, anyway. :-)
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWrt 19.03 plans

[Vincent Wiemann]

Hi Bjørn,

routers are critical infrastructure. We should try to achieve the best we can.
One of the reasons for the Lede split was that problems were procrastinated
and accumulated over the release timeline.
That's the reason why we should release less often, but with a higher quality.

If problems delay a release that is a sign of taking responsibility.

Some time ago a friend of mine told me that they have a problem with tickets 
that
nobody wants to take care of. I told him when those tickets appear he
should automatically assign them to all people with highest priority after a due
date even if it is a minor issue. Productivity has increased rapidly since then.

If a device is not supported in a specific release, that might give someone the
stimulus to sit down and get this device working again.
E.g. many devices have a partition layout on which a bigger kernel does not fit.
It is possible to change the partition layout in most cases requiring a 
modification
of the U-Boot boot environment variable. So hard it sounds unfortunately someone
needs to be urged to do it. It's the same with porting ar71xx to ath79...
When we stop generating ar71xx images some device owners wonder why there is no
new release for it. They become aware that they need to sort of add support for
this device as if it was a new device support and they might do it.
Urging is a bad word, but we need to motivate people to do changes which are not
of the fun kind or we might end up in a 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 top of my head:
>>
>> - make sure all targets are ported properly to 4.14
>> - disable all devices which cannot cannot handle the increased kernel
>>   size anymore
>> - drop all targets which are not ported to 4.14
>> - fix important open issues in the tracker
> 
> Apologies if this is out of line...  I just fealt the urge to post my
> personal opinion, FWIW.
> 
> It seems to me that you are setting way too high standards for
> yourselves.  From my point of view, the OpenWrt master branch is almost
> always in a releasable state. The OpenWrt development and review process
> ensures an extremely high quality, even for targets which are considered
> WiP. There are very few days over the last 6 months where you could not
> have decided to cut a release branch, and got away with it.  It's
> something to be proud of! But you need to tell the rest of the world
> that you are proud of this by making releases.
> 
> You should accept that the targets which are ported properly to 4.14
> defines "all targets" for the next release.  It's not the other way
> round.  Any remaining targets which can be expected to be ported to 4.14
> or later, if any, can and should be deferred for a later release.  Note
> that accepting this means that there could be a "next release" in 2019
> too...
> 
> You should also accept that there will be unfixed important open issues
> at all times.  You can't fix them all.  To make a release, these issues
> will either have to be
>  - ignored for that release,
>  - demoted to less important. or
>  - removed by removing the feature/target/whatever is affected by the
>issue from the release
> 
> Look at the Debian "release critical" bug handling.  It's not really
> about fixing all the RC bugs, but dealing with them.
> 
> I realize that actually making a release is real work too, and that this
> has to take some time after making the initial cut.  But delaying the
> cut for the master branch to get in an even "more ready" state is not
> really helping...
> 
> Just my .021 € (considering inflation)
> 
> 
> Bjørn
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 

___
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

[Vincent Wiemann]

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 device ID is wildcarded.
> Consistency has been tested among all Ubiquiti platforms.
> These values seem to be PA gains and likely do not include
> antenna gains. I expect the antenna gains to be defined 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
> @@ -17,6 +17,99 @@
>  0x 0x 0x 0xc1055  0  "Ubiquiti" "NanoStation Loco5"
>  0x 0x 0x 0xc202   10  0  "Ubiquiti" "Bullet2"
>  0x 0x 0x 0xc2055  0  "Ubiquiti" "Bullet5"
> +0x168c 0x 0x0777 0xe0026  0  "Ubiquiti" "airOS XM"
> +0x168c 0x 0x0777 0xe0033  0  "Ubiquiti" "airOS XM"
> +0x168c 0x 0x0777 0xe0055  0  "Ubiquiti" "NanoStation M5" /* 
> airOS XM */
> +0x168c 0x 0x0777 0xe0065  0  "Ubiquiti" "airOS XM"
> +0x168c 0x 0x0777 0xe0096  0  "Ubiquiti" "NanoStation Loco M9" /* 
> airOS XM */
> +0x168c 0x 0x0777 0xe012   10  0  "Ubiquiti" "NanoStation M2" /* 
> airOS XM */
> +0x168c 0x 0x0777 0xe0353  0  "Ubiquiti" "NanoStation M3" /* 
> airOS XM */
> +0x168c 0x 0x0777 0xe0a22  0  "Ubiquiti" "NanoStation Loco M2" /* 
> airOS XM */
> +0x168c 0x 0x0777 0xe0a51  0  "Ubiquiti" "NanoStation Loco M5" /* 
> airOS XM */
> +0x168c 0x 0x0777 0xe1026  0  "Ubiquiti" "airOS XM"
> +0x168c 0x 0x0777 0xe1055  0  "Ubiquiti" "Rocket M5" /* airOS XM 
> */
> +0x168c 0x 0x0777 0xe112   10  0  "Ubiquiti" "airOS XM"
> +0x168c 0x 0x0777 0xe1153  0  "Ubiquiti" "airOS XM"
> +0x168c 0x 0x0777 0xe1a33  0  "Ubiquiti" "airOS XM"
> +0x168c 0x 0x0777 0xe1a55  0  "Ubiquiti" "PowerBridge M5" /* 
> airOS XM */
> +0x168c 0x 0x0777 0xe1b2   10  0  "Ubiquiti" "airOS XM"
> +0x168c 0x 0x0777 0xe1b33  0  "Ubiquiti" "airOS XM"
> +0x168c 0x 0x0777 0xe1b55  0  "Ubiquiti" "Rocket M5" /* airOS XM 
> */
> +0x168c 0x 0x0777 0xe1b65  0  "Ubiquiti" "airOS XM"
> +0x168c 0x 0x0777 0xe1b96  0  "Ubiquiti" "Rocket M9" /* airOS XM 
> */
> +0x168c 0x 0x0777 0xe1c2   10  0  "Ubiquiti" "airOS XM"
> +0x168c 0x 0x0777 0xe1c33  0  "Ubiquiti" "Rocket M3" /* airOS XM 
> */
> +0x168c 0x 0x0777 0xe1c55  0  "Ubiquiti" "Rocket M5 GPS" /* airOS 
> XM */
> +0x168c 0x 0x0777 0xe1c55  0  "Ubiquiti" "airOS XM"
> +0x168c 0x 0x0777 0xe1d2   10  0  "Ubiquiti" "Rocket M2 Titanium" /* 
> airOS XM/XW */
> +0x168c 0x 0x0777 0xe1d33  0  "Ubiquiti" "airOS XM"
> +0x168c 0x 0x0777 0xe1d55  0  "Ubiquiti" "airOS XM/XW"
> +0x168c 0x 0x0777 0xe1d96  0  "Ubiquiti" "airOS XM"
> +0x168c 0x 0x0777 0xe1e33  0  "Ubiquiti" "airOS XM"
> +0x168c 0x 0x0777 0xe1e55  0  "Ubiquiti" "airOS XM"
> +0x168c 0x 0x0777 0xe202   12  0  "Ubiquiti" "Bullet M2" /* airOS XM 
> */
> +0x168c 0x 0x0777 0xe2056  0  "Ubiquiti" "Bullet M5" /* airOS XM 
> */
> +0x168c 0x 0x0777 0xe2121  0  "Ubiquiti" "AirGrid M2" /* airOS XM 
> */
> +0x168c 0x 0x0777 0xe2151  0  "Ubiquiti" "AirGrid M5" /* airOS XM 
> */
> +0x168c 0x 0x0777 0xe2322  0  "Ubiquiti" "NanoBridge M2" /* airOS 
> XM */
> +0x168c 0x 0x0777 0xe2333  0  "Ubiquiti" "airOS XM"
> +0x168c 0x 0x0777 0xe2351  0  "Ubiquiti" "NanoBridge M5" /* airOS 
> XM */
> +0x168c 0x 0x0777 0xe2396  0  &quo

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

[Vincent Wiemann]

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

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

[Vincent Wiemann]

This commit includes all power offsets and subsystem device IDs
for Ubiquiti XM and XW devices. The device ID is wildcarded.
Consistency has been tested among all Ubiquiti platforms.
These values seem to be PA gains and likely do not include
antenna gains. I expect the antenna gains to be defined 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
@@ -17,6 +17,99 @@
 0x 0x 0x 0xc1055  0  "Ubiquiti" "NanoStation Loco5"
 0x 0x 0x 0xc202   10  0  "Ubiquiti" "Bullet2"
 0x 0x 0x 0xc2055  0  "Ubiquiti" "Bullet5"
+0x168c 0x 0x0777 0xe0026  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe0033  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe0055  0  "Ubiquiti" "NanoStation M5" /* airOS 
XM */
+0x168c 0x 0x0777 0xe0065  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe0096  0  "Ubiquiti" "NanoStation Loco M9" /* 
airOS XM */
+0x168c 0x 0x0777 0xe012   10  0  "Ubiquiti" "NanoStation M2" /* airOS 
XM */
+0x168c 0x 0x0777 0xe0353  0  "Ubiquiti" "NanoStation M3" /* airOS 
XM */
+0x168c 0x 0x0777 0xe0a22  0  "Ubiquiti" "NanoStation Loco M2" /* 
airOS XM */
+0x168c 0x 0x0777 0xe0a51  0  "Ubiquiti" "NanoStation Loco M5" /* 
airOS XM */
+0x168c 0x 0x0777 0xe1026  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1055  0  "Ubiquiti" "Rocket M5" /* airOS XM */
+0x168c 0x 0x0777 0xe112   10  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1153  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1a33  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1a55  0  "Ubiquiti" "PowerBridge M5" /* airOS 
XM */
+0x168c 0x 0x0777 0xe1b2   10  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1b33  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1b55  0  "Ubiquiti" "Rocket M5" /* airOS XM */
+0x168c 0x 0x0777 0xe1b65  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1b96  0  "Ubiquiti" "Rocket M9" /* airOS XM */
+0x168c 0x 0x0777 0xe1c2   10  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1c33  0  "Ubiquiti" "Rocket M3" /* airOS XM */
+0x168c 0x 0x0777 0xe1c55  0  "Ubiquiti" "Rocket M5 GPS" /* airOS 
XM */
+0x168c 0x 0x0777 0xe1c55  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1d2   10  0  "Ubiquiti" "Rocket M2 Titanium" /* 
airOS XM/XW */
+0x168c 0x 0x0777 0xe1d33  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1d55  0  "Ubiquiti" "airOS XM/XW"
+0x168c 0x 0x0777 0xe1d96  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1e33  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1e55  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe202   12  0  "Ubiquiti" "Bullet M2" /* airOS XM */
+0x168c 0x 0x0777 0xe2056  0  "Ubiquiti" "Bullet M5" /* airOS XM */
+0x168c 0x 0x0777 0xe2121  0  "Ubiquiti" "AirGrid M2" /* airOS XM */
+0x168c 0x 0x0777 0xe2151  0  "Ubiquiti" "AirGrid M5" /* airOS XM */
+0x168c 0x 0x0777 0xe2322  0  "Ubiquiti" "NanoBridge M2" /* airOS 
XM */
+0x168c 0x 0x0777 0xe2333  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe2351  0  "Ubiquiti" "NanoBridge M5" /* airOS 
XM */
+0x168c 0x 0x0777 0xe2396  0  "Ubiquiti" "NanoBridge M9" /* airOS 
XM */
+0x168c 0x 0x0777 0xe2429  0  "Ubiquiti" "AirGrid M2 HP" /* airOS 
XM */
+0x168c 0x 0x0777 0xe2433  0  "Ubiquiti" "NanoBridge M3" /* airOS 
XM */
+0x168c 0x 0x0777 0xe2456  0  "Ubiquiti" "AirGrid M5 HP" /* airOS 
XM */
+0x168c 0x 0x0777 0xe2529  0  "Ubiquiti" "AirGrid M2 HP" /* airOS 
XM */
+0x168c 0x 0x0777 0xe2556  0  "Ubiquiti" "AirGrid M5 HP" /* airOS

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

[Vincent Wiemann]

This commit includes all power offsets and subsystem device IDs
for Ubiquiti XM and XW devices. The device ID is wildcarded.
Consistency has been tested among all Ubiquiti platforms.
These values seem to be PA gains and likely do not include
antenna gains. I expect the antenna gains to be defined 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
@@ -17,6 +17,99 @@
 0x 0x 0x 0xc1055  0  "Ubiquiti" "NanoStation Loco5"
 0x 0x 0x 0xc202   10  0  "Ubiquiti" "Bullet2"
 0x 0x 0x 0xc2055  0  "Ubiquiti" "Bullet5"
+0x168c 0x 0x0777 0xe0026  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe0033  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe0055  0  "Ubiquiti" "NanoStation M5" /*
airOS XM */
+0x168c 0x 0x0777 0xe0065  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe0096  0  "Ubiquiti" "NanoStation Loco
M9" /* airOS XM */
+0x168c 0x 0x0777 0xe012   10  0  "Ubiquiti" "NanoStation M2" /*
airOS XM */
+0x168c 0x 0x0777 0xe0353  0  "Ubiquiti" "NanoStation M3" /*
airOS XM */
+0x168c 0x 0x0777 0xe0a22  0  "Ubiquiti" "NanoStation Loco
M2" /* airOS XM */
+0x168c 0x 0x0777 0xe0a51  0  "Ubiquiti" "NanoStation Loco
M5" /* airOS XM */
+0x168c 0x 0x0777 0xe1026  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1055  0  "Ubiquiti" "Rocket M5" /*
airOS XM */
+0x168c 0x 0x0777 0xe112   10  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1153  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1a33  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1a55  0  "Ubiquiti" "PowerBridge M5" /*
airOS XM */
+0x168c 0x 0x0777 0xe1b2   10  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1b33  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1b55  0  "Ubiquiti" "Rocket M5" /*
airOS XM */
+0x168c 0x 0x0777 0xe1b65  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1b96  0  "Ubiquiti" "Rocket M9" /*
airOS XM */
+0x168c 0x 0x0777 0xe1c2   10  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1c33  0  "Ubiquiti" "Rocket M3" /*
airOS XM */
+0x168c 0x 0x0777 0xe1c55  0  "Ubiquiti" "Rocket M5 GPS" /*
airOS XM */
+0x168c 0x 0x0777 0xe1c55  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1d2   10  0  "Ubiquiti" "Rocket M2
Titanium" /* airOS XM/XW */
+0x168c 0x 0x0777 0xe1d33  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1d55  0  "Ubiquiti" "airOS XM/XW"
+0x168c 0x 0x0777 0xe1d96  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1e33  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe1e55  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe202   12  0  "Ubiquiti" "Bullet M2" /*
airOS XM */
+0x168c 0x 0x0777 0xe2056  0  "Ubiquiti" "Bullet M5" /*
airOS XM */
+0x168c 0x 0x0777 0xe2121  0  "Ubiquiti" "AirGrid M2" /*
airOS XM */
+0x168c 0x 0x0777 0xe2151  0  "Ubiquiti" "AirGrid M5" /*
airOS XM */
+0x168c 0x 0x0777 0xe2322  0  "Ubiquiti" "NanoBridge M2" /*
airOS XM */
+0x168c 0x 0x0777 0xe2333  0  "Ubiquiti" "airOS XM"
+0x168c 0x 0x0777 0xe2351  0  "Ubiquiti" "NanoBridge M5" /*
airOS XM */
+0x168c 0x 0x0777 0xe2396  0  "Ubiquiti" "NanoBridge M9" /*
airOS XM */
+0x168c 0x 0x0777 0xe2429  0  "Ubiquiti" "AirGrid M2 HP" /*
airOS XM */
+0x168c 0x 0x0777 0xe2433  0  "Ubiquiti" "NanoBridge M3" /*
airOS XM */
+0x168c 0x 0x0777 0xe2456  0  "Ubiquiti" "AirGrid M5 HP" /*
airOS XM */
+0x168c 0x 0x0777 0xe2529  0  "Ubiquiti" "AirGrid M2 HP" /*
airOS XM */
+0x168c 0x 0x0777 0xe2556  0  "Ubiquiti" "AirGrid M5 HP" /*
airOS XM */
+0x16

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

[Vincent Wiemann]

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, to answer my question: today we received an email from Belkin/Linksys,
> asking for a shipping address.
> 

Kind regards,
CodeFetch
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

[Vincent Wiemann]

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 those changes to the filesystem/flash.
It doesn't matter whether you use the command line tool or lua
bindings... „Commit“ will kill your flashchip in the long run :D.
Ordinarily OpenWrt doesn't do any write to flash without user interaction.

Regards,
CodeFetch
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

[Vincent Wiemann]

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
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

[Vincent Wiemann]

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,
CodeFetch
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

[Vincent Wiemann]

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 m...@bibbl.com


--- 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-615-e4)
ucidef_set_led_switch lan4 LAN4 d-link:green:lan4 switch0 0x10
;;

+dir-615-c1)
+   ucidef_set_led_netdev wan WAN d-link:green:wan eth1
+   ucidef_set_led_wlan wlan WLAN d-link:green:wlan phy0tpt
+   ;;
+
 dir-825-b1)
ucidef_set_led_usbdev usb USB d-link:blue:usb 1-1
;;



signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel