On 21.06.2021 16:57, Rafał Miłecki wrote:
On 19.06.2021 20:36, Hauke Mehrtens wrote:
On a DSA switch the ports have an upper device, the CPU device, e.g.
eth0. This device has to be in up state to bring up the lower devices
like lan1.
Parse the link device from "ip link show" and bri
On 19.06.2021 20:36, Hauke Mehrtens wrote:
On a DSA switch the ports have an upper device, the CPU device, e.g.
eth0. This device has to be in up state to bring up the lower devices
like lan1.
Parse the link device from "ip link show" and bring it into up stated
before bringing up the actual int
quot;ports" array in board.json network for
bridges")
Signed-off-by: Hauke Mehrtens
This fixes failsafe on bcm53xx (swconfig target). Thanks a lot.
Reviewed-by: Rafał Miłecki
[see 1 inline comment below]
.../files/lib/preinit/10_indicate_preinit | 18 --
From: Rafał Miłecki
Include mtu, igmp_snooping and igmp_v3 while migrating.
Signed-off-by: Rafał Miłecki
---
.../luci-static/resources/view/network/interfaces.js | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git
a/modules/luci-mod-network/htdocs/luci-static
From: Rafał Miłecki
This helps managing LAN ports.
Ref:
https://forum.openwrt.org/t/openwrt-21-02-0-second-release-candidate/98026/121
Fixes: 95b0c07a618f ("ipq40xx: add support for FritzBox 7530")
Cc: David Bauer
Signed-off-by: Rafał Miłecki
---
target/linux/ipq40xx/base-files/e
On 01.06.2021 09:21, Embedded Devel wrote:
something is odd with Linksys E8450 on master as of last night
eth0 has no ip address, wan has a dhcp address as the gateway, no client behind it
connected to the lan can ping 8.8.8.8, the router itself can ping 8.8.8.8 , it worked
fine before the
On 31.05.2021 23:58, Hauke Mehrtens wrote:
New network configuration syntax
There have been several changes to the network configuration syntax in
/etc/config/network:
To provide some context: that change resulted in cleaner configs and
manageable UI interface (LuCI) support.
Big thanks to J
On 28.05.2021 20:18, Evgeny K wrote:
3. Drop section name
It's not required by netifd or LuCI & it's not needed by this script
as $device contains a single device name now.
It could be convenient to have it, though. In the former scheme of
things, if one would like to know the interface
From: Rafał Miłecki
Link: https://forum.openwrt.org/t/network-migration-21-02-0-rc2/97934
Signed-off-by: Rafał Miłecki
---
.../htdocs/luci-static/resources/view/network/interfaces.js | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
a/modules/luci-mod-network/htdocs/luci
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
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-74be30
From: Rafał Miłecki
Problem with handling all migrations in 1 step is that uci.sections()
doesn't include changes queued using uci.callAdd() and uci.callSet().
That could result in unexpected behaviour and generating invalid
configs.
For the sake of simplicity and reliability use 2
From: Rafał Miłecki
Those are L2 options that are not part of interfaces (L3), should not be
set there and don't work. Setting MAC and MTU should be done at device
layer (config device) and is supported for basic types already.
Signed-off-by: Rafał Miłecki
---
.../htdocs/luci-static/reso
From: Rafał Miłecki
1. Move code above interface generation
It results in more logical order. Device gets its config section
above interface section.
2. Drop the loop
We have separated code handling bridges now so $device should be
guaranteed to contain a single device name.
3. Drop
On 28.05.2021 03:36, Mike Bernardo wrote:
I have the below working config, is there a way to get the name to be 'vlan20',
instead of 'bonding-lan.20' ? I have tried a bunch of stuff and so far nothing
has worked.
I don't think you can change Linux interface name. I believe this is how
Linux h
From: Rafał Miłecki
Signed-off-by: Rafał Miłecki
---
.../htdocs/luci-static/resources/tools/network.js | 2 ++
1 file changed, 2 insertions(+)
diff --git
a/modules/luci-mod-network/htdocs/luci-static/resources/tools/network.js
b/modules/luci-mod-network/htdocs/luci-static
From: Rafał Miłecki
Interfaces need to be assigned to devices. For that purpose a "device"
option should be more accurate than "ifname" one.
For backward compatibility old option remains supported too.
Config example:
config device
option name 'br-lan
I'd like to abort uclient connection after getting HTTP error code in a
response header.
Example:
static void foo_header_done_cb(struct uclient *cl)
{
if (cl->status_code != 200) {
uclient_disconnect(cl);
uclient_free(cl);
}
}
The problem is that u
On 23.05.2021 13:59, Russell Senior wrote:
+ð0 {
+ status = "okay";
+
+ /* default for ar934x, except for 1000M and 10M */
+ pll-data = <0x0200 0x0101 0x1313>;
+
+ mtd-mac-address = <&art 0x0>;
I'd love to have new DTS use upstream "nvmem-cells" property for
From: Rafał Miłecki
netifd has been recently patched to use "device" option instead of
"ifname" as more clear & accurate.
Signed-off-by: Rafał Miłecki
---
.../htdocs/luci-static/resources/network.js | 100 +-
.../resources/view/network/interfaces.
From: Rafał Miłecki
Replace "ifname" with "device" as netifd has been recently patches to
used the later one. It's more clear and accurate.
Signed-off-by: Rafał Miłecki
---
This can be applied after updating netfid to include:
[PATCH V2 netifd] interface: rename &quo
On 23.05.2021 23:06, Rafał Miłecki wrote:
I'm looking at existing code, at the commit be09c5a3cd65 ("base-files:
add board.d support for bridge device") and I have some problems
understanding those bridges.
If you can, please kindly answer me two questions:
Please also
On 23.05.2021 13:30, INAGAKI Hiroshi wrote:
After the commit 43fc720657c6e3b30c6ed89d7227ee6e646c158b
("base-files: generate "device UCI type section for bridge"), the wrong
network configuration is generated for the devices that already have the
bridge device section for VLAN, such as the device
On 23.05.2021 13:30, INAGAKI Hiroshi wrote:
After the commit 43fc720657c6e3b30c6ed89d7227ee6e646c158b
("base-files: generate "device UCI type section for bridge"), the wrong
network configuration is generated for the devices that already have the
bridge device section for VLAN, such as the device
From: Rafał Miłecki
Interfaces need to be assigned to devices. For that purpose a "device"
option should be more accurate than "ifname" one.
For backward compatibility add a temporary config translation.
Config example:
config device
option name 'br-lan
From: Rafał Miłecki
Now that every bridge is guaranteed to be defined as a standalone device
there is no need for aliases there anymore.
Signed-off-by: Rafał Miłecki
---
.../htdocs/luci-static/resources/view/network/interfaces.js | 5 ++---
1 file changed, 2 insertions(+), 3 deletions
From: Rafał Miłecki
LuCI supports only the newer method of specifying bridge ports using the
"ports" option. Offer users migration so they can configure their
network.
Example:
1. Before
config device
option name 'br-lan'
option type 'bridge&#
From: Rafał Miłecki
Old "interface" sections for bridges were mixing layer 2 and layer 3.
That syntax got deprecated and UCI section "device" is used for bridge
configuration now.
Backward compatibility may be dropped from netifd soon now so migrate
old configs using
On 17.05.2021 14:10, Rafał Miłecki wrote:
From: Rafał Miłecki
netifd has been recently patched to use more accurate "ports" option
instead of "ifname"
Signed-off-by: Rafał Miłecki
---
.../htdocs/luci-static/resources/tools/network.js | 4 ++--
1 file c
On 17.05.2021 17:32, Paul Oranje wrote:
Op 17 mei 2021, om 16:49 heeft Rafał Miłecki het volgende
geschreven:
From: Rafał Miłecki
Interfaces need to be assigned to devices. For that purpose a "device"
option should be more accurate than "ifname" one.
For backward
From: Rafał Miłecki
Interfaces need to be assigned to devices. For that purpose a "device"
option should be more accurate than "ifname" one.
For backward compatibility add a temporary config translation.
Config example:
config device
option name 'lan
From: Rafał Miłecki
UCI "interface" L3 sections use "ifname" option for pointing L2 devices.
A more accurate option would be "device" but for now adjust UI at least
to make configuration easier for LuCI users.
Signed-off-by: Rafał Miłecki
---
.../htdocs/luci
From: Rafał Miłecki
netifd has been recently patched to use more accurate "ports" option
instead of "ifname"
Signed-off-by: Rafał Miłecki
---
.../htdocs/luci-static/resources/tools/network.js | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
From: Rafał Miłecki
The old way of defining bridge (L2) as part of interface (L3) is
deprecated. All such configs should be migrated to define bridge as L3
UCI section type "device".
Signed-off-by: Rafał Miłecki
---
.../luci-static/resources/tools/network.j
From: Rafał Miłecki
The old way of defining bridge (L2) as part of interface (L3) is
deprecated. Don't support *adding* interfaces like that.
Support for *editing* legacy bridges is kept for now for compatibility
with existing legacy setups.
Signed-off-by: Rafał Miłecki
---
.../reso
On 16.05.2021 12:10, Paul Oranje (BB) wrote:
I like this setup. Just some questions and a tiny nit pick.
Paul
Op 15 mei 2021, om 23:11 heeft Rafał Miłecki het volgende
geschreven:
From: Rafał Miłecki
Old "interface" sections for bridges were mixing layer 2 and layer 3.
Migrate t
On 15.05.2021 22:39, Perry wrote:
On 5/15/21 7:18 PM, Rafał Miłecki wrote:
On 15.05.2021 11:09, Paul Oranje wrote:
Op 14 mei 2021, om 15:27 heeft Rafał Miłecki het
volgende geschreven:
From: Rafał Miłecki
Bridge aggregates multiple ports so use a more accurate name ("ports").
From: Rafał Miłecki
Old "interface" sections for bridges were mixing layer 2 and layer 3.
Migrate them to the new styles that has:
1. "device" UCI section for L2 bridge
2. "interface" UCI section for L3 interface
Signed-off-by: Rafał Miłecki
---
.../files/etc/
From: Rafał Miłecki
This switches from the old way of defining bridges in an "interface" UCI
section type (that should be used for layer 3 only). From now a defualt
board switch will have its own "device" UCI section type. It's a new &
preferred way of defining
On 15.05.2021 11:09, Paul Oranje wrote:
Op 14 mei 2021, om 15:27 heeft Rafał Miłecki het volgende
geschreven:
From: Rafał Miłecki
Bridge aggregates multiple ports so use a more accurate name ("ports").
Confusing that a logical network "interface" references somet
From: Rafał Miłecki
Bridge aggregates multiple ports so use a more accurate name ("ports").
For backward compatibility add a temporary config translation.
Config example:
config interface 'lan'
option type 'bridge'
list ports 'lan1'
From: Rafał Miłecki
Bridge aggregates multiple ports so use a more accurate name ("ports")
and format (array) for storing them in board.json.
Example:
"network": {
"lan": {
"ports": [
On 13.05.2021 17:47, Felix Fietkau wrote:
On 2021-05-13 15:58, Rafał Miłecki wrote:
Current /etc/config/network design and netifd implementation are quite a
bit messy:
1. There is no clear layer 2 vs. layer 3 distinction
I think aside from a few legacy compatibility hacks (e.g. the infamous
Current /etc/config/network design and netifd implementation are quite a
bit messy:
1. There is no clear layer 2 vs. layer 3 distinction
2. UCI sections are inconsistent
3. For some setups there are few ways of defining them
4. A lot of netifd states are implicit (magic behaviour)
5. It's really h
From: Rafał Miłecki
This is a tiny app that reads list of PoE devices and initializes them
using built-in drivers. PoE status can be read using ubus.
Signed-off-by: Rafał Miłecki
---
This is a *** DRAFT *** for how we could handle PoE devices in OpenWrt.
Please feel free to comment if this
On 11.05.2021 19:54, John Crispin wrote:
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
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
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/ope
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/m
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 pur
way to support one particular device rather than
a proper solution for PoE capable devices. I really think we should
design a proper PoE layer instead of accepting this hack.
I'm sorry but I'm really against commiting this as it is. It supports
rtl83xx without any standarized way. It adds n
On 2021-04-13 08:39, Rafał Miłecki wrote:
On 13.04.2021 00:46, Sven Roederer wrote:
since some days my master builds failing for ath79-generic. I was able
to
narrow it to running "mkmylofw for compex_wpj344-16m".
The tool runs till the drive is full, currently my "compex_wpj34
From: Rafał Miłecki
CRYPTO_DEV_CCP depends on X86 or ARM64
CRYPTO_DEV_CCP_DD depends on CPU_SUP_AMD or ARM64
Compiling this driver makes sense for x86 mainly. If one day support for
ARM64 board with AMD Secure Processor gets added this package may be
updated.
Trying to build this package on
On 2021-04-13 12:02, Felix Fietkau wrote:
On 2021-04-13 11:46, Rafał Miłecki wrote:
From: Rafał Miłecki
CONFIG_CRYPTO_DEV_SP_CCP depends on DMA_ENGINE which depends on
DMADEVICES=y which bcm4908 doesn't need and doesn't use at this point.
Trying to build this package on bcm4908 w
From: Rafał Miłecki
CONFIG_CRYPTO_DEV_SP_CCP depends on DMA_ENGINE which depends on
DMADEVICES=y which bcm4908 doesn't need and doesn't use at this point.
Trying to build this package on bcm4908 was causing:
ERROR: module
'build_dir/target-aarch64_cortex-a53_musl/linux-bcm490
On 13.04.2021 00:46, Sven Roederer wrote:
since some days my master builds failing for ath79-generic. I was able to
narrow it to running "mkmylofw for compex_wpj344-16m".
The tool runs till the drive is full, currently my "compex_wpj344-16m-
squashfs-cpximg-6a08.bin.new" is 161GB and growing ...
From: Rafał Miłecki
Save path is a directory where config change (delta) files are stored.
Having a custom individual save dir can be used to prevent two (or more)
"uci" cli callers (e.g. bash scripts) from commiting each other changes.
In the following exam
From: Rafał Miłecki
Add "-i" option for reading & displaying firmware info. First it lists
in-firmware partitions ("fwup-ptn"). Then it checks for human
understandable partitions and prints data found in each of them.
This new feature is meant for development & de
From: Rafał Miłecki
1. This tool is also required on target devices (for flashing purposes)
so make it a package
2. Originally this firmware format was used by bcm63xx so adjust name of
this tool
Signed-off-by: Rafał Miłecki
---
package/utils/bcm63xximg/Makefile | 52
On 24.03.2021 19:10, Adrian Schmutzler wrote:
The usual nitpicks below ...
Thanks for review!
+ [ "$magic" = "GT-AC5300" ] && {
+ echo "asus"
+ return
+ }
+
+ echo "unknown"
+}
One could modify this towards a case with default "unknown" (and dr
From: Rafał Miłecki
It isn't UBI aware yet - that remains to be implemented.
Signed-off-by: Rafał Miłecki
---
target/linux/bcm4908/Makefile | 4 +-
.../base-files/lib/upgrade/platform.sh| 114 ++
2 files changed, 117 insertions(+), 1 del
From: Rafał Miłecki
On BCM4908 it's required to rename cferam.000 file in firmware image
before flashing it.
Signed-off-by: Rafał Miłecki
---
package/utils/bcm63xx-bootfs/Makefile | 34 ++
package/utils/bcm63xx-bootfs/src/Makefile | 7 +
.../utils/bcm63xx-bootfs/src/bc
We're planning a 21.xx release and for a lot of our end users LuCI is
an important part of OpenWrt.
I'd like to ask: what's the current state of LuCI?
One thing that probably requires some extra focus is DSA. Are there
any remaining issues regarding it?
I'd be also nice to get some extra LuCI tes
From: Rafał Miłecki
Asus looks for an extra data at the end of BCM4908 image, right before
the BCM4908 tail. It needs to be properly filled to make Asus accept
firmware image.
This tool constructs such a tail, writes it and updates CRC32 in BCM4908
tail accordingly.
Signed-off-by: Rafał
On 21.05.2017 22:22, Rafał Miłecki wrote:
On 14 March 2017 at 07:37, Rafał Miłecki wrote:
My current DTS file contains following entry:
bootargs = "console=ttyS0,115200"
and it works in a following way:
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2],
On 20.01.2021 16:44, Bjørn Mork wrote:
Rafał Miłecki writes:
Did you check that binding with the dt_binding_check?
Something like:
make dt_binding_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/mtd/partitions/openwrt,uimage.yaml
(you may need arch too, e.g. ARCH=arm64)
Yes, I
On 20.01.2021 16:48, Bjørn Mork wrote:
Rafał Miłecki writes:
On 20.01.2021 15:35, Bjørn Mork wrote:
diff --git a/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c
b/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c
index 58c40e9ec70b..32c027d3e979 100644
From: Rafał Miłecki
It's required for BCM4908. It cannot use "bcm-wfi-fw" parser because
that one requires *two* JFFS2 partitions which is untested / unsupported
on the BCM4908 architecture. With a single JFFS2 partition "bcm-wfi-fw"
parser will:
1. Fail to find "vm
On 20.01.2021 15:35, Bjørn Mork wrote:
This series replace a number of device specific variants of the
"denx,uimage" partition splitter with a unified parser, using optional
device-tree properties to describe deviations from the standard U-Boot
Image.
This is now tested on a number of devices.
On 20.01.2021 15:35, Bjørn Mork wrote:
@@ -283,59 +264,10 @@ static struct mtd_part_parser uimage_generic_parser = {
.owner = THIS_MODULE,
.name = "uimage-fw",
.of_match_table = mtdsplit_uimage_of_match_table,
- .parse_fn = mtdsplit_uimage_parse_generic,
+ .par
On 20.01.2021 15:35, Bjørn Mork wrote:
diff --git a/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c
b/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c
index 58c40e9ec70b..32c027d3e979 100644
--- a/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.
On 20.01.2021 15:35, Bjørn Mork wrote:
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/partitions/openwrt,uimage.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OpenWrt variations of U-Boot Image partitions
+
+ma
From: Rafał Miłecki
BCM4908 bootloader requires firmware with JFFS2 image containing:
1. cferam.000
2. 94908.dtb
3. vmlinux.lz
4. device custom files
cferam.000 can be obtained from the bcm63xx-cfe repository.
device custom files are stored in images dir.
Signed-off-by: Rafał Miłecki
On 19.01.2021 19:53, Adrian Schmutzler wrote:
This sets the DTS paths automatically based on their device definition
name. Devices where this is not possible may still be served by simply
overwriting DEVICE_DTS in their respective definition.
Cc: Rafał Miłecki
Signed-off-by: Adrian Schmutzler
On 2021-01-19 12:32, Adrian Schmutzler wrote:
> cp $(KDIR)/bcm63xx-cfe/$(subst
_,$(comma),$(DEVICE_NAME))/cferam.000
> $@-bootfs/
>
> This will remove the additional variable by simply making the current
> soft rule to have matching device definition name and compatible a
> hard one.
Are you sti
On 2021-01-18 12:50, Adrian Schmutzler wrote:
> Note that if you do apply these two "changes", you get rid of the
> COMPATIBLE variable at all for the proposed patch, and this is
> probably the reason why a variable like this is not needed for "build
> steps" in the other targets (at least those
On 2021-01-18 12:29, Adrian Schmutzler wrote:
Do you mean "files" as "directories" (I know every dir is a file ;) )?
If you talk
about "asus,gt-ac5300", it's used by the:
cp -r $(COMPATIBLE)/* $@-bootfs/
line in the Build/bcm4908img.
Ah, okay. Yes, I was referring to the directory names here.
From: Rafał Miłecki
BCM4908 bootloader requires firmware with JFFS2 image containing:
1. cferam.000
2. 94908.dtb
3. vmlinux.lz
4. device custom files
cferam.000 can be obtained from the bcm63xx-cfe repository. It requires
specifying directory path that is defined using COMPATIBLE variable.
For
On 15.01.2021 16:18, Adrian Schmutzler wrote:
-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
On Behalf Of Rafal Milecki
Sent: Freitag, 15. Januar 2021 10:44
To: openwrt-devel@lists.openwrt.org
Cc: Rafał Miłecki
Subject: [PATCH 2/2] bcm4908: build
From: Rafał Miłecki
bcm4908 target needs to include cferam images in firmware files too
Signed-off-by: Rafał Miłecki
---
package/kernel/bcm63xx-cfe/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/package/kernel/bcm63xx-cfe/Makefile
b/package/kernel/bcm63xx
From: Rafał Miłecki
BCM4908 bootloader requires firmware with JFFS2 image containing:
1. cferam.000
2. 94908.dtb
3. vmlinux.lz
4. device custom files
cferam.000 can be obtained from the bcm63xx-cfe repository. It requires
specifying directory path that is defined using COMPATIBLE variable.
For
From: Rafał Miłecki
Flashing image with BCM4908 CFE bootloader requires specific firmware
format. It needs 20 extra bytes with magic numbers and CRC32 appended.
This tools allows appending such a tail to the specified image and also
verifying CRC32 of existing BCM4908 image.
Signed-off-by
From: Rafał Miłecki
BCM4908 CFE bootloader requires kernel to be prepended with a custom
header. This simple tool implements support for such headers.
Signed-off-by: Rafał Miłecki
---
tools/firmware-utils/Makefile| 1 +
tools/firmware-utils/src/bcm4908kernel.c | 127
On 08.01.2021 19:30, Adrian Schmutzler wrote:
-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
On Behalf Of Rafal Milecki
Sent: Freitag, 8. Januar 2021 14:53
To: openwrt-devel@lists.openwrt.org
Cc: Rafał Miłecki
Subject: [PATCH] bcm4908: initial
From: Rafał Miłecki
BCM4906, BCM4908 and BCM49408 are SoCs with 64 bit ARMv8 B53 CPUs.
Upstream Linux is slowly getting support for that SoCs family so it
makes sense to add target for it.
It isn't usable yet (it only produces a bootable kernel) so "source-only"
is used.
Signe
On 08.01.2021 13:42, Alexander Couzens wrote:
The partition layout doesn't match the partition layout read out by OEM
version. It's unclear to me if different firmware version have different
partition layouts.
Missing Signed-off-by
---
target/linux/ramips/dts/mt7628an_xiaomi_mi-router-4a-
On 2020-09-23 23:33, Andre Valentin wrote:
I'm experimenting again a bit with the new API. I subscribed to the
hostapd events and saw that
after some time the connection is still up, but now new events come in.
How can I control timeout and make sure, that the subscription
connections stays as lo
From: Rafał Miłecki
It was a cosmetic feature that doesn't work anymore with the latest
uhttpd ubus API. Adding RESTful API resulted in treating URL part
following the /ubus/ as the new API request.
---
modules/luci-base/htdocs/luci-static/resources/rpc.js | 3 ---
1 file changed, 3 dele
From: Rafał Miłecki
After specified time of network inactivity uhttpd is meant to close
connection. It doesn't seem to work thought. After timeout client
doesn't receive any more data but connection it still opened.
This change fixes that.
Signed-off-by: Rafał Miłecki
---
From: Rafał Miłecki
By default uhttpd replies with Access-Control-Allow-Origin containing
URL from the request Origin header. It allows sending CORS requests from
any website allowing attacks.
Add support for -o option that allows specifying a single URL to be put
in the Access-Control-Allow
From: Rafał Miłecki
Complex GET requests (e.g. those with custom headers) require browsers
to send preflight OPTIONS request with:
Access-Control-Request-Method: GET
It's important to reply to such requests with all relevant
Access-Control-Allow-* headers to allow CORS requests.
Adding G
On Tue, 1 Sep 2020 at 06:48, Todor Colov wrote:
>
> ---
> tools/firmware-utils/Makefile | 4 +-
> tools/firmware-utils/src/linksys/addfwhdr.c | 195
> tools/firmware-utils/src/linksys/bcmdefs.h| 318 +
> .../firmware-utils/src/linksys/code_pattern.h |
On Tue, 1 Sep 2020 at 06:41, Todor Colov wrote:
> bundle of 4 patches to add support for Linksys E8350 dual band wifi router
> type AC2350
Apart from my comment on Broadcom code you also need to sign off all
your changes. See OpenWrt documentation on submitting patches and "git
help commit" and
On Mon, 14 Sep 2020 at 14:22, David Bauer wrote:
> + firmware-partition@5 {
> + label = "firmware";
> + reg = <0x5 0xf6>;
> + };
Please specify "compatible" so the kernel doesn't ha
From: Rafał Miłecki
With this change ubus will allow users with access to the object pseudo
method ":subscribe" to subscribe for notifications.
1. Move uh_ubus_allowed() up in the code
2. Export "Authorization" parsing code to the uh_ubus_get_auth()
3. Check for "
On 14.09.2020 18:31, Rafał Miłecki wrote:
@@ -2553,10 +2553,19 @@
rpcBaseURL = Session.getLocalData('rpcBaseURL');
if (rpcBaseURL == null) {
+ var msg = {
+ jso
From: Rafał Miłecki
This is proof of concept for the new uhttpd ubus API. It switches LuCI
(in a bit hacky way) to the new API.
Signed-off-by: Rafał Miłecki
---
.../htdocs/luci-static/resources/luci.js | 5 +++
.../htdocs/luci-static/resources/rpc.js | 31 +--
2
On 14.09.2020 17:15, Rafał Miłecki wrote:
+static void uh_ubus_handle_post(struct client *cl)
+{
+ static const struct blobmsg_policy hdr_policy[__HDR_UBUS_MAX] = {
+ [HDR_AUTHORIZATION] = { "authorization", BLOBMSG_TYPE_STRING },
+ };
+ struct dispatc
From: Rafał Miłecki
Sending GET request to the main RPC base URL and expecting HTTP response
code 400 had two flaws:
1. It was not verifying actual JSON-RPC interface availability
2. It did not allow implementing support for new requests
Signed-off-by: Rafał Miłecki
---
.../luci-base/htdocs
From: Rafał Miłecki
Initial uhttpd ubus API was fully based on JSON-RPC. That restricted it
from supporting ubus notifications that don't fit its model.
Notifications require protocol that allows server to send data without
being polled. There are two candidates for that:
1. Server-sent e
301 - 400 of 1493 matches
Mail list logo
