Fwd: ZTE H201L
Hey guys, Im trying to put OpenWrt on my ZTE ZXV10-H201L and after flashing image without vmmc driver device boot's but without WiFi Here is little log trying to reset WiFi root@OpenWrt:/sys/devices/platform/1000.fpi/1e100b10.pinmux/gpiochip0/gpio/wifi# echo 0 > value root@OpenWrt:/sys/devices/platform/1000.fpi/1e100b10.pinmux/gpiochip0/gpio/wifi# echo 1 > value [ 310.050982] usb 1-1: new high-speed USB device number 3 using dwc2 [ 310.265365] usb 1-1: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested [ 310.564695] usb 1-1: ath9k_htc: Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size: 51008 [ 310.816790] ath9k_htc 1-1:1.0: ath9k_htc: HTC initialized with 33 credits [ 311.243039] ath: phy1: Failed to read SREV register [ 311.243061] ath: phy1: Could not read hardware revisions [ 311.246562] ath: phy1: Unable to initialize hardware; initialization status: -122 [ 311.259311] ath: phy1: Unable to initialize hardware; initialization status: -122 [ 311.273171] ath9k_htc: Failed to initialize the device [ 311.277527] usb 1-1: ath9k_htc: USB layer deinitialized So does anyone have and idea what should I try ? Best regards Slobodan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
FRAG Attacks (new vuln for wifi)
https://www.fragattacks.com/ https://lore.kernel.org/linux-wireless/20210511180259.159598-1-johan...@sipsolutions.net/ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Activate https server support in 21.02 by default
I am no sure https support should still be something by default in the images as it's not something really essential although the storage usage increase seems really low based on what you mention. Fernando On 11/05/2021 19:55, Hauke Mehrtens wrote: Hi, OpenWrt 21.02 currently ships with wolfssl and LuCI for http. It would be nice to also have https support included in the default images. To add this the following packages have to be added: * luci-ssl (969 Bytes ipkg) * px5g-wolfssl (5216 bytes ipkg) For me the images increased by 2.2 KBytes when these packages were included. We should *not* activate the automatic forwarding from http to https by default. This was deactivated here and should stay like this: https://git.openwrt.org/0cf3c5dd7257dff1c87b61c5e53e5b1787ab7015 It would be nice to have this as an option in the default LuCI configuration, see here: https://github.com/openwrt/luci/pull/4659 Where are the default packages for the 21.02 releases defined? I haven't found it here: https://git.openwrt.org/?p=buildbot.git;a=summary My proposal: * Add luci-ssl to the default packages for the 21.02 branch * merge this: https://github.com/openwrt/luci/pull/4659 @Jow what do you think about this? Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Activate https server support in 21.02 by default
Hi, OpenWrt 21.02 currently ships with wolfssl and LuCI for http. It would be nice to also have https support included in the default images. To add this the following packages have to be added: * luci-ssl (969 Bytes ipkg) * px5g-wolfssl (5216 bytes ipkg) For me the images increased by 2.2 KBytes when these packages were included. We should *not* activate the automatic forwarding from http to https by default. This was deactivated here and should stay like this: https://git.openwrt.org/0cf3c5dd7257dff1c87b61c5e53e5b1787ab7015 It would be nice to have this as an option in the default LuCI configuration, see here: https://github.com/openwrt/luci/pull/4659 Where are the default packages for the 21.02 releases defined? I haven't found it here: https://git.openwrt.org/?p=buildbot.git;a=summary My proposal: * Add luci-ssl to the default packages for the 21.02 branch * merge this: https://github.com/openwrt/luci/pull/4659 @Jow what do you think about this? Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[Q] [master][openwrt-21.02] Check on 'which' in include/prereq-build.mk fails for Fedora 34 since recently, how to fix?
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 ---
tldr; A recent upgrade of the which package on Fedora 34 broke the test
in OpenWRT on 'which' being installed on the host. I would love to send
a patch, but my question is how to fix this? Any ideas welcome!
Regards,
Bas.
I ran into the following:
$ ./scripst/feeds update -a
(...)
Checking 'rsync'... ok.
Checking 'which'... failed.
Checking 'ldconfig-stub'... ok.
Build dependency: Please install 'which'
(...)
$ rpm -qa which
which-2.21-26.fc34.x86_64
I noticed that file /etc/profile.d/which2.sh had changed recently. So I
downloaded previous version of the package and extracted said file.
Sourced the old file and ran update again:
$ . ~/Downloads/which2.sh
$ ./scripts/feeds update
(...)
Checking 'rsync'... ok.
Checking 'which'... ok.
Checking 'ldconfig-stub'... ok.
(...)
The relevant part in include/prereq-build.mk is:
$(eval $(call SetupHostCommand,which,Please install 'which', \
which which | grep which))
The difference between the two versions of which2.sh is:
$ diff -u ~/Downloads/which2.sh /etc/profile.d/which2.sh
--- /home/bas/Downloads/which2.sh 2021-03-23 20:22:52.0 +0100
+++ /etc/profile.d/which2.sh2021-05-04 11:52:55.0 +0200
@@ -1,18 +1,19 @@
# shellcheck shell=sh
# Initialization script for bash, sh, mksh and ksh
-_declare="declare -f"
-_opt="-f"
-_shell="$(basename $SHELL)"
+which_declare="declare -f"
+which_opt="-f"
+which_shell="$(cat /proc/$$/comm)"
-if [ "$_shell" = "ksh" ] || [ "$_shell" = "mksh" ] || [ "$_shell" =
"zsh" ] ; then
- _declare="typeset -f"
- _opt=""
+if [ "$which_shell" = "ksh" ] || [ "$which_shell" = "mksh" ] || [
"$which_shell" = "zsh" ] ; then
+ which_declare="typeset -f"
+ which_opt=""
fi
which ()
{
-(alias; eval ${_declare}) | /usr/bin/which --tty-only --read-alias
--read-functions --show-tilde --show-dot "$@"
+(alias; eval ${which_declare}) | /usr/bin/which --tty-only --read-alias
--read-functions --show-tilde --show-dot "$@"
}
-export ${_opt} which
+export which_declare
+export ${which_opt} which
I don't see why this breaks the check. The difference is mainly in
renaming the variables used.
As said, any hint welcome!
Regards,
Bas.
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
On 11/05/2021 19:51, Rafał Miłecki wrote: On 11.05.2021 19:46, John Crispin wrote: On 11.05.21 19:45, Rafał Miłecki wrote: I'm really tired of dealing with such hacky solutions. Look at netifd, DSA and LuCI as example. We ended up with something that noone fully understands. Jo - our UI guru - couldn't deal with designing a proper UI for that f*cked config syntax. sorry mate, I am not the reason you are having a bad day, so dont vent it out on me. It's just an example of shitty situation we got. Nothing more. I took a good amount of time to provide valuable review for the [PATCH v2] rtl83xx-poe: add package I described problems, missing parts, provided examples how one can solve it. Let's discuss that please. Instead of commenting on one example I provided. I think the growing RTL83xx crowd has shown that we are able to refactor code and strive for the good stuff, see all the drivers that are now getting into mainline. I also don't think we are getting into any kind of cul-de-sac we cannot get out, because also other platforms will make use of the uart-based interface these PoE chips offer, so I do not see that there would be any need for major re-designs, and in particular no need to implement this in kernel space. If for some reasons there are PoE solutions that have a similar command-set but different (GPIO) interface then if necessary this could be handled by a separate kernel module that would offer a uart interface for the user-space. Alternatively we go to a different user-space interface altogether, but it is clear a user-space solution which talks PoE commands will be needed. Birger ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] uqmi: fix network registration loop
On 10-05-21, Florian Eckert wrote:
>
>
> On 2021-05-08 12:33, Baptiste Jonglez wrote:
> > Applied, thanks.
> >
> > Does this need to be backported to 21.02 or even 19.07?
>
> yes that would not be bad at least for openwrt-21.02
> On openwrt-19.07 there are additional commits needed.
Ok, then I won't touch 19.07, unless uqmi support is really broken.
I've backported this patch to 21.02.
> Thanks for take care
>
> >
> > Baptiste
> >
> > On 20-04-21, thomas.rich...@kontron.com wrote:
> > > From: Thomas Richard
> > >
> > > With some debug in qmi.sh using following patch, some errors are
> > > visible
> > > in the registration step
> > > @@ -29,6 +29,7 @@ proto_qmi_init_config() {
> > > }
> > >
> > > proto_qmi_setup() {
> > > + set -x
> > > local interface="$1"
> > > local dataformat connstat plmn_mode mcc mnc
> > > local device apn auth username password pincode delay modes
> > > pdptype
> > > @@ -224,6 +225,8 @@ proto_qmi_setup() {
> > > fi
> > > done
> > >
> > > + registration=$(uqmi -s -d "$device" --get-serving-system)
> > > +
> > > [ -n "$modes" ] && uqmi -s -d "$device" --set-network-modes
> > > "$modes" > /dev/null 2>&1
> > >
> > > echo "Starting network $interface"
> > >
> > > During the boot of the system, modem could not start automatically its
> > > network registration.
> > > netifd: wan (9235): + echo 'Waiting for network registration'
> > > netifd: wan (9235): Waiting for network registration
> > > netifd: wan (9235): + local 'registration_timeout=0'
> > > netifd: wan (9235): + uqmi -s -d /dev/cdc-wdm1 --get-serving-system
> > > netifd: wan (9235): + grep '"searching"'
> > > netifd: wan (9235): + uqmi -s -d /dev/cdc-wdm1 --get-serving-system
> > > netifd: wan (9235): +
> > > registration='{"registration":"not_registered","plmn_mcc":208,"plmn_mnc":20,"plmn_description":"","roaming":true}'
> > > netifd: wan (9235): + '[' -n ]
> > > netifd: wan (9235): + echo 'Starting network wan'
> > >
> > > As the while loop checks only "searching" pattern, uqmi.sh script
> > > quits
> > > searching loop and continues whereas the modem is not registered
> > >
> > > Other issue, after X seconds modem stops searching.
> > > netifd: wan (9213): + uqmi -s -d /dev/cdc-wdm0 --get-serving-system
> > > netifd: wan (9213): + grep '"searching"'
> > > netifd: wan (9213): + '[' -e /dev/cdc-wdm0 ]
> > > netifd: wan (9213): + '[' 3 -lt 0 -o 0 '=' 0 ]
> > > netifd: wan (9213): + let registration_timeout++
> > > netifd: wan (9213): + sleep 1
> > > netifd: wan (9213): + uqmi -s -d /dev/cdc-wdm0 --get-serving-system
> > > netifd: wan (9213): + grep '"searching"'
> > > netifd: wan (9213): + uqmi -s -d /dev/cdc-wdm0 --get-serving-system
> > > netifd: wan (9213): + registration='{"registration":"not_registered"}'
> > > netifd: wan (9213): + '[' -n ]
> > > netifd: wan (9213): + echo 'Starting network wan'
> > > netifd: wan (9213): Starting network wan
> > >
> > > If registration_timeout is not expired, registration can be restarted
> > >
> > > Signed-off-by: Thomas Richard
> > > ---
> > > package/network/utils/uqmi/Makefile| 2 +-
> > > .../utils/uqmi/files/lib/netifd/proto/qmi.sh | 35
> > > --
> > > 2 files changed, 27 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/package/network/utils/uqmi/Makefile
> > > b/package/network/utils/uqmi/Makefile
> > > index 68958a3729..da54ba0f46 100644
> > > --- a/package/network/utils/uqmi/Makefile
> > > +++ b/package/network/utils/uqmi/Makefile
> > > @@ -1,7 +1,7 @@
> > > include $(TOPDIR)/rules.mk
> > >
> > > PKG_NAME:=uqmi
> > > -PKG_RELEASE:=2
> > > +PKG_RELEASE:=3
> > >
> > > PKG_SOURCE_PROTO:=git
> > > PKG_SOURCE_URL=$(PROJECT_GIT)/project/uqmi.git
> > > diff --git
> > > a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
> > > b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
> > > index a6c785eb56..c0134f44dd 100755
> > > --- a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
> > > +++ b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
> > > @@ -209,19 +209,36 @@ proto_qmi_setup() {
> > >
> > > uqmi -s -d "$device" --sync > /dev/null 2>&1
> > >
> > > + uqmi -s -d "$device" --network-register > /dev/null 2>&1
> > > +
> > > echo "Waiting for network registration"
> > > + sleep 1
> > > local registration_timeout=0
> > > - while uqmi -s -d "$device" --get-serving-system | grep
> > > '"searching"' > /dev/null; do
> > > - [ -e "$device" ] || return 1
> > > - if [ "$registration_timeout" -lt "$timeout" -o "$timeout" = "0"
> > > ]; then
> > > - let registration_timeout++
> > > - sleep 1;
> > > + local registration_state=""
> > > + while true; do
> > > + registration_state=$(uqmi -s -d "$device" --get-serving-system
> > > 2>/dev/null | jsonfilter -e "@.registration" 2>/dev/null)
> > > +
> > > + [ "$registration_state" = "registered" ] &&
Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
On 11.05.21 19:51, Rafał Miłecki wrote: On 11.05.2021 19:46, John Crispin wrote: On 11.05.21 19:45, Rafał Miłecki wrote: I'm really tired of dealing with such hacky solutions. Look at netifd, DSA and LuCI as example. We ended up with something that noone fully understands. Jo - our UI guru - couldn't deal with designing a proper UI for that f*cked config syntax. sorry mate, I am not the reason you are having a bad day, so dont vent it out on me. It's just an example of shitty situation we got. Nothing more. I took a good amount of time to provide valuable review for the [PATCH v2] rtl83xx-poe: add package I described problems, missing parts, provided examples how one can solve it. Let's discuss that please. Instead of commenting on one example I provided. lulz, why so aggravated ... its about the code not the person ... possibly I missed some of your feedback, will review tomorrow, keep the spirit mate and just chill a little ... John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
On 11.05.2021 19:46, John Crispin wrote: On 11.05.21 19:45, Rafał Miłecki wrote: I'm really tired of dealing with such hacky solutions. Look at netifd, DSA and LuCI as example. We ended up with something that noone fully understands. Jo - our UI guru - couldn't deal with designing a proper UI for that f*cked config syntax. sorry mate, I am not the reason you are having a bad day, so dont vent it out on me. It's just an example of shitty situation we got. Nothing more. I took a good amount of time to provide valuable review for the [PATCH v2] rtl83xx-poe: add package I described problems, missing parts, provided examples how one can solve it. Let's discuss that please. Instead of commenting on one example I provided. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
On 11.05.21 19:45, Rafał Miłecki wrote: I'm really tired of dealing with such hacky solutions. Look at netifd, DSA and LuCI as example. We ended up with something that noone fully understands. Jo - our UI guru - couldn't deal with designing a proper UI for that f*cked config syntax. sorry mate, I am not the reason you are having a bad day, so dont vent it out on me. John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
On 11.05.2021 19:38, John Crispin wrote: On 11.05.21 19:34, Rafał Miłecki wrote: I'm happy to see C code, but this implementation still doesn't address any of my comments I posted in the Re: [PATCH v2] rtl83xx-poe: add package https://patchwork.ozlabs.org/project/openwrt/patch/20210313165419.10713-1-bj...@mork.no/#2666485 I strongly believe we need a more generic solution. A tiny framework with generic PoE imlementation and then rtl83xx support on top of that. agreed, but for now this makes PoE work for the community. the next step will be to move this into kernel space using the appropriate subsystems, however that will take time and effort. the aim of the patch is to get support functional out of the box for the community and then address the real solution afterwards. This never works. When we commit hacks like this to the repo they stay for years or for ever. Once you commit this we'll see uci defaults for PoE. Then LuCI module. Cleaning that up later will require a lot more planning to avoid breaking existing setups. Developing this as a tiny subsystem really won't take much more time. How much can it be? Two days? I'm really tired of dealing with such hacky solutions. Look at netifd, DSA and LuCI as example. We ended up with something that noone fully understands. Jo - our UI guru - couldn't deal with designing a proper UI for that f*cked config syntax. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
On 11.05.21 19:38, John Crispin wrote: On 11.05.21 19:34, Rafał Miłecki wrote: I'm happy to see C code, but this implementation still doesn't address any of my comments I posted in the Re: [PATCH v2] rtl83xx-poe: add package https://patchwork.ozlabs.org/project/openwrt/patch/20210313165419.10713-1-bj...@mork.no/#2666485 I strongly believe we need a more generic solution. A tiny framework with generic PoE imlementation and then rtl83xx support on top of that. agreed, but for now this makes PoE work for the community. the next step will be to move this into kernel space using the appropriate subsystems, however that will take time and effort. the aim of the patch is to get support functional out of the box for the community and then address the real solution afterwards. John that being said, I have a edgerouter-x(-sfp) on my desk. I already started a PoC patch to support a more generic approach for PoE that is agnostic of wheter the HW support is driven via GPIO or a ttyS attached MCU. but as I said, takes time and effort. for now, the RTL crowd will have PoE and 1-2 months down the line we will have a more generic approach... any other PoE capable HW around that we need to consider in the design phase ? John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
On 11.05.21 19:34, Rafał Miłecki wrote: I'm happy to see C code, but this implementation still doesn't address any of my comments I posted in the Re: [PATCH v2] rtl83xx-poe: add package https://patchwork.ozlabs.org/project/openwrt/patch/20210313165419.10713-1-bj...@mork.no/#2666485 I strongly believe we need a more generic solution. A tiny framework with generic PoE imlementation and then rtl83xx support on top of that. agreed, but for now this makes PoE work for the community. the next step will be to move this into kernel space using the appropriate subsystems, however that will take time and effort. the aim of the patch is to get support functional out of the box for the community and then address the real solution afterwards. John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
On 11.05.21 17:56, Bjørn Mork wrote: Tested-by: Bjørn Mork Running on a ZyXEL GS1900-10HP: thanks for testing. I just found 2 tiny issues that I already fixed locally and added a uci-defaults script s.T. we can setup a sane default uci for the various switches. If there are no further comments, I will merge this in the next couple of days John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
On 11.05.2021 17:22, John Crispin wrote:
This patch adds a C rewrite of the LUA tool previously posted. With this new
daemon we map the DSA port names to the PSE port id. Support for several now
features was added, such as setting the priority and at/af mode. In the next
iteration addition port/mcu states will be exposed, aswell as adding support
for 4 wire mode and fault handling.
A Sample config looks like this:
config global
option budget '65'
config port
option enable '1'
option id '1'
option name 'lan1'
option poe_plus '1'
option priority '2'
ubus call poe info
{
"firmware": "v48.2",
"mcu": "Nuvoton M05xx LAN Microcontroller",
"budget": 65.00,
"consumption": 2.40,
"ports": {
"lan1": {
"priority": 2,
"mode": "PoE",
"status": "Delivering power",
"consumption": 2.40
}
}
}
I'm happy to see C code, but this implementation still doesn't address
any of my comments I posted in the
Re: [PATCH v2] rtl83xx-poe: add package
https://patchwork.ozlabs.org/project/openwrt/patch/20210313165419.10713-1-bj...@mork.no/#2666485
I strongly believe we need a more generic solution. A tiny framework
with generic PoE imlementation and then rtl83xx support on top of that.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH netifd] config: support bridge designed UCI section
From: Rafał Miłecki
Network layer 2 devices should have their own UCI section types. They
differ so much that each device type requires a custom handling anyway.
Currently there is "type" option used to distinguish them while UCI
supports different section types right for that purpose. This change
will result in cleaner UCI and UI code.
Example UCI section:
config bridge
option name 'foo'
list ports 'lan1'
list ports 'lan2'
While introducing this new bridge section a new option was added for
storing bridge port names: "ports". It's clearer than previously used
"ifname". A simple validation code is present to make sure "ports" is
used and contains a list of ports.
Signed-off-by: Rafał Miłecki
---
bridge.c | 14 +-
config.c | 52
2 files changed, 61 insertions(+), 5 deletions(-)
diff --git a/bridge.c b/bridge.c
index 099dfe4..ce49a74 100644
--- a/bridge.c
+++ b/bridge.c
@@ -23,7 +23,8 @@
#include "system.h"
enum {
- BRIDGE_ATTR_IFNAME,
+ BRIDGE_ATTR_PORTS,
+ BRIDGE_ATTR_IFNAME, /* Deprecated */
BRIDGE_ATTR_STP,
BRIDGE_ATTR_FORWARD_DELAY,
BRIDGE_ATTR_PRIORITY,
@@ -44,6 +45,7 @@ enum {
};
static const struct blobmsg_policy bridge_attrs[__BRIDGE_ATTR_MAX] = {
+ [BRIDGE_ATTR_PORTS] = { "ports", BLOBMSG_TYPE_ARRAY },
[BRIDGE_ATTR_IFNAME] = { "ifname", BLOBMSG_TYPE_ARRAY },
[BRIDGE_ATTR_STP] = { "stp", BLOBMSG_TYPE_BOOL },
[BRIDGE_ATTR_FORWARD_DELAY] = { "forward_delay", BLOBMSG_TYPE_INT32 },
@@ -104,7 +106,7 @@ struct bridge_state {
struct blob_attr *config_data;
struct bridge_config config;
- struct blob_attr *ifnames;
+ struct blob_attr *ports;
bool active;
bool force_active;
bool has_vlans;
@@ -853,8 +855,8 @@ bridge_config_init(struct device *dev)
bst->n_failed = 0;
vlist_update(>members);
- if (bst->ifnames) {
- blobmsg_for_each_attr(cur, bst->ifnames, rem) {
+ if (bst->ports) {
+ blobmsg_for_each_attr(cur, bst->ports, rem) {
bridge_add_member(bst, blobmsg_data(cur));
}
}
@@ -970,7 +972,9 @@ bridge_reload(struct device *dev, struct blob_attr *attr)
if (tb_dev[DEV_ATTR_MACADDR])
bst->primary_port = NULL;
- bst->ifnames = tb_br[BRIDGE_ATTR_IFNAME];
+ bst->ports = tb_br[BRIDGE_ATTR_PORTS];
+ if (!bst->ports)
+ bst->ports = tb_br[BRIDGE_ATTR_IFNAME];
device_init_settings(dev, tb_dev);
bridge_apply_settings(bst, tb_br);
diff --git a/config.c b/config.c
index fa7cbe4..4cc5a61 100644
--- a/config.c
+++ b/config.c
@@ -223,6 +223,57 @@ config_parse_rule(struct uci_section *s, bool v6)
iprule_add(blob_data(b.head), v6);
}
+/**
+ * config_init_bridges - create bridges for new syntax UCI sections
+ *
+ * The new syntax uses dedicated UCI "bridge" sections for describing bridges.
+ * They use "ports" list instead of "ifname" for specifying bridge ports.
+ */
+static void config_init_bridges()
+{
+ struct uci_element *e;
+
+ uci_foreach_element(_network->sections, e) {
+ struct uci_section *s = uci_to_section(e);
+ struct device_type *devtype;
+ struct uci_option *o;
+ struct device *dev;
+ const char *name;
+
+ if (strcmp(s->type, "bridge"))
+ continue;
+
+ name = uci_lookup_option_string(uci_ctx, s, "name");
+ if (!name)
+ continue;
+
+ devtype = device_type_get("bridge");
+ if (!devtype)
+ continue;
+
+ config_fixup_bridge_vlan_filtering(s, name);
+ o = uci_lookup_option(uci_ctx, s, "ifname");
+ if (o) {
+ netifd_log_message(L_WARNING, "Unsupported \"ifname\"
bridge option\n");
+ continue;
+ }
+ o = uci_lookup_option(uci_ctx, s, "ports");
+ if (o && o->type != UCI_TYPE_LIST) {
+ netifd_log_message(L_WARNING, "Invalid \"ports\" option
format\n");
+ continue;
+ }
+
+ blob_buf_init(, 0);
+ uci_to_blob(, s, devtype->config_params);
+
+ dev = device_create(name, devtype, b.head);
+ if (!dev)
+ continue;
+
+ dev->default_config = false;
+ }
+}
+
static void
config_init_devices(bool bridge)
{
@@ -737,6 +788,7 @@ config_init_all(void)
device_lock();
device_reset_config();
+ config_init_bridges();
config_init_devices(true);
config_init_vlans();
config_init_devices(false);
--
2.26.2
___
openwrt-devel mailing list
Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
John Crispin writes:
> This patch adds a C rewrite of the LUA tool previously posted. With this new
> daemon we map the DSA port names to the PSE port id. Support for several now
> features was added, such as setting the priority and at/af mode. In the next
> iteration addition port/mcu states will be exposed, aswell as adding support
> for 4 wire mode and fault handling.
>
> A Sample config looks like this:
>
> config global
> option budget '65'
>
> config port
> option enable '1'
> option id '1'
> option name 'lan1'
> option poe_plus '1'
> option priority '2'
>
> ubus call poe info
> {
> "firmware": "v48.2",
> "mcu": "Nuvoton M05xx LAN Microcontroller",
> "budget": 65.00,
> "consumption": 2.40,
> "ports": {
> "lan1": {
> "priority": 2,
> "mode": "PoE",
> "status": "Delivering power",
> "consumption": 2.40
> }
> }
> }
Tested-by: Bjørn Mork
Running on a ZyXEL GS1900-10HP:
root@gs1900-10hp:~# ubus call poe info
{
"firmware": "v22.4",
"mcu": "ST Micro ST32F100 Microcontroller",
"budget": 77.00,
"consumption": 7.70,
"ports": {
"lan1": {
"priority": 0,
"mode": "PoE+",
"status": "Searching"
},
"lan2": {
"priority": 0,
"mode": "PoE+",
"status": "Searching"
},
"lan3": {
"priority": 0,
"mode": "PoE+",
"status": "Searching"
},
"lan4": {
"priority": 0,
"mode": "PoE+",
"status": "Searching"
},
"lan5": {
"priority": 0,
"mode": "PoE+",
"status": "Searching"
},
"lan6": {
"priority": 0,
"mode": "PoE+",
"status": "Searching"
},
"lan7": {
"priority": 0,
"mode": "PoE+",
"status": "Delivering power",
"consumption": 3.90
},
"lan8": {
"priority": 0,
"mode": "PoE+",
"status": "Delivering power",
"consumption": 3.80
}
}
}
Really nice stuff!
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] realtek-poe: add support for PoE on Realtek switches
This patch adds a C rewrite of the LUA tool previously posted. With this new
daemon we map the DSA port names to the PSE port id. Support for several now
features was added, such as setting the priority and at/af mode. In the next
iteration addition port/mcu states will be exposed, aswell as adding support
for 4 wire mode and fault handling.
A Sample config looks like this:
config global
option budget '65'
config port
option enable '1'
option id '1'
option name 'lan1'
option poe_plus '1'
option priority '2'
ubus call poe info
{
"firmware": "v48.2",
"mcu": "Nuvoton M05xx LAN Microcontroller",
"budget": 65.00,
"consumption": 2.40,
"ports": {
"lan1": {
"priority": 2,
"mode": "PoE",
"status": "Delivering power",
"consumption": 2.40
}
}
}
Signed-off-by: John Crispin
---
package/network/config/realtek-poe/Makefile | 25 +
.../config/realtek-poe/files/etc/config/poe | 9 +
.../config/realtek-poe/files/etc/init.d/poe | 20 +
.../config/realtek-poe/src/CMakeLists.txt | 28 +
package/network/config/realtek-poe/src/main.c | 844 ++
5 files changed, 926 insertions(+)
create mode 100644 package/network/config/realtek-poe/Makefile
create mode 100644 package/network/config/realtek-poe/files/etc/config/poe
create mode 100755 package/network/config/realtek-poe/files/etc/init.d/poe
create mode 100644 package/network/config/realtek-poe/src/CMakeLists.txt
create mode 100644 package/network/config/realtek-poe/src/main.c
diff --git a/package/network/config/realtek-poe/Makefile
b/package/network/config/realtek-poe/Makefile
new file mode 100644
index 00..4dba054bb2
--- /dev/null
+++ b/package/network/config/realtek-poe/Makefile
@@ -0,0 +1,25 @@
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=realtek-poe
+PKG_RELEASE:=1
+
+PKG_LICENSE:=GPL-2.0
+PKG_MAINTAINER:=John Crispin
+
+include $(INCLUDE_DIR)/package.mk
+include $(INCLUDE_DIR)/cmake.mk
+
+define Package/realtek-poe
+ SECTION:=net
+ CATEGORY:=Network
+ TITLE:=Realtek PoE Switch Port daemon
+ DEPENDS:=@TARGET_realtek +libubox +libubus +libuci
+endef
+
+define Package/realtek-poe/install
+ $(INSTALL_DIR) $(1)/usr/bin
+ $(INSTALL_BIN) $(PKG_BUILD_DIR)/realtek-poe $(1)/usr/bin/
+ $(CP) ./files/* $(1)
+endef
+
+$(eval $(call BuildPackage,realtek-poe))
diff --git a/package/network/config/realtek-poe/files/etc/config/poe
b/package/network/config/realtek-poe/files/etc/config/poe
new file mode 100644
index 00..6ef9d40ad2
--- /dev/null
+++ b/package/network/config/realtek-poe/files/etc/config/poe
@@ -0,0 +1,9 @@
+config global
+ option budget '65'
+
+config port
+ option enable '1'
+ option id '1'
+ option name 'lan1'
+ option poe_plus '1'
+ option priority '2'
diff --git a/package/network/config/realtek-poe/files/etc/init.d/poe
b/package/network/config/realtek-poe/files/etc/init.d/poe
new file mode 100755
index 00..66f77d6ef9
--- /dev/null
+++ b/package/network/config/realtek-poe/files/etc/init.d/poe
@@ -0,0 +1,20 @@
+#!/bin/sh /etc/rc.common
+
+START=80
+USE_PROCD=1
+PROG=/usr/bin/realtek-poe
+
+reload_service() {
+ ubus call poe reload
+}
+
+service_triggers() {
+procd_add_config_trigger "config.change" "poe" ubus call poe reload
+}
+
+start_service() {
+ procd_open_instance
+ procd_set_param command "$PROG"
+ procd_set_param respawn
+ procd_close_instance
+}
diff --git a/package/network/config/realtek-poe/src/CMakeLists.txt
b/package/network/config/realtek-poe/src/CMakeLists.txt
new file mode 100644
index 00..4eb81f4577
--- /dev/null
+++ b/package/network/config/realtek-poe/src/CMakeLists.txt
@@ -0,0 +1,28 @@
+cmake_minimum_required(VERSION 2.6)
+
+PROJECT(realtek-poe C)
+ADD_DEFINITIONS(-Os -ggdb -Wextra -Wall -Werror --std=gnu99
-Wmissing-declarations -Wno-unused-parameter)
+
+SET(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS "")
+
+SET(SOURCES main.c)
+
+IF(DEBUG)
+ ADD_DEFINITIONS(-DDEBUG -g3)
+ENDIF()
+
+FIND_LIBRARY(ubus NAMES ubus)
+FIND_LIBRARY(uci NAMES uci)
+FIND_LIBRARY(ubox NAMES ubox)
+FIND_PATH(uci_include_dir NAMES uci.h)
+FIND_PATH(ubus_include_dir NAMES libubus.h)
+FIND_PATH(ubox_include_dir NAMES libubox/usock.h)
+INCLUDE_DIRECTORIES(${ubox_include_dir} ${ubus_include_dir} ${uci_include_dir})
+
+ADD_EXECUTABLE(realtek-poe ${SOURCES})
+
+TARGET_LINK_LIBRARIES(realtek-poe ${ubox} ${ubus} ${uci})
+
+INSTALL(TARGETS realtek-poe
+ RUNTIME DESTINATION sbin
+)
diff --git a/package/network/config/realtek-poe/src/main.c
b/package/network/config/realtek-poe/src/main.c
new file mode 100644
index 00..034ac27432
--- /dev/null
+++ b/package/network/config/realtek-poe/src/main.c
@@ -0,0 +1,844 @@
+/*
[FIX proposal] Build error of host mklibs pkg of openwrt-19.07 branch on Fedora 34
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 ---
Hi all,
The g++ version 11.1.1 of Fedora 34 defaults to g++17 and making the
build of host package mklibs fail. See build error below.
Obviously, least intrusive fix is to set the C++ standard to g++14 or
lower. However, on master the problem is not there due to an upgrade of
mklibs to version 0.1.44 (among some other changes). This is done in
commit 9437012b9ee4dc550e42665b71902cf885169100.
Guess we best cherry-pick that commit from master to upgrade mklibs to
0.1.44 as well. This commit was cleanly applied on top of openwrt-19.07
and the build went fine afterwards.
(build was for TP-Link Archer C7 v5 default config with ccache enabled
if that matters)
Regards,
Bas.
make[3]: Entering directory '/home/bas/Workspace/openwrt-19.07/tools/mklibs'
CFLAGS="-O2 -I/home/bas/Workspace/openwrt-19.07/staging_dir/host/include
-I/home/bas/Workspace/openwrt-19.07/tools/mklibs/include"
CPPFLAGS="-I/home/bas/Workspace/openwrt-19.07/staging_dir/host/include "
CXXFLAGS=""
LDFLAGS="-L/home/bas/Workspace/openwrt-19.07/staging_dir/host/lib " make
-j1 -C /home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35
make[4]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35'
make all-recursive
make[5]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35'
Making all in lib
make[6]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib'
Making all in mklibs
make[7]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs'
Making all in utils
make[8]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs/utils'
make[8]: Nothing to be done for 'all'.
make[8]: Leaving directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs/utils'
make[8]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs'
make[8]: Nothing to be done for 'all-am'.
make[8]: Leaving directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs'
make[7]: Leaving directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs'
make[7]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib'
make[7]: Nothing to be done for 'all-am'.
make[7]: Leaving directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib'
make[6]: Leaving directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib'
Making all in src
make[6]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/src'
Making all in mklibs-readelf
make[7]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/src/mklibs-readelf'
ccache g++ -DHAVE_CONFIG_H -I. -I../..
-I/home/bas/Workspace/openwrt-19.07/staging_dir/host/include -g -O2
-MT elf.o -MD -MP -MF .deps/elf.Tpo -c -o elf.o elf.cpp
In file included from elf_data.hpp:24,
from elf.cpp:21:
elf.hpp:52:56: error: ISO C++17 does not allow dynamic exception
specifications
52 | const section _section(unsigned int i) const throw
(std::out_of_range) { return *sections.at(i); };
|^
elf.hpp:62:47: error: ISO C++17 does not allow dynamic exception
specifications
62 | static file *open(const char *filename) throw
(std::bad_alloc, std::runtime_error);
| ^
elf.hpp:65:38: error: ISO C++17 does not allow dynamic exception
specifications
65 | file(uint8_t *mem, size_t len) throw (std::bad_alloc) :
mem(mem), len(len) { }
| ^
elf.hpp:68:52: error: ISO C++17 does not allow dynamic exception
specifications
68 | static file *open_class(uint8_t *, size_t) throw
(std::bad_alloc, std::runtime_error);
|^
elf.hpp:131:55: error: ISO C++17 does not allow dynamic exception
specifications
131 | std::string get_string(uint32_t offset) const throw
(std::bad_alloc)
| ^
elf.hpp:266:39: error: ISO C++17 does not allow dynamic exception
specifications
266 | std::string get_version() const throw (std::bad_alloc);
| ^
elf.hpp:267:44: error: ISO C++17 does not allow dynamic exception
specifications
267 | std::string get_version_file() const throw (std::bad_alloc);
|^
elf.hpp:269:44: error:
[FIX proposal] Build error of host mklibs pkg of openwrt-19.07 branch on Fedora 34
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 ---
(resent as previous attempt didn't seem to get through)
Hi all,
The g++ version 11.1.1 of Fedora 34 defaults to g++17 and making the
build of host package mklibs fail. See build error below.
Obviously, least intrusive fix is to set the C++ standard to g++14 or
lower. However, on master the problem is not there due to an upgrade of
mklibs to version 0.1.44 (among some other changes). This is done in
commit 9437012b9ee4dc550e42665b71902cf885169100.
Guess we best cherry-pick that commit from master to upgrade mklibs to
0.1.44 as well. This commit was cleanly applied on top of openwrt-19.07
and the build went fine afterwards.
(build was for TP-Link Archer C7 v5 default config with ccache enabled
if that matters)
Regards,
Bas.
make[3]: Entering directory
'/home/bas/Workspace/openwrt-19.07/tools/mklibs'
CFLAGS="-O2 -I/home/bas/Workspace/openwrt-19.07/staging_dir/host/include
-I/home/bas/Workspace/openwrt-19.07/tools/mklibs/include"
CPPFLAGS="-I/home/bas/Workspace/openwrt-19.07/staging_dir/host/include "
CXXFLAGS=""
LDFLAGS="-L/home/bas/Workspace/openwrt-19.07/staging_dir/host/lib " make
-j1 -C /home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35
make[4]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35'
make all-recursive
make[5]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35'
Making all in lib
make[6]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib'
Making all in mklibs
make[7]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs'
Making all in utils
make[8]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs/utils'
make[8]: Nothing to be done for 'all'.
make[8]: Leaving directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs/utils'
make[8]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs'
make[8]: Nothing to be done for 'all-am'.
make[8]: Leaving directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs'
make[7]: Leaving directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs'
make[7]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib'
make[7]: Nothing to be done for 'all-am'.
make[7]: Leaving directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib'
make[6]: Leaving directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib'
Making all in src
make[6]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/src'
Making all in mklibs-readelf
make[7]: Entering directory
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/src/mklibs-readelf'
ccache g++ -DHAVE_CONFIG_H -I. -I../..
-I/home/bas/Workspace/openwrt-19.07/staging_dir/host/include -g -O2
-MT elf.o -MD -MP -MF .deps/elf.Tpo -c -o elf.o elf.cpp
In file included from elf_data.hpp:24,
from elf.cpp:21:
elf.hpp:52:56: error: ISO C++17 does not allow dynamic exception
specifications
52 | const section _section(unsigned int i) const throw
(std::out_of_range) { return *sections.at(i); };
|^
elf.hpp:62:47: error: ISO C++17 does not allow dynamic exception
specifications
62 | static file *open(const char *filename) throw
(std::bad_alloc, std::runtime_error);
| ^
elf.hpp:65:38: error: ISO C++17 does not allow dynamic exception
specifications
65 | file(uint8_t *mem, size_t len) throw (std::bad_alloc) :
mem(mem), len(len) { }
| ^
elf.hpp:68:52: error: ISO C++17 does not allow dynamic exception
specifications
68 | static file *open_class(uint8_t *, size_t) throw
(std::bad_alloc, std::runtime_error);
|^
elf.hpp:131:55: error: ISO C++17 does not allow dynamic exception
specifications
131 | std::string get_string(uint32_t offset) const throw
(std::bad_alloc)
| ^
elf.hpp:266:39: error: ISO C++17 does not allow dynamic exception
specifications
266 | std::string get_version() const throw (std::bad_alloc);
| ^
elf.hpp:267:44: error: ISO C++17 does not allow dynamic exception
specifications
267 | std::string get_version_file() const throw
(std::bad_alloc);
|
