date:20200714

Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules

2020-07-14 Thread Bjørn Mork

Perry  writes:

> With dsaconfig, all vlans get tagged on the switch to "self". I
> understand this as tagging the cpu port.
>
> It is exactly this step which I skip to have unmanageable switched
> vlans.  The devices do not show up with "ip l" but the vlans can be seen
> with "bridge v".

Yes, I'd also like to avoid unnecessarily switching every packet to the
CPU port (assuming it will be in prmisc mode from time to time). It
would be nice if we could add only the necessary VLANs there. I.e. VLAN
interfaces with IP config, or being members of another bridge, or
backing PPPoE, or whatever

But I don't know how to implement that automagically. I wouldn't want to
be forced to explicitly configure this either. 

Bjørn

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

Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules

2020-07-14 Thread Luiz Angelo Daros de Luca

> > config bridge br-lan <- the real bridge device name
>
> This is invalid uci syntax, dashes are not allowed. It also duplicates "config
> device" with "option type bridge".

Yes, "config device" is better. If used, a wireless definition would
now reference a device
and not an interface.

> >   option type "auto" # use the best way to merge every ports
>
> What possible ways would there be?

The bridge type to use. It could be a software bridge, DSA,
swconfig, openvswitch.
But with a device section, "option type 'openvswitch'" might already cover it.

> It might be a matter of taste but personally I don't see what is easier about
> it. The main change seems to be that instead by VLAN ID, your proposal groups
> the port memberships by bridge. So instead having a vlan section that attaches
> ports to a bridge, you declare a bridge containing ports with their respective
> VLAN IDs.

A bridge is a broader concept than a vlan inside a switch. It might
include ports that
use different vlans (although not very common) or devices outside the switch.
Linux configures DSA using the bridge concept and not vlans. I think using vlan
would simply make it harder to map or limit what you can do with it.

I'm still ignorant about DSA and all I know is only from docs. Would
it be possible
to simply connect any ethernet device to a DSA bridge? Something like:

ip link add name br0 type bridge
ip link set dev lan1 master br0
ip link set dev lan2 master br0
ip link set dev lan3 master br0
ip link set dev usb0 master br0

> > The main points are to split L2 and L3 confs, split port list into
> > individual options and let the system decide the best way to implement
> > the proposed setup.
>
> Point 1 is already doable, point 2 can be easily added (in fact changing
> "option ports 'lan1 lan2 lan3'" to "list ports lan1; list ports lan2; list
> ports lan3" is possible without changing any code).
>
> I disagree with point 3. Having a network config that automagically translates
> into different things on different boards makes debugging potential issues
> very hard. The uci network config is too low level for that imho.

You are right. It would not be nice to have too much implicit
configuration. A more complex
setup might use a device that references other devices.

Regard,

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

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

Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules

2020-07-14 Thread Perry

Hi,

In the setup that I have (dsa), in addition to creating interfaces which
are managed, I also have vlans which are not managed at all, thus having
pure switching for these specific vlans.

With dsaconfig, all vlans get tagged on the switch to "self". I
understand this as tagging the cpu port.

It is exactly this step which I skip to have unmanageable switched
vlans.  The devices do not show up with "ip l" but the vlans can be seen
with "bridge v".

I would propose adding an option something like this:

config dsa_vlan
option vlan 500
option ports 'lan3.t lan4.t'
option cpuport '0' # default value is 1

The CPU Port with the swconfig setup is always some number which changes
from router to router followed by a 't'.  This way, tagging the cpu port
is the default but can be overridden.

Greets,
Perry

On 7/14/20 5:34 PM, Josh Bendavid wrote:
> Hi,
> I have a somewhat radical comment on this.
> 
> As far as I understand, the vlan filtering support in the linux bridge
> subsystem is not specific to dsa, but can equally be configured for a
> pure software bridge.  The fact that the switch supports dsa/switchdev
> then simply allows this to be transparently handled in hardware, just
> like the simple bridging of the switch port interfaces.
> 
> Isn't it conceptually more correct in this case for the vlan filtering
> to be configured as part of the "interface" in uci?
> Ie I configure an interface of type "bridge" which bridges the switch
> ports, then the vlan filtering is a configuration property of this
> interface (just like enabling igmp_snooping on a bridge interface)
> 
> Thanks,
> Josh
> 
> On Tue, 7 Jul 2020 at 22:13, Jo-Philipp Wich  wrote:
>>
>> This patch series introduces a new package "dsaconfig" which provides the
>> necessary logic to allow configuration of bridge vlan filter rules for
>> DSA switches.
>>
>> While well supported DSA switches can be programmed by solely bridging
>> per-port netdevices together, explicit bridge VLAN filter rules are needed
>> for more complex scenarios or for DSA switches that do not support a
>> tagging protocol.
>>
>> The UCI configuration interpreted by the dsaconfig package closely follows
>> the structure and semantics of the legacy swconfig architecture, honouring
>> "dsa", "dsa_vlan" and "dsa_port" sections within the
>> /etc/config/network file. The only difference compared to swconfig is
>> that "dsa" sections are optional and that the syntax of ports within
>> the "dsa_vlan" section differs, instead of ?, e.g.
>> "0t", "1u" or "2", it is now (.)?, e.g. "wan.u", "lan1.t"
>> or "lan2".
>>
>> The dsaconfig package will spawn a bridge device named "switchN" for each
>> DSA switch, where N denotes the number of the switch. In contrast to
>> swconfig, interfaces do not use the CPU port to target VLAN port groups on
>> the switch but reference a VLAN on top of the switch, e.g.
>> "option ifname switch0.1" to use the VLAN 1 port group on the first DSA
>> switch.
>>
>> A complete configuration example for a simple LAN/WAN setup might look
>> like below. Note that this configuration should be equivalent to just
>> bridging lan1..lan4 without any VLAN filter rules.
>>
>> -- 8< --
>> config dsa_vlan
>>   option vlan 1
>>   option ports 'lan1 lan2 lan3 lan4'
>>
>> config dsa_vlan
>>   option vlan 2
>>   option ports 'wan'
>>
>> config interface lan
>>   option ifname switch0.1
>>   option proto static
>>   option ipaddr 192.168.1.1/24
>>
>> config interface wan
>>   option ifname switch0.2
>>   option proto dhcp
>> -- >8 --
>>
>> A slightly more complex example that uses multiple tagged VLANs on different
>> ports would look like this:
>>
>> -- 8< --
>> config dsa switch0
>>   ## Override CPU port. Normally it is auto-discovered.
>>   #option cpu_port eth0
>>
>> config dsa_vlan
>>   ## Specify the switch this vlan belongs to.
>>   ## If there is only one switch on the system, it may be omitted.
>>   #option device switch0
>>   option vlan 1
>>   option ports 'lan1 lan2.t'
>>
>> config dsa_vlan
>>   #option device switch0
>>   option vlan 2
>>   option ports 'wan'
>>
>> config dsa_vlan
>>   #option device switch0
>>   option vlan 5
>>   option ports 'lan2.t lan3'
>>
>> config dsa_vlan
>>   #option device switch0
>>   option vlan 8
>>   option ports 'lan2.t lan4'
>>
>> config dsa_vlan
>>   #option device switch0
>>   option vlan 11
>>   option ports 'lan2.t lan4.t'
>>
>> config dsa_port
>>   #option device switch0
>>   option port lan2
>>   ## By default, the port PVID is set to the ID of the first
>>   ## untagged VLAN the port is member of. It can be overriden here.
>>   option pvid 5
>>
>> config interface lan
>>   option type bridge
>>   option ifname 'switch0.1 wlan0'
>>   option proto static
>>   option ipaddr 192.168.1.1/24
>>
>> config interface wan
>>   option ifname switch0.2
>>   option proto dhcp
>>
>> config interface vlan5
>>   option ifname switch0.5
>>   option proto static
>>   option ipaddr 10.255.5.1/24
>>
>> config interface

Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules

2020-07-14 Thread Josh Bendavid

Ok thanks.
I think my main point was not that this belongs in interface per-se,
but that it makes sense for the configuration of vlan tagging to apply
to bridges in general (and to have as little as possible special
handling of dsa in uci, since the logic is that it should be possible
to configure it exactly as a generic bridge)

On Tue, 14 Jul 2020 at 19:05, Jo-Philipp Wich  wrote:
>
> Hi,
>
> > [...]
> > Isn't it conceptually more correct in this case for the vlan filtering
> > to be configured as part of the "interface" in uci?
> > Ie I configure an interface of type "bridge" which bridges the switch
> > ports, then the vlan filtering is a configuration property of this
> > interface (just like enabling igmp_snooping on a bridge interface)
>
> the "config interface" section type already is quite overloaded with different
> layer2 and layer3 configuration semantics which leads to confusion and quirks,
> as can be seen e.g. with "option mtu" on top of PPPoE interfaces or "option
> mac" on bridges.
>
> I agree that this setting could conceptually make sense in a "config device"
> section of type bridge, but with the VLAN filter settings being
> multi-dimensional it does not fit very well into simple uci option values
> without defining yet another micro format to declare VLAN / port memberships.
>
> The proposed dsaconfig approach has been selected due to its similarity with
> swconfig, it is easier to understand for people already used to swconfig and
> even allows for some automatic configuration conversion to some extent.
>
> I also do see it as a complementary higher level kind of configuration. It is
> entirely opt-in and can be supplemented or superseded with per-interface and
> per-device attributes that are implemented in netifd eventually.
>
>
> Regards,
> Jo
>

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

dnsmasq responding to the outside

2020-07-14 Thread Enrico Mioso


Hello!!

I am experiencing my router answering dns requests coming from WAN interface. 
Is this something I introduced with my config BTW, or not?
My config is pretty standard, but who knows.

I may send it when I have access to my device.

Enrico


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

Re: [PATCH] busybox: tr: enable options required by POSIX

2020-07-14 Thread Bjørn Mork

Jordan Geoghegan  writes:

> This isn't about 500 bytes of space anymore is it? 

FWIW, I believe it is.  It is about the sum of all the 500 bytes of
space contributed by each feature which doesn't qualify as strictly
necessary.

The upside is that OpenWrt runs on devices with almost no RAM and flash.
I thought that was pretty obvious.  This is the result of a rather
tedious work over a long time, defining features as "bloat". It makes
OpenWrt unique.

There is obviously also a downside, as you have pointed out.  All those
removed features are useful in some context. And it is definitely
frustrating every time you miss one of them.

But I don't think you help your cause by describing the current state as
"not have a working tr".  It might not work as you expected.  That's
understandable.  But that is by design and not a bug, as you've been
explained.



Bjørn

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

Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules

2020-07-14 Thread Jo-Philipp Wich

Hi,

> [...]
> The same feeling is still with this DSA proposal. The syntax "lan2.t
> lan2 lan3 lan5" is unstructured and it does not help too.

What is unstructured about it? The fact that it is not a uci list? That can be
easily changed.

> The use of "switch0" for cpu interface is good and I think it should
> even be used for swconfig (simply rename eth0 to switch0 by default
> and it will improve usability).

I agree but I don't think it'll ever materialize for swconfig.

> Trying to reuse the current swconfig syntax might be a curse that will
> haunt us. We could have simply 2 sections: bridge (L2) and interface
> (L3). My proposal:
> 
> config bridge br-lan <- the real bridge device name

This is invalid uci syntax, dashes are not allowed. It also duplicates "config
device" with "option type bridge".

>   option type "auto" # use the best way to merge every ports

What possible ways would there be?

>   # swconfig
>   [...] 

Skipped because I don't think there will be new syntax for swconfig anymore.

>   # DSA
>   list port lan1 # lan1, no vlan filtering (trunk mode)
>   list port lan2.1  # lan2 port, vlan 1, untagged
>   list port lan3.1t # lan3 port, vlan 1, tagged
>   list port lan3.2t # lan3 port, vlan 2, tagged

All of that except vlan/untagged are already possible using:

config interface foo
  option type bridge
  list ifname lan1
  list ifname lan2.1
  list ifname lan3.1
  list ifname lan3.2
  option proto ...

or alternatively using:

config device
  option type bridge
  option name blah0
  list ifname lan1
  list ifname lan2.1
  list ifname lan3.1
  list ifname lan3.2


> [...]
> 
> My proposal might have tons of uncovered cases (PPPoE, vlan, tunnel)
> but it looks easier than current swconfig and dsa proposed
> configuration.

It might be a matter of taste but personally I don't see what is easier about
it. The main change seems to be that instead by VLAN ID, your proposal groups
the port memberships by bridge. So instead having a vlan section that attaches
ports to a bridge, you declare a bridge containing ports with their respective
VLAN IDs.

> The main points are to split L2 and L3 confs, split port list into
> individual options and let the system decide the best way to implement
> the proposed setup.

Point 1 is already doable, point 2 can be easily added (in fact changing
"option ports 'lan1 lan2 lan3'" to "list ports lan1; list ports lan2; list
ports lan3" is possible without changing any code).

I disagree with point 3. Having a network config that automagically translates
into different things on different boards makes debugging potential issues
very hard. The uci network config is too low level for that imho.


Regards,
Jo



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

Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules

2020-07-14 Thread Luiz Angelo Daros de Luca

Hello,

I had the same feeling since I saw this patch. I would really like
something that could transparently allow me to bridge
either DSA ports, standard ethernet ports or even have a syntax that
would be compatible with swconfig (where dsa is not available).

It is a good opportunity to rebuild current network configuration from
scratch. Today, OpenWrt config does not make clear
how this two are connected:

config switch
   option name 'switch0'
   option reset '1'
   option enable_vlan '1'

config interface 'lan'
   option type 'bridge'
   option ifname 'eth0.1'
   option proto 'static'
   option ipaddr '192.168.1.1'
   option netmask '255.255.255.0'

And we still have wireless:

config wifi-iface 'wifinet0'
   option device 'radio0'
   option mode 'ap'
   option network 'lan' #shouldn't it be "interface"?

It's confusing for someone just arriving that switch0 will use eth0
and switch0 vlan 1 will be mapped to eth0.1. And, after bringing up
the interface, we have a br-lan, not mentioned anywhere.
Both L2 and L3 configurations are mixed, with part of it being even in
a separated configuration file (wireless).

The same feeling is still with this DSA proposal. The syntax "lan2.t
lan2 lan3 lan5" is unstructured and it does not help too.
The use of "switch0" for cpu interface is good and I think it should
even be used for swconfig (simply rename eth0 to switch0 by default
and it will improve usability).
Trying to reuse the current swconfig syntax might be a curse that will
haunt us. We could have simply 2 sections: bridge (L2) and interface
(L3). My proposal:

config bridge br-lan <- the real bridge device name
  option type "auto" # use the best way to merge every ports
  # swconfig
  list port switch0@1.1 # switch0, port 1, vlan 1, untagged
  list port switch0@2.1 # switch0, port 2, vlan 1, untagged
  list port switch0@3.1t # switch0, port 3, vlan 1, tagged
  list port switch0@4.2t # switch0, port 4, vlan 2, tagged
  list port switch0@4 # switch0, port 4, no vlan filtering (trunk mode)
  # DSA
  list port lan1 # lan1, no vlan filtering (trunk mode)
  list port lan2.1  # lan2 port, vlan 1, untagged
  list port lan3.1t # lan3 port, vlan 1, tagged
  list port lan3.2t # lan3 port, vlan 2, tagged
  # Other interfaces
  list port eth0 # eth0 port, no vlan filtering (trunk mode)
  list port eth0.2t # eth0 port, vlan 2, tagged
  list port wlan0 # it could also be specified in wifi-iface

# for swconfig, where wan would be what eth0.2 is today (simply renamed).
# it might keep the current misunderstanding that eth0.2 is not wan
port but a two-port bridge
# between CPU and wan ports
bridge wan
  list port switch0@0 # swith0, port 0, no vlan filtering

# for DSA or swconfig
interface wan
  ifname wan
  proto dhcp

interface lan
  ifname lanbridge0 #<- the real bridge device name
  proto static
  ...



config wifi-iface 'wifinet'
   option bridge lanbridge0
   ...

I don't have a working DSA system to test on but according to
https://www.kernel.org/doc/html/latest/networking/dsa/configuration.html,
it looks like DSA could allow two different ports to use the same vlan
but belong to different bridges. swconfig does not allow that setup
when you use two bridges. But, it could join them using software
bridges. There are obviously incompatible arrangements but the system
could detect them if the configured setup is not possible and avoid to
load them (or load whatever is possible). The bridge device might be
a DSA switch, a software bridge, or simply the CPU port (maybe even
using openvswitch when available?).

My proposal might have tons of uncovered cases (PPPoE, vlan, tunnel)
but it looks easier than current swconfig and dsa proposed
configuration.
The main points are to split L2 and L3 confs, split port list into
individual options and let the system decide the best way to implement
the proposed setup.

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

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

Re: [PATCH] busybox: tr: enable options required by POSIX

2020-07-14 Thread Jordan Geoghegan




On 2020-07-14 02:54, Bjørn Mork wrote:

Jordan Geoghegan  writes:


'tr' is a standard system utility, I wasn't expecting such pushback
against making it behave as every other modern implementation does.

OpenWrt exists because it is different from every other distribution.

https://openwrt.org/about describes it as "all the features you need
with none of the bloat".  There is no promise of all the features you
want, or all the featues of any other distro, or even all POSIX
features. What you "need" is obviously something you can discuss, but I
believe it is reasonable to limit it to the software included with the
distro.  OpenWrt specific porting might be required for any 3rd party
scripts or applications, even those running unmodified on other distros.

OpenWrt provides GNU coreutils as an optional alternative for the 'tr'
application.  This is full featured++, like GNU utils often are.

Just my 2 peanuts.


Bjørn

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



This isn't about 500 bytes of space anymore is it? I think at this point 
people just want to be "different" special snowflakes and not have a 
working tr even though nobody has presented any potential upside to 
leaving this unfixed.


The folks that have responded to this bug report (not even sure any of 
them have commit access lol) seem more interested in bikeshedding than 
actually fixing problems.


I'm now bored of debating this, so if you want to ship broken trash, 
I'll leave you alone.


Regards,

Jordan

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

Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules

2020-07-14 Thread Jo-Philipp Wich

Hi,

> [...]
> Isn't it conceptually more correct in this case for the vlan filtering
> to be configured as part of the "interface" in uci?
> Ie I configure an interface of type "bridge" which bridges the switch
> ports, then the vlan filtering is a configuration property of this
> interface (just like enabling igmp_snooping on a bridge interface)

the "config interface" section type already is quite overloaded with different
layer2 and layer3 configuration semantics which leads to confusion and quirks,
as can be seen e.g. with "option mtu" on top of PPPoE interfaces or "option
mac" on bridges.

I agree that this setting could conceptually make sense in a "config device"
section of type bridge, but with the VLAN filter settings being
multi-dimensional it does not fit very well into simple uci option values
without defining yet another micro format to declare VLAN / port memberships.

The proposed dsaconfig approach has been selected due to its similarity with
swconfig, it is easier to understand for people already used to swconfig and
even allows for some automatic configuration conversion to some extent.

I also do see it as a complementary higher level kind of configuration. It is
entirely opt-in and can be supplemented or superseded with per-interface and
per-device attributes that are implemented in netifd eventually.


Regards,
Jo



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

Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules

2020-07-14 Thread Josh Bendavid

Hi,
I have a somewhat radical comment on this.

As far as I understand, the vlan filtering support in the linux bridge
subsystem is not specific to dsa, but can equally be configured for a
pure software bridge.  The fact that the switch supports dsa/switchdev
then simply allows this to be transparently handled in hardware, just
like the simple bridging of the switch port interfaces.

Isn't it conceptually more correct in this case for the vlan filtering
to be configured as part of the "interface" in uci?
Ie I configure an interface of type "bridge" which bridges the switch
ports, then the vlan filtering is a configuration property of this
interface (just like enabling igmp_snooping on a bridge interface)

Thanks,
Josh

On Tue, 7 Jul 2020 at 22:13, Jo-Philipp Wich  wrote:
>
> This patch series introduces a new package "dsaconfig" which provides the
> necessary logic to allow configuration of bridge vlan filter rules for
> DSA switches.
>
> While well supported DSA switches can be programmed by solely bridging
> per-port netdevices together, explicit bridge VLAN filter rules are needed
> for more complex scenarios or for DSA switches that do not support a
> tagging protocol.
>
> The UCI configuration interpreted by the dsaconfig package closely follows
> the structure and semantics of the legacy swconfig architecture, honouring
> "dsa", "dsa_vlan" and "dsa_port" sections within the
> /etc/config/network file. The only difference compared to swconfig is
> that "dsa" sections are optional and that the syntax of ports within
> the "dsa_vlan" section differs, instead of ?, e.g.
> "0t", "1u" or "2", it is now (.)?, e.g. "wan.u", "lan1.t"
> or "lan2".
>
> The dsaconfig package will spawn a bridge device named "switchN" for each
> DSA switch, where N denotes the number of the switch. In contrast to
> swconfig, interfaces do not use the CPU port to target VLAN port groups on
> the switch but reference a VLAN on top of the switch, e.g.
> "option ifname switch0.1" to use the VLAN 1 port group on the first DSA
> switch.
>
> A complete configuration example for a simple LAN/WAN setup might look
> like below. Note that this configuration should be equivalent to just
> bridging lan1..lan4 without any VLAN filter rules.
>
> -- 8< --
> config dsa_vlan
>   option vlan 1
>   option ports 'lan1 lan2 lan3 lan4'
>
> config dsa_vlan
>   option vlan 2
>   option ports 'wan'
>
> config interface lan
>   option ifname switch0.1
>   option proto static
>   option ipaddr 192.168.1.1/24
>
> config interface wan
>   option ifname switch0.2
>   option proto dhcp
> -- >8 --
>
> A slightly more complex example that uses multiple tagged VLANs on different
> ports would look like this:
>
> -- 8< --
> config dsa switch0
>   ## Override CPU port. Normally it is auto-discovered.
>   #option cpu_port eth0
>
> config dsa_vlan
>   ## Specify the switch this vlan belongs to.
>   ## If there is only one switch on the system, it may be omitted.
>   #option device switch0
>   option vlan 1
>   option ports 'lan1 lan2.t'
>
> config dsa_vlan
>   #option device switch0
>   option vlan 2
>   option ports 'wan'
>
> config dsa_vlan
>   #option device switch0
>   option vlan 5
>   option ports 'lan2.t lan3'
>
> config dsa_vlan
>   #option device switch0
>   option vlan 8
>   option ports 'lan2.t lan4'
>
> config dsa_vlan
>   #option device switch0
>   option vlan 11
>   option ports 'lan2.t lan4.t'
>
> config dsa_port
>   #option device switch0
>   option port lan2
>   ## By default, the port PVID is set to the ID of the first
>   ## untagged VLAN the port is member of. It can be overriden here.
>   option pvid 5
>
> config interface lan
>   option type bridge
>   option ifname 'switch0.1 wlan0'
>   option proto static
>   option ipaddr 192.168.1.1/24
>
> config interface wan
>   option ifname switch0.2
>   option proto dhcp
>
> config interface vlan5
>   option ifname switch0.5
>   option proto static
>   option ipaddr 10.255.5.1/24
>
> config interface vlan8
>   option ifname switch0.8
>   option proto static
>   option ipaddr 10.255.8.1/24
>
> config interface vlan11
>   option ifname switch0.11
>   option proto static
>   option ipaddr 10.255.11.1/24
> -- >8 --
>
> Additionally, the "dsaconfig" executable provided by this package implements
> a "show" option to display the current switch port states and their VLAN
> memberships in a compact manner. For the latter configuration example above,
> the utility would produce an output similar to the following:
>
> -- 8< --
> root@OpenWrt:~# dsaconfig show
> Switch: switch0
> VLAN/ | lan1  | lan2  | lan3  | lan4  | wan   |
> Link: | down  | 1000F | down  | 1000F | down  |
>1  |  u*   |  t|   |   |   |
>2  |   |   |   |   |  u*   |
>5  |   |  t*   |  u*   |   |   |
>8  |  t|  t|   |  u*   |   |
>   11  |   |  t|   |  t|   |
>
> -- >8 --
>
> This code has been tested on a WRT3200ACM and a Mir3G but is supposed to
> wor

[PATCH] zram-swap: drop the conditional dependency on swap-utils

2020-07-14 Thread Rui Salvaterra

The original idea was to pull-in swap-utils when the required BusyBox utilities
were unavailable. However, this made the zram-swap package strictly depend on
swap-utils when using the image builder, which is incorrect. Moreover,
swap-utils dropped the swapon/swapoff utilities years ago.

Let's just drop this dependency. BusyBox in the official builds includes the
required applets. I believe it's safe to assume people doing their own builds
and customising the configuration of BusyBox know what they're doing, since no
other package verifies and/or depends on specific BUSYBOX_* symbols.

Signed-off-by: Rui Salvaterra 
---
 package/system/zram-swap/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/system/zram-swap/Makefile 
b/package/system/zram-swap/Makefile
index a6661ce5e9..0d809c10e4 100644
--- a/package/system/zram-swap/Makefile
+++ b/package/system/zram-swap/Makefile
@@ -18,7 +18,7 @@ include $(INCLUDE_DIR)/package.mk
 define Package/zram-swap
   SECTION:=utils
   CATEGORY:=Base system
-  DEPENDS:=+kmod-zram 
+!(BUSYBOX_CONFIG_MKSWAP&&BUSYBOX_CONFIG_SWAPON&&BUSYBOX_CONFIG_SWAPOFF):swap-utils
+  DEPENDS:=+kmod-zram
   TITLE:=ZRAM swap scripts
   PKGARCH:=all
 endef
-- 
2.27.0


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

[PATCH v2 1/6] build: add DEVICE_COMPAT_VERSION and DEVICE_COMPAT_MESSAGE

2020-07-14 Thread Adrian Schmutzler

We regularly encounter the situation that devices are subject to
changes that will make them incompatible to previous versions.
Removing SUPPORTED_DEVICES will not really be helpful in most of these
cases, as this only helps after a rename.

To solve this situation, this patchset introduces a compatibility
version for devices. It will be implemented via a per-device
Make variable DEVICE_COMPAT_VERSION, which will be set to 1.0
globally by default and then can be overwritten as needed.

Furthermore, a variable DEVICE_COMPAT_MESSAGE is added, where
a message to be displayed during sysupgrade may be specified
optionally.

This patch only implements the build variables and adds them
to the sysupgrade metadata, the evaluation will be addressed
in a subsequent patch.

To set it, one would just need to add the following to a device node:

define Device/somedevice
  ...
  DEVICE_COMPAT_VERSION := 1.1
  DEVICE_COMPAT_MESSAGE := Config cannot be migrated from swconfig to DSA
endef

Signed-off-by: Adrian Schmutzler 
---
 include/image-commands.mk | 7 +--
 include/image.mk  | 3 +++
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/include/image-commands.mk b/include/image-commands.mk
index e7db7128b4..9da712e733 100644
--- a/include/image-commands.mk
+++ b/include/image-commands.mk
@@ -384,13 +384,16 @@ define Build/tplink-v2-image
rm -rf $@.new
 endef
 
+compat_version=$(if $(DEVICE_COMPAT_VERSION),$(DEVICE_COMPAT_VERSION),1.0)
 json_quote=$(subst ','\'',$(subst ",\",$(1)))
 #")')
 metadata_devices=$(if $(1),$(subst "$(space)","$(comma)",$(strip $(foreach 
v,$(1),"$(call json_quote,$(v))"
 metadata_json = \
'{ $(if $(IMAGE_METADATA),$(IMAGE_METADATA)$(comma)) \
"metadata_version": "1.0", \
-   "supported_devices":[$(call metadata_devices,$(1))], \
+   "compat_version": "$(call json_quote,$(compat_version))", \
+   $(if $(DEVICE_COMPAT_MESSAGE),"compat_message": "$(call 
json_quote,$(DEVICE_COMPAT_MESSAGE))"$(comma)) \
+   "supported_devices":[$(call 
metadata_devices,$(SUPPORTED_DEVICES))], \
"version": { \
"dist": "$(call json_quote,$(VERSION_DIST))", \
"version": "$(call json_quote,$(VERSION_NUMBER))", \
@@ -401,7 +404,7 @@ metadata_json = \
}'
 
 define Build/append-metadata
-   $(if $(SUPPORTED_DEVICES),-echo $(call 
metadata_json,$(SUPPORTED_DEVICES)) | fwtool -I - $@)
+   $(if $(SUPPORTED_DEVICES),-echo $(call metadata_json) | fwtool -I - $@)
[ ! -s "$(BUILD_KEY)" -o ! -s "$(BUILD_KEY).ucert" -o ! -s "$@" ] || { \
cp "$(BUILD_KEY).ucert" "$@.ucert" ;\
usign -S -m "$@" -s "$(BUILD_KEY)" -x "$@.sig" ;\
diff --git a/include/image.mk b/include/image.mk
index 300f7a6619..dbdc820f4d 100644
--- a/include/image.mk
+++ b/include/image.mk
@@ -419,6 +419,8 @@ define Device/Init
 
   BOARD_NAME :=
   UIMAGE_NAME :=
+  DEVICE_COMPAT_VERSION := 1.0
+  DEVICE_COMPAT_MESSAGE :=
   SUPPORTED_DEVICES :=
   IMAGE_METADATA :=
 
@@ -435,6 +437,7 @@ DEFAULT_DEVICE_VARS := \
   VID_HDR_OFFSET UBINIZE_OPTS UBINIZE_PARTS MKUBIFS_OPTS DEVICE_DTS \
   DEVICE_DTS_CONFIG DEVICE_DTS_DIR SOC BOARD_NAME UIMAGE_NAME 
SUPPORTED_DEVICES \
   IMAGE_METADATA KERNEL_ENTRY KERNEL_LOADADDR UBOOT_PATH IMAGE_SIZE \
+  DEVICE_COMPAT_VERSION DEVICE_COMPAT_MESSAGE \
   DEVICE_VENDOR DEVICE_MODEL DEVICE_VARIANT \
   DEVICE_ALT0_VENDOR DEVICE_ALT0_MODEL DEVICE_ALT0_VARIANT \
   DEVICE_ALT1_VENDOR DEVICE_ALT1_MODEL DEVICE_ALT1_VARIANT \
-- 
2.20.1


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

[PATCH v2 0/6] sysupgrade: introduce compatibility version for devices

2020-07-14 Thread Adrian Schmutzler

This revised patchset provides some polishing to the initial submission.

It does not change the mechanics substantially, but just provides some
aesthetic improvements.

Notable functional changes:
- compat version check is now executed _after_ the supported_devices check
- the DEVICE_COMPAT_MESSAGE is now also printed for the legacy sysupgrade hack

Cosmetic changes:
- The "error" message have been reworded to be more conclusive and provide
  more information.

Further additions:
- Instead of the example implementation patch for ath79, this now features
  the actual implementation for swconfig->DSA change in mvebu and kirkwood.
  (adding mt7621 will be considered after merge)

While v1 has been device-tested, I have not run-tested this patchset so
far, as changes between them are mostly cosmetic and I want to wait for
feedback first.

Adrian Schmutzler (6):
  build: add DEVICE_COMPAT_VERSION and DEVICE_COMPAT_MESSAGE
  base-files: add support for compat_version on device
  base-files: fwtool: implement compatibility check for images
  base-files: fwtool: make compat_version backward compatible
  mvebu: implement compatibility version for DSA migration
  kirkwood: implement compatibility version for DSA migration

 include/image-commands.mk | 10 --
 include/image.mk  |  3 ++
 package/base-files/files/bin/config_generate  |  7 +
 .../files/lib/functions/uci-defaults.sh   |  6 
 .../base-files/files/lib/upgrade/fwtool.sh| 31 +--
 .../base-files/etc/board.d/02_network |  1 +
 target/linux/kirkwood/image/Makefile  |  7 +
 .../base-files/etc/board.d/02_network | 14 +
 target/linux/mvebu/image/cortexa9.mk  | 19 
 9 files changed, 88 insertions(+), 10 deletions(-)

-- 
2.20.1


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

[PATCH v2 5/6] mvebu: implement compatibility version for DSA migration

2020-07-14 Thread Adrian Schmutzler

This implements the newly introduced compat-version to prevent
upgrade between swconfig and DSA for mvebu.

Just define a compat version with minor increment and an appropriate
message for both image (in Makefile) and device (in base-files).

Having taken care of sysupgrade, we can put back the SUPPORTED_DEVICES
that have been removed in previous patches to prevent broken config.

While at it, fix alphabetic sorting in 02_network.

Signed-off-by: Adrian Schmutzler 

---

Added in v2
---
 .../base-files/etc/board.d/02_network | 14 --
 target/linux/mvebu/image/cortexa9.mk  | 19 +++
 2 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/target/linux/mvebu/cortexa9/base-files/etc/board.d/02_network 
b/target/linux/mvebu/cortexa9/base-files/etc/board.d/02_network
index 9718b332a7..9255f2535e 100755
--- a/target/linux/mvebu/cortexa9/base-files/etc/board.d/02_network
+++ b/target/linux/mvebu/cortexa9/base-files/etc/board.d/02_network
@@ -23,6 +23,7 @@ mvebu_setup_interfaces()
linksys,wrt3200acm|\
linksys,wrt32x)
ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4" "wan"
+   ucidef_set_compat_version "1.1"
;;
marvell,a385-db-ap)
ucidef_set_interfaces_lan_wan "eth0 eth1" "eth2"
@@ -30,18 +31,19 @@ mvebu_setup_interfaces()
marvell,axp-gp)
ucidef_set_interface_lan "eth0 eth1 eth2 eth3"
;;
-   solidrun,clearfog-pro-a1)
-   # eth0 is standalone ethernet
-   # eth1 is switch
-   # eth2 is SFP
-   ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4 lan5 lan6" 
"eth0 eth2"
-   ;;
solidrun,clearfog-base-a1)
# eth0 is standalone ethernet
# eth1 is standalone ethernet
# eth2 is SFP
ucidef_set_interfaces_lan_wan "eth1" "eth0 eth2"
;;
+   solidrun,clearfog-pro-a1)
+   # eth0 is standalone ethernet
+   # eth1 is switch
+   # eth2 is SFP
+   ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4 lan5 lan6" 
"eth0 eth2"
+   ucidef_set_compat_version "1.1"
+   ;;
*)
ucidef_set_interface_lan "eth0"
;;
diff --git a/target/linux/mvebu/image/cortexa9.mk 
b/target/linux/mvebu/image/cortexa9.mk
index 7f0a2fe697..1a4c43d133 100644
--- a/target/linux/mvebu/image/cortexa9.mk
+++ b/target/linux/mvebu/image/cortexa9.mk
@@ -6,6 +6,11 @@
 # See /LICENSE for more information.
 #
 
+define Device/dsa-migration
+  DEVICE_COMPAT_VERSION := 1.1
+  DEVICE_COMPAT_MESSAGE := Config cannot be migrated from swconfig to DSA
+endef
+
 define Device/buffalo_ls421de
   $(Device/NAND-128K)
   DEVICE_VENDOR := Buffalo
@@ -63,16 +68,19 @@ endef
 
 define Device/linksys_wrt1200ac
   $(call Device/linksys)
+  $(Device/dsa-migration)
   DEVICE_MODEL := WRT1200AC
   DEVICE_ALT0_VENDOR := Linksys
   DEVICE_ALT0_MODEL := Caiman
   DEVICE_DTS := armada-385-linksys-caiman
   DEVICE_PACKAGES += mwlwifi-firmware-88w8864
+  SUPPORTED_DEVICES += armada-385-linksys-caiman linksys,caiman
 endef
 TARGET_DEVICES += linksys_wrt1200ac
 
 define Device/linksys_wrt1900acs
   $(call Device/linksys)
+  $(Device/dsa-migration)
   DEVICE_MODEL := WRT1900ACS
   DEVICE_VARIANT := v1
   DEVICE_ALT0_VENDOR := Linksys
@@ -82,11 +90,13 @@ define Device/linksys_wrt1900acs
   DEVICE_ALT1_MODEL := Shelby
   DEVICE_DTS := armada-385-linksys-shelby
   DEVICE_PACKAGES += mwlwifi-firmware-88w8864
+  SUPPORTED_DEVICES += armada-385-linksys-shelby linksys,shelby
 endef
 TARGET_DEVICES += linksys_wrt1900acs
 
 define Device/linksys_wrt1900ac-v1
   $(call Device/linksys)
+  $(Device/dsa-migration)
   DEVICE_MODEL := WRT1900AC
   DEVICE_VARIANT := v1
   DEVICE_ALT0_VENDOR := Linksys
@@ -94,32 +104,38 @@ define Device/linksys_wrt1900ac-v1
   DEVICE_DTS := armada-xp-linksys-mamba
   DEVICE_PACKAGES += mwlwifi-firmware-88w8864
   KERNEL_SIZE := 3072k
+  SUPPORTED_DEVICES += armada-xp-linksys-mamba linksys,mamba
 endef
 TARGET_DEVICES += linksys_wrt1900ac-v1
 
 define Device/linksys_wrt1900ac-v2
   $(call Device/linksys)
+  $(Device/dsa-migration)
   DEVICE_MODEL := WRT1900AC
   DEVICE_VARIANT := v2
   DEVICE_ALT0_VENDOR := Linksys
   DEVICE_ALT0_MODEL := Cobra
   DEVICE_DTS := armada-385-linksys-cobra
   DEVICE_PACKAGES += mwlwifi-firmware-88w8864
+  SUPPORTED_DEVICES += armada-385-linksys-cobra linksys,cobra
 endef
 TARGET_DEVICES += linksys_wrt1900ac-v2
 
 define Device/linksys_wrt3200acm
   $(call Device/linksys)
+  $(Device/dsa-migration)
   DEVICE_MODEL := WRT3200ACM
   DEVICE_ALT0_VENDOR := Linksys
   DEVICE_ALT0_MODEL := Rango
   DEVICE_DTS := armada-385-linksys-rango
   DEVICE_PACKAGES += kmod-btmrvl kmod-mwifiex-sdio mwlwifi-firmware-88w8964
+  SUPPORTED_DEVICES += armada-385-linksys-rango linksys,rango
 endef
 TARGET_DEVICES += linksys_wrt3200acm
 
 define Device

[PATCH v2 2/6] base-files: add support for compat_version on device

2020-07-14 Thread Adrian Schmutzler

We regularly encounter the situation that devices are subject to
changes that will make them incompatible to previous versions.
Removing SUPPORTED_DEVICES will not really be helpful in most of these
cases, as this only helps after a rename.

To solve this situation, this patchset introduces a compatibility
version for devices. To complement the DEVICE_COMPAT_VERSION set
for the image to be flashed, this implements a compat_version on
the device, so it will have something to compare with the image.

The only viable way to achieve this seems to be via board.d files,
i.e. this is technically adding a compat version for the device's
config.

Like for the network setup, this will set up a command
ucidef_set_compat_version to set the compat_version in board.d.
This will then add a string to /etc/board.json, which will be
translated into uci system config by bin/config_generate.
By this, the compat_version, being a version of the config, will
also be exposed to the user.

As with DEVICE_COMPAT_VERSION, missing uci entry will be assumed
as compat_version "1.0", so we only need to add this if a device
needs to be bumped, e.g.

   ucidef_set_compat_version "1.1"

Signed-off-by: Adrian Schmutzler 
---
 package/base-files/files/bin/config_generate   | 7 +++
 package/base-files/files/lib/functions/uci-defaults.sh | 6 ++
 2 files changed, 13 insertions(+)

diff --git a/package/base-files/files/bin/config_generate 
b/package/base-files/files/bin/config_generate
index abb1388ba1..eb6816e519 100755
--- a/package/base-files/files/bin/config_generate
+++ b/package/base-files/files/bin/config_generate
@@ -264,6 +264,13 @@ generate_static_system() {
uci -q set 
"system.@system[-1].hostname=$hostname"
fi
 
+   local compat_version
+   if json_get_var compat_version compat_version; then
+   uci -q set 
"system.@system[-1].compat_version=$compat_version"
+   else
+   uci -q set 
"system.@system[-1].compat_version=1.0"
+   fi
+
if json_is_a ntpserver array; then
local keys key
json_get_keys keys ntpserver
diff --git a/package/base-files/files/lib/functions/uci-defaults.sh 
b/package/base-files/files/lib/functions/uci-defaults.sh
index 12b900031d..27a409fe3b 100755
--- a/package/base-files/files/lib/functions/uci-defaults.sh
+++ b/package/base-files/files/lib/functions/uci-defaults.sh
@@ -68,6 +68,12 @@ ucidef_set_model_name() {
json_select ..
 }
 
+ucidef_set_compat_version() {
+   json_select_object system
+   json_add_string compat_version "${1:-1.0}"
+   json_select ..
+}
+
 ucidef_set_interface_lan() {
ucidef_set_interface "lan" ifname "$1" protocol "${2:-static}"
 }
-- 
2.20.1


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

[PATCH v2 6/6] kirkwood: implement compatibility version for DSA migration

2020-07-14 Thread Adrian Schmutzler

This implements the newly introduced compat-version to prevent
upgrade between swconfig and DSA for kirkwood.

Just define a compat version with minor increment and an appropriate
message for both image (in Makefile) and device (in base-files).

Since we never removed SUPPORTED_DEVICES for this target, we don't
have to add it back either.

Signed-off-by: Adrian Schmutzler 

---

Added in v2
---
 target/linux/kirkwood/base-files/etc/board.d/02_network | 1 +
 target/linux/kirkwood/image/Makefile| 7 +++
 2 files changed, 8 insertions(+)

diff --git a/target/linux/kirkwood/base-files/etc/board.d/02_network 
b/target/linux/kirkwood/base-files/etc/board.d/02_network
index 658ce13346..45c0182493 100755
--- a/target/linux/kirkwood/base-files/etc/board.d/02_network
+++ b/target/linux/kirkwood/base-files/etc/board.d/02_network
@@ -32,6 +32,7 @@ case "$board" in
 "linksys,viper")
ucidef_set_interfaces_lan_wan "ethernet1 ethernet2 ethernet3 ethernet4" 
"internet"
ucidef_set_interface_macaddr "wan" $( mtd_get_mac_ascii u_env eth1addr )
+   ucidef_set_compat_version "1.1"
;;
 "zyxel,nsa310b"|\
 "zyxel,nsa325")
diff --git a/target/linux/kirkwood/image/Makefile 
b/target/linux/kirkwood/image/Makefile
index ba93fffeb2..6554fc2669 100644
--- a/target/linux/kirkwood/image/Makefile
+++ b/target/linux/kirkwood/image/Makefile
@@ -10,6 +10,11 @@ include $(INCLUDE_DIR)/image.mk
 
 KERNEL_LOADADDR:=0x8000
 
+define Device/dsa-migration
+  DEVICE_COMPAT_VERSION := 1.1
+  DEVICE_COMPAT_MESSAGE := Config cannot be migrated from swconfig to DSA
+endef
+
 define Device/Default
   PROFILES := Default
   DEVICE_DTS = $$(if $$(BOARD_NAME),kirkwood-$$(BOARD_NAME),)
@@ -92,6 +97,7 @@ endef
 TARGET_DEVICES += iom_ix2-200
 
 define Device/linksys_audi
+  $(Device/dsa-migration)
   DEVICE_VENDOR := Linksys
   DEVICE_MODEL := EA3500 (Audi)
   DEVICE_PACKAGES := kmod-mwl8k wpad-basic kmod-gpio-button-hotplug
@@ -107,6 +113,7 @@ endef
 TARGET_DEVICES += linksys_audi
 
 define Device/linksys_viper
+  $(Device/dsa-migration)
   DEVICE_VENDOR := Linksys
   DEVICE_MODEL := E4200v2 / EA4500 (Viper)
   DEVICE_PACKAGES := kmod-mwl8k wpad-basic kmod-gpio-button-hotplug
-- 
2.20.1


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

[PATCH v2 3/6] base-files: fwtool: implement compatibility check for images

2020-07-14 Thread Adrian Schmutzler

We regularly encounter the situation that devices are subject to
changes that will make them incompatible to previous versions.
Removing SUPPORTED_DEVICES will not really be helpful in most of these
cases, as this only helps after a rename.

To solve this situation, this patchset introduces a compatibility
version for devices. In this patch, the actual checks are implemented
into fwtool_check_image():

If an incompatible change is introduced, one can increase either
the minor version (1.0->1.1) or the major version (1.0->2.0).

Minor version increment:
This will still allow sysupgrade, but require to reset config
(-n or SAVE_CONFIG=0). If sysupgrade is called without -n, a
corresponding message will be printed. If sysupgrade is called
with -n, it will just pass, with supported devices being checked
as usual. (Which will allow us to add back SUPPORTED_DEVICES for
many cases.)

Major version increment:
This is meant for potential (rare) cases where sysupgrade is
not possible at all, because it would break the device.
In this case, a warning will be printed, and -n won't help.

If image check fails because of one of the versions parts not
matching, the content of DEVICE_COMPAT_MESSAGE is printed in
addition to the generic message (if set).

For both cases, upgrade can still be forced with -F as usual.

Signed-off-by: Adrian Schmutzler 

---

Changes in v2:
- Move compat check AFTER supported_devices check
- Improve error messages
---
 .../base-files/files/lib/upgrade/fwtool.sh| 24 ++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/package/base-files/files/lib/upgrade/fwtool.sh 
b/package/base-files/files/lib/upgrade/fwtool.sh
index a0b3fb0a04..1807aecd6d 100644
--- a/package/base-files/files/lib/upgrade/fwtool.sh
+++ b/package/base-files/files/lib/upgrade/fwtool.sh
@@ -44,13 +44,35 @@ fwtool_check_image() {
}
 
device="$(cat /tmp/sysinfo/board_name)"
+   devicecompat="$(uci -q get system.@system[0].compat_version)"
+   [ -n "$devicecompat" ] || devicecompat="1.0"
+
+   json_get_var imagecompat compat_version
+   json_get_var compatmessage compat_message
+   [ -n "$imagecompat" ] || imagecompat="1.0"
 
json_select supported_devices || return 1
 
json_get_keys dev_keys
for k in $dev_keys; do
json_get_var dev "$k"
-   [ "$dev" = "$device" ] && return 0
+   if [ "$dev" = "$device" ]; then
+   # major compat version -> no sysupgrade
+   if [ "${devicecompat%.*}" != "${imagecompat%.*}" ]; then
+   echo "The device is supported, but this image 
is incompatible for sysupgrade based on the image version 
($devicecompat->$imagecompat)."
+   [ -n "$compatmessage" ] && echo "$compatmessage"
+   return 1
+   fi
+
+   # minor compat version -> sysupgrade with -n required
+   if [ "${devicecompat#.*}" != "${imagecompat#.*}" ] && [ 
"$SAVE_CONFIG" = "1" ]; then
+   echo "The device is supported, but the config 
is incompatible to the new image ($devicecompat->$imagecompat). Please upgrade 
with -n."
+   [ -n "$compatmessage" ] && echo "$compatmessage"
+   return 1
+   fi
+
+   return 0
+   fi
done
 
echo "Device $device not supported by this image"
-- 
2.20.1


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

[PATCH v2 4/6] base-files: fwtool: make compat_version backward compatible

2020-07-14 Thread Adrian Schmutzler

So far, the compatibility mechanism only works if both device and
image are already updated to the new routines. This patch extends
the sysupgrade metadata and fwtool_check_image() to account for
"older" images as well:

The basic mechanism for older devices to check for image compatibility
is the supported_devices entry. This can be exploited by putting
a custom message into this variable of the metadata, so older FW
will produce a mismatch and print the message as it thinks it's the
list of supported devices. So, we have two cases:

device 1.0, image 1.0:
  The metadata will just contain supported_devices as before.

device 1.0, image 1.1:
  The metadata will contain:

  "new_supported_devices":["device_string1", "device_string2", ...],
  "supported_devices":["Upgrade incompatible. Please check Wiki ..."]

  If the device is "legacy", i.e. does not have the updated fwtool.sh,
  it will just fail with image check and print the content of
  supported_devices. Upgrade can still be performed with -F like when
  SUPPORTED_DEVICES has been removed to prevent bricking.

  If the device has updated fwtool.sh (but is 1.0), it will just use
  the new_supported_devices instead, and work as intended (flashing
  with -n will work, flashing without will print the appropriate
  warning).

This mechanism should provide a fair tradeoff between simplicity
and functionality.

Signed-off-by: Adrian Schmutzler 

---

Changes in v2:
- Add DEVICE_COMPAT_MESSAGE and reword comment for legacy warning.
---
 include/image-commands.mk  | 5 -
 package/base-files/files/lib/upgrade/fwtool.sh | 7 ++-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/include/image-commands.mk b/include/image-commands.mk
index 9da712e733..e21472a659 100644
--- a/include/image-commands.mk
+++ b/include/image-commands.mk
@@ -393,7 +393,10 @@ metadata_json = \
"metadata_version": "1.0", \
"compat_version": "$(call json_quote,$(compat_version))", \
$(if $(DEVICE_COMPAT_MESSAGE),"compat_message": "$(call 
json_quote,$(DEVICE_COMPAT_MESSAGE))"$(comma)) \
-   "supported_devices":[$(call 
metadata_devices,$(SUPPORTED_DEVICES))], \
+   $(if $(filter-out 
1.0,$(compat_version)),"new_supported_devices":[$(call 
metadata_devices,$(SUPPORTED_DEVICES))]$(comma)) \
+   $(if $(filter-out 1.0,$(compat_version)),"supported_devices": \
+   ["$(call json_quote,Image version $(compat_version) 
incompatible to device: $(if 
$(DEVICE_COMPAT_MESSAGE),$(DEVICE_COMPAT_MESSAGE),Please check documentation 
...)"]$(comma)) \
+   $(if $(filter 
1.0,$(compat_version)),"supported_devices":[$(call 
metadata_devices,$(SUPPORTED_DEVICES))]$(comma)) \
"version": { \
"dist": "$(call json_quote,$(VERSION_DIST))", \
"version": "$(call json_quote,$(VERSION_NUMBER))", \
diff --git a/package/base-files/files/lib/upgrade/fwtool.sh 
b/package/base-files/files/lib/upgrade/fwtool.sh
index 1807aecd6d..59f981f6c3 100644
--- a/package/base-files/files/lib/upgrade/fwtool.sh
+++ b/package/base-files/files/lib/upgrade/fwtool.sh
@@ -51,7 +51,12 @@ fwtool_check_image() {
json_get_var compatmessage compat_message
[ -n "$imagecompat" ] || imagecompat="1.0"
 
-   json_select supported_devices || return 1
+   # select correct supported list based on compat_version
+   # (using this ensures that compatibility check works for devices
+   #  not knowing about compat-version)
+   local supported=supported_devices
+   [ "$imagecompat" != "1.0" ] && supported=new_supported_devices
+   json_select $supported || return 1
 
json_get_keys dev_keys
for k in $dev_keys; do
-- 
2.20.1


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

Re: [PATCH] wireless-regdb: add country selection

2020-07-14 Thread Felix Fietkau

On 2020-07-14 13:57, Florian Eckert wrote:
> 
>> What's the use case for this?
> As much as I remember there was the problem in 2017 that you can't 
> change the country code or have to restrict it.
> https://ec.europa.eu/growth/sectors/electrical-engineering/red-directive_de
> Of course this change can't fulfill with this patch, but it wouldn't be 
> bad if you can put together regdb yourself and not always provide all 
> country codes.
Makes sense, thanks.

>> Couldn't we simply add add two options to blacklist or whitelist 
>> country
>> codes using a comma separated string?
> 
> That doesn't sound like a bad idea.
> If the option CONFIG_WIRELESS_REGDB_WHITELIST or 
> CONFIG_WIRELESS_REGDB_BLACKLIST is configured then a regdb is created at 
> compile time?
> Otherwise the package uses the regdb as it is.
Yes, exactly.

- Felix

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

[PATCH] ath10k-ct-firmware: update firmware images

2020-07-14 Thread Michael Yartys

Fix at least one rare wave-2 crash.

Signed-off-by: Michael Yartys 
---
 package/firmware/ath10k-ct-firmware/Makefile | 56 ++--
 1 file changed, 28 insertions(+), 28 deletions(-)

diff --git a/package/firmware/ath10k-ct-firmware/Makefile 
b/package/firmware/ath10k-ct-firmware/Makefile
index 18370b7d85..10c72ae4c2 100644
--- a/package/firmware/ath10k-ct-firmware/Makefile
+++ b/package/firmware/ath10k-ct-firmware/Makefile
@@ -95,14 +95,14 @@ define Download/ct-firmware-htt
   URL_FILE:=$($(1)_FIRMWARE_FILE_CT_HTT)
 endef
 
-QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.018
+QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.019
 define Download/ath10k-firmware-qca988x-ct
   $(call Download/ct-firmware,QCA988X,)
   HASH:=8b4c99253aa309d35f2e060c190091b8db1b84dbda06a6a15c83ac0f9a938126
 endef
 $(eval $(call Download,ath10k-firmware-qca988x-ct))
 
-QCA988X_FIRMWARE_FILE_CT_FULL_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.018
+QCA988X_FIRMWARE_FILE_CT_FULL_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.019
 define Download/ath10k-firmware-qca988x-ct-full-htt
   $(call Download/ct-firmware-full-htt,QCA988X,)
   HASH:=a7168916d6aa5e4d7858f8b620c0c980c76d03f390929db6f4077685ce2051e7
@@ -110,14 +110,14 @@ endef
 $(eval $(call Download,ath10k-firmware-qca988x-ct-full-htt))
 
 
-QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.018
+QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.019
 define Download/ath10k-firmware-qca9887-ct
   $(call Download/ct-firmware,QCA9887,ath10k-9887)
   HASH:=459692deb186a63ab8eeddb7ad5d54779266e68ca686e7c46062554db6dca12b
 endef
 $(eval $(call Download,ath10k-firmware-qca9887-ct))
 
-QCA9887_FIRMWARE_FILE_CT_FULL_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.018
+QCA9887_FIRMWARE_FILE_CT_FULL_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.019
 define Download/ath10k-firmware-qca9887-ct-full-htt
   $(call Download/ct-firmware-full-htt,QCA9887,ath10k-9887)
   HASH:=fd126a457d0927d0c8ea10d66ef5b67d5e1e0741f8692bb3016bb602d0af3098
@@ -125,90 +125,90 @@ endef
 $(eval $(call Download,ath10k-firmware-qca9887-ct-full-htt))
 
 
-QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.018
+QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.019
 define Download/ath10k-firmware-qca99x0-ct
   $(call Download/ct-firmware,QCA99X0,ath10k-10-4b)
-  HASH:=cf26eb37524de54af51fe9b2efffc85e0e70ab849e8607ef63ce5a8ecffeaa42
+  HASH:=7dc934f934bc4973c9273a4f22cfead8e26ec6f579647af31b718a860eca0a4b
 endef
 $(eval $(call Download,ath10k-firmware-qca99x0-ct))
 
-QCA99X0_FIRMWARE_FILE_CT_FULL_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.018
+QCA99X0_FIRMWARE_FILE_CT_FULL_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.019
 define Download/ath10k-firmware-qca99x0-ct-full-htt
   $(call Download/ct-firmware-full-htt,QCA99X0,ath10k-10-4b)
-  HASH:=e9737538d7379e13ad4e4c8c519a63659b5e34a35455ed9ac4399ae8097caabc
+  HASH:=71a27b245a382fe009938d2826d5c97a90dceb10ddf638325268df91837ea302
 endef
 $(eval $(call Download,ath10k-firmware-qca99x0-ct-full-htt))
 
-QCA99X0_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-htt-mgt-community-12.bin-lede.018
+QCA99X0_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-htt-mgt-community-12.bin-lede.019
 define Download/ath10k-firmware-qca99x0-ct-htt
   $(call Download/ct-firmware-htt,QCA99X0,ath10k-10-4b)
-  HASH:=4d4f74afca487d452f244cd48304cf9710d8941eb97a6346a949ed6b6877d657
+  HASH:=9ed4fe41e5b0f30172f71ae0fe382dc0aab8aa4f8a898417af4f7ee936575ef6
 endef
 $(eval $(call Download,ath10k-firmware-qca99x0-ct-htt))
 
 
-QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.018
+QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.019
 define Download/ath10k-firmware-qca9984-ct
   $(call Download/ct-firmware,QCA9984,ath10k-9984-10-4b)
-  HASH:=a6b3d66efe640a430a837f238e91eddcd423eed6b887d3ae19716d87a71fd0b1
+  HASH:=32d13f432691fe759ded7d027052e925233adb436cd8f729f85ec3d19ccd1dfd
 endef
 $(eval $(call Download,ath10k-firmware-qca9984-ct))
 
-QCA9984_FIRMWARE_FILE_CT_FULL_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.018
+QCA9984_FIRMWARE_FILE_CT_FULL_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.019
 define Download/ath10k-firmware-qca9984-ct-full-htt
   $(call Download/ct-firmware-full-htt,QCA9984,ath10k-9984-10-4b)
-  HASH:=96060227e372b3b210badccbe6b0bd75d9a35335a7a0f2966964e9e89f66b00f
+  HASH:=e8ab69777bd00b5fc6b1b7acccb55b903553a99932a5b0351602b5f690106588
 endef
 $(eval $(call Download,ath10k-firmware-qca9984-ct-full-htt))
 
-QCA9984_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-htt-mgt-community-12.bin-lede.018
+QCA9984_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-htt-mgt-community-12.bin-lede.019
 define Download/ath10k-firmware-qca9984-ct-htt
   $(call Download/ct-firmware-htt,QCA9984,ath10k-9984-10-4b)
-  HASH:=ee593fb5724d75c372de02ac7894e1630ee9f909fcb2e2bbf17aadef67cb9d43
+  HASH:=74449b303b626e0713b3fd4f2d6103d65859403b

[PATCH] ath10k-ct-firmware: update firmware images

2020-07-14 Thread Michael Yartys

From: Michael Yartys 

Fix at least one rare wave-2 crash.

Signed-off-by: Michael Yartys 
---
 package/firmware/ath10k-ct-firmware/Makefile | 56 ++--
 1 file changed, 28 insertions(+), 28 deletions(-)

diff --git a/package/firmware/ath10k-ct-firmware/Makefile 
b/package/firmware/ath10k-ct-firmware/Makefile
index 18370b7d85..10c72ae4c2 100644
--- a/package/firmware/ath10k-ct-firmware/Makefile
+++ b/package/firmware/ath10k-ct-firmware/Makefile
@@ -95,14 +95,14 @@ define Download/ct-firmware-htt
   URL_FILE:=$($(1)_FIRMWARE_FILE_CT_HTT)
 endef
 
-QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.018
+QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.019
 define Download/ath10k-firmware-qca988x-ct
   $(call Download/ct-firmware,QCA988X,)
   HASH:=8b4c99253aa309d35f2e060c190091b8db1b84dbda06a6a15c83ac0f9a938126
 endef
 $(eval $(call Download,ath10k-firmware-qca988x-ct))
 
-QCA988X_FIRMWARE_FILE_CT_FULL_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.018
+QCA988X_FIRMWARE_FILE_CT_FULL_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.019
 define Download/ath10k-firmware-qca988x-ct-full-htt
   $(call Download/ct-firmware-full-htt,QCA988X,)
   HASH:=a7168916d6aa5e4d7858f8b620c0c980c76d03f390929db6f4077685ce2051e7
@@ -110,14 +110,14 @@ endef
 $(eval $(call Download,ath10k-firmware-qca988x-ct-full-htt))
 
 
-QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.018
+QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.019
 define Download/ath10k-firmware-qca9887-ct
   $(call Download/ct-firmware,QCA9887,ath10k-9887)
   HASH:=459692deb186a63ab8eeddb7ad5d54779266e68ca686e7c46062554db6dca12b
 endef
 $(eval $(call Download,ath10k-firmware-qca9887-ct))
 
-QCA9887_FIRMWARE_FILE_CT_FULL_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.018
+QCA9887_FIRMWARE_FILE_CT_FULL_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.019
 define Download/ath10k-firmware-qca9887-ct-full-htt
   $(call Download/ct-firmware-full-htt,QCA9887,ath10k-9887)
   HASH:=fd126a457d0927d0c8ea10d66ef5b67d5e1e0741f8692bb3016bb602d0af3098
@@ -125,90 +125,90 @@ endef
 $(eval $(call Download,ath10k-firmware-qca9887-ct-full-htt))
 
 
-QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.018
+QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.019
 define Download/ath10k-firmware-qca99x0-ct
   $(call Download/ct-firmware,QCA99X0,ath10k-10-4b)
-  HASH:=cf26eb37524de54af51fe9b2efffc85e0e70ab849e8607ef63ce5a8ecffeaa42
+  HASH:=7dc934f934bc4973c9273a4f22cfead8e26ec6f579647af31b718a860eca0a4b
 endef
 $(eval $(call Download,ath10k-firmware-qca99x0-ct))
 
-QCA99X0_FIRMWARE_FILE_CT_FULL_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.018
+QCA99X0_FIRMWARE_FILE_CT_FULL_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.019
 define Download/ath10k-firmware-qca99x0-ct-full-htt
   $(call Download/ct-firmware-full-htt,QCA99X0,ath10k-10-4b)
-  HASH:=e9737538d7379e13ad4e4c8c519a63659b5e34a35455ed9ac4399ae8097caabc
+  HASH:=71a27b245a382fe009938d2826d5c97a90dceb10ddf638325268df91837ea302
 endef
 $(eval $(call Download,ath10k-firmware-qca99x0-ct-full-htt))
 
-QCA99X0_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-htt-mgt-community-12.bin-lede.018
+QCA99X0_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-htt-mgt-community-12.bin-lede.019
 define Download/ath10k-firmware-qca99x0-ct-htt
   $(call Download/ct-firmware-htt,QCA99X0,ath10k-10-4b)
-  HASH:=4d4f74afca487d452f244cd48304cf9710d8941eb97a6346a949ed6b6877d657
+  HASH:=9ed4fe41e5b0f30172f71ae0fe382dc0aab8aa4f8a898417af4f7ee936575ef6
 endef
 $(eval $(call Download,ath10k-firmware-qca99x0-ct-htt))
 
 
-QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.018
+QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.019
 define Download/ath10k-firmware-qca9984-ct
   $(call Download/ct-firmware,QCA9984,ath10k-9984-10-4b)
-  HASH:=a6b3d66efe640a430a837f238e91eddcd423eed6b887d3ae19716d87a71fd0b1
+  HASH:=32d13f432691fe759ded7d027052e925233adb436cd8f729f85ec3d19ccd1dfd
 endef
 $(eval $(call Download,ath10k-firmware-qca9984-ct))
 
-QCA9984_FIRMWARE_FILE_CT_FULL_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.018
+QCA9984_FIRMWARE_FILE_CT_FULL_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.019
 define Download/ath10k-firmware-qca9984-ct-full-htt
   $(call Download/ct-firmware-full-htt,QCA9984,ath10k-9984-10-4b)
-  HASH:=96060227e372b3b210badccbe6b0bd75d9a35335a7a0f2966964e9e89f66b00f
+  HASH:=e8ab69777bd00b5fc6b1b7acccb55b903553a99932a5b0351602b5f690106588
 endef
 $(eval $(call Download,ath10k-firmware-qca9984-ct-full-htt))
 
-QCA9984_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-htt-mgt-community-12.bin-lede.018
+QCA9984_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-htt-mgt-community-12.bin-lede.019
 define Download/ath10k-firmware-qca9984-ct-htt
   $(call Download/ct-firmware-htt,QCA9984,ath10k-9984-10-4b)
-  HASH:=ee593fb5724d75c372de02ac7894e1630ee9f909fcb2e2bbf17aadef67cb9d43
+  HASH:=74449b303b626e071

[RFC PATCH] Splitting auth_cache

2020-07-14 Thread Michael Yartys

Currently both PMKSA caching and Opportunistic Key Caching are set by the
option auth_cache. iOS devices are unable to connect to WPA3-Personal
networks when PMKSA caching is not enabled, but setting auth_cache to 1
also enables Opportunistic Key Caching which is not required. This doesn't
seem to have any negative impact, but I believe it's better to do things
properly and split auth_cache into its constituent pats to be able to set
them individually. Having separate options would also be good for those who
for whatever reason wish to test these features separately.

However, a potential problem is that the wireless config options would
change, and those who use the auth_cache option would need to update their
config. This is why I'm sending this as an RFC.

The following patches have been tested on my R7800 with a 5th gen. iPad.



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

[RFC PATCH 1/2] hostapd: split auth_cache into individual components

2020-07-14 Thread Michael Yartys

Split auth_cache into pmksa_cache (PMKSA caching) and
okc (Opportunistic Key Caching) to enable setting these options
individually.

Signed-off-by: Michael Yartys 
---
 .../network/services/hostapd/files/hostapd.sh   | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/package/network/services/hostapd/files/hostapd.sh 
b/package/network/services/hostapd/files/hostapd.sh
index f4e2aa559c..644bad2a62 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -191,7 +191,7 @@ hostapd_common_add_bss_config() {
 
config_add_boolean tdls_prohibit
 
-   config_add_boolean rsn_preauth auth_cache
+   config_add_boolean rsn_preauth pmksa_cache okc
config_add_int ieee80211w
config_add_int eapol_version
 
@@ -308,7 +308,7 @@ hostapd_set_bss_options() {
json_get_vars \
wep_rekey wpa_group_rekey wpa_pair_rekey wpa_master_rekey 
wpa_strict_rekey \
wpa_disable_eapol_key_retries tdls_prohibit \
-   maxassoc max_inactivity disassoc_low_ack isolate auth_cache \
+   maxassoc max_inactivity disassoc_low_ack isolate pmksa_cache 
okc \
wps_pushbutton wps_label ext_registrar wps_pbc_in_m1 
wps_ap_setup_locked \
wps_independent wps_device_type wps_device_name 
wps_manufacturer wps_pin \
macfilter ssid utf8_ssid wmm uapsd hidden short_preamble 
rsn_preauth \
@@ -609,22 +609,25 @@ hostapd_set_bss_options() {
 
if [ "$wpa" -ge "2" ]; then
if [ -n "$network_bridge" -a "$rsn_preauth" = 1 ]; then
-   set_default auth_cache 1
+   set_default pmksa_cache 1
+   set_default okc 1
append bss_conf "rsn_preauth=1" "$N"
append bss_conf 
"rsn_preauth_interfaces=$network_bridge" "$N"
else
case "$auth_type" in
sae|psk-sae|owe)
-   set_default auth_cache 1
+   set_default pmksa_cache 1
+   set_default okc 1
;;
*)
-   set_default auth_cache 0
+   set_default pmksa_cache 0
+   set_default okc 0
;;
esac
fi
 
-   append bss_conf "okc=$auth_cache" "$N"
-   [ "$auth_cache" = 0 ] && append bss_conf 
"disable_pmksa_caching=1" "$N"
+   append bss_conf "okc=$okc" "$N"
+   [ "$pmksa_cache" = 0 ] && append bss_conf 
"disable_pmksa_caching=1" "$N"
 
# RSN -> allow management frame protection
case "$ieee80211w" in
-- 
2.26.2


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

[RFC PATCH 2/2] hostapd: disable okc by default on WPA3-Personal networks

2020-07-14 Thread Michael Yartys

Don't enable Opportunistic Key Caching by default on WPA3-Personal
networks. iOS devices only require PMKSA caching to be enabled to connect
to a WPA3-Personal network, not Opportunistic Key Caching.

Fixes: 3034f8c3b85e70b1dd9b4cd5cd33e9d2cd8be3b8 ("hostapd: enable PMKSA and OK 
caching for WPA3-Personal")

Signed-off-by: Michael Yartys 
---
 package/network/services/hostapd/files/hostapd.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/network/services/hostapd/files/hostapd.sh 
b/package/network/services/hostapd/files/hostapd.sh
index 644bad2a62..e8c7d5154e 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -617,7 +617,7 @@ hostapd_set_bss_options() {
case "$auth_type" in
sae|psk-sae|owe)
set_default pmksa_cache 1
-   set_default okc 1
+   set_default okc 0
;;
*)
set_default pmksa_cache 0
-- 
2.26.2


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

Re: [PATCH] wireless-regdb: add country selection

2020-07-14 Thread Florian Eckert





What's the use case for this?
As much as I remember there was the problem in 2017 that you can't 
change the country code or have to restrict it.

https://ec.europa.eu/growth/sectors/electrical-engineering/red-directive_de
Of course this change can't fulfill with this patch, but it wouldn't be 
bad if you can put together regdb yourself and not always provide all 
country codes.


Couldn't we simply add add two options to blacklist or whitelist 
country

codes using a comma separated string?


That doesn't sound like a bad idea.
If the option CONFIG_WIRELESS_REGDB_WHITELIST or 
CONFIG_WIRELESS_REGDB_BLACKLIST is configured then a regdb is created at 
compile time?

Otherwise the package uses the regdb as it is.

Kind regards

Florian

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

[PATCH] ramips: move redundant console setup to mt7621 SoC DTSI

2020-07-14 Thread Adrian Schmutzler

For mt7621, console is set up via DTS bootargs individually in
device DTS/DTSI files. However, 44 of 74 statements use the
following setting:

chosen {
bootargs = "console=ttyS0,57600";
};

Therefore, don't repeat ourselves and move that definition to the SoC
DTSI file.

This patch is cosmetic.

Signed-off-by: Adrian Schmutzler 
---
 target/linux/ramips/dts/mt7621.dtsi   | 4 
 target/linux/ramips/dts/mt7621_adslr_g7.dts   | 4 
 target/linux/ramips/dts/mt7621_afoundry_ew1200.dts| 4 
 target/linux/ramips/dts/mt7621_asiarf_ap7621.dtsi | 4 
 target/linux/ramips/dts/mt7621_asus_rt-ac57u.dts  | 4 
 target/linux/ramips/dts/mt7621_asus_rt-acx5p.dtsi | 4 
 target/linux/ramips/dts/mt7621_buffalo_wsr-1166dhp.dts| 4 
 target/linux/ramips/dts/mt7621_buffalo_wsr-2533dhpl.dts   | 4 
 target/linux/ramips/dts/mt7621_buffalo_wsr-600dhp.dts | 4 
 target/linux/ramips/dts/mt7621_dlink_dir-860l-b1.dts  | 4 
 target/linux/ramips/dts/mt7621_dlink_dir-878-a1.dts   | 4 
 target/linux/ramips/dts/mt7621_edimax_re23s.dts   | 4 
 target/linux/ramips/dts/mt7621_edimax_rx21s.dtsi  | 4 
 target/linux/ramips/dts/mt7621_elecom_wrc-1167ghbk2-s.dts | 4 
 target/linux/ramips/dts/mt7621_elecom_wrc-gst.dtsi| 4 
 target/linux/ramips/dts/mt7621_firefly_firewrt.dts| 4 
 target/linux/ramips/dts/mt7621_gehua_ghl-r-001.dts| 4 
 target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts  | 4 
 target/linux/ramips/dts/mt7621_gnubee_gb-pc2.dts  | 4 
 target/linux/ramips/dts/mt7621_iodata_wn-xx-xr.dtsi   | 4 
 target/linux/ramips/dts/mt7621_iodata_wnpr2600g.dts   | 4 
 target/linux/ramips/dts/mt7621_iptime_a6ns-m.dts  | 4 
 target/linux/ramips/dts/mt7621_iptime_a8004t.dts  | 4 
 target/linux/ramips/dts/mt7621_jcg_jhr-ac876m.dts | 4 
 target/linux/ramips/dts/mt7621_linksys_re6500.dts | 4 
 target/linux/ramips/dts/mt7621_mediatek_ap-mt7621a-v60.dts| 4 
 target/linux/ramips/dts/mt7621_mediatek_mt7621-eval-board.dts | 4 
 target/linux/ramips/dts/mt7621_mqmaker_witi.dts   | 4 
 target/linux/ramips/dts/mt7621_mtc_wr1201.dts | 4 
 target/linux/ramips/dts/mt7621_netgear_ex6150.dts | 4 
 target/linux/ramips/dts/mt7621_netgear_sercomm_ayx.dtsi   | 4 
 target/linux/ramips/dts/mt7621_netgear_sercomm_bzv.dtsi   | 4 
 target/linux/ramips/dts/mt7621_netgear_sercomm_chj.dtsi   | 4 
 target/linux/ramips/dts/mt7621_netgear_wac104.dts | 4 
 target/linux/ramips/dts/mt7621_netis_wf2881.dts   | 4 
 target/linux/ramips/dts/mt7621_phicomm_k2p.dts| 4 
 target/linux/ramips/dts/mt7621_planex_vr500.dts   | 4 
 target/linux/ramips/dts/mt7621_samknows_whitebox-v8.dts   | 4 
 target/linux/ramips/dts/mt7621_storylink_sap-g3200u3.dts  | 4 
 target/linux/ramips/dts/mt7621_totolink_a7000r.dts| 4 
 target/linux/ramips/dts/mt7621_tplink_re350-v1.dts| 4 
 target/linux/ramips/dts/mt7621_tplink_rexx0-v1.dtsi   | 4 
 target/linux/ramips/dts/mt7621_ubnt_edgerouter-x.dtsi | 4 
 target/linux/ramips/dts/mt7621_wevo_w2914ns-v2.dtsi   | 4 
 target/linux/ramips/dts/mt7621_xiaomi_router-ac2100.dtsi  | 1 -
 target/linux/ramips/dts/mt7621_xiaoyu_xy-c5.dts   | 4 
 target/linux/ramips/dts/mt7621_zyxel_wap6805.dts  | 4 
 47 files changed, 4 insertions(+), 181 deletions(-)

diff --git a/target/linux/ramips/dts/mt7621.dtsi 
b/target/linux/ramips/dts/mt7621.dtsi
index 78979dc420..6172784869 100644
--- a/target/linux/ramips/dts/mt7621.dtsi
+++ b/target/linux/ramips/dts/mt7621.dtsi
@@ -35,6 +35,10 @@
serial0 = &uartlite;
};
 
+   chosen {
+   bootargs = "console=ttyS0,57600";
+   };
+
pll: pll {
compatible = "mediatek,mt7621-pll", "syscon";
 
diff --git a/target/linux/ramips/dts/mt7621_adslr_g7.dts 
b/target/linux/ramips/dts/mt7621_adslr_g7.dts
index aa3f423f9b..b6af1155c5 100644
--- a/target/linux/ramips/dts/mt7621_adslr_g7.dts
+++ b/target/linux/ramips/dts/mt7621_adslr_g7.dts
@@ -18,10 +18,6 @@
label-mac-device = &gmac0;
};
 
-   chosen {
-   bootargs = "console=ttyS0,57600";
-   };
-
leds {
compatible = "gpio-leds";
 
diff --git a/target/linux/ramips/dts/mt7621_afoundry_ew1200.dts 
b/target/linux/ramips/dts/mt7621_afoundry_ew1200.dts
index 2384fadbee..661c7d89de 100644
--- a/target/linux/ramips/dts/mt7621_afoundry_ew1200.dts
+++ b/target/linux/ramips/dts/mt7621_afoundry_ew1200.dts
@@ -16,10 +16,6 @@

Re: [PATCH] busybox: tr: enable options required by POSIX

2020-07-14 Thread Bjørn Mork

Jordan Geoghegan  writes:

> 'tr' is a standard system utility, I wasn't expecting such pushback
> against making it behave as every other modern implementation does.

OpenWrt exists because it is different from every other distribution.

https://openwrt.org/about describes it as "all the features you need
with none of the bloat".  There is no promise of all the features you
want, or all the featues of any other distro, or even all POSIX
features. What you "need" is obviously something you can discuss, but I
believe it is reasonable to limit it to the software included with the
distro.  OpenWrt specific porting might be required for any 3rd party
scripts or applications, even those running unmodified on other distros.

OpenWrt provides GNU coreutils as an optional alternative for the 'tr'
application.  This is full featured++, like GNU utils often are.

Just my 2 peanuts.

Bjørn

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

Re: [PATCH] busybox: tr: enable options required by POSIX

2020-07-14 Thread Jordan Geoghegan




On 2020-07-14 02:08, Petr Štetiar wrote:

Jordan Geoghegan  [2020-07-13 23:06:30]:


Also, the use of "tr 'a-z'..." is unsafe for exotic locales

Buildsystem sets LC_ALL=C explicitly, so whats the issue here?


I've reported that 'tr' behaves abnormally, that's about all I can do. 
If you guys want to be edgelords and ship a broken 'tr' in the name of 
saving 500 bytes, then that's your prerogative.


'tr' is a standard system utility, I wasn't expecting such pushback 
against making it behave as every other modern implementation does.


If there's somebody here on the mailing list with commit access that 
wants to do something about this, then I guess now is the time to have 
your say.


Regards,

Jordan Geoghegan

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

Re: [PATCH] busybox: tr: enable options required by POSIX

2020-07-14 Thread Petr Štetiar

Jordan Geoghegan  [2020-07-13 23:06:30]:

> Also, the use of "tr 'a-z'..." is unsafe for exotic locales

Buildsystem sets LC_ALL=C explicitly, so whats the issue here?

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

Re: [PATCH] busybox: tr: enable options required by POSIX

2020-07-14 Thread Petr Štetiar

Jordan Geoghegan  [2020-07-13 22:44:05]:

> scripts/mkits.sh
> 59:ARCH_UPPER=$(echo "$ARCH" | tr '[:lower:]' '[:upper:]')

What's a problem here? It's running on host, so this classes are supported.

> ryzen$ rg "tr '\["
> utils/lxc/patches/010-Remove-distro-check.patch
> 43:-with_distro=`echo ${with_distro} | tr '[[:upper:]]' '[[:lower:]]'`

Upstream issue, it's removed, so not actually used, but still host related.
Should be fixed upstream anyway not OpenWrt related. Unlikely that this value
would ever contain square brackets.

> sound/shairport-sync/patches/010-no-cxx.patch
> 28:@@ -19,7 +19,6 @@ with_os=`echo ${with_os} | tr '[[:upper:]]'
> '[[:lower:]]' `

Upstream issue, this is context in the patch not added by OpenWrt, running on
host. Unlikely that this value would ever contain square brackets.

> utils/pciutils/patches/105-fix-host.patch
> 7:-host=`echo $HOST | sed -e
> 's/^\([^-]*\)-\([^-]*\)-\([^-]*\)-\([^-]*\)$/\1-\3/' -e
> 's/^\([^-]*\)-\([^-]*\)-\([^-]*\)$/\1-\2/' -e
> 's/^\([^-]*\)-\([^-]*\)$/\1--\2/' | tr '[A-Z]' '[a-z]'`
> 8:+host=`echo $HOST | sed -e
> 's/^\([^-]*\)-\([^-]*\)-\([^-]*\)-\([^-]*\)$/\1-\3/' -e
> 's/^\([^-]*\)-\([^-]*\)$/\1--\2/' | tr '[A-Z]' '[a-z]'`

Upstream even provided you the comment few lines above:

 # CAVEAT: tr on Solaris is a bit weird and the extra [] is otherwise harmless.

> net/ser2net/files/ser2net.init
> 28:    [ "$uc" -eq 1 ] && key=`echo "$key" | tr '[a-z]' '[A-Z]'`
> 120:    parity=`echo "$parity" | tr '[a-z]' '[A-Z]'`

If you look at the context, not an issue. Those values would never contain
square brackets. Anyway feel free to submit PR with a square brackets removal.

So actually no issues.

-- ynezz

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

RE: Re: [OpenWrt-Devel] [PATCH v6] ramips: add support for JS76x8 series DEV boards

2020-07-14 Thread mail

> 2.About "missing reg property".
> Adrian Schmutzler wrote a letter to me about that, then I tested as he said, 
> it was ok. Here is the letter from him.

@Petr: The reg property is in the DTS files, while everything else is in the 
DTSI. It's also a case of DRY :-)

> 5.About "Be DRY, use some common Device and just change IMAGE_SIZE and 
> DEVICE_VARIANT".
> Here are three real type of boards by my hand, each has different flash, I 
> don't think it's good way to change board types by modifying the DTS file, 
> it's better to do that by selecting in menuconfig.

@Robinson Wu: That's a misunderstanding from your side. What Petr meant was 
just to rearrange the definitions inside mt76x8.mk like this, so you define a 
common blueprint and then use that for the actual device definitions (note that 
MTK_SOC is not required anymore, as it's defined globally at the top of the 
file):

+define Device/jotale_js76x8
+  DEVICE_VENDOR := Jotale
+  DEVICE_MODEL := JS76x8
+  DEVICE_PACKAGES := kmod-usb2 kmod-usb-ohci
+endef

+define Device/jotale_js76x8-16m
+  $(Device/jotale_js76x8)
+  IMAGE_SIZE := 16064k
+  DEVICE_VARIANT := 16M
+endef
+TARGET_DEVICES += jotale_js76x8-16m

and so on for the other two devices.

I just didn't request that as I personally prefer individual statement if it's 
"just" three lines for the common definition.

Apart from that, please note these additional comments:

7. In master, gpio setup has changed, so you only have one &gpio now. So you 
will need to convert e.g.
<&gpio1 5 GPIO_ACTIVE_LOW>;
to
<&gpio 37 GPIO_ACTIVE_LOW>;

8. pinctrl property rename:
Convert
+   ralink,group = "p1led_an";
+   ralink,function = "p1led_an";
to
+   groups = "p1led_an";
+   ralink,function = "p1led_an";

Sorry for not having taken care earlier, but I can review only 80 % of your PR, 
and that's just not enough to merge it.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules

Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules

Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules

Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules

dnsmasq responding to the outside

Re: [PATCH] busybox: tr: enable options required by POSIX

Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules

Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules

Re: [PATCH] busybox: tr: enable options required by POSIX

Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules

Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules

[PATCH] zram-swap: drop the conditional dependency on swap-utils

[PATCH v2 1/6] build: add DEVICE_COMPAT_VERSION and DEVICE_COMPAT_MESSAGE

[PATCH v2 0/6] sysupgrade: introduce compatibility version for devices

[PATCH v2 5/6] mvebu: implement compatibility version for DSA migration

[PATCH v2 2/6] base-files: add support for compat_version on device

[PATCH v2 6/6] kirkwood: implement compatibility version for DSA migration

[PATCH v2 3/6] base-files: fwtool: implement compatibility check for images

[PATCH v2 4/6] base-files: fwtool: make compat_version backward compatible

Re: [PATCH] wireless-regdb: add country selection

[PATCH] ath10k-ct-firmware: update firmware images

[PATCH] ath10k-ct-firmware: update firmware images

[RFC PATCH] Splitting auth_cache

[RFC PATCH 1/2] hostapd: split auth_cache into individual components

[RFC PATCH 2/2] hostapd: disable okc by default on WPA3-Personal networks

Re: [PATCH] wireless-regdb: add country selection

[PATCH] ramips: move redundant console setup to mt7621 SoC DTSI

Re: [PATCH] busybox: tr: enable options required by POSIX

Re: [PATCH] busybox: tr: enable options required by POSIX

Re: [PATCH] busybox: tr: enable options required by POSIX

Re: [PATCH] busybox: tr: enable options required by POSIX

RE: Re: [OpenWrt-Devel] [PATCH v6] ramips: add support for JS76x8 series DEV boards

32 matches

Site Navigation

Mail list logo

Footer information