Re: [OpenWrt-Devel] [PATCH] build: have scripts/feeds honor feed.mk of the individual feed
Hi, tbh I don't really like the approach of arbitrarily defining "feed.mk" to be a change source. Can we extend this to take all toplevel *.mk files into consideration? I think this falls more in line with what people would expect. ~ 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: [OpenWrt-Devel] [PATCH] build: have scripts/feeds honor feed.mk of the individual feed
On 2019-03-07 17:28, Jo-Philipp Wich wrote: Hi, I do not understand the exact purpose of this patch. As far as I know, there is no "feed.mk" anywhere in the LuCI repo. Jo, you are correct, there is currently no such file. But I'm preparing some PRs for LuCI and freifunk feed [1], [2] which will create such file. This commit is one end of the horse ... Sven 1 - https://github.com/SvenRoederer/openwrt-luci/tree/feed_mk 2 - https://github.com/SvenRoederer/freifunk_openwrt-packages/tree/fix_mod-freifunk ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Random PARTUUID on every rebuild
On 2019-03-06 12:31, Jo-Philipp Wich wrote: > Hi, > > the random PARTUUID has been chosen to ensure that a given boot grub > partition (containing grub config, kernel, sysupgrade restore tarball) > boots the correct corresponding rootfs in case multiple openwrt > partitions are present on the device (e.g. different versions on > different block devices). > > Chosing a random uuid at build time was the simplest way to achieve that. > > The random identifier can be replaced by a stable identifier derived > from the version or something like SOURCE_DATE_EPOCH combined with a > checksum over the kernel config or similar. > > Maybe the kernel version magic value would be a suitable pseudorandom > seed candidate to produce a reproducible partuuid which still > distinguishes different kernel/rootfs pairs sufficiently. How about we use a hash of the kernel and rootfs images as PARTUUID? - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Random PARTUUID on every rebuild
On Thu, Mar 7, 2019 at 10:36 AM Jo-Philipp Wich wrote: > Hi, > > > Could this be a CLI parameter to make, or something that's written to > > the .config? > > Once it is set in .config it will remain the same with every subsequent > rebuild, defeating its purpose entirely. > > ~ Jo > > Users who set it in the .config file will expect it to be the same with every subsequent rebuild. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Random PARTUUID on every rebuild
Hi, > Could this be a CLI parameter to make, or something that's written to > the .config? Once it is set in .config it will remain the same with every subsequent rebuild, defeating its purpose entirely. ~ 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: [OpenWrt-Devel] [PATCH] build: have scripts/feeds honor feed.mk of the individual feed
Hi, I do not understand the exact purpose of this patch. As far as I know, there is no "feed.mk" anywhere in the LuCI repo. ~ 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: [OpenWrt-Devel] [B.A.T.M.A.N.] [RFC openwrt-routing] batman-adv: Split batadv proto in meshif and hardif part
On Sunday, February 24, 2019 5:51:13 PM CET Sven Eckelmann wrote: > batman-adv allows to configure three different objects: > > * batadv hardif > > - network interface used by batadv meshif to transport the batman-adv > packets > - its master interface is set to the batadv meshif > > * batadv (meshif/softif) > > - virtual interface that emulates a normal 802.3 interface on top > - encapsulates traffic and forwards it via the batadv hardifs > > * batadv vlan > > - potential VLAN ID on top of batadv meshif > - allows filtering of traffic from specific VIDs > > While batadv vlan objects were already represented as an own proto > "batadv_vlan", the batadv meshif could never be fully configured using > /etc/config/network. Instead, parts of its configuration were stored in > /etc/config/batman_adv and some in the interfaces with the "batadv" proto. > > To increase the confusion, the "batadv" proto wasn't used to define the > batadv meshif but to identify batadv (slave) hardifs. The batman-adv > meshifs were also never created directly but only when a hardif was > configured. The actual modification of the configuration settings was then > applied using a hotplug script hack. The batadv meshif network interface > could therefore only be created when an hardif was available and not > manipulated with ifup/ifdown. Also `/etc/init.d/network reload` didn't > modify the batadv meshif interface configuration correctly. > > The "batadv" is now renamed to "batadv_hardif" and a new "batadv" proto is > used to configure the main (meshif) network interface with all its > configuration. > > A simple network configuration with WiFi & ethernet interfaces and static > IP on top of bat0 would look like: > > # batadv meshif bat0 > config interface 'bat0' > option proto 'batadv' > option routing_algo 'BATMAN_IV' > option aggregated_ogms 1 > option ap_isolation 0 > option bonding 0 > option fragmentation 1 > #option gw_bandwidth '1/2000' > option gw_mode 'off' > #option gw_sel_class 20 > option log_level 0 > option orig_interval 1000 > option bridge_loop_avoidance 1 > option distributed_arp_table 1 > option multicast_mode 1 > option network_coding 0 > option hop_penalty 30 > option isolation_mark '0x/0x' > > # add *single* wifi-iface with network bat0_hardif_wlan as hardif to bat0 > config interface 'bat0_hardif_wlan' > option mtu '1536' > option proto 'batadv_hardif' > option master 'bat0' > # option ifname is filled out by the wifi-iface > > # add eth0 as hardif to bat0 > config interface 'bat0_hardif_eth0' > option proto 'batadv_hardif' > option master 'bat0' > option ifname 'eth0' > option mtu '1536' > > # configure IP on bat0 > config interface 'bat0_lan' > option ifname 'bat0' > option proto 'static' > option ipaddr '192.168.1.1' > option netmask '255.255.255.0' > option ip6assign '60' Hey, thank you very much for proposing that. It looks very good to me. We just discussed personally if it were possible to get rid of the bat0_hardif sections, but we will need them to configure other things in the future (e.g. ELP intervals, throughput override). And doing the "ifname" list in bat0 would result in a bad hack as we currently have for bridges, this is not favorable. So +1 from me for this. Cheers, Simon signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] EU feedback on "Upload of software on radio equipment"
Eric Luehrsen writes: > On 3/4/19 6:35 PM, Hauke Mehrtens wrote: >> Hi, >> >> The European commission asked for feedback on the Radio Equipment >> Directive (RED) regarding the restrictions on "Upload of software on >> radio equipment" >> >> I posted here a comment in the name of the OpenWrt project: >> https://ec.europa.eu/info/law/better-regulation/initiatives/ares-2018-6621038/feedback/F240894_en?p_id=380919 >> The deadline for comments was 4. March. >> >> Thank you for the help and also the others who posted feedback to the >> European commission. >> >> More details can be found here: >> https://fsfe.org/activities/radiodirective/ >> >> Hauke > > Historical Reference > > US FCC attempted a similar thing a few years ago and it received some > backlash. They chose to revise the interpretation instructions for > the rule. Although a regulation (FCC rule) is flexible and less > worrisome. Bad legislation can hang around for a long time. > > FCC NPRM: > https://docs.fcc.gov/public/attachments/FCC-15-92A1.pdf > FCC Informal News: > https://www.fcc.gov/news-events/blog/2015/11/12/clearing-air-wi-fi-software-updates > FCC Revised Interpretation: > https://apps.fcc.gov/kdb/GetAttachment.html?id=zXtrctoj6zH7oNEOO6De6g%3D%3D=594280%20D02%20U-NII%20Device%20Security%20v01r03_number=39498 > Credible Response: > https://ecfsapi.fcc.gov/file/60001333550.pdf I appreciate y'all citing that ex parte brief of mine to the FCC. I have not been paying much attention to what's going on in the EU of late, and would appreciate a brief on what's happening there now. I will be at netdevconf and IETF in prague march 16th-31st, and still have a few spare bunks on the houseboat if anyone going needs a place to crash. Otherwise, I could make a detour to berlin, afterwards. > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v6 2/3] ar71xx: Speed up caldata/eeprom handling
Reading and writing to and from flash storage is slowed down
enormously by some functions which use a block size of 1.
This patch reworks the extraction scripts to be much faster and
efficient by reading and writing in possibly one big block.
This is based on the initial commit a69e101 for ipq40xx by
Christian Lamparter .
Speed comparison @ TP-Link TL-WDR4300 (just manually) results
in a time reduction by three orders of magnitude (99.9 %).
> time dd if=/dev/mtd3 of=/lib/firmware/test-slow bs=1 count=4096 skip=4096
4096+0 records in
4096+0 records out
real0m 15.85s
user0m 0.06s
sys 0m 13.28s
> time dd if=/dev/mtd3 of=/lib/firmware/test-fast bs=4096 count=1 skip=4096
> iflag=skip_bytes
1+0 records in
1+0 records out
real0m 0.02s
user0m 0.00s
sys 0m 0.02s
Signed-off-by: Adrian Schmutzler
---
Changed in v3:
- Changed position of iflag/oflag to be consistent with ath79
Changed in v4:
- Rebased
Changed in v5:
- Rebased
---
.../linux/ar71xx/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom | 6 +++---
.../ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git
a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
index 94bce7d335..208d5f6bff 100644
--- a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
+++ b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
@@ -20,7 +20,7 @@ ath9k_eeprom_extract() {
[ -n "$mtd" ] || \
ath9k_eeprom_die "no mtd device found for partition $part"
- dd if=$mtd of=/lib/firmware/$FIRMWARE bs=1 skip=$offset count=$count
2>/dev/null || \
+ dd if=$mtd of=/lib/firmware/$FIRMWARE iflag=skip_bytes bs=$count
skip=$offset count=1 2>/dev/null || \
ath9k_eeprom_die "failed to extract from $mtd"
}
@@ -35,7 +35,7 @@ ath9k_ubi_eeprom_extract() {
[ -n "$ubi" ] || \
ath9k_eeprom_die "no UBI volume found for $part"
- dd if=/dev/$ubi of=/lib/firmware/$FIRMWARE bs=1 skip=$offset
count=$count 2>/dev/null || \
+ dd if=/dev/$ubi of=/lib/firmware/$FIRMWARE iflag=skip_bytes bs=$count
skip=$offset count=1 2>/dev/null || \
ath9k_eeprom_die "failed to extract from $ubi"
}
@@ -62,7 +62,7 @@ ath9k_patch_firmware_mac() {
[ -z "$mac" ] && return
- macaddr_2bin $mac | dd of=/lib/firmware/$FIRMWARE conv=notrunc bs=1
seek=2 count=6
+ macaddr_2bin $mac | dd of=/lib/firmware/$FIRMWARE conv=notrunc
oflag=seek_bytes bs=6 seek=2 count=1
}
board=$(board_name)
diff --git
a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 3450819630..cd5c1c2bcb 100644
--- a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -10,7 +10,7 @@ ath10kcal_from_file() {
local offset=$2
local count=$3
- dd if=$source of=/lib/firmware/$FIRMWARE bs=1 skip=$offset count=$count
2>/dev/null || \
+ dd if=$source of=/lib/firmware/$FIRMWARE iflag=skip_bytes bs=$count
skip=$offset count=1 2>/dev/null || \
ath10kcal_die "failed to extract calibration data from $source"
}
@@ -30,7 +30,7 @@ ath10kcal_extract() {
[ "$count" = "$cal_size" ] || \
ath10kcal_die "no calibration data found in $part"
- dd if=$mtd of=/lib/firmware/$FIRMWARE bs=1 skip=$offset count=$count
2>/dev/null || \
+ dd if=$mtd of=/lib/firmware/$FIRMWARE iflag=skip_bytes bs=$count
skip=$offset count=1 2>/dev/null || \
ath10kcal_die "failed to extract calibration data from $mtd"
}
@@ -39,7 +39,7 @@ ath10kcal_patch_mac() {
[ -z "$mac" ] && return
- macaddr_2bin $mac | dd of=/lib/firmware/$FIRMWARE conv=notrunc bs=1
seek=6 count=6
+ macaddr_2bin $mac | dd of=/lib/firmware/$FIRMWARE conv=notrunc
oflag=seek_bytes bs=6 seek=6 count=1
}
[ -e /lib/firmware/$FIRMWARE ] && exit 0
--
2.11.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v6 3/3] ar71xx: Speed up mtd extraction in ar71xx.sh
Although the amount of data read here is smaller than for the
caldata, there still might be some speed gain compared to reading
bytewise. And there is no harm ...
Signed-off-by: Adrian Schmutzler
---
Changed in v3:
- Changed position of iflag to be consistent
Changed in v4:
- Rebased
Changed in v5:
- Rebased
---
target/linux/ar71xx/base-files/lib/ar71xx.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 95fa247f4b..f0f6f0398b 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -16,7 +16,7 @@ ar71xx_get_mtd_offset_size_format() {
dev=$(find_mtd_part $mtd)
[ -z "$dev" ] && return
- dd if=$dev bs=1 skip=$offset count=$size 2>/dev/null | hexdump -v -e
"1/1 \"$format\""
+ dd if=$dev iflag=skip_bytes bs=$size skip=$offset count=1 2>/dev/null |
hexdump -v -e "1/1 \"$format\""
}
ar71xx_get_mtd_part_magic() {
@@ -390,7 +390,7 @@ tplink_pharos_v2_get_model_string() {
part=$(find_mtd_part 'product-info')
[ -z "$part" ] && return 1
- dd if=$part bs=1 skip=4360 count=64 2>/dev/null | tr -d '\r\0' | head
-n 1
+ dd if=$part iflag=skip_bytes bs=64 skip=4360 count=1 2>/dev/null | tr
-d '\r\0' | head -n 1
}
ar71xx_board_detect() {
--
2.11.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v6 0/3] Speed up caldata/eeprom extraction
This patchset goes on with the attempt to speed up caldata/eeprom handling by reading blockwise. Since the code merge in eeprom.sh seems to be not desired, I removed this part, so this patchset only contain the mere speedup for ath79 and ar71xx. Adrian Schmutzler (3): ath79: Speed up caldata/eeprom handling ar71xx: Speed up caldata/eeprom handling ar71xx: Speed up mtd extraction in ar71xx.sh .../linux/ar71xx/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom | 6 +++--- .../ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata | 6 +++--- target/linux/ar71xx/base-files/lib/ar71xx.sh| 4 ++-- .../linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom | 2 +- .../linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata | 6 +++--- 5 files changed, 12 insertions(+), 12 deletions(-) -- 2.11.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v6 1/3] ath79: Speed up caldata/eeprom handling
Reading and writing to and from flash storage is slowed down
enormously by some functions which use a block size of 1.
This patch reworks the extraction scripts to be much faster and
efficient by reading and writing in possibly one big block.
This is based on the initial commit a69e101 for ipq40xx by
Christian Lamparter .
Speed comparison @ UBNT AC-Mesh (just manually) results
in a time reduction by three orders of magnitude (99.9 %).
> time dd if=/dev/mtd6 of=/lib/firmware/test-slow bs=1 count=4096 skip=4096
4096+0 records in
4096+0 records out
real0m 16.84s
user0m 0.07s
sys 0m 13.54s
> time dd if=/dev/mtd6 of=/lib/firmware/test-fast bs=4096 count=1 skip=4096
> iflag=skip_bytes
1+0 records in
1+0 records out
real0m 0.02s
user0m 0.00s
sys 0m 0.02s
Signed-off-by: Adrian Schmutzler
Tested-by: Rosen Penev
---
Changed in v3:
- Rebased on the patch from Dmitry Tunin
- Changed position of iflag/oflag to be consistent with Dmitry
Changed in v4:
- Rebased
Changed in v5:
- Rebased
---
.../linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom | 2 +-
.../linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git
a/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
b/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
index 84e4d07b35..d8b292f4da 100644
--- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
+++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
@@ -81,7 +81,7 @@ ath9k_patch_fw_mac() {
dd of=/lib/firmware/$FIRMWARE conv=notrunc bs=1
seek=$chksum_offset count=2
}
- macaddr_2bin $mac | dd of=/lib/firmware/$FIRMWARE conv=notrunc bs=1
seek=$mac_offset count=6
+ macaddr_2bin $mac | dd of=/lib/firmware/$FIRMWARE conv=notrunc
oflag=seek_bytes bs=6 seek=$mac_offset count=1
}
ath9k_patch_fw_mac_crc() {
diff --git
a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 096064b7ce..f8e385be68 100644
--- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -28,7 +28,7 @@ ath10kcal_from_file() {
local offset=$2
local count=$3
- dd if=$source of=/lib/firmware/$FIRMWARE bs=1 skip=$offset count=$count
2>/dev/null || \
+ dd if=$source of=/lib/firmware/$FIRMWARE iflag=skip_bytes bs=$count
skip=$offset count=1 2>/dev/null || \
ath10kcal_die "failed to extract calibration data from $source"
}
@@ -42,7 +42,7 @@ ath10kcal_extract() {
[ -n "$mtd" ] || \
ath10kcal_die "no mtd device found for partition $part"
- dd if=$mtd of=/lib/firmware/$FIRMWARE bs=1 skip=$offset count=$count
2>/dev/null || \
+ dd if=$mtd of=/lib/firmware/$FIRMWARE iflag=skip_bytes bs=$count
skip=$offset count=1 2>/dev/null || \
ath10kcal_die "failed to extract calibration data from $mtd"
}
@@ -51,7 +51,7 @@ ath10kcal_patch_mac() {
[ -z "$mac" ] && return
- macaddr_2bin $mac | dd of=/lib/firmware/$FIRMWARE conv=notrunc bs=1
seek=6 count=6
+ macaddr_2bin $mac | dd of=/lib/firmware/$FIRMWARE conv=notrunc
oflag=seek_bytes bs=6 seek=6 count=1
}
ath10kcal_patch_mac_crc() {
--
2.11.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
