Re: Luci->Network->Interfaces is broken
On 30.05.2021 18:02, e9hack wrote:
Am 30.05.2021 um 15:41 schrieb e9hack:
Am 30.05.2021 um 09:59 schrieb Rafał Miłecki:
On 29.05.2021 23:28, e9hack wrote:
I'm using a TP-Link Archer C7 v2 router. For every build, I do update my
sandbox with the current OpenWrt repository and the feeds. The first not
working build from 27.05. shows in Luci:
OpenWrt SNAPSHOT r16834-53b9cc442f / LuCI Master git-21.147.31971-74be304
Related to the changes to bridge configuration, I'm using some bridge
interfaces without a configured network device, because it's for a single WiFi
device only. For such interfaces, the configuration was not changed. I did
generate a device section without ports options manually. But it didn't help.
I broken my crystal ball, please post your network config.
74be304 is known to introduce a bug, see e7c9c63c6579 ("luci-mod-network: split
config migration into 2 steps")
If your network config already got migrated into broken version you may need to
fix it up manually.
This is my network config. I did change the option ifname to device for
interface lan manually.
I'm trying the same with a TP-Link WDR3600 router. The same does occur. I did
do a factory reset. Nothing did change. I get the same error page. Build is
OpenWrt SNAPSHOT r16844-296aa0781b / LuCI Master git-21.148.48881-79947af.
Please try the standard LuCI interface and let us know if that one works
correctly.
What do you see in web browser's console on that page?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC v2 3/3] ath79: add support for Mikrotik RouterBoard 912G
Hello Adrian,
On Mon, May 31, 2021 at 1:15 AM Adrian Schmutzler
wrote:
>
> Hi,
>
> > -Original Message-
> > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> > On Behalf Of Sergey Ryazanov
> > Sent: Montag, 24. Mai 2021 01:07
> > To: Adrian Schmutzler ; Denis Kalashnikov
> >
> > Cc: OpenWrt Development List ; Gabor
> > Juhos ; Koen Vandeputte
> >
> > Subject: Re: [RFC v2 3/3] ath79: add support for Mikrotik RouterBoard 912G
> >
> > Hello Adrian and Denis,
> >
> > sorry for interfering with your conversation, I would like to discuss the
> > best
> > way to document not yet finished functionality. Please find my question and
> > proposal below.
> >
> > On Sun, May 23, 2021 at 12:01 PM Adrian Schmutzler
> > wrote:
> >
> > [skipped]
> >
> > >> + beeper {
> > >> + status = "disabled";
> > >> + compatible = "gpio-beeper";
> > >> + gpios = < 5 GPIO_ACTIVE_HIGH>;
> > >> + };
> > >
> > > If it's broken, I'd not add it here but just name the correct GPIO number
> > > in
> > the commit message.
> > >
> > >> +
> > >> + keys {
> > >> + status = "disabled";
> > >
> > > Like above: If it's broken, remove it, so nobody enables it accidentally
> > > and
> > causes harm.
> > > (But document how to set it up in the commit message, as you mostly
> > > did already ...)
> >
> > Factoring out realization details to the commit message is quite unusual, I
> > personally assume that the commit message is a place where a committer
> > should describe reasons for a particular change. While hard to understand
> > things should be commented on in the code themself.
> >
> > I agree with Adrian that a not yet finished code should not be committed to
> > the master branch. But the device tree has a dualistic nature, on one hand
> > it
> > is a place for driver configuration, on the other hand it is a way to
> > document
> > board stuff interconnections. So maybe we should combine Denise's
> > approach to document even a not yet fully supported component in the DTS
> > with Adrian's suggestion to document why a component is not supported yet
> > and place the reason to disable DTS node as comment inside the node? E.g.:
>
> My main motivation is preventing too much bloat in the DTS files.
>
> Nevertheless, typically, if stuff is not working it will either not be
> resolved ever
> or the solution will deviate from what people were thinking it would be
> initially
> (otherwise, they would have solved it back then). Thus, the DTS
> "implementation" of that part is either irrelevant (first case) or
> wrong/subject
> to change (second case) later. In both cases, I don't think it really makes
> sense to add it to the DTS in the first place.
Well! These reasons for not adding broken nodes to DTS sounds
perfectly reasonable for me.
But what is the best way to document hard-to-find but not yet
functional GPIO lines then? Wiki? If so, should we add a wiki page URL
as a comment to the DTS to facilitate work of future contributors?
> Hovewer, I'm relatively flexible here. So if you really think it would be
> necessary to have this broken part of configuration in the DTS, I won't stop
> you because of that.
>
> >
> > 8< --- keys {
> > compatible = "gpio-keys-polled";
> >
> > reset {
> > ...
> > gpios = < 15 GPIO_ACTIVE_LOW>;
> > /*
> > * GPIO line #15 is shared between the reset button on input and
> > * the NAND ALE (via the latch) on output. We are unable to just
> > * enable the reset button. So, this node here is for
> > * documentation purposes only.
> > *
> > * [Here should be a text describing the possible ways to
> > * overcome shared line issues]
> > */
> > status = "disabled";
> > };
> > };
> > 8< ---
> >
> > This way we will keep all interconnection documentation in DTS and at the
> > same time we will make sure that no sane user enables this node.
> >
> > > > + compatible = "gpio-keys";
> > > > + reset {
> > > > + label = "reset";
> > > > + linux,code = ;
> > > > + gpios = < 15 GPIO_ACTIVE_LOW>;
> > > > + debounce-interval = <60>;
> > > > + };
> > > > + };
--
Sergey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [RFC v2 3/3] ath79: add support for Mikrotik RouterBoard 912G
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Koen Vandeputte > Sent: Donnerstag, 27. Mai 2021 13:52 > To: Adrian Schmutzler ; 'Denis Kalashnikov' > ; openwrt-devel@lists.openwrt.org > Cc: 'Gabor Juhos' ; 'Sergey Ryazanov' > > Subject: Re: [RFC v2 3/3] ath79: add support for Mikrotik RouterBoard 912G > > > On 23.05.21 11:01, Adrian Schmutzler wrote: > > ... > >> diff --git a/target/linux/ath79/image/mikrotik.mk > >> b/target/linux/ath79/image/mikrotik.mk > >> index 74f8603b5a..0072ec527d 100644 > >> --- a/target/linux/ath79/image/mikrotik.mk > >> +++ b/target/linux/ath79/image/mikrotik.mk > >> @@ -9,6 +9,15 @@ define Device/mikrotik_routerboard-493g endef > >> TARGET_DEVICES += mikrotik_routerboard-493g > >> > >> +define Device/mikrotik_routerboard-912g > >> + $(Device/mikrotik_nand) > >> + SOC := ar9342 > >> + DEVICE_MODEL := RouterBOARD 912G > >> + DEVICE_PACKAGES += kmod-usb-ehci kmod-usb2 kmod-gpio-beeper > >> + SUPPORTED_DEVICES += rb-912uag-5hpnd rb-912uag-2hpnd endef > > So, both have exactly the same setup as implemented here? > > > > Best > > > > Adrian > > > yes. > > I personally use rb-912uag-5hpnd board. > The hardware is identical with the exception of the band used. > > What's your 2 cents to get both supported using a single target? I do not have any problems with the presented solution, this was just a question. The naming and organization of the Mikrotik devices in OpenWrt has been an open discussion for quite some time now, and I have given up any hope of finding a solution that will be satisfying all competing requirements. (The only thing that I try to keep consistent for now is having "routerboard-" instead of "rb-" for the "new" names.) So, no objections for the choice made here. Best Adrian > > Thanks, > > Koen > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel 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 v2 3/3] ath79: add support for Mikrotik RouterBoard 912G
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Sergey Ryazanov
> Sent: Montag, 24. Mai 2021 01:07
> To: Adrian Schmutzler ; Denis Kalashnikov
>
> Cc: OpenWrt Development List ; Gabor
> Juhos ; Koen Vandeputte
>
> Subject: Re: [RFC v2 3/3] ath79: add support for Mikrotik RouterBoard 912G
>
> Hello Adrian and Denis,
>
> sorry for interfering with your conversation, I would like to discuss the best
> way to document not yet finished functionality. Please find my question and
> proposal below.
>
> On Sun, May 23, 2021 at 12:01 PM Adrian Schmutzler
> wrote:
>
> [skipped]
>
> >> + beeper {
> >> + status = "disabled";
> >> + compatible = "gpio-beeper";
> >> + gpios = < 5 GPIO_ACTIVE_HIGH>;
> >> + };
> >
> > If it's broken, I'd not add it here but just name the correct GPIO number in
> the commit message.
> >
> >> +
> >> + keys {
> >> + status = "disabled";
> >
> > Like above: If it's broken, remove it, so nobody enables it accidentally and
> causes harm.
> > (But document how to set it up in the commit message, as you mostly
> > did already ...)
>
> Factoring out realization details to the commit message is quite unusual, I
> personally assume that the commit message is a place where a committer
> should describe reasons for a particular change. While hard to understand
> things should be commented on in the code themself.
>
> I agree with Adrian that a not yet finished code should not be committed to
> the master branch. But the device tree has a dualistic nature, on one hand it
> is a place for driver configuration, on the other hand it is a way to document
> board stuff interconnections. So maybe we should combine Denise's
> approach to document even a not yet fully supported component in the DTS
> with Adrian's suggestion to document why a component is not supported yet
> and place the reason to disable DTS node as comment inside the node? E.g.:
My main motivation is preventing too much bloat in the DTS files.
Nevertheless, typically, if stuff is not working it will either not be resolved
ever or the solution will deviate from what people were thinking it would be
initially (otherwise, they would have solved it back then). Thus, the DTS
"implementation" of that part is either irrelevant (first case) or
wrong/subject to change (second case) later. In both cases, I don't think it
really makes sense to add it to the DTS in the first place.
Hovewer, I'm relatively flexible here. So if you really think it would be
necessary to have this broken part of configuration in the DTS, I won't stop
you because of that.
Best
Adrian
>
> 8< --- keys {
> compatible = "gpio-keys-polled";
>
> reset {
> ...
> gpios = < 15 GPIO_ACTIVE_LOW>;
> /*
> * GPIO line #15 is shared between the reset button on input and
> * the NAND ALE (via the latch) on output. We are unable to just
> * enable the reset button. So, this node here is for
> * documentation purposes only.
> *
> * [Here should be a text describing the possible ways to
> * overcome shared line issues]
> */
> status = "disabled";
> };
> };
> 8< ---
>
> This way we will keep all interconnection documentation in DTS and at the
> same time we will make sure that no sane user enables this node.
>
> > > + compatible = "gpio-keys";
> > > + reset {
> > > + label = "reset";
> > > + linux,code = ;
> > > + gpios = < 15 GPIO_ACTIVE_LOW>;
> > > + debounce-interval = <60>;
> > > + };
> > > + };
>
> --
> Sergey
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[sdwalker/sdwalker.github.io] a874bb: This week's update
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Branch: refs/heads/master Home: https://github.com/sdwalker/sdwalker.github.io Commit: a874bb8f2f9cac7f48a121cda291a7d618111c7d https://github.com/sdwalker/sdwalker.github.io/commit/a874bb8f2f9cac7f48a121cda291a7d618111c7d Author: Stephen Walker Date: 2021-05-30 (Sun, 30 May 2021) Changed paths: M uscan/index-18.06.html M uscan/index-19.07.html M uscan/index.html Log Message: --- This week's update --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Luci->Network->Interfaces is broken
Am 30.05.2021 um 15:41 schrieb e9hack:
Am 30.05.2021 um 09:59 schrieb Rafał Miłecki:
On 29.05.2021 23:28, e9hack wrote:
I'm using a TP-Link Archer C7 v2 router. For every build, I do update my
sandbox with the current OpenWrt repository and the feeds. The first not
working build from 27.05. shows in Luci:
OpenWrt SNAPSHOT r16834-53b9cc442f / LuCI Master git-21.147.31971-74be304
Related to the changes to bridge configuration, I'm using some bridge
interfaces without a configured network device, because it's for a single WiFi
device only. For such interfaces, the configuration was not changed. I did
generate a device section without ports options manually. But it didn't help.
I broken my crystal ball, please post your network config.
74be304 is known to introduce a bug, see e7c9c63c6579 ("luci-mod-network: split
config migration into 2 steps")
If your network config already got migrated into broken version you may need to
fix it up manually.
This is my network config. I did change the option ifname to device for
interface lan manually.
I'm trying the same with a TP-Link WDR3600 router. The same does occur. I did
do a factory reset. Nothing did change. I get the same error page. Build is
OpenWrt SNAPSHOT r16844-296aa0781b / LuCI Master git-21.148.48881-79947af.
Regards,
Hartmut
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fd25:357b:1499::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth0.1'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
config device
option name 'eth0.2'
option macaddr 'ff:ff:ff:ff:ff:ff'
config interface 'wan'
option device 'eth0.2'
option proto 'dhcp'
config interface 'wan6'
option device 'eth0.2'
option proto 'dhcpv6'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option ports '2 3 4 5 0t'
config switch_vlan
option device 'switch0'
option vlan '2'
option ports '1 0t'
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH luci] luci-mod-network: split config migration into 2 steps
Am Samstag, 29. Mai 2021, 18:10:59 CEST schrieb Hauke Mehrtens: > On 5/29/21 5:25 PM, Rafał Miłecki wrote: > > > > For the sake of simplicity and reliability use 2 steps migration. The > > downside is that users may get prompted twice to migrate. > > > > I tested it in OpenWrt 21.02 doing the migration in one step by clicking > continue 2 times and also interrupting it in between, both worked. > I just gave it a try from a 21.02-rc1 based config and it looks fine. One note: I made PR https://github.com/openwrt/luci/pull/5086 to include a hint, that the conversion-dialog might come up multiple times. This will prevent confusion of the user, which might expect an endless loop when the dialog comes up the 2nd time. Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Luci->Network->Interfaces is broken
Am 30.05.2021 um 09:59 schrieb Rafał Miłecki:
On 29.05.2021 23:28, e9hack wrote:
I'm using a TP-Link Archer C7 v2 router. For every build, I do update my
sandbox with the current OpenWrt repository and the feeds. The first not
working build from 27.05. shows in Luci:
OpenWrt SNAPSHOT r16834-53b9cc442f / LuCI Master git-21.147.31971-74be304
Related to the changes to bridge configuration, I'm using some bridge
interfaces without a configured network device, because it's for a single WiFi
device only. For such interfaces, the configuration was not changed. I did
generate a device section without ports options manually. But it didn't help.
I broken my crystal ball, please post your network config.
74be304 is known to introduce a bug, see e7c9c63c6579 ("luci-mod-network: split
config migration into 2 steps")
If your network config already got migrated into broken version you may need to
fix it up manually.
This is my network config. I did change the option ifname to device for
interface lan manually.
Regards,
Hartmut
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fde9:abcd:0123::/48'
config interface 'lan'
option proto 'static'
option ipaddr '192.168.103.1'
list ip6addr 'fec0:0:0::0:0:0:1/64'
list ip6addr 'fec0:0:0::0:0:0:2/64'
option netmask '255.255.255.0'
option ip6assign '62'
option ip6hint 'ad'
option device 'br-lan'
config interface 'guest1'
option type 'bridge'
option proto 'static'
option ipaddr '10.1.0.1'
option netmask '255.255.0.0'
option ip6hint 'e1'
option ip6assign '64'
option ip6class 'wan_6'
list ip6addr 'fec0:0::1:0:0:0:1/64'
config interface 'guest2'
option type 'bridge'
option proto 'static'
option ipaddr '10.2.0.1'
option netmask '255.255.0.0'
option ip6hint 'e2'
option ip6assign '64'
option ip6class 'wan_6'
list ip6addr 'fec0:0::2:0:0:0:1/64'
config interface 'IoT'
option type 'bridge'
option proto 'static'
option ipaddr '192.168.255.1'
option netmask '255.255.255.0'
option ipv6 '0'
config interface 'wan'
option ifname 'eth0.7'
option proto 'pppoe'
option username ''
option password ''
option keepalive '10 5'
option pppd_options 'debug'
option persist '1'
option maxfail '50'
option holdoff '5'
config interface 'modem'
option ifname 'eth0.2'
option proto 'static'
option ipaddr '192.168.1.80'
option netmask '255.255.255.0'
option peerdns '0'
option ipv6 '0'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option vid '1'
option ports '0t 2 3 4'
option description 'lan'
config switch_vlan
option device 'switch0'
option vlan '7'
option ports '1t 6t'
option vid '7'
option description 'wan'
config switch_vlan
option device 'switch0'
option vlan '2'
option ports '1 6t'
option vid '2'
option description 'modem'
config switch_port
option port '1'
option pvid '2'
config switch_vlan
option device 'switch0'
option vlan '3'
option ports '0t 5'
option vid '3'
option description 'phone'
config interface 'phone'
option ifname 'eth1.3'
option proto 'static'
option ipaddr '192.168.200.1'
option netmask '255.255.255.0'
option ipv6 '0'
config interface 'vpn'
option proto 'none'
option ifname 'tun1'
option auto '1'
config interface 'tor'
option type 'bridge'
option proto 'static'
option ipaddr '172.16.1.1'
option netmask '255.255.0.0'
option ipv6 '0'
config interface 'wg0'
option proto 'wireguard'
option listen_port '51820'
option addresses '100.64.10.0/32'
option private_key ''
option persistent_keepalive '25'
config wireguard_wg0
option preshared_key ''
option public_key ''
option route_allowed_ips '1'
list allowed_ips '100.64.10.102/32'
option persistent_keepalive '25'
option description ''
config wireguard_wg0
option preshared_key ''
option public_key ''
option route_allowed_ips '1'
list allowed_ips '100.64.10.30/32'
option persistent_keepalive '25'
option description ''
config wireguard_wg0
option preshared_key ''
option public_key ''
option route_allowed_ips '1'
list allowed_ips '100.64.10.108/32'
Re: Luci->Network->Interfaces is broken
On 29.05.2021 23:28, e9hack wrote:
I'm using a TP-Link Archer C7 v2 router. For every build, I do update my
sandbox with the current OpenWrt repository and the feeds. The first not
working build from 27.05. shows in Luci:
OpenWrt SNAPSHOT r16834-53b9cc442f / LuCI Master git-21.147.31971-74be304
Related to the changes to bridge configuration, I'm using some bridge
interfaces without a configured network device, because it's for a single WiFi
device only. For such interfaces, the configuration was not changed. I did
generate a device section without ports options manually. But it didn't help.
I broken my crystal ball, please post your network config.
74be304 is known to introduce a bug, see e7c9c63c6579 ("luci-mod-network: split
config migration into 2 steps")
If your network config already got migrated into broken version you may need to
fix it up manually.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
