Re: [PATCH V3 2/3] base-files: sysupgrade: use tar helper to include installed_packages.txt

[Luiz Angelo Daros de Luca]

>
> Replace mount + overlay with manually built tar archive that gets
> prepended to the actual config files backup. This allows more
> flexibility with including extra backup files. They can be included at
> any paths and don't require writing to flash or mounting an overlay
> which has its own limitations (mount points).
>
> Signed-off-by: Rafał Miłecki 
> ---
>  package/base-files/files/sbin/sysupgrade | 44 +---
>  1 file changed, 16 insertions(+), 28 deletions(-)
>
> diff --git a/package/base-files/files/sbin/sysupgrade 
> b/package/base-files/files/sbin/sysupgrade
> index 6b3fb0666f..a11e17615c 100755
> --- a/package/base-files/files/sbin/sysupgrade
> +++ b/package/base-files/files/sbin/sysupgrade
> @@ -237,8 +237,6 @@ include /lib/upgrade
>  create_backup_archive() {
> local conf_tar="$1"
>
> -   local umount_etcbackup_dir=0
> -
> [ "$(rootfs_type)" = "tmpfs" ] && {
> echo "Cannot save config while running from ramdisk." >&2
> ask_bool 0 "Abort" && exit
> @@ -248,41 +246,31 @@ create_backup_archive() {
> run_hooks "$CONFFILES" $sysupgrade_init_conffiles
> ask_bool 0 "Edit config file list" && vi "$CONFFILES"
>
> -   if [ "$SAVE_INSTALLED_PKGS" -eq 1 ]; then
> -   echo "${INSTALLED_PACKAGES}" >> "$CONFFILES"
> -   mkdir -p "$ETCBACKUP_DIR"
> -   # Avoid touching filesystem on each backup
> -   RAMFS="$(mktemp -d -t sysupgrade.XX)"
> -   mkdir -p "$RAMFS/upper" "$RAMFS/work"
> -   mount -t overlay overlay -o 
> lowerdir=$ETCBACKUP_DIR,upperdir=$RAMFS/upper,workdir=$RAMFS/work 
> $ETCBACKUP_DIR &&
> -   umount_etcbackup_dir=1 || {
> -   echo "Cannot mount '$ETCBACKUP_DIR' as tmpfs 
> to avoid touching disk while saving the list of installed packages." >&2
> -   ask_bool 0 "Abort" && exit
> -   }
> -
> -   # Format: pkg-name{rom,overlay,unknown}
> -   # rom is used for pkgs in /rom, even if updated later
> -   find /usr/lib/opkg/info -name "*.control" \( \
> -   \( -exec test -f /rom/{} \; -exec echo {} rom \; \) 
> -o \
> -   \( -exec test -f /overlay/upper/{} \; -exec echo {} 
> overlay \; \) -o \
> -   \( -exec echo {} unknown \; \) \
> -   \) | sed -e 's,.*/,,;s/\.control /\t/' > 
> ${INSTALLED_PACKAGES}
> -   fi
> -
> v "Saving config files..."
> [ "$VERBOSE" -gt 1 ] && TAR_V="v" || TAR_V=""
> sed -i -e 's,^/,,' "$CONFFILES"
> -   tar c${TAR_V}zf "$conf_tar" -C / -T "$CONFFILES"
> +   {
> +   # Part of archive with installed packages info
> +   if [ "$SAVE_INSTALLED_PKGS" -eq 1 ]; then
> +   # Format: pkg-name{rom,overlay,unknown}
> +   # rom is used for pkgs in /rom, even if updated later
> +   tar_print_member "$INSTALLED_PACKAGES" "$(find 
> /usr/lib/opkg/info -name "*.control" \( \
> +   \( -exec test -f /rom/{} \; -exec echo {} rom 
> \; \) -o \
> +   \( -exec test -f /overlay/upper/{} \; -exec 
> echo {} overlay \; \) -o \
> +   \( -exec echo {} unknown \; \) \
> +   \) | sed -e 's,.*/,,;s/\.control /\t/')"
> +   fi

I don't like the idea of running tar_print_member without checking for
errors. This is even more important for the following tar that
includes files specified by the user. In my opinion, it should abort
the process if tar fails.
As ash cannot read the pipe exit status, you could print the error and
touch a /tmp/${mypid}_abort, checking for it after the gzip to abort
the process (and erase the error flag file).

> +
> +   # Rest of archive with config files and ending padding
> +   tar c${TAR_V} -C / -T "$CONFFILES"
> +   } | gzip > "$conf_tar"
> +
> local err=$?
> if [ "$err" -ne 0 ]; then
> echo "Failed to create the configuration backup."
> rm -f "$conf_tar"
> fi
>
> -   [ "$umount_etcbackup_dir" -eq 1 ] && {
> -   umount "$ETCBACKUP_DIR"
> -   rm -rf "$RAMFS"
> -   }
> rm -f "$CONFFILES"
>
> return "$err"
> --
> 2.35.3
>

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

Re: [PATCH V3 1/3] base-files: sysupgrade: add tar.sh with helpers for building archives

[Luiz Angelo Daros de Luca]

Hello Rafał,

Sorry for the late review.

I know this will be used for a limited context but it can be
constructed in such a way it could be used for more cases without
increasing its complexity.

> From: Jo-Philipp Wich 
>
> This allows building uncompressed tar archives from shell scripts (and
> compressing them later if needed)
>
> Signed-off-by: Rafał Miłecki 
> ---
> V2: Simplify dd in __tar_print_padding (I still think helper is useful)
> Hardcode 0/0/ root/root for now as most likely it'll be enough
> Simplify name validation (leasing slash)
> Reorder some variables
> V3: Fix dd in __tar_print_padding
> Rename functions
> Drop unused functions
> Document usage
>
>  package/base-files/files/lib/upgrade/tar.sh | 71 +
>  1 file changed, 71 insertions(+)
>  create mode 100644 package/base-files/files/lib/upgrade/tar.sh
>
> diff --git a/package/base-files/files/lib/upgrade/tar.sh 
> b/package/base-files/files/lib/upgrade/tar.sh
> new file mode 100644
> index 00..a9d1d559e6
> --- /dev/null
> +++ b/package/base-files/files/lib/upgrade/tar.sh
> @@ -0,0 +1,71 @@
> +# SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +
> +# Example usage:
> +#
> +# {
> +# tar_print_member "date.txt" "It's $(date +"%Y")"
> +# tar_print_trailer
> +# } > test.tar
> +
> +__tar_print_padding() {
> +   dd if=/dev/zero bs=1 count=$1 2>/dev/null
> +}
> +
> +tar_print_member() {
> +   local name="$1"
> +   local content="$2"
> +   local mtime="${3:-$(date +%s)}"
> +   local mode=644
> +   local uid=0
> +   local gid=0
> +   local size=${#content}
> +   local type=0
> +   local link=""
> +   local username="root"
> +   local groupname="root"
> +
> +   # 100 byte of padding bytes, using 0x01 since the shell does not 
> tolerate null bytes in strings
> +   local 
> pad=$'\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1'

\1 is still a valid filename character. Shell cannot save a string
with \0 but printf can handle it nicely (as well as pipes). If you
build the header using a function at the moment you use it, you could
avoid the \1 hack.

print_header() {
   local filename=$1
   local mode=$2
   ...
   local checksum=$7
   ...
   printf '%s' "$filename"; printf '\x00%.0s' $(seq $((100 - ${#filename})))
   ...
}

print_header "$filename" "$mode" \
   "$uid" "$gid" .. | hexdump -ve '1/1 "%u

If you don't like the printf trick to repeat a char, you could use
__tar_print_padding (or use printf for both).

You could call it twice, first without a checksum to calculate it and
then a new one to generate the final output.

> +
> +   # validate name (strip leading slash if present)
> +   name=${name#/}
> +
> +   # truncate string header values to their maximum length
> +   name=${name:0:100}

It feels strange to simply truncate the name. If you need to truncate
it, you are implying it might be larger. In that case, it should fail
if it cannot fit a specific filename. Otherwise, you could end up
overwriting two filenames with the same first 100 bytes. And BTW,
shouldn't ustar support 255 or 256 filenames?

> +   link=${link:0:100}
> +   username=${username:0:32}
> +   groupname=${groupname:0:32}
> +
> +   # construct header part before checksum field
> +   local header1="${name}${pad:0:$((100 - ${#name}))}"
> +   header1="${header1}$(printf '%07d\1' $mode)"
> +   header1="${header1}$(printf '%07o\1' $uid)"
> +   header1="${header1}$(printf '%07o\1' $gid)"
> +   header1="${header1}$(printf '%011o\1' $size)"
> +   header1="${header1}$(printf '%011o\1' $mtime)"
> +
> +   # construct header part after checksum field
> +   local header2="$(printf '%d' $type)"
> +   header2="${header2}${link}${pad:0:$((100 - ${#link}))}"
> +   header2="${header2}ustar  ${pad:0:1}"
> +   header2="${header2}${username}${pad:0:$((32 - ${#username}))}"
> +   header2="${header2}${groupname}${pad:0:$((32 - ${#groupname}))}"

It seems to be a strange ustar format. Shouldn't it have an ustar
version before the username? And Device major/minor after groupname,
followed by more 150 filename prefix? It might still work if the
reader interprets it as a v7.

> +   # calculate checksum over header fields
> +   local checksum=0
> +   for byte in $(printf '%s%8s%s' "$header1" "" "$header2" | tr '\1' 
> '\0' | hexdump -ve '1/1 "%u "'); do
> +   checksum=$((checksum + byte))
> +   done
> +

Maybe use a single line like:

checksum=$(print header... | hexdump -ve '1/1 "%u\n"' | awk '{s+=$1}
END {print s}')

?

> +   # print member header, padded to 512 byte
> +   printf '%s%06o\0 %s' "$header1" $checksum "$header2" | tr '\1' '\0'
> +   __tar_print_padding 183
> +
> +   # print content data, 

uhttpd fixes via github

[Luiz Angelo Daros de Luca]

Hello,

There is a small fix for uhttpd pending in github.

https://github.com/openwrt/uhttpd/pull/2

If github should not be used for that, it would be nice to have it
explicitly mentioned in the github project or a Readme.md file.

Regards,

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

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

Re: sysupgrade is broken

[Luiz Angelo Daros de Luca]

> On 21.02.2024 20:52, e9hack wrote:
> > root@WLAN-DSL9:~# sysupgrade -b /var/config-backup.tar.gz
> > Wed Feb 21 20:48:30 CET 2024 upgrade: Saving config files...
> > tar: var/dhcp.leases: No such file or directory
> > tar: var/lib/logrotate.status: No such file or directory
> > tar: var/log/logrotate.log: No such file or directory
> > tar: error exit delayed from previous errors
> > Failed to create the configuration backup.
>
> I can reproduce that. The problem is caused by:
> mount -t overlay overlay -o 
> lowerdir=/,upperdir="$tmp/upper",workdir="$tmp/work" "$dir"
>
> Apparently lowerdir=/ doesn't work as I expected. In $dir I can see
> squashfs + overlay changes but I don't see mounts.
>
> root@OpenWrt:/# ls -l $dir/tmp/
> root@OpenWrt:/# ls -l $dir/rom/
> -rw-r--r--1 root root   116 Feb 19 12:53 note
> root@OpenWrt:/# ls -l $dir/dev/
> crw---1 root root5,   1 Feb 19 12:53 console
>
> I'm not sure if there is an easy way to solve that. Anyone?

Easy as "a overlay fs option to follow mounted subfilesystems"? Sorry,
AFAIK, no.

I commented earlier today in github
(https://github.com/openwrt/openwrt/commit/4fa9aaf0bed984d200b3c48d1cc81fca7847c394)

In summary, you can overlay every mounted filesystem. Alternatively,
you can change the strategy and only overlay the leaf directory you
actually need to modify, exclude them from main backup and append the
overlay contents.

Regards,

Luiz

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

Re: [PATCH RFC] base-files: sysupgrade: always setup overlay when creating backup

[Luiz Angelo Daros de Luca]

> From: Rafał Miłecki 
>
> Setting overlay while creating backup allows including extra files in
> archive without actually writing them to flash. Right now this feature
> is limited to /etc/backup/ directory and is used only for including
> installed_packages.txt.
>
> Extend this solution to make it more generic:
> 1. Always mount overlay while creating backup
> 2. Overlay whole / to don't limit it to /etc/backup/
>
> This allows including any additional files in backups and adding more
> sysupgrade features.

It is a nice feature. Thanks.

>
> Cc: Luiz Angelo Daros de Luca 
> Cc: Christian Marangi 
> Cc: Jo-Philipp Wich 
> Cc: Jonas Gorski 
> Signed-off-by: Rafał Miłecki 
> ---
> This will allow me to include /etc/uci-defaults/ scripts in backups so
> we can e.g. have script disabling previously disabled services.
>
>  package/base-files/files/sbin/sysupgrade | 37 ++--
>  1 file changed, 21 insertions(+), 16 deletions(-)
>
> diff --git a/package/base-files/files/sbin/sysupgrade 
> b/package/base-files/files/sbin/sysupgrade
> index 1fcd44da2a..1e09f65e07 100755
> --- a/package/base-files/files/sbin/sysupgrade
> +++ b/package/base-files/files/sbin/sysupgrade
> @@ -237,7 +237,8 @@ include /lib/upgrade
>  create_backup_archive() {
> local conf_tar="$1"
>
> -   local umount_etcbackup_dir=0
> +   local overlay
> +   local dir
>
> [ "$(rootfs_type)" = "tmpfs" ] && {
> echo "Cannot save config while running from ramdisk." >&2
> @@ -248,17 +249,20 @@ create_backup_archive() {
> run_hooks "$CONFFILES" $sysupgrade_init_conffiles
> ask_bool 0 "Edit config file list" && vi "$CONFFILES"
>
> +   # Mount root directory with temporary overlay on top of it.
> +   # This allows including extra (temporary) files in backup archive
> +   # without messing actual rootfs.
> +   overlay="$(mktemp -d -t overlay.XX)"
> +   mkdir -p "$overlay/upper" "$overlay/work"
> +   dir="$(mktemp -d -t backup.XX)"

You could avoid two mktemp creating a single unique parent directory.
It makes the cleanup simpler.

> +   if ! mount -t overlay overlay -o 
> lowerdir=/,upperdir="$overlay/upper",workdir="$overlay/work" "$dir"; then
> +   echo "Cannot mount backup overlay to $dir." >&2
> +   ask_bool 0 "Abort" && exit
> +   fi
> +
> if [ "$SAVE_INSTALLED_PKGS" -eq 1 ]; then
> echo "${INSTALLED_PACKAGES}" >> "$CONFFILES"
> -   mkdir -p "$ETCBACKUP_DIR"
> -   # Avoid touching filesystem on each backup
> -   RAMFS="$(mktemp -d -t sysupgrade.XX)"
> -   mkdir -p "$RAMFS/upper" "$RAMFS/work"
> -   mount -t overlay overlay -o 
> lowerdir=$ETCBACKUP_DIR,upperdir=$RAMFS/upper,workdir=$RAMFS/work 
> $ETCBACKUP_DIR &&
> -   umount_etcbackup_dir=1 || {
> -   echo "Cannot mount '$ETCBACKUP_DIR' as tmpfs 
> to avoid touching disk while saving the list of installed packages." >&2
> -   ask_bool 0 "Abort" && exit
> -   }
> +   mkdir -p "$dir/$ETCBACKUP_DIR"
>
> # Format: pkg-name{rom,overlay,unkown}
> # rom is used for pkgs in /rom, even if updated later
> @@ -266,22 +270,23 @@ create_backup_archive() {
> \( -exec test -f /rom/{} \; -exec echo {} rom \; \) 
> -o \
> \( -exec test -f /overlay/upper/{} \; -exec echo {} 
> overlay \; \) -o \
> \( -exec echo {} unknown \; \) \
> -   \) | sed -e 's,.*/,,;s/\.control /\t/' > 
> ${INSTALLED_PACKAGES}
> +   \) | sed -e 's,.*/,,;s/\.control /\t/' > 
> "$dir/${INSTALLED_PACKAGES}"
> fi
>
> v "Saving config files..."
> +   sed -i 's/^\///' "$CONFFILES" # Drop leading slashes
> [ "$VERBOSE" -gt 1 ] && TAR_V="v" || TAR_V=""
> -   tar c${TAR_V}zf "$conf_tar" -T "$CONFFILES" 2>/dev/null
> +   tar c${TAR_V}zf "$conf_tar" -C "${dir:-/}" -T "$CONFFILES"

These were already part of an PR that fixed a couple of sysupgrade issues:
https://github.com/openwrt/openwrt/pull/11022 (since Oct 2022 but
still re

Re: qca8327/qca8337 switch

[Luiz Angelo Daros de Luca]

> Am 12.02.2024 um 17:59 schrieb Christian Marangi (Ansuel):
> > Would be ideal to know what target are we talking about.
>
> The device is a TP Link C7 converted to using DSA.

It is a good opportunity to use it as a loadable module. It is tricky
but it works if configured correctly.

Regards,

Luiz

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

Re: Linux kernel 6.1 or 6.6 for OpenWrt 24.x release?

[Luiz Angelo Daros de Luca]

> >I would choose 6.1: to get more time for some things to stabilize out and 
> >because I am under the impression the kernel size is growing too fast and so 
> >we are accelerating hw obsolescence.

The firmware overall size is not the only problem. Some bootloaders
might have trouble loading larger kernels. Even today, some devices
cannot handle initramfs (kernel+rootfs). We should try to focus on
migrating more stuff into modules, which might also save some extra
RAM for drivers only needed by some devices.


Regards,

Luiz

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

Re: Packaging ZFS

[Luiz Angelo Daros de Luca]

> Thanks, Alberto.  I'm wondering how much work making it cross-build packages 
> is going to be...
>
> Digging into it now...
>

You should take a look at ksmbd package. It does compile an out-of-tree module.

Maintaining a package like that might be challenging for a stable
version. The kernel in the stable branch might receive updates during
its life but they are only published when a dot version (yy.mm.x+1) is
actually released.
However, packages are rebuilt as they are changed using the current
kernel in the stable branch. So, to build your module with a kernel
that will actually be published. you can only update a package with a
kernel module when you know the kernel in the stable branch is the one
that will be used by the next dot release. This "window of
opportunity" happens a little before or after the dot release is
built. Once the kernel is updated again, that window is closed. And
that updated kernel module will only be compatible with that specific
dot version, and not with any other dot version before or after it.

Regards,

Luiz

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

Re: fw4/nftables - performance seriously degraded after upgrade to 22.03.5 (from 21.03)

[Luiz Angelo Daros de Luca]

> Would it be too complex to implement a log limit for fw4?

Not really. But I might not have followed the best practices as this
is my first run on ucode/nftables:

https://github.com/luizluca/firewall4/tree/log_limit

It needs some more tests on cases that I'm not using in production and
a test if it can avoid DoS the router.

Regards,

Luiz

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

fw4/nftables - performance seriously degraded after upgrade to 22.03.5 (from 21.03)

[Luiz Angelo Daros de Luca]

Hello,

After I upgraded to 22.03.5 (from 21.03.x), I noticed that the
performance was seriously degraded.
The reason was that fw4/nftables was not handling a large number of
rejections the same way as fw3/iptables. If I disable the log, the
router is back to normal. I don't know if fw3 was implicitly limiting
the amount of logs (it now generates almost double the number of
lines) or the logs are just more expensive, but it introduces a way to
DoS a router with logs enabled (much worse than with fw3/iptables).

Is there a workaround for that other than disabling logs? log_limit
does not seem to be supported by fw4:

https://git.openwrt.org/?p=project/firewall4.git;a=blob;f=root/usr/share/ucode/fw4.uc;h=06ef932c8a501bbc057669629d3b8ebeabde4aa7;hb=HEAD#l1997

Although the wiki firewall doc still mentions log_limit.

Would it be too complex to implement a log limit for fw4?

Regards,

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

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

Re: Any plans to submit realtek target drivers to mainline Linux?

[Luiz Angelo Daros de Luca]

Em sáb., 6 de mai. de 2023 06:12, Arınç ÜNAL  escreveu:
>
> Hi.

Hi Arinç,

> I see a lot of development on the network drivers like DSA, PHY, etc.
> Are there any plans to put all these drivers on the realtek target on
> mainline Linux? To fully support these SoCs on mainline Linux?
>
> Arınç
>

I'm a minor contributor to the DSA driver for the realtek target, but
I have my 2 cents to share. I believe we can start to enlist what
would be needed to get the drivers upstream. We can start the
discussion from there:

- The DSA driver uses a lot of magic numbers that would not be
accepted by the upstream kernel. They must be converted into macros,
enum, inline functions and friends.
- There are shared functions with internal conditions (if modelA then
...). Mixed with magic numbers, it is much easier to miss a
peculiarity about a subtarget and introduce bugs. A nice way to avoid
that is to convert them into indirect calls to subtarget functions
(*_ops).
- The driver uses hardcoded addresses and direct memory writes. I
don't know if there is anything incompatible but upstream drivers
normally use regmap. It will also clean up a lot of things and
introduce nice functions.
- The DSA driver uses a generic tag that is converted afterwards by
each (ethernet?) driver into its CPU tag. The DSA taggers were
designed to decouple CPU tag from ethernet driver logic and upstream
maintainters might ask to implement each CPU tagger as a proper DSA
tag. Although it might not make sense to have an ethernet driver
without a tag in this target, it would get closer to how outer drivers
work and make it easier to understand the driver.

Regards,

Luiz

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

Re: Some Modest Virtualization Observations

[Luiz Angelo Daros de Luca]

> When reading https://openwrt.org/docs/guide-user/virtualization/start it
> is clear this hasn't seen much love.  Several portions seemed to
> exclusively target developers and not really be meant for serious use.
> As such I was unsurprised to discover:
> https://openwrt.org/docs/guide-developer/start#testing_openwrt_in_a_virtual_machine
> Which is exactly the same information in the developer guide.  This area
> seems to need work.
>
> One obvious problem is mixing Docker and LXC with virtualization.  These
> are useful for very basic testing, but they cannot handle many types of
> testing which VMs can do.
>
> It is notable `xm` was deprecated by the Xen Project and was replaced
> with `xl`.  `xm` had completely disappeared by 2019 and was on its way
> out by 2018.
>
> Both examples are also using older boot methods.  If you're doing a new
> setup, you likely want to use PvGRUB.  PyGRUB is semi-deprecated (PvGRUB
> is far superior on x86, not yet available on other arches) while direct
> kernel boot is more often used to load PvGRUB or EDK2 as a bootloader.
>
>
>
> The image directly under "Where is my router?":
> https://openwrt.org/docs/guide-user/virtualization/virtualbox-advanced#where_is_my_router
> makes me wonder whether the creater of the image had an interesting
> insight.
>
> A useful capability of modern hypervisors is the ability to pass hardware
> devices (notably PCI and USB) into a VM.  I've confirmed Xen, Bhyve and
> KVM have this capability.  I would be surprised if any other hypervisor
> doesn't have the capability, if appropriate hardware is available
> (notably an IOMMU).
>
> How exactly you do this will vary from hypervisor to hypervisor.  The
> basic idea though is the hypervisor removes/hides a device from the
> supervisor VM, and installs it into another VM.  This can be done with
> most devices, notably graphics cards, ethernet NICs and 802.11 cards.
>
> The fun bit is, what happens if you have a hypervisor machine with a
> spare ethernet NIC and 802.11 card, not being used for any other purpose?
> On such a machine you could run OpenWRT in a VM.  One NIC being the
> physical ethernet interface.  One NIC being the 802.11 interface.  Then a
> last interface going to the hypervisor's internal software switch.
>
> Thing is this has all the characteristics of a serious use of OpenWRT.
> If the physical ethernet interface connects to your ISP, it can handle
> NAT for both 802.11 devices and everything on the network.  The only
> difference being this merely uses /part/ of a high-powered computer,
> rather than all of an embedded device.
>
> Certainly not my intended target, but imagining a Hyper-V system using
> OpenWRT to handle the upstream connection seems an interesting idea.
>
>
> The problems I forsee with this setup revolve around the choices made for
> OpenWRT which are appropriate for embedded devices, but inappropriate for
> dynamic systems.
>
> Notably much of OpenWRT is based on knowning more about the platform
> ahead of time.  Whereas when running on a hypervisor, most drivers should
> be dynamically loaded.  Except much of that support is stripped out by
> OpenWRT to reduce kernel size.

Yes, docs are quite outdated, mostly because everything now runs out
of the box. The x86/64 target does not have the embedded restrictions
in mind and the kernel has all VM drivers for most hypervisors
built-in (see: 
https://github.com/openwrt/openwrt/blob/master/target/linux/x86/64/config-5.15).
It's just like any other modern appliance.

I run openwrt both in test and production using xen, qemu and
virtualbox and there is not much extra TODOs other than use the image
as a virtual disk, add some virtual NICs and have fun. The extra tips
also applies to any x86 target like "resize your image and its
partitions before flashing/upgrading if you need more room" or "a
custom grub, like from sles xen, might look for a config at a
different path (/boot/grub vs /boot/grub2)". Hyper V might work out of
the box, but I never used it.

The docs are in a wiki and you might be able to update it. It might
have rotten because nobody really needs it anymore. However, if you
looked for it and it didn't answer your questions, you are in the best
position to add those extra questions and answers to the docs and
delete outdated stuff. We are mostly volunteers that just scratch
where it itches.

Regards,

Luiz

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

Re: Ethernet switch with linux/openwrt and DSA

[Luiz Angelo Daros de Luca]

> Thanks all!
> Finally buy: D-LINK DGS-1210-48 G1.
>
> U-Boot 2011.12.(2.1.5.67086)-Candidate1 (Apr 13 2017 - 13:58:11)
>
> Board: RTL839x CPU:700MHz LXB:200MHz MEM:400MHz
> DRAM:  128 MB
> SPI-F: 1x32 MB
>
> Next:
>  - connected serial cable
>  - stop in uboot
>  - boot from 
> tftp/openwrt-realtek-rtl839x-d-link_dgs-1210-52-initramfs-kernel.bin
>  - next simple scp/sysupgrade
> openwrt-realtek-rtl839x-d-link_dgs-1210-52-squashfs-sysupgrade.bin


Great news! Interesting, is it the same model as 1210-52 but with the
extra ports as non combo? Or are SFP+ still combo ports with 45-48
ports? Currently 49-52 they are disabled in -52 variant but they might
introduce a problem if someone gets that fixed and they are missing in
your device. Ports are statically defined in the DTS file and they
might brick the device if missing.

Did you try the image1 firmware? It should work from the web interface
but you need to write it to the image1, not image2 slot. If it is that
close to F1 series, might be able to dual boot the device back to the
original firmware. If that doesn't work, we might need to change some
flags in the dlink image generator. Is the original firmware shared
between -f1 and -g1 series?

I would include a new DTS file/firmware generation, even if it only
includes/copies -52 variant. It would make the lives of newcomers much
easier.

>
> root@OpenWrt:~# ubus call system board
> {
> "kernel": "5.10.156",
> "hostname": "OpenWrt",
> "system": "RTL8393",
> "model": "D-Link DGS-1210-52",
> "board_name": "d-link,dgs-1210-52",
> "rootfs_type": "squashfs",
> "release": {
> "distribution": "OpenWrt",
> "version": "SNAPSHOT",
> "revision": "r21432-4c0919839d",
> "target": "realtek/rtl839x",
> "description": "OpenWrt SNAPSHOT r21432-4c0919839d"
> }
> }
> root@OpenWrt:~#

Regards,

Luiz

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

Re: Ethernet switch with linux/openwrt and DSA

[Luiz Angelo Daros de Luca]

>
>
> > D-Link DGS-1210-48 HW Ver. G1 - will be fine? I need some confirmation.
> > Anyone could confirm?
>

D-Link DGS-1210-52 F does work in snapshot. You'll need to wait for
the next 23.x for a stable release.
I think there is only one switch with >=48 ports supported in 22.03:
zyxel gs1900. And even that one might be missing some fixes current in
the master branch.

I would recommend to search for a switch with less ports or wait for
the 23.x release.

Regards,

Luiz

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

Re: [RFC] dropping of $(AUTORELEASE) feature

[Luiz Angelo Daros de Luca]

I know that autorelease has introduced some problems but it would be
good to keep a way to automatically bump releases. Every second we
could save from devs/maintainers is more time to do really useful
things.

Can't we have a central way to publish the "official list of package
releases''? It could be a file inside the git, but automatically
updated by a bot when we build packages for publishing. Any local
changes (git can track them without a history) or local commit will
introduce some "dirty tag" to the release number, similar to what
already happens with the openwrt build number (r+x-abcdef). For
example:

foo-1.3-34 (oficial built)
foo-1.3-34.2.abcd12ef+ ("2" local commits being the last one
"abcd12ef" and some extra ("+") uncommited changes)
foo-1.3-34+ (package with some extra ("+") uncommited changes)

If we have reproducible builds, we could bump that release only when
the final binary differs from the last one, skipping cosmetic changes
that do not change the final package but including external ones that
affect one or more packages. It would even avoid bumping subpackages
when the source changes when only some of them really changed.

If that would add too much noise to the history, that same official
list of packages could be published somewhere else. For example, it
could have a file with a list of commits on each branch and the
corresponding "official list of package releases". Something like:

master:
b97e5ac785960c13199239dd4821dd53f3801da3 master-0454
6f729163b18fb5860f1aa5a5a0c8861a8e3f53ad master-0454 <<< built bot
published this one
9179f484bfcb37e1c59e736b2a64c9583eb00356 master-0453
...

master-454:
foo-1.3 34
bar-1.2 45
...

The client would download that list and iteratively look for the last
commit that is found in the list and download the official list of
packages. Count the commits since that commit used for publishing
(including those in the master file or local history) and adjust the
releases. If someone checks out a tagged commit or one used to publish
packages, all releases will match the official one. If not, it will
use some extra release numbers.

There might be a lot of improvements, like sorting the commit list,
plenty of different solutions that solve this problem and maybe some
of them already exist in other build solutions (like OBS). I just
don't like the idea of returning to manual management.

Regards,

Luiz

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

Re: Security changes - restricting uhttpd addresses

[Luiz Angelo Daros de Luca]

> The default uhttpd configuration has this:
>
> # HTTP listen addresses, multiple allowed
> list listen_http0.0.0.0:80
> list listen_http[::]:80
>
> Now, I know there's lots of practical reasons for this to be the case,
> and I know also that the firewall setup in OpenWrt is robust and
> isn't going to allow WAN-side access.
>
> Nevertheless, the security people are looking at this config
> statically, and not seeing that it's bound to the LAN interface IP
> only.

It might be easy to bind to the LAN interface in a simple product but
OpenWrt might have multiple interfaces.
It is much easier to let the firewall zones deal with that.

> As aside, they don't see the iptables tool in the system, and don't
> understand that that's been deprecated (although I since did add it
> for some unrelated legacy usage), and think there's no firewall at all.

22.03? Did you read the release notes? nftables.

> For my use, I've changed the default binding to the LAN IP, and also
> added another init.d script to check the current LAN address, and
> update the uhttpd config if need be and then restart it (and add
> a config hook to the network config). Obviously this isn't
> very satisfactory, open to better suggestions here.

It would be better to improve the uhttpd startup script, allowing it
to bind to a list of openwrt interfaces. It is always better to
reference an existing config than to duplicate it.
Or leave the original bind address.

> It might also be better if uhttpd could be configured to bind
> to a specific interface rather than knowing its IP upfront, but
> that might be impractical.

No, there are dozens of services that do just that.

Regards,

Luiz

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

Re: [PATCH] realtek: fix RTL839x receive tag decoding

[Luiz Angelo Daros de Luca]

> > The previous fixup was incomplete, and the offsets for the
> > queue and crc_error cpu_tag bitfields were still wrong on
> > RTL839x.
> >
> > Fixes: 545c6113c93b ("realtek: fix RTL838x receive tag decoding")
> > Suggested-by: Jan Hoffmann 
> > Signed-off-by: Bjørn Mork 
> > ---
> > Jan pointed put that I missed two fields on the RTL839x. Sloppy. Fix
> > those as well.
> >
> > This time even without complaints from checkpatch :-)
> >
> > But build tested only.  I don't have any 839x and I don't know how
> > to verify these features anyway.
>
> +CC Andreas, Hiroshi, Luiz, Markus as rtl839x users.

I was hoping this would fix the missing vlan tag for traffic that goes
through the switch.
I just tested https://github.com/openwrt/openwrt/pull/10643 rebased on
current master
and the issue is the same: tagged vlan to tagged vlan forwarded by the
switch is sent untagged while tagged traffic that goes
to/from the CPU works as expected. It does not seem to be related to
the received tag. It looks like the tag
is added correctly by the CPU but the switch is not configured
correctly to add a tag for traffic to a specific vlan.
I would bet it is the internal switch vlan setup, not the linux side.

BTW, it might be time to merge that PR as, AFAIK, this vlan issue
affects the SoC, not that specific device.

Regards,

Luiz

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

Re: DSA Mini-tutorial still marked as Work In Progress

[Luiz Angelo Daros de Luca]

> - Bridge device "br-vlan10" containing "lan1.10 lan2.10 lan3.10"
>   - VLAN filtering disabled


Bridging virtual 802.1q interfaces might fail in some scenarios, like
when you use vlan1 or mix tagged with untagged traffic
(https://github.com/openwrt/openwrt/issues/9066)
I do recommend bridge-vlan as the first option, although ip-bridge is
not installed by default.

I know that it is a little bit off topic but I would love some
transitioning code that could mimic swconfig devices as if they were
DSA. Instead of using swconfig settings for tagged vlans/isolated
ports, just create fake lan1, lan2, wan interfaces (802.1q) and derive
the swconfig settings from that. I've been doing that for some time,
creating switch_vlan configs from bridge+bridge-vlan and replacing the
user ports with the CPU port in every related bridge-vlan. This way I
can share the config with swconfig, DSA and even devices without
switches (VM like gns3) if I rename eth0, eth1, eth2 to lan1, wan,
lan2. The only downsides are that untagged bridging is done using
software bridge and the config is generated as a single-shot step
(uci-default). However, if that mapping is done inside netifd, I
believe it might be able to better handle those cases.

Regards,

Luiz

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

Re: [PATCH 6/7] tools: add 7z host package

[Luiz Angelo Daros de Luca]

> On Sun, Jul 31, 2022 at 03:36:32PM +0200, Sander Vanheule wrote:
> > On Sat, 2022-07-23 at 22:53 +0200, Jan Hoffmann wrote:
> > > Add the 7zr command line tool, which is a version of the 7z application
> > > that only supports 7z archives.
> > >
> > > 7z is one of the two compression formats supported in H3C firmware
> > > images (the alternative would be ARJ).
> > >
> > > (Alternatively, the 7zr command line tool could also be built from a
> > > current version of the public-domain LZMA SDK. That would require
> > > repackaging the source package, as it is only provided in 7z format.)
> > >
> > > Signed-off-by: Jan Hoffmann 
> >
> > This caused builds to fail on systems with GCC 12 (Arch, Fedora 36).
>
> Strange, I'm on archlinux with gcc 12.1.0 and it worked for me.
> Maybe it only fails in silent mode when warnings are treated as errors?
>
> Anyway, thanks for taking care of that!

It seems the issue is back. Tested with OpenSUSE Tumbleweed 20220813,
gcc (SUSE Linux) 12.1.1 20220721 [revision
4f15d2234608e82159d030dadb17af678cfad626],
even with 7z 22.01 version:

cc x86_64 -O2 -c -Wall -Werror -Wextra  -DNDEBUG -D_REENTRANT
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -f
PIC  -o _o/7zStream.o ../../../../C/7zStream.c
cc: warning: x86_64: linker input file unused because linking not done
cc: error: x86_64: linker input file not found: No such file or directory
make[3]: *** [../../7zip_gcc.mak:1070: _o/7zStream.o] Error 1

Regards,

Luiz

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

Re: [RFT 0/5] realtek: support boards similar to DGS-1210-10

[Luiz Angelo Daros de Luca]

Em dom., 17 de jul. de 2022 06:55, Paul Fertser  escreveu:
>
> On Sat, Jul 16, 2022 at 11:32:52PM -0300, Luiz Angelo Daros de Luca wrote:
> > It uses SOC := rtl8380 while all existing dgs-1210 F1 variants use
> > rtl8382 (except for the pending -52 variant). The commit didn't
> > mention why that happened.
>
> It's just cosmetic AFAICT but the datasheet clearly states that the
> SoC used for <=18 ports switches is called RTL8380.

It seems we have multiple SoCs for DGS-1210:

1) RTL8380 for -10
2) RTL8382 for -28
3) RTL8393 for -52

It is not the best approach to include a shared config and redefine a
property. The dgs-1210 definition should go in Makefile (we also have
an rtl8393) with only common properties and SoC should be defined by
each device. I was preparing something like that for -52 here:

https://github.com/openwrt/openwrt/pull/10227/commits/8e5b473bc1f7f1a8ad796e8b8cc7587fedbad9f5

>
> > I'm not sure which one is correct here. However, if it is really a
> > different SoC and with what we currently know, we could create a
> > generic rtl83xx_d-link_dgs-1210.dtsi as the -52 variant uses even a
> > more different SoC (rtl8393). They share a lot of stuff like flash
> > layout and gpios (and the vendor firmware even uses the same image). I
> > could do some generic and family review but I only have -28 and -52
> > variants.
>
> I only have access to non-PoE dgs-1210-10 R1 board.
>
> You say they share GPIO layout, does it mean you currently can't fully
> handle SFP ports on your hardware but my patches make it work?

I believe the same setup might work for any dgs-1210 F series. It
makes sense as d-link uses a common firmware for Fx-Series. However, I
didn't test SFP patches in my -28 because I lost all my 1g modules a
couple years ago and 10g modules don't work. Anyway, the -52 variant
does seem to share the same GPIOs, even using a different SoC. Besides
reboot, reset button and led, I could only test the pin that detects
the module presence. All of them match those same pins used by other
variantes. I would expect that the remaining SFP pins are also at the
same positions. I only tried SFP patches to fix (it didn't) the combo
ports initialization in the -52 model, although they might touch
another part of the driver not used by that device (as it uses
different SoC).


>
>
> --
> Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
> mailto:fercer...@gmail.com

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

Re: [RFT 0/5] realtek: support boards similar to DGS-1210-10

[Luiz Angelo Daros de Luca]

> On Tue, 2021-10-05 at 22:40 +0300, Paul Fertser wrote:
> > I only have D-Link DGS-1210-10P R1 for testing but other devices should be
> > very
> > similar judging by the photos. Would be nice to share support for all the
> > features available rather than get just R1 fully working.
> >
> > Paul Fertser (5):
> >   realtek: split DGS-1210-10P DTS
> >   realtek: add all LEDs, buttons and SFP signals to DGS-1210-10
> >   realtek: add non-PoE version of DGS-1210-10 F1
> >   realtek: support D-Link DGS-1210-10P H/W:R1
> >   realtek: support Trendnet TPE-082WS V1
>
> Recently you two have provided some patches for the DGS-1210 switches, and you
> apear to have a nice collection of different devices. I would like to draw 
> your
> attention to these (old) patches, with some improvments Paul suggested. Sadly
> nobody showed up to test them at the time. I was wondering if these changes 
> are
> still relevant and if you could have a look at them.

I didn't have any DGS-1210 switches back then. Now I have hundreds.

It looks like an interesting submission, still relevant but it
requires a v2 rebasing and with the suggested changes.

It uses SOC := rtl8380 while all existing dgs-1210 F1 variants use
rtl8382 (except for the pending -52 variant). The commit didn't
mention why that happened.
I'm not sure which one is correct here. However, if it is really a
different SoC and with what we currently know, we could create a
generic rtl83xx_d-link_dgs-1210.dtsi as the -52 variant uses even a
more different SoC (rtl8393). They share a lot of stuff like flash
layout and gpios (and the vendor firmware even uses the same image). I
could do some generic and family review but I only have -28 and -52
variants.

> The different patches can be found at, and downloaded from:
> https://patchwork.ozlabs.org/project/openwrt/list/?series=265587=*
>
> In case you weren't subscribed to the mailing list at the time and you would
> like to reply to one of the patches, they can be downloaded from patchwork in
> mbox format and imported into a mail client.
>
> Best,
> Sander


Regards,

Luiz

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

Re: Help with testing needed [Was: Re: [PATCH 1/3] ramips: ethernet: ralink: mt7620 jumbo frame support]

[Luiz Angelo Daros de Luca]

 > >
> > Hi Andrey,
> >
> > > It simple a) don't apply to master tree; b) not working - MAX_RX_LENGTH 
> > > constant not
> > > touched, GSW_REG_GMACCR not tweaked for accepting jumbo frames.
> >
> > a) Sorry, I missed your answer and thanks for the review. Yes, it was
> > not applying to master. It was based on another patch deeper in my
> > tree. I fixed that a long time ago but I postponed the fix as I didn't
> > see any interest from ML (I was wrong). I was focusing on upstream
> > patches (realtek dsa switches merged into 5.18) and postponed the
> > ramips fixes for when they would be needed.
> >
> > b) MAX_RX_LENGTH seems to be used only for keeping the buffer at least
> > over (MAX_RX_LENGTH - FE_RX_ETH_HLEN) and it does not care when mtu is
> > actually even bigger than (MAX_RX_LENGTH - FE_RX_ETH_HLEN). See:
>
> MAX_RX_LENGTH affects buffers for DMA transfers.

Is it because when you unconditionally enable jumbo frames in switch,
you need to prepare the ethernet driver to receive a larger frame,
even when mtu is 1500 or smaller?

>
> > c) MAX_RX_JUMBO and MAX_RX_PKT_LEN in GSW_REG_GMACCR are switch regs
> > while I touched only ethernet frame engine regs.
>
> There are two parts - FE and switch. And both need to be properly programmed.
>
> Attached patch tested on real MT7620 with internal switch and it is
> able to operate with a 2048-bytes frame (included single VLAN tag).

Are you ignoring CONFIG_SOC_MT7621 support for this driver? (it is
indeed upstream for recent kernels).

The patch worked as expected! Thanks a lot! Do you plan to submit it?

Tested-by: Luiz Angelo Daros de Luca 

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

Re: Help with testing needed [Was: Re: [PATCH 1/3] ramips: ethernet: ralink: mt7620 jumbo frame support]

[Luiz Angelo Daros de Luca]

Hi Andrey,

> It simple a) don't apply to master tree; b) not working - MAX_RX_LENGTH 
> constant not
> touched, GSW_REG_GMACCR not tweaked for accepting jumbo frames.

a) Sorry, I missed your answer and thanks for the review. Yes, it was
not applying to master. It was based on another patch deeper in my
tree. I fixed that a long time ago but I postponed the fix as I didn't
see any interest from ML (I was wrong). I was focusing on upstream
patches (realtek dsa switches merged into 5.18) and postponed the
ramips fixes for when they would be needed.

b) MAX_RX_LENGTH seems to be used only for keeping the buffer at least
over (MAX_RX_LENGTH - FE_RX_ETH_HLEN) and it does not care when mtu is
actually even bigger than (MAX_RX_LENGTH - FE_RX_ETH_HLEN). See:

target/linux/ramips/files/drivers/net/ethernet/ralink/mtk_eth_soc.c:
static inline int fe_max_frag_size(int mtu)
{
   /* make sure buf_size will be at least MAX_RX_LENGTH */
   if (mtu + FE_RX_ETH_HLEN < MAX_RX_LENGTH)
   mtu = MAX_RX_LENGTH - FE_RX_ETH_HLEN;

   return SKB_DATA_ALIGN(FE_RX_HLEN + mtu) +
   SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
}

static inline int fe_max_buf_size(int frag_size)
{
   int buf_size = frag_size - NET_SKB_PAD - NET_IP_ALIGN -
  SKB_DATA_ALIGN(sizeof(struct skb_shared_info));

   BUG_ON(buf_size < MAX_RX_LENGTH);
   return buf_size;
}

Does this logic need to be updated somehow for jumbo or even non jumbo frames?

c) MAX_RX_JUMBO and MAX_RX_PKT_LEN in GSW_REG_GMACCR are switch regs
while I touched only ethernet frame engine regs. For me, the switch
was happily forwarding frames with 8 extra bytes (DSA tag). In my
device, the internal switch was being used as a transparent switch (no
vlan), connecting to an external switch (RTL8367S) through the RGMII
interface. Maybe the small increase was still falling into an accepted
frame size range (for the switch), the RGMII interface might have a
less restricted access or disabling vlans also makes the switch more
tolerant to larger frames. The FastEthernet ports are not used in my
device so extra bytes might need to come from the RTL8367S DSA switch,
which currently does not support increasing the MTU of slave ports. I
cannot easily generate incoming frames larger than 1508.

I wonder if it is the ethernet driver's responsibility to increase the
switch frame size or if it is the switch driver (swconfig or DSA). It
might not only affect the CPU port but any traffic between ports. I'm
not very comfortable touching a piece of code I cannot really test. If
a dev does have access to a mt7620 device that actually uses its
ports, it might be easier for that dev to go ahead and fix it himself.
The patch is as simple as:

#ifdef CONFIG_SOC_MT7620
   if ( > 1536) {
  // set MAX_RX_JUMBO as 2k
  GSW_REG_GMACCR |= 0x2 << 2
  // set MAX_RX_PKT_LEN as MAX_RX_JUMBO
  GSW_REG_GMACCR |= 0x3
   }
#endif

It might be inserted into the same place fe_max_frag_size is called in
fe_change_mtu() but I'm not sure how it would interact with other non
MT7621 SoCs.

I wonder why MT7621 does not seem to bother the extra bytes. Anyway,
the patch is a step further and it is still required and enough for an
external DSA switch.
The extra GSW_REG_GMACCR tweaks, if needed, might be added in the
future. I'll wait a couple of days to settle this thread and resubmit
a master-compatible v2 (just a minor fix you pointed out) with an
extra patch for disabling checksum offload when the DSA tag is not
Mediatek.

Regards,

Luiz

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

Re: [PATCH 19.07 v2 0/3] wolfssl security updates

[Luiz Angelo Daros de Luca]

> I've started to look at the first vulnerability, but it is not as
> straightforward as I was hoping.  Perhaps Luiz Angelo Daros de Luca,
> reporter and author of the fixes, can help me out with this.

Sure. And I do have interest in getting it fixed. It is both a
security fix (when it does not block what it should) and a bug fix
(when it blocks what it shouldn't). It affects special certificates
with multiple name constraints, used mostly to limit the power of an
internal CA. It is normally not used in public CA.

The fix is a drop-in replacement for the validation function
ConfirmNameConstraints() and a small applicable change to
MatchBaseName(). There are some required commits to get that change
cleanly applied and I don't think it is worth it (a55e94cf6f touches
almost all the tree). I think you can use this standalone backport:

https://github.com/luizluca/wolfssl/commit/ede75f0f0618243147ad8315b8c059ce77c751e7

When applied to 4.7.0, it will have the same final result for
ConfirmNameConstraints() and MatchBaseName() as the upstream patch.

Regards,

Luiz

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

[PATCH 2/3] ramips: ethernet: ralink: fix MT7620A_GDMA regs

[Luiz Angelo Daros de Luca]

Registers in MT7620A_GDMA_OFFSET range were incorrect, except for the
first one GDM_FWD_CFG (which is actually the only one in use).
The next and last register is GDM_SHPR_CFG. All others are not mentioned
in docs.

Signed-off-by: Luiz Angelo Daros de Luca 
---
 .../ramips/files/drivers/net/ethernet/ralink/mtk_eth_soc.h   | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git 
a/target/linux/ramips/files/drivers/net/ethernet/ralink/mtk_eth_soc.h 
b/target/linux/ramips/files/drivers/net/ethernet/ralink/mtk_eth_soc.h
index 968db366cf..6b81946e30 100644
--- a/target/linux/ramips/files/drivers/net/ethernet/ralink/mtk_eth_soc.h
+++ b/target/linux/ramips/files/drivers/net/ethernet/ralink/mtk_eth_soc.h
@@ -152,10 +152,7 @@ enum fe_work_flag {
 #define MT7620A_GDMA_OFFSET0x0600
 #endif
 #defineMT7620A_GDMA1_FWD_CFG   (MT7620A_GDMA_OFFSET + 0x00)
-#define MT7620A_FE_GDMA1_SCH_CFG   (MT7620A_GDMA_OFFSET + 0x04)
-#define MT7620A_FE_GDMA1_SHPR_CFG  (MT7620A_GDMA_OFFSET + 0x08)
-#define MT7620A_FE_GDMA1_MAC_ADRL  (MT7620A_GDMA_OFFSET + 0x0C)
-#define MT7620A_FE_GDMA1_MAC_ADRH  (MT7620A_GDMA_OFFSET + 0x10)
+#define MT7620A_FE_GDMA1_SHPR_CFG  (MT7620A_GDMA_OFFSET + 0x04)
 
 #define MT7620A_RESET_FE   BIT(21)
 #define MT7620A_RESET_ESW  BIT(23)
-- 
2.34.0


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

[PATCH 1/3] ramips: ethernet: ralink: mt7620 jumbo frame support

[Luiz Angelo Daros de Luca]

mt7620 can forward jumbo frames. The fe_change_mtu() was already
compatible except for the GDM_FWD_CFG address.

An MTU greater than 1500 is required to use DSA tags with a stacked
switch chip.

Signed-off-by: Luiz Angelo Daros de Luca 
---
 .../files/drivers/net/ethernet/ralink/mtk_eth_soc.c | 13 ++---
 .../files/drivers/net/ethernet/ralink/soc_mt7620.c  |  3 ++-
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git 
a/target/linux/ramips/files/drivers/net/ethernet/ralink/mtk_eth_soc.c 
b/target/linux/ramips/files/drivers/net/ethernet/ralink/mtk_eth_soc.c
index 8b57a3cc9a..be2ee6ba7f 100644
--- a/target/linux/ramips/files/drivers/net/ethernet/ralink/mtk_eth_soc.c
+++ b/target/linux/ramips/files/drivers/net/ethernet/ralink/mtk_eth_soc.c
@@ -1458,6 +1458,13 @@ static int fe_change_mtu(struct net_device *dev, int 
new_mtu)
struct fe_priv *priv = netdev_priv(dev);
int frag_size, old_mtu;
u32 fwd_cfg;
+   u32 fwd_reg;
+
+#ifdef CONFIG_SOC_MT7620
+   fwd_reg = MT7620A_GDMA1_FWD_CFG;
+#else
+   fwd_reg = FE_GDMA1_FWD_CFG;
+#endif
 
old_mtu = dev->mtu;
dev->mtu = new_mtu;
@@ -1482,7 +1489,7 @@ static int fe_change_mtu(struct net_device *dev, int 
new_mtu)
 
fe_stop(dev);
if (!IS_ENABLED(CONFIG_SOC_MT7621)) {
-   fwd_cfg = fe_r32(FE_GDMA1_FWD_CFG);
+   fwd_cfg = fe_r32(fwd_reg);
if (new_mtu <= ETH_DATA_LEN) {
fwd_cfg &= ~FE_GDM1_JMB_EN;
} else {
@@ -1491,7 +1498,7 @@ static int fe_change_mtu(struct net_device *dev, int 
new_mtu)
fwd_cfg |= (DIV_ROUND_UP(frag_size, 1024) <<
FE_GDM1_JMB_LEN_SHIFT) | FE_GDM1_JMB_EN;
}
-   fe_w32(fwd_cfg, FE_GDMA1_FWD_CFG);
+   fe_w32(fwd_cfg, fwd_reg);
}
 
return fe_open(dev);
@@ -1610,7 +1617,7 @@ static int fe_probe(struct platform_device *pdev)
 
 
if (IS_ENABLED(CONFIG_SOC_MT7620))
-   netdev->max_mtu = 1508;
+   netdev->max_mtu = 2048;
if (IS_ENABLED(CONFIG_SOC_MT7621))
netdev->max_mtu = 2048;
 
diff --git a/target/linux/ramips/files/drivers/net/ethernet/ralink/soc_mt7620.c 
b/target/linux/ramips/files/drivers/net/ethernet/ralink/soc_mt7620.c
index 42685eebc3..8c43e6d78f 100644
--- a/target/linux/ramips/files/drivers/net/ethernet/ralink/soc_mt7620.c
+++ b/target/linux/ramips/files/drivers/net/ethernet/ralink/soc_mt7620.c
@@ -345,7 +345,8 @@ static void mt7620_init_data(struct fe_soc_data *data,
struct fe_priv *priv = netdev_priv(netdev);
 
priv->flags = FE_FLAG_PADDING_64B | FE_FLAG_RX_2B_OFFSET |
-   FE_FLAG_RX_SG_DMA | FE_FLAG_HAS_SWITCH;
+   FE_FLAG_RX_SG_DMA | FE_FLAG_HAS_SWITCH |
+   FE_FLAG_JUMBO_FRAME;
 
netdev->hw_features = NETIF_F_IP_CSUM | NETIF_F_RXCSUM |
NETIF_F_HW_VLAN_CTAG_TX;
-- 
2.34.0


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

[PATCH 3/3] ramips: ethernet: ralink: mtu change while interface is down

[Luiz Angelo Daros de Luca]

fe_change_mtu didn't update the registers if the interface was down.

DSA increases the CPU port MTU to accommodate the CPU tag. As this
happens while the CPU port was still down, the chip regs didn't get
updated and larger frames were dropped.

Signed-off-by: Luiz Angelo Daros de Luca 
---
 .../files/drivers/net/ethernet/ralink/mtk_eth_soc.c| 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git 
a/target/linux/ramips/files/drivers/net/ethernet/ralink/mtk_eth_soc.c 
b/target/linux/ramips/files/drivers/net/ethernet/ralink/mtk_eth_soc.c
index be2ee6ba7f..0ae520183b 100644
--- a/target/linux/ramips/files/drivers/net/ethernet/ralink/mtk_eth_soc.c
+++ b/target/linux/ramips/files/drivers/net/ethernet/ralink/mtk_eth_soc.c
@@ -1484,10 +1484,9 @@ static int fe_change_mtu(struct net_device *dev, int 
new_mtu)
priv->rx_ring.frag_size = PAGE_SIZE;
priv->rx_ring.rx_buf_size = fe_max_buf_size(priv->rx_ring.frag_size);
 
-   if (!netif_running(dev))
-   return 0;
+   if (netif_running(dev))
+   fe_stop(dev);
 
-   fe_stop(dev);
if (!IS_ENABLED(CONFIG_SOC_MT7621)) {
fwd_cfg = fe_r32(fwd_reg);
if (new_mtu <= ETH_DATA_LEN) {
@@ -1501,7 +1500,10 @@ static int fe_change_mtu(struct net_device *dev, int 
new_mtu)
fe_w32(fwd_cfg, fwd_reg);
}
 
-   return fe_open(dev);
+   if (netif_running(dev))
+   return fe_open(dev);
+
+   return 0;
 }
 
 static const struct net_device_ops fe_netdev_ops = {
-- 
2.34.0


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

mt7620 tests with DSA switch, problem with mtk_eth_soc MTU

[Luiz Angelo Daros de Luca]

Hello,

I'm testing a device with mt7620 with rtl8367s switch with DSA. I
modified the upstream DSA driver for rtl8365mb (kernel 5.15..5.16) to
support rtl8367s with a mdio interface. Although the upstream driver
does not have any offload feature (switching is done in CPU), it is
working fine. I might soon submit those patches upstream.

However, I have some issues with the mt7620 ethernet.  I disabled vlan
for the mt7620 internal switch (mt7530?) by removing the
mediatek,portmap property as it is just used to connect the CPU to the
rtl8367s switch though a gigabit connection. swconfig is still working
but not used.

There is an upstream driver for mediatek ethernet but it looks like it
does not support the mt7620. So, I'm using the one provided by
OpenWrt.

The issue is with MTU. Once DSA is up, it tries to increase the
interface MTU by 8 bytes (1508) to fit the Ethertype DSA tag (rtl8_4).
However, mtk_eth_soc does not accept that and it fails. I hacked the
driver to pass that test (netdev->max_mtu = 1508) but I still get
packets dropped.

I can see the outbound traffic working as expected even with the
802.1Q tag. So, the mt7530 switch is not the issue. However, when I
receive the inbound traffic, any ethernet payload (also considering
the DSA tag) that is over 1500 bytes (frame size 1514) is dropped. The
netdev->max_mtu field seems to be just a software control of what the
driver would accept but it looks like this driver simply ignores any
mtu increases. Does anyone have a suggestion?

I wonder how 802.1Q worked with swconfig... is the 802.1Q tag inserted
in a lower layer than DSA tags, before the MTU limit is in place?

Another issue is with checksum offload. After DSA was in place,
checksum stopped working. For now, I'm disabling it with "ethtool
--offload eth0 tx off" but it would be nice to have it back.

Regards,

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

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

Re: [RFC] Stop providing binary package updates for release builds?

[Luiz Angelo Daros de Luca]

The package update is not a perfect solution but it is better to have
it as is than to remove it.

Updated packages are also used by imagebuilder and attended
sysupgrade. I normally generate a new image to apply updates because
some devices cannot afford the extra installation. If we need updated
packages for those cases, there is no reason to not publish them. If
server resources are the problem, we should ask for help with more
resources or reduce the build frequency but not stop it. Please, keep
the repo packages updated.

Reflashing is a delicate operation for remote devices and I need to
prepare a long maintenance window (and I have dozens of remote
locations). For security issues, I always evaluate if I need to
reflash the device or if I can update just that package, especially if
it will not affect the endusers operation. For x86 targets, I normally
use much more package upgrade than reflash. Please, also keep opkg
upgrade feature.

I have no problem if there was an automated monthly, weekly or even
daily dot release with all updates. However, a reflash is a complex
operation for anyone with some extra packages and files and an
extremely complex one when extroot is in use.
This will consume more from our (specialist enduser) time, not a
non-technical enduser (they will probably not upgrade the router by
themselves anyway).

The package upgrade has issues. One of them is that an update can
break the system, normally those with small flashes. It would be nice
if opkg could revert to the previous state when it fails (it also
happens with opkg install).

The attended sysupgrade service is a nice feature but it removes the
ability to uninstall a package after an upgrade (and it does not work
with extroot). I would prefer a solution where the extra packages were
appended to the backup
file or downloaded after reboot (if we could detect which packages are
not required to connect to the internet). And moving a package from
overlay to squashfs might introduce issues with hotplug scripts
(however, that is another issue that should be fixed).
Anyway, without a very frequent dot release or a repo with updates,
attended sysupgrade is not a good replacement for updates.

When there are pending updates, either a package or even a new image,
it is not easy to know that and what was fixed. The user has no known
reason for updates. For a package, repos could provide a
.changelog file, even if it was a simple raw git log. For images,
it would be nice if a service like the "attended upgrade" could
summarize a custom changelog for that device, with some red ink for
security issues.

Packages that provide kernel modules are always broken when they are
updated in repo. This happens because the kernel (or its config) in
the stable branch is a moving target, introducing a different kernel
dependency. Buildbot always builds
with the latest SDK (and kernel), which will generate kmod packages
not compatible with any released images. The current workaround is to
postpone those package commits until a new dot release is about to be
released and manually merge them. The real solution would be to
compile package mods also for each released SDK.

I think the "use another downstream distribution" is the worst option
by far. It simply hopes that different subgroups will independently
solve the same OpenWrt issues (multiple times) and using less
resources than solving them inside OpenWrt. It does not make any sense
for me. It is just asking for that "other downstream distribution" to
become the "de facto" new OpenWrt. I know it is not nice to maintain
old releases but it is part of what a good Linux distribution should
do. The reason for an OSS project is its users and reduce the number
of users never helped an OSS project.

I hope some day OpenWrt will be able to provide an trusted automated
update system just like any decent OS and stopping to providing binary
package updates for release builds just goes backwards this path.

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

Re: [PATCH 1/2] interface-ip: copy more info for target host route

[Luiz Angelo Daros de Luca]

> > @@ -301,9 +301,26 @@ interface_ip_add_target_route(union if_addr *addr, 
> > bool v6, struct interface *if
> >   route->mask = v6 ? 128 : 32;
> >   memcpy(>addr, addr, addrsize);
> >   memcpy(>nexthop, _next->nexthop, sizeof(route->nexthop));
> > - route->mtu = r_next->mtu;
> > - route->metric = r_next->metric;
> > - route->table = r_next->table;
> > + if (r_next->flags & DEVROUTE_MTU) {
> > + route->mtu = r_next->mtu;
> > + route->flags |= DEVROUTE_MTU;
> > + }
> > + if (r_next->flags & DEVROUTE_METRIC) {
> > + route->metric = r_next->metric;
> > + route->flags |= DEVROUTE_METRIC;
> > + }
> > + if (r_next->flags & DEVROUTE_TABLE) {
> > + route->table = r_next->table;
> > + route->flags |= DEVROUTE_TABLE;
> > + }
> > + if (r_next->flags & DEVROUTE_TYPE) {
> > + route->type = r_next->type;
> > + route->flags |= DEVROUTE_TYPE;
> > + }
> > + if (r_next->flags & DEVROUTE_ONLINK)
> > + route->flags |= DEVROUTE_ONLINK;
> How about leaving the route->{mtu,metric,table} assignment as-is and
> doing something like this:
> route->flags |= r->next & (DEVROUTE_MTU | DEVROUTE_METRIC |
>DEVROUTE_TYPE | DEVROUTE_ONLINK);
>

Sure. I'll resent as the code bellow after your ACK.

I noticed that metric was being added to the OS route even though
DEVROUTE_METRIC
was never set. The same might also happen with mtu and table (however,
I didn't test it). You didn't mention
DEVROUTE_TABLE in your suggestion but I added it anyway. I think that, in fact,
table will never be used as interface_ip_find_route_target() will
ignore routes with the table flag.
Should I remove it, both the flag and the assignment, or it is not worth it?

I added source/mask even without using it in my case as I think a new
route without it would break the
original route proposal.

It is still missing "valid_until" but I'm not sure if it should be
added or not as it might get out of sync with
the original route if that one gets updated.

@@ -298,12 +300,17 @@ interface_ip_add_target_route(union if_addr
*addr, bool v6, struct interface *if
   return NULL;

   route->flags = v6 ? DEVADDR_INET6 : DEVADDR_INET4;
+   route->flags |= r->next & (DEVROUTE_MTU | DEVROUTE_METRIC |
+   DEVROUTE_TYPE | DEVROUTE_ONLINK | DEVROUTE_TABLE);
   route->mask = v6 ? 128 : 32;
   memcpy(>addr, addr, addrsize);
   memcpy(>nexthop, _next->nexthop, sizeof(route->nexthop));
   route->mtu = r_next->mtu;
   route->metric = r_next->metric;
   route->table = r_next->table;
+   route->type = r_next->type;
+   memcpy(>source, _next->source, addrsize);
+   route->sourcemask = r_next->sourcemask;
   route->iface = iface;
   vlist_add(>host_routes, >node, route);

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

Re: Netifd proto_add_host_dependency (called by wireguard) replacing unreachable route

[Luiz Angelo Daros de Luca]

> I think that netifd really wanted to add a dependency to the first
> route, not the second one.
> Maybe netifd should ignore those routes with types for host
> dependencies, but I don't know  the consequences of that change.

Or maybe it is ok to monitor those kinds of routes if their type is preserved
and it netifd consider metrics when it selects the best route.

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

Netifd proto_add_host_dependency (called by wireguard) replacing unreachable route

[Luiz Angelo Daros de Luca]

Hello,

I have a static rule to reach a wireguard server through a specific
interface and an
unreachable route to make sure that the static route is the only way
to reach that
server.

10.1.2.1 via 10.3.1.5 dev eth1  src 10.3.1.6  metric 100
unreachable 10.1.2.1  metric 2147483645

After wg is up, wireguard.sh calls "proto_add_host_dependency wgint 10.1.2.1".
That call modifies the unreachable route to a normal route (it removes
the type).
The result is this:

10.1.2.1 via 10.3.1.5 dev eth1  src 10.3.1.6  metric 100
10.1.2.1 dev lo scope link  metric 2147483645

I think that netifd really wanted to add a dependency to the first
route, not the second one.
Maybe netifd should ignore those routes with types for host
dependencies, but I don't know  the consequences of that change.

Regards,

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

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

couldplug happening before modules.d

[Luiz Angelo Daros de Luca]

Hello,

I'm trying to mount a USB storage device using hotplug.d/block.
However, it never works during boot because "hotplug.d/block" is
triggered before modules.d are loaded. It only works if the filesystem
was already loaded by modules-boot.d (normally ext4).

I'm manually loading all fs modules before "mount" with something like:

for fsmods in /etc/modules.d/*-fs-*; do
while read -r fsmod; do
modprobe $fsmod
done <$fsmods
done
mount ...

But shouldn't it work "by design"?

It used to work in the past, maybe in the "18.06 era".

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

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

Re: OpenWrt 21.02 status

[Luiz Angelo Daros de Luca]

> I believe what he meant to say was to make another 19.07.x point
> release with an updated sysupgrade mechanism which would improve the
> situation when upgrading to 21.02.x and, for example, allow
> flashing with non-matching DEVICE_COMPAT_VERSION already when
> specifying the '-n' flag to not keep configuration, but not require
> the '-F' flag which is scary for regular users (for good reasons).

That is exactly what I propose. We should somehow make sysupgrade in
19.07 be able
to understand a DSA image and allow an upgrade '-n' without warning and forces.
I think a package upgrade or a new package installation might be able
to do that. It touches the image
validation, which I guess happens before switch_root. It does not
invalidate the use of -F for older images
but it allows a safer path. We could have a new 19.07 point release
with that update, but it is just another way
to install the new/updated package.

I think all involved files in image validation are in base-files. I
think they should be in an individual package
to help upgrade them without touching the rest of the system. This
will not be the last time OpenWrt will need to prepare
an old version to deal with a new release image.

> > We can discuss this for the future, i.e. for updates starting at 21.xx, and 
> > we can discuss the exact wording of the message.

First we need a solution to offer the user.

> > > It would also be great if we could detect a config from a pre-dsa system 
> > > and
> > > restore everything but skipping or renaming DSA relevant files (nework,
> > > wifi?) DSA) with a suffix like '.pre-dsa'.
> >
> > We had a very long delay due to DSA and nobody was even slightly interested 
> > in creating a migration script.
> > For partial migration, I suspect that implementing something here that is 
> > general will be much more complicated than just having the user select what 
> > he wants/needs.

This is not a migration script but a mitigation. A 21.02 image should
detect during boot if the current network config was for swconfig in a
system using DSA.
It could happen during early boot stages, after FS are mounted, before
services are started, something similar to uci-defaults, but not in a
"run once" way.
It would cover both upgrades with confs and restores. We are asking
the user to upgrade without saving confs but nothing will prevent them
from keeping settings while
using "sysupgrade -F" nor restoring an 19.07 backup "manually" into a
21.02. I think an expert dev could solve this one with a 5 line script
;-)

Regards,

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

Re: OpenWrt 21.02 status

[Luiz Angelo Daros de Luca]

> > 2) I was pretty fuzzy about what people should do if their target did 
> > migrate to DSA. Do we have a guide to help those people through the 
> > transition?
>
> We do not support a migration and people have to start with a new fresh
> installation. Doing a backup and restoring some settings manually works.

The last time I tried it was very confusing. When I first read about
"new fresh installation", I thought: "install without keeping
settings".
However, OpenWrt returned an image check failure, even when I did not
keep the settings (sysupgrade -n). It was the same type of
error (image validation failed) that would happen if I selected the
wrong firmware (but maybe with a different content). The only way
to install it was forcing the operation, which might also allow an
incompatible image to be installed (bricking the device). Please
reconsider some form of upgrade path that validates the image and
allows the user to upgrade without a force or going back
to factory before reinstalling OpenWrt with DSA. Something like
"update package foo to version n.m.z or upgrade to 19.07.9 before
installing 21.02 for proper image validation". Most users will not be
confident to apply a forced installation.

>From wiki upgrading to 21.02 page:

"Don't worry - If you try to upgrade with the wrong target, sysupgrade
will refuse to proceed with an error message like this:
Image version mismatch. image 1.1 device 1.0 Please wipe config during
upgrade (force required) or reinstall. Config cannot be migrated from
swconfig to DSA Image check failed"

My experience and the message content indicates that it will show for
all migrations from "swconfig" to "DSA" and not only for "wrong
target".

I tried to start a discussion about it in an email "Usability issues
for DSA upgrade" (jun/28) but I got no answer.

It would also be great if we could detect a config from a pre-dsa
system and restore everything but skipping or renaming DSA
relevant files (nework, wifi?) DSA) with a suffix like '.pre-dsa'.

DSA is missing a lot of docs. For example: is there a simple, secure
way to detect a system is using DSA for a specific switch (or device)?
Is it possible to exist a device with two switches and only one of
them uses DSA?

Regards,

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

Missing files from package build by buildbot and no Phase 2 logs

[Luiz Angelo Daros de Luca]

Hello,

I'm trying to identify what caused
https://github.com/openwrt/packages/issues/16085.
If I build the package locally, I get everything in place. However,
the file built by buildbot is missing some files.

The command that would copy those is:

https://github.com/openwrt/packages/blob/69df02cabade31c19cec92252a564e354df44d75/utils/sane-backends/Makefile#L286-L289

using files generated by:

https://github.com/openwrt/packages/blob/69df02cabade31c19cec92252a564e354df44d75/utils/sane-backends/Makefile#L196-L202

It is probably something missing like awk/sort or sh compatibility.
However, I get no output from:
https://buildbot.openwrt.org/openwrt-21.02/packages/#/builders/12/builds/58/steps/24/logs/stdio

Is there any place to get full buildbot output for packages? Or an
easy way to locally simulate a buildbot?

Regards,

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

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

Re: Enabling Wi-Fi on First boot

[Luiz Angelo Daros de Luca]

Hello,

I would enable wifi during the first boot. Maybe we could disable it
after a couple of minutes if nothing happens.
I would not use an unprotected network, like OpenWrt, as someone could
sniff the new password (we also have no https://).
But an OpenWrt/OpenWrt could work.

If you have a working OpenWrt and want to do a clean setup through
wifi, one solution would be to apply a simple "enable wifi"
configuration
together with the new image. Luci does not allow but CLI sysupgrade
does have the option "-f conf.tgz". OpenWrt could provide a standard
enable-wifi.tgz and a way to flash a firmware with configuration from LuCI.

Some devices block the user from using the router to access the
internet until some basic things are set, like admin and wifi
password.
They normally redirect all http traffic to the router. It would be
nice to have something similar to force the user to set a password.
However, it will never get merged if that setup applies to everything
as it would break many provisioning. It might be overkill but maybe it
looks like a new image flavor...

My 2 cents,

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

Em ter., 6 de jul. de 2021 às 21:43, Alberto Bursi
 escreveu:
>
>
>
> On 06/07/21 22:57, Michael Richardson wrote:
> >
> > Alberto Bursi  wrote:
> >  > "unique" per-device passwords like most vendors are doing are low 
> > security
> >  > and relatively easy to brute force once someone has disassembled the 
> > firmware
> >  > and learned the algorithm used to generate them. They rely on 
> > obscurity for
> >  > most of their security, which is not really a thing for an open 
> > source
> >  > project.
> >
> > If they devices are shipped with such derivable passwords, then they violate
> > the California (now US) regulations, and also the come UK ones.
> > We can do better, and we are doing better.
>
> Yeah, like most devices are also paying lip service to the other US laws
> about not allowing "custom firmware" on the device because that could
> make it go against radio power/emission regulations.
> One thing is the law, one thing is actually enforcing it besides asking
> nicely to the OEMs and trusting their "boy scout's word" that it's all
> secure.
>
> >
> >  > They are also completely useless for DYI users that are just 
> > flashing a
> >  > couple devices.
> >  > With much less effort you can just ship a pre-made wifi config file 
> > with your
> >  > own settings and passwords, and that's what many are already doing.
> >
> > Many devices have USB ports, and I'd suggest having a standard names .json
> > file that can be fed into uci in some way.  I think that this solves a lot
> > problems.  Have to make sure that vfat support is included in the base image
> > because... users.
>
> And the idea mill keeps going. Not specifically just you but I've seen
> these discussions run in circles so many times at this point that I'm a
> bit jaded.
> Imho this proposal does open more problems than it solves, and it is
> non-trivial to implement, and it adds bloat in firmware images so people
> will be unhappy.
> And it is not universal, a lot of devices don't have USB ports.
>
>
>
> The best idea I've seen so far is to just add the feature to add a
> custom wifi config (possibly more than just wifi) in the image builder
> website frontend framework thing made by Spooren (aparcar on github)
> https://github.com/aparcar/asu
> So that the user can generate an image with custom config from a point
> and click interface, and when the device does the first boot it will
> come up with an already configured wifi and network and whatnot.
>
> This avoids bloating images, does not add any new attack vectors in the
> device firmware, keeps the wifi security freaks happy as no wifi is
> enabled by default, while still being friendly to the end user.
>
> The only thing that could go wrong is that the user screws up the config
> and locks himself out, device reset will not change the configs he
> integrated, but I think Fallback mode can to be modified to always use
> "openwrt default configs (i.e. 192.168.1.1 IP and device default ports
> for LAN/WAN, no wifi enabled)" instead of whatever the user has shipped.
> So that if the user does something wrong they can still get into
> fallback mode and then reflash a new firmware with the right configs.
>
> Not saying this is easier to develop or faster or whatever.
> Just that imho this would be the optimal "solution" that satisfies the
> most types of userbase.
>
> -Alberto
>
> ___
> 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

Usability issues for DSA upgrade

[Luiz Angelo Daros de Luca]

Hello,

While upgrading from 19.07 to 21.02, there is an scary error message
when target migrates to DSA (both Luci or CLI):

root@OpenWrt:/tmp# sysupgrade -n
openwrt-21.02.0-rc3-mvebu-cortexa9-linksys_wrt1900acs-squashfs-sysupgrade.bin
Device linksys,shelby not supported by this image
Supported devices: linksys,wrt1900acs armada-385-linksys-shelby
linksys,shelby - Image version mismatch: image 1.1, device 1.0. Please
wipe config during upgrade (force required) or reinstall. Reason:
Config cannot be migrated from swconfig to DSA
Image check failed.

OpenWrt devs are probably confident that they can force an upgrade for
that image. "force" means "I know what I'm doing, ignore the checks".
However, for many users, sometimes non-technical ones, they do not
really know what they are doing. There might be a wave of support
requests about that message and another wave of bricked devices. Even
knowing some OpenWrt internals, I'm not sure what "...or reinstall"
means. Shouldn't '-n' be enough? Isn't sysupgrade already a reinstall?
Or should it be the factory image? If it is really suggesting factory
images, should I return to the original firmware before or use some
emergency firmware recovery?

Can we provide a 19.07 update to, at least, allow the upgrade without
errors or "force" if confs are not kept? "Force" comes with great
responsibility and it will overwrite other checks as board
compatibility.

The error message could be, instead of:

"Please wipe config during upgrade (force required) or reinstall.
Reason: Config cannot be migrated from swconfig to DSA"

Something like this:

"Configuration cannot be migrated from swconfig to DSA. To properly
validate this firmware, please update OpenWrt at least to version
19.07.8 or pkgfoobar to version 1.2.3 and retry. Alternatively, if you
are sure that this image is compatible, you can proceed not retaining
the current configuration and forcing the process."

I omitted the "...or reinstall'' as I'm still not sure what it means.
I also used "not retaining the current configuration" as Luci (nor
sysupgrade) does not mention wipe but "Keep settings and retain the
current configuration" (which, by the way, seems to be two redundant
sentences).

Regards,

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

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

Re: [PATCH] tplink-safeloader: fix C7v5 factory flashing from vendor fw > v1.1.x

[Luiz Angelo Daros de Luca]

> Currently it's not possible to flash factory images on devices shipped
> with vendor firmware versions 1.1.0 Build 20201120 rel. 50406 (published
> 2020-12-22):
>
>  (curFw_ver, newFw_ver) == (1.1, 1.0) [NM_Error](nm_checkSoftVer) 00848: 
> Firmwave not supports, check failed.
>  [NM_Error](nm_checkUpdateContent) 01084: software version dismatched
>  [NM_Error](nm_buildUpgradeStruct) 01188: checkUpdateContent failed.
>
> They've even following note in release notes:
>
>  Note: You will be unable to downgrade to the previous firmware version after 
> updating this firmware.
>
> This version check is in vendor firmware is implemented in
> /usr/bin/nvrammanager binary as following code[1]:
>
>  sscanf(buf, "%d.%d.%*s",_fw_major, _fw_minor);
>  ...
>  if (((int)upd_fw_major < (int)cur_fw_major) ||
>  ((ret = 1, cur_fw_major == upd_fw_major && (upd_fw_minor < 
> (int)cur_fw_minor {
>ret = 0;
>printf("[NM_Error](%s) %05d: Firmwave not supports, check 
> failed.\r\n\r\n","nm_checkSoftVer" ,0x350);
>  }
>  ...
>  return ret;
>
> So in order to fix this and make it future proof it should be enough to
> ship our factory firmware images with major version 7 (lucky number).
>
> Tested on latest firmware version 1.1.2 Build 20210125 rel.37999:
>
>  Firmwave supports, check OK.
>   (curFw_ver, newFw_ver) == (1.1, 7.0) check firmware ok!
>  chekc firmware file success!
>
> 1. https://gist.github.com/ynezz/2e0583647d863386a66c3d231541b6d1
>
> Signed-off-by: Petr Štetiar 
> ---
>  tools/firmware-utils/src/tplink-safeloader.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/firmware-utils/src/tplink-safeloader.c 
> b/tools/firmware-utils/src/tplink-safeloader.c
> index da73e1bf307e..ac71b3305ee6 100644
> --- a/tools/firmware-utils/src/tplink-safeloader.c
> +++ b/tools/firmware-utils/src/tplink-safeloader.c
> @@ -1262,7 +1262,7 @@ static struct device_info boards[] = {
> "{product_name:Archer 
> C7,product_ver:5.0.0,special_id:4B52}\n",
>
> .part_trail = 0x00,
> -   .soft_ver = "soft_ver:1.0.0\n",
> +   .soft_ver = "soft_ver:7.0.0\n",


Why not something bigger? Maybe 126 instead of 7? It is still safe
even if the version is stored as an unsigned char.

>
> Currently it's not possible to flash factory images on devices shipped
> with vendor firmware versions 1.1.0 Build 20201120 rel. 50406 (published
> 2020-12-22):
>
>  (curFw_ver, newFw_ver) == (1.1, 1.0) [NM_Error](nm_checkSoftVer) 00848: 
> Firmwave not supports, check failed.
>  [NM_Error](nm_checkUpdateContent) 01084: software version dismatched
>  [NM_Error](nm_buildUpgradeStruct) 01188: checkUpdateContent failed.
>
> They've even following note in release notes:
>
>  Note: You will be unable to downgrade to the previous firmware version after 
> updating this firmware.
>
> This version check is in vendor firmware is implemented in
> /usr/bin/nvrammanager binary as following code[1]:
>
>  sscanf(buf, "%d.%d.%*s",_fw_major, _fw_minor);
>  ...
>  if (((int)upd_fw_major < (int)cur_fw_major) ||
>  ((ret = 1, cur_fw_major == upd_fw_major && (upd_fw_minor < 
> (int)cur_fw_minor {
>ret = 0;
>printf("[NM_Error](%s) %05d: Firmwave not supports, check 
> failed.\r\n\r\n","nm_checkSoftVer" ,0x350);
>  }
>  ...
>  return ret;
>
> So in order to fix this and make it future proof it should be enough to
> ship our factory firmware images with major version 7 (lucky number).
>
> Tested on latest firmware version 1.1.2 Build 20210125 rel.37999:
>
>  Firmwave supports, check OK.
>   (curFw_ver, newFw_ver) == (1.1, 7.0) check firmware ok!
>  chekc firmware file success!
>
> 1. https://gist.github.com/ynezz/2e0583647d863386a66c3d231541b6d1
>
> Signed-off-by: Petr Štetiar 
> ---
>  tools/firmware-utils/src/tplink-safeloader.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/firmware-utils/src/tplink-safeloader.c 
> b/tools/firmware-utils/src/tplink-safeloader.c
> index da73e1bf307e..ac71b3305ee6 100644
> --- a/tools/firmware-utils/src/tplink-safeloader.c
> +++ b/tools/firmware-utils/src/tplink-safeloader.c
> @@ -1262,7 +1262,7 @@ static struct device_info boards[] = {
> "{product_name:Archer 
> C7,product_ver:5.0.0,special_id:4B520000}\n",
>
> .part_trail = 0x00,
> -   .soft_ver = "soft_ver:1.0.0\n",
> +   .soft_ver = "soft_ver:7.0.0\n",
>
> /* We're using a dynamic kernel/rootfs split here */
> .partitions = {
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

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

tcpdump missing packets with different filters for different interfaces

[Luiz Angelo Daros de Luca]

Hello,

While debugging with tcpdump, I noticed some strange results. I tested
both with tcpdump-mini and tcpdump in 19.07. My router uses the
standard eth0.2 as wan, eth0.1 and multiple wlan bridged br-lan.

While pinging dns.google (ipv6 and ipv4), I tried these with tcpdump(-full):

Listening to "any", I got only IPv4 (wlan, br-lan, eth0.2 /  eth0,
eth0.2, br-lan, wlan), I got no IPv6

# tcpdump -i any icmp or icmp6 -n
01:02:21.804830 IP 192.168.3.999 > 8.8.8.8: ICMP echo request, id 46,
seq 30, length 64
01:02:21.804830 IP 192.168.3.999 > 8.8.8.8: ICMP echo request, id 46,
seq 30, length 64
01:02:21.804946 IP 999.999.96.75 > 8.8.8.8: ICMP echo request, id 46,
seq 30, length 64
01:02:21.826868 ethertype IPv4, IP 8.8.8.8 > 999.999.96.75: ICMP echo
reply, id 46, seq 30, length 64
01:02:21.826868 IP 8.8.8.8 > 999.999.96.75: ICMP echo reply, id 46,
seq 30, length 64
01:02:21.826962 IP 8.8.8.8 > 192.168.3.999: ICMP echo reply, id 46,
seq 30, length 64
01:02:21.826978 IP 8.8.8.8 > 192.168.3.999: ICMP echo reply, id 46,
seq 30, length 64

If do not use filter, I can see the expected ICMPv6 packets arriving:

# tcpdump -i any -n
01:22:06.348704 IP 192.168.3.999 > 8.8.8.8: ICMP echo request, id 46,
seq 1213, length 64
01:22:06.348704 IP 192.168.3.999 > 8.8.8.8: ICMP echo request, id 46,
seq 1213, length 64
01:22:06.348812 IP 999.999.96.75 > 8.8.8.8: ICMP echo request, id 46,
seq 1213, length 64
01:22:06.368259 ethertype IPv4, IP 8.8.8.8 > 999.999.96.75: ICMP echo
reply, id 46, seq 1213, length 64
01:22:06.368259 IP 8.8.8.8 > 999.999.96.75: ICMP echo reply, id 46,
seq 1213, length 64
01:22:06.368357 IP 8.8.8.8 > 192.168.3.999: ICMP echo reply, id 46,
seq 1213, length 64
01:22:06.368375 IP 8.8.8.8 > 192.168.3.999: ICMP echo reply, id 46,
seq 1213, length 64
...
01:22:06.255748 IP6 2804:::::9ca > 2001:4860:4860:::
ICMP6, echo request, seq 1324, length 64
01:22:06.255748 IP6 2804:::::9ca > 2001:4860:4860:::
ICMP6, echo request, seq 1324, length 64
01:22:06.255895 IP6 2804:::::9ca > 2001:4860:4860:::
ICMP6, echo request, seq 1324, length 64
01:22:06.278039 ethertype IPv6, IP6 2001:4860:4860:: >
2804:::::9ca: ICMP6, echo reply, seq 1324, length 64
01:22:06.278039 IP6 2001:4860:4860:: > 2804:::::9ca:
ICMP6, echo reply, seq 1324, length 64
01:22:06.278171 IP6 2001:4860:4860:: > 2804:::::9ca:
ICMP6, echo reply, seq 1324, length 64
01:22:06.278191 IP6 2001:4860:4860:: > 2804:::::9ca:
ICMP6, echo reply, seq 1324, length 64


Listening to "eth0", I got IPv4 and IPv6, but only incoming.

# tcpdump -i eth0 icmp or icmp6 -n
01:05:34.013966 IP 8.8.8.8 > 999.999.96.75: ICMP echo reply, id 46,
seq 222, length 64
01:05:34.014860 IP6 2001:4860:4860:: > 2804:::::9ca:
ICMP6, echo reply, seq 333, length 64

Again, if I change the filter to something like 'vlan 2', I can see both:

# tcpdump -i eth0 vlan 2 -n
...
01:06:56.107341 IP 999.999.96.75 > 8.8.8.8: ICMP echo request, id 46,
seq 304, length 64
...
01:06:56.127299 IP 8.8.8.8 > 999.999.96.75: ICMP echo reply, id 46,
seq 304, length 64
...
01:06:57.067497 IP6 2804:::::9ca > 2001:4860:4860:::
ICMP6, echo request, seq 416, length 64
...
01:06:57.096174 IP6 2001:4860:4860:: > 2804:::::9ca:
ICMP6, echo reply, seq 416, length 64

If I capture the external vlan interface or br-lan, all works as expected:

# tcpdump -i eth0.2 icmp or icmp6 -n
01:08:38.213303 IP6 2804:::::9ca > 2001:4860:4860:::
ICMP6, echo request, seq 517, length 64
01:08:38.233701 IP6 2001:4860:4860:: > 2804:::::9ca:
ICMP6, echo reply, seq 517, length 64
01:08:38.256486 IP 999.999.96.75 > 8.8.8.8: ICMP echo request, id 46,
seq 406, length 64
01:08:38.278949 IP 8.8.8.8 > 999.999.96.75: ICMP echo reply, id 46,
seq 406, length 64

# tcpdump -i br-lan icmp or icmp6 -n
01:10:40.406118 IP6 2804:::::9ca > 2001:4860:4860:::
ICMP6, echo request, seq 639, length 64
01:10:40.429046 IP6 2001:4860:4860:: > 2804:::::9ca:
ICMP6, echo reply, seq 639, length 64
01:10:40.432067 IP 192.168.3.999 > 8.8.8.8: ICMP echo request, id 46,
seq 528, length 64
01:10:40.453203 IP 8.8.8.8 > 192.168.3.999: ICMP echo reply, id 46,
seq 528, length 64

The only reliable way to filter is to not use them and let the reader
(wireshark) do it afterwards. But that workaround is not
an option while capturing through the same interface you need to
capture traffic on.

Is this really expected? Maybe a weird mips bug? Or a bad side effect
from some openwrt size optimization?

Regards,

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

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

Re: [PATCH] base-files: sysupgrade: store status of system-services

[Luiz Angelo Daros de Luca]

> When saving the list of installed pkgs, also store the status of the
> system services. The list is created in the etc/backup folder also
> and formated as:
>
> /etc/init.d/ {enable|disable}
>
> This way it can be sourced after sysupgrade, to restore the previous
> state.

I also liked the idea. I didn't like the use of -k option (save a list
of installed packages). I would either create a new option for it,
enable it when -c or -o is in use, or simply enable it by default.

I also think that ${SERVICE_STATUS} could be executed by default after
the reboot. If the user asked to preserve service status, it could be
implicitly assumed that the user wants to restore it after the backup
is applied. The problem is that you cannot write directly to
/etc/uci-defaults without touching the flash on each backup. The
/etc/backup is a good solution but you need to change when it is
mounted, and not only when '-k' is selected.

I would create a new /etc/uci-defaults/01-post-restore.sh provided by
base-files (and not created by a backup) that would read a possible
/etc/backup/post-restore.sh script. There you could place your
enable/disable calls.

Regards,

Luiz Angelo

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

Re: 20.xx: postponse LuCI HTTPS per default

[Luiz Angelo Daros de Luca]

Hi,

I guess we could simply ask the user by default (with options to auto
generate a certificate or ignore https). Luci already warns that a
root password must be set.
Why not also add something like: "Upgrade to a secure connection?".


   "No password Set!
   There is no ...
   ...
   "

   "You are using an unencrypted connection!
   Before informing sensitive information, like a password, it is
recommended to enable encryption (https)
   ...
# it will require authentication if a
password is already set
   "

If the user opts to use it, it could generate a self-signed
certificate and offer it to be downloaded/imported even before using
it.

   http://192.168.1.1/luci/https-settings#generate-self-signed...

   HTTP Settings:

 #if "the certificate is not trusted by the browser. Can we test it using ajax?"
   
   Click here to download and import the router certificate now.
Otherwise, your browser will
   warn you that the router certificate is not trusted. Then, you can
ignore the error and continue. However,
   it would be safer to add the router to browser certificate
exceptions. You might need to do it again every time
   the certificate is regenerated.

   If the certificate warning page reappears again for the same router
at the same browser, it might not be automatically
   trusted as it could be a malicious device impersonating your router
trying to steal your credentials.
 #endif

   [Generate a new self-signed certificate]
   [Generate a new certificate request] / [Import the signed
certificate] # if a CSR was generated
   [Generate a new Let's Encrypt certificate] # it would be a nice add-on
   [Remove current certificate and disable encryption]

The next luci request will redirect the browser to https://

My 2 cents,

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

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

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

[Luiz Angelo Daros de Luca]

> The disadvantage is that the wireless config has to be different if we switch 
> to a default config with no separate LAN bridge, and it becomes potentially 
> more confusing for common use cases.
> I think semantically it fits quite well to just assign a Wifi interface to 
> the lan network and hide some implementation details of what that means.

I think we should try hard to split between L2 and L3 as a goal. Those
convenient shortcuts (interface.type=bridge) make it harder for a
newcomer to understand what is going on. I would try to avoid them.
I had to explain the mixed concepts dozens of times for newbies, even
for those with Linux experience. It's just confusing that linux
network devices, which are also called network interfaces, are not
OpenWrt interfaces. I hope someday I could see the same "names" both
in config and the output from network commands like ip address.
OpenWrt interface name could be a label for an address.

OpenWrt uses multiple names "ifname, iface, device, network,
interface" sometimes for the same and also different concepts. Those
names/references should be standardized. Choose one and stick with it.
Also, there is the problem of how to reference a device/interface. It
should be much easier if the section name could be always used.
However, uci has its limitations, which requires an "option name".
I would use "option name" as "section name" by default, requiring it
to be set explicitly only as a way to overcome the uci section name
limitations.

Wireless defines a network device and maybe wifi-iface should be
declared simply as a type of device with some extra options and a
reference to a radio. BTW, wireless.wifi-device introduces another
confusion with network.device and simply "radio" might be better.

It would be better to have predictable interface names for everything.
If it is not possible, we could introduce a reverse option
"device_for". As both device and interface section can have a device
option, "option device_for" could use both as a valid value.

This is a simple example to illustrate general idea:

config radio 'radio0'
   option type 'mac80211'
   option hwmode '11a'

config device 'wifinet_wan'
   option type wifi
   option ssid 'uplink_wwan'
   option radio 'radio0'
   option mode 'sta'
   option device_for wan # reverse referenced for an interface

config device 'wifinet_OpenWrt' # wifinet_ap will be the linux network
device name
   option type wifi
   option ssid 'OpenWrt'
   option radio 'radio0'
   option mode 'ap'
   option device_for brlan # reverse referenced for a device

config device 'wifinet_OpenWrt2' # wifinet_ap2 will be the linux
network device name
   option type wifi
   option ssid 'OpenWrt2'
   option radio 'radio0'
   option mode 'ap'

config device brlan
   type bridge
   # option name brlan # by default, no need to set
   list device dev1
   list device dev2
   list device dev3
   # list device wifinet_OpenWrt
   list device wifinet_OpenWrt2 # directly referencing

config interface lan
   option device brlan #device instead of ifname
   option proto static

config interface lan6
   option device @lan #the value for lan.device
   option proto static

config interface wan
   # option device wifinet_wan
   option proto dhcp

---
 Luiz Angelo Daros de Luca

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

Re: Restoring (old) config backups and

[Luiz Angelo Daros de Luca]

Hello,

> The problems we've observed with the backup *restore* functionality are:
>
> * It is applied with a simple reboot, and _apparently_, it has no hooks
> or other way to ensure system sanity before (or after) the backup restore.
>
> Which would be fine if the following point was never true:
>
> * End users are likely to use the backup-restore facility across
> sysupgrade (i.e. use older backups).
>
>
>
> Some possible root causes of the issues created on backup restoration:
>
> 1. /etc/uci-defaults is not "reset" like a sysupgrade would.  When the
> backup is "outdated" from the PoV of current packages in the running
> firmware image, it can cause issues ranging from minor, to severe.

It would be interesting to have a way to do firstboot+restore in a
single step (as cmdline can sysupgrade/restore).
However uci-defaults seems to be used to generate missing
configuration, not converting an existing one. A package
update could (ab)use this to migrate an existing configuration, but it
does seem to be the ideal usage (there are pre/post scripts).

> 2. Account information is not properly sanitized/recreated (/etc/passwd,
> shadow, group).  Thus, system accounts that were meant to be used by
> packages might be missing or have incorrect contents.   This is a
> consequence of (1), thus not a "root cause", but I find it relevant
> enough to mention it explicitly.
>
> If things fail to start because of missing system users, it is bad.
> When they *don't* fail to start and instead run as root, it is arguably
> *worse*.

It is a harder problem as it is not a simple migration but a merge process.
Somehow, a merge process will have to read both files at the same time
and merge them.
Today, the backup is restored directly over existing files. The merge
process would require
to expand it to a temporary directory and do the merge process.

> Some possible solutions:
>
> * It is not too hard to bake a firmware image uuid, randomly generated
> at build-time, add it to the backup tarball, and use it to detect the
> fact that we (re-)booted into a new environment that should go through
> /etc/uci-defaults processing as if it had been through a sysupgrade.

I guess uci-defaults is not ideal for that task. Those scripts are
meant to run once and get discarded after that.
UUID gives less info than BUILD_ID. It would be nice to have some form
of version information inside the backup,
even if it is informational only, like a /etc/.config_restored_version.

> This requires /etc/uci-defaults scripts that can handle being run when
> the changes they need to apply are already in place, which is *already*
> a best-practice, but still...

I imagine it could be possible to have something similar to database
migration scripts, where a set of atomic migrations occurs between
version x and version x+1. They would run only when
/etc/.config_restored_version exists. They should run immediately
after the restore happens. After that, /etc/.config_restored_version
could be removed or, in case a migration script fails, identify the
last working step.
Ideally, all these processes should be executed in a form of
"snapshot" of existing rootfs (a new layer of overlayfs?) and just
applied when it is finished.

It looks better than an "option migrated_featureX 1".

> Alternatively, or perhaps additionally to uci-defaults, it could run
> package-provided scripts from a directory on restore (pre-reboot,
> after-reboot).

It would be better if all migration could occur immediately after the
restore. However, there are two moments when a restore happens: when
the user asks for it and during
a sysupgrade that keeps existing configuration or provides a backup file.

Regards,

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

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

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

[Luiz Angelo Daros de Luca]

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

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

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

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

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

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

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

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

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

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

Regard,

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

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

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

[Luiz Angelo Daros de Luca]

Hello,

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

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

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

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

And we still have wireless:

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

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

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

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

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

# for DSA or swconfig
interface wan
  ifname wan
  proto dhcp

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



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

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

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

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

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

Re: [OpenWrt-Devel] Signing, meta-data, etc. on images and losetup mounts...

[Luiz Angelo Daros de Luca]

>
>
>
> Thanks.  Where is the beginning of the whole disk image (and end) if I
> want to “dd” it onto an SSD or SD?
>

Meta is at the end. Gunzip will give you a warning and ignored it when
expanded.

First byte of the expanded image is the disk sector 0. It is a normal disk
image with partitions. I didn't test EFI, which might use GPT but the other
one is simply a DOSMBR partitioned disk.

The default size is about 256MB (or is it 128?). Just dd it to something a
little bit bigger and let it run.

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

Re: [OpenWrt-Devel] [PATCH 19.07] libpcap: Update shared-lib patch from Debian to fix linking problems

[Luiz Angelo Daros de Luca]

Hello Hauke,

libpcap is broken and this patch might be the cause.

root@xxx:~# tcpdump
Error loading shared library libpcap.so.1: No such file or directory
(needed by /usr/sbin/tcpdump)
Error relocating /usr/sbin/tcpdump: pcap_set_tstamp_type: symbol not found
...

It's missing the last digit:

root@xxx:~# opkg files libpcap1
Package libpcap1 (1.9.1-2) is installed on root and has the following files:
/usr/lib/libpcap.so.0.8
/usr/lib/libpcap.so.

root@xxx:~# opkg info libpcap1
Package: libpcap1
Version: 1.9.1-2
Depends: libc
Provides: libpcap
Status: install user installed
Section: libs
Architecture: x86_64
Size: 100915
Filename: libpcap1_1.9.1-2_x86_64.ipk
Description: This package contains a system-independent library for
user-level network packet
capture.
Installed-Time: 1587678893

Manually creating the link "libpcap.so. -> libpcap.so.1" does solve the problem.

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

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


Em sex., 20 de mar. de 2020 às 15:07, Hauke Mehrtens
 escreveu:
>
> This updates the shared-lib patch to the recent version from debian
> found here:
> https://salsa.debian.org/rfrancoise/libpcap/-/blob/debian/1.9.1-2/debian/patches/shared-lib.diff
>
> This patch makes it include missing/strlcpy.o to the shared library
> which is needed for OpenWrt glibc builds, otherwise there is an
> undefined symbol and tcpdump and other builds are failing.
>
> Fixes: 44f11353de04 ("libpcap: update to 1.9.1")
> Signed-off-by: Hauke Mehrtens 
> ---
>  package/libs/libpcap/Makefile |   4 +-
>  .../patches/100-debian_shared_lib.patch   | 194 ++
>  .../102-makefile_disable_manpages.patch   |   6 +-
>  .../103-makefile_flex_workaround.patch|   2 +-
>  4 files changed, 157 insertions(+), 49 deletions(-)
>
> diff --git a/package/libs/libpcap/Makefile b/package/libs/libpcap/Makefile
> index fae955a54d..9a78216e3a 100644
> --- a/package/libs/libpcap/Makefile
> +++ b/package/libs/libpcap/Makefile
> @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
>
>  PKG_NAME:=libpcap
>  PKG_VERSION:=1.9.1
> -PKG_RELEASE:=1
> +PKG_RELEASE:=2
>
>  PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
>  PKG_SOURCE_URL:=http://www.us.tcpdump.org/release/ \
> @@ -32,7 +32,7 @@ define Package/libpcap
>TITLE:=Low-level packet capture library
>URL:=http://www.tcpdump.org/
>MENU:=1
> -  ABI_VERSION:=1
> +  ABI_VERSION:=2
>  endef
>
>  define Package/libpcap/description
> diff --git a/package/libs/libpcap/patches/100-debian_shared_lib.patch 
> b/package/libs/libpcap/patches/100-debian_shared_lib.patch
> index 454490fbfa..ab70417de7 100644
> --- a/package/libs/libpcap/patches/100-debian_shared_lib.patch
> +++ b/package/libs/libpcap/patches/100-debian_shared_lib.patch
> @@ -3,12 +3,13 @@ build a shared library.
>
>  --- a/Makefile.in
>  +++ b/Makefile.in
> -@@ -40,6 +40,13 @@ mandir = @mandir@
> +@@ -40,6 +40,14 @@ mandir = @mandir@
>   srcdir = @srcdir@
>   VPATH = @srcdir@
>
>  +# some defines for shared library compilation
> -+LIBVERSION=1
> ++MAJ=0.8
> ++LIBVERSION=$(shell head -1 debian/changelog | perl -nle 
> 'm/\S+\s+\((\S+)-\S+\)/ and print $$1')
>  +LIBNAME=pcap
>  +LIBRARY=lib$(LIBNAME).a
>  +SOLIBRARY=lib$(LIBNAME).so
> @@ -17,38 +18,38 @@ build a shared library.
>   #
>   # You shouldn't need to edit anything below.
>   #
> -@@ -69,7 +76,8 @@ INSTALL_RPCAPD=@INSTALL_RPCAPD@
> +@@ -69,7 +77,8 @@ INSTALL_RPCAPD=@INSTALL_RPCAPD@
>   EXTRA_NETWORK_LIBS=@EXTRA_NETWORK_LIBS@
>
>   # Standard CFLAGS for building members of a shared library
>  -FULL_CFLAGS = $(CCOPT) @V_LIB_CCOPT_FAT@ $(SHLIB_CCOPT) $(INCLS) $(DEFS) 
> $(CFLAGS)
>  +FULL_CFLAGS = $(CCOPT) @V_LIB_CCOPT_FAT@ $(SHLIB_CCOPT) $(INCLS) $(DEFS) 
> $(CFLAGS) $(CPPFLAGS)
> -+CFLAGS_SHARED = -shared -Wl,-soname,$(SHAREDLIB)
> ++CFLAGS_SHARED = -shared -Wl,-soname,$(SOLIBRARY).$(MAJ) 
> -Wl,--version-script=libpcap-symbols.lds
>
>   INSTALL = @INSTALL@
>   INSTALL_PROGRAM = @INSTALL_PROGRAM@
> -@@ -84,7 +92,11 @@ YACC = @YACC@
> +@@ -84,7 +93,11 @@ YACC = @YACC@
>   # problem if you don't own the file but can write to the directory.
>   .c.o:
> @rm -f $@
>  -  $(CC) $(FULL_CFLAGS) -c $(srcdir)/$*.c
>  +  $(CC) $(FULL_CFLAGS) -c -o $@ $(srcdir)/$*.c
>  +
> -+%_pic.o: %.c %.o
> ++%_pic.o: %.c
>  +  @rm -f $@
>  +  $(CC) -fPIC $(FULL_CFLAGS) -c -o $@ $(srcdir)/$*.c
>
>   PSRC =pcap-@V_PCAP@.c @USB_SRC@ @BT_SRC@ @BT_MONITOR_SRC@ 
> @NETFILTER_SRC@ @DBUS_SRC@ @NETMAP_SRC@ @RDMA_SRC@
>   FSRC =  @V_FINDALLDEVS@
> -@@ -101,6 +113,7 @@ SRC =  $(PSRC) $(FSRC) $(CSRC) $(SSRC) $(
> +@@ -101,6 +114,7 @@ SRC =   

[OpenWrt-Devel] openwrt-18.06 broken since kernel bump 4.14 to 4.14.169

[Luiz Angelo Daros de Luca]

Hello,

I was doing a clean build for 18.06 and got:

x86 instruction decoder selftest (X86_DECODER_SELFTEST) [N/y/?] (NEW)
aborted!

It looks like kernel bump happened both in openwrt-19.07
(eca8a2ee0d4404d9454cac473ee8d4d1ce7152e4) and openwrt-18.06
(4eba86820fd3d0ccf1f8e6addaa24ed6cd994b2f) but only openwrt-19.07 got a fix
(d91b52b1a2edd3645c88b29deb1091ae5f82fda8)

Regards,

---
 Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] ethernet broken on ath79/tl-wr2543nd since upgrade to kernel 5.4

[Luiz Angelo Daros de Luca]

Hello,

Since upgrade to kernel 5.4, I got no network with tp-link tl-wr2543nd. It
failed to initialize ethernet driver:

With 5.4:

[0.747634] rtl8367 rtl8367: cannot find mdio node phandle
[0.753186] rtl8367 rtl8367: using GPIO pins 1 (SDA) and 6 (SCK)
[0.759900] rtl8367 rtl8367: RTL8367R ver. 0 chip found
[2.584910] random: fast init done
[2.799942] libphy: rtl8367: probed
[2.839257] libphy: Fixed MDIO Bus: probed
[2.847887] ag71xx: probe of 1900.eth failed with error -2

With 4.19:

[0.744922] rtl8367 rtl8367: cannot find mdio node phandle
[0.750555] rtl8367 rtl8367: using GPIO pins 1 (SDA) and 6 (SCK)
[0.757212] rtl8367 rtl8367: RTL8367R ver. 0 chip found
[2.586809] random: fast init done
[2.801820] libphy: rtl8367: probed
[2.840548] libphy: Fixed MDIO Bus: probed
[3.217608] ag71xx 1900.eth: connected to PHY at fixed-0:00
[uid=, driv]
[3.227646] eth0: Atheros AG71xx at 0xb900, irq 4, mode: rgmii

I'm using serial interface and I'm testing using initram.

Wireless and swconfig seems to be OK. However, I get not eth0.
Does anyone have a clue where it is broken?

Regards,

---
 Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] RFC: versions.json

[Luiz Angelo Daros de Luca]

Hello,

Thinking on which info the client side would need, I would remove the
minors info if we can just skip to latest. And, It's missing a changelog
link. Also, each release can have its own info.json with more info.

How would it deal with devices that cannot be upgrades (like the past case
of 4/32)? Or will it bother the user forever with a nonsense upgrade
suggestion? How would it deal with devices target or subtarget changes
(like ar71xx -> ath79, or generic -> tiny) or this is more a "go to
OpenWrt.org" instead of "click here to download"? And aborted releases that
brick devices until a new release is ready, specially when they are
specific to a device?

The version.json would speed up upgrade rollout. It would also increase the
impact of a bugged upgrade. I would be nice to have something like a staged
release process, even just for suggesting them to the user. We could create
some form of machine id mixing device mac, urandom seed, board id and the
new release version and use it for selecting a device for a stage. It could
be a client-side-code only strategy but versions.json could inform the
proportion of each stage.

It would also be interesting to have some form of automatic or manual
success feedback like "Notify OpenWrt if your upgrade worked". This way, a
backend could be notified before the upgrade and expect a response
afterwards.

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

[OpenWrt-Devel] Rebuild kernel modules from changed packages for each stable dot release

[Luiz Angelo Daros de Luca]

Hello,

ksmbd recently got an update for 19.07. It consists on a kernel module and
some auxiliary programs. The auxiliar programs got into the oficial repo as
usual. However, the new userland package might be incompatible with the old
kernel module.

I downloaded the last SDK and the kernel module package dir and it built
nicely.

Once a package kernel module is changed on a stable branch, can we rebuild
it with each previous dot releases SDK for each target and subtarget? And,
finally, add the new kmod*.ipk to the respective
//kmods//?

Regards,

---
 Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Random data on rootfs_data for tp-wr2543nd-v1 only with ath79

[Luiz Angelo Daros de Luca]

> There's no need for this. If it's implemented we could simply
> use it on all chips and gain the increased flash reading speed.
>

Ok. I'm using it during my tests, but I could remove it in the final
version.


> On memory-mapped flash reading, spi controller issues 0x0b
> fast-read instruction. for the sake of correctness in spi-mem
> we should check whether spi-mem-op matches 0x0b + 3-byte
> address + 1-byte dummy before executing the operation.
> You'll need to set m25p,fast-read for spi-nor code to generate
> this matching operation.
>

The old fast read patch did not check the dummy byte. I'll do it as you
suggested.

I already have a working WIP patch. It does fix the issue. I might post a
RFC version today.

Regards,
> Chuanhong Guo
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Random data on rootfs_data for tp-wr2543nd-v1 only with ath79

[Luiz Angelo Daros de Luca]

Thanks Chuanhong,

That is exactly what introduced the issue. I double check with and without
the patch and without it I got the random data from mtd:

Without the patch
target/linux/ath79/patches-4.14/461-spi-ath79-add-fast-flash-read.patch:

root@OpenWrt:/# dd if=/dev/mtd4 | md5sum -
d339cbfaf5ce709878d98bf83b853b63  -
7936+0 records in
7936+0 records out
root@OpenWrt:/# dd if=/dev/mtd4 | md5sum -
b97c976391ae881a8139f325a18ecdb2  -
7936+0 records in
7936+0 records out
root@OpenWrt:/# uname -a
Linux OpenWrt 4.14.167 #0 Mon Feb 3 15:18:08 2020 mips GNU/Linux

With the patch
target/linux/ath79/patches-4.14/461-spi-ath79-add-fast-flash-read.patch:

root@OpenWrt:/# dd if=/dev/mtd4 | md5sum -
2404e891bd9e420fc4ec45e61cdd0ca9  -
7936+0 records in
7936+0 records out
root@OpenWrt:/# dd if=/dev/mtd4 | md5sum -
2404e891bd9e420fc4ec45e61cdd0ca9  -
7936+0 records in
7936+0 records out
root@OpenWrt:/# dd if=/dev/mtd4 | md5sum -
2404e891bd9e420fc4ec45e61cdd0ca9  -
7936+0 records in
7936+0 records out
root@OpenWrt:/# uname -a
Linux OpenWrt 4.14.167 #0 Mon Feb 3 15:18:08 2020 mips GNU/Linux

Buildtime are equal... maybe it is because of some reproducibility effort
that does not consider patches.
All my tests are using initram image and kernel 4.14.

The flash is a Spansion S25FL064PIF. It is the same of TL-WR842NDv1, which
has the flash section of DTS identical.

Kernel always detects it as:
[0.656283] m25p80 spi0.0: s25sl064p (8192 Kbytes)

I tried some random changes (without knowing what I'm really doing) like:

compatible = "spansion,spi-nor";
compatible = "spansion,s25sl064p", "spansion,m25p80", "jedec,spi-nor"
m25p,fast-read;

But I guess all those name variations will, in the end, mean just the same.
"m25p,fast-read" does not fix the issue as well.

Regards,

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


Em qui., 6 de fev. de 2020 às 23:57, Chuanhong Guo 
escreveu:

> Hi!
>
> On Fri, Feb 7, 2020 at 6:44 AM Luiz Angelo Daros de Luca
>  wrote:
> >
> > Hello,
> >
> > I isolated the problem to be kernel upgrade from 4.14 to 4.19. If I
> build ath79 with 4.14, it simply works.
> > The mtd problem also happens while booting 4.19 without touching the
> flash 4.19 (using initram image).
> >
>
> Flash reading is handled differently between 4.14 and 4.19. 4.14 reads
> directly from 0x1f00 where spi is mapped. But the interface used
> for that got removed in 4.19 so bit-bang mode is used instead.
> Could you try if removing
> target/linux/ath79/patches-4.14/461-spi-ath79-add-fast-flash-read.patch
> also breaks ath79/4.14?
>
> Regards,
> Chuanhong Guo
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Random data on rootfs_data for tp-wr2543nd-v1 only with ath79

[Luiz Angelo Daros de Luca]

Hello,

I isolated the problem to be kernel upgrade from 4.14 to 4.19. If I build
ath79 with 4.14, it simply works.
The mtd problem also happens while booting 4.19 without touching the flash
4.19 (using initram image).

Is there a mechanism to do a kernel bisect in OpenWrt?
Or does anybody have any clue of what could have caused this?

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


Em sex., 31 de jan. de 2020 às 03:53, Luiz Angelo Daros de Luca <
luizl...@gmail.com> escreveu:

> Hello,
>
> I'm trying to debug
> https://bugs.openwrt.org/index.php?do=details_id=2742.
> So far, what I discovered:
>
> 1) it happens only in master, 19.07 is fine on both ath79 and ar71xx
> 2) it happens only in ath79. ar71xx is fine in master
> 3) rootfs_data (mtd4) contents keeps changing on each read. Each time I
> run: "dd if=/dev/mtd4 | md5sum - " I get a different hash.
> 4) I get the random data reading flash from firmware (mtd1), rootfs (mtd3)
> or rootfs_data(mtd4), but always around the region where rootfs_data is
> (after squashfs). I could not identify the exactly upper and lower
> boundaries where it happens (addresses are random).
> 5) I also happens without mounting jffs2 (failsafe)
> 6) Most mtd4 is 0xff (as expected). Only sparse bytes or sequence of bytes
> contains other values.
> 7) I looked for a string inside mtd4 (if I came some a buffer), but
> changes where too small and without any sequence of printable chars.
>
> There are plenty of longs in the bug report.
>
> Has someone faced something similar?
>
> Regards,
> ---
>  Luiz Angelo Daros de Luca
> luizl...@gmail.com
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Random data on rootfs_data for tp-wr2543nd-v1 only with ath79

[Luiz Angelo Daros de Luca]

Hello,

I'm trying to debug
https://bugs.openwrt.org/index.php?do=details_id=2742.
So far, what I discovered:

1) it happens only in master, 19.07 is fine on both ath79 and ar71xx
2) it happens only in ath79. ar71xx is fine in master
3) rootfs_data (mtd4) contents keeps changing on each read. Each time I
run: "dd if=/dev/mtd4 | md5sum - " I get a different hash.
4) I get the random data reading flash from firmware (mtd1), rootfs (mtd3)
or rootfs_data(mtd4), but always around the region where rootfs_data is
(after squashfs). I could not identify the exactly upper and lower
boundaries where it happens (addresses are random).
5) I also happens without mounting jffs2 (failsafe)
6) Most mtd4 is 0xff (as expected). Only sparse bytes or sequence of bytes
contains other values.
7) I looked for a string inside mtd4 (if I came some a buffer), but changes
where too small and without any sequence of printable chars.

There are plenty of longs in the bug report.

Has someone faced something similar?

Regards,
---
 Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] ToH dump missing HW version

[Luiz Angelo Daros de Luca]

Hello,

I was using https://openwrt.org/_media/toh_dump_tab_separated_csv.zip from
https://openwrt.org/supported_devices and it is missing the hardware
version.
It is also missing the "unsupported features". Both are quite important for
selecting a device.
Wiki dynamic table does include them.

Can someone add it?

Regards,

---
 Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWrt 19.07 status

[Luiz Angelo Daros de Luca]

Hello,

19.07 page has a Roadmap without dates:
https://openwrt.org/releases/19.07/start#roadmap

It should have some real info with dates, something to make clear that it
does not have a real schedule ("It's ready when it is ready") or simply get
removed.

Regards,
---
 Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Download link not working for 18.06.5 and 19.07.0rc1

[Luiz Angelo Daros de Luca]

Hello,

The OpenWrt front page has a "Download a firmware image for your device"
for each released version. However, the last two links are currently
useless. Both show no devices.

For 18.06.5, it seems that something somewhere must be updated from 18.06.4
to 18.06.5.

For 19.07, it could be only a temporary issue while in RC. However, if so,
OpenWrt should not advertise that link for now.

And please, hide "Firmware OpenWrt snapshot Install URL" and "Firmware
OpenWrt snapshot Upgrade URL" from a ToH link that filter support for a
specific release. It only allows the user to wrongly install snapshot
versions.

Regards,

---
 Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWrt Roadmap

[Luiz Angelo Daros de Luca]

Hello,

There are a significant amount of devices out there that has 4/32
specs. Even brand new ones.
If there is stability issues with newer OpenWrt versions on those
devices, we should rethink LEDE EOL.

Maintenance burden is directly related to the amount of software to
maintain. At the same time, low specs means they might have no
interest in most packages.
Maybe 15.05 life could be extend with a lower cost by limiting
maintenance to a subset of packages (core? even less?). We could
release LEDE 15.05.(x+1) LTS with feeds configured to use only that
subset of packages. We could also limit the images to those low spec
models.

EOL is not really a big deal until it requires a new HW. Routers are
things that die hard, even after a decade. It just doesn't seem right
to turn old working hw into electronic waste because of software.
Keeping old stuff running is even on of the reasons to use OSS.

Regards,

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

Re: [OpenWrt-Devel] Is printf considered to be guaranteed?

[Luiz Angelo Daros de Luca]

I think so. It is compiled by default:

$ grep PRINTF -A2 package/utils/busybox/Config-defaults.in
config BUSYBOX_DEFAULT_PRINTF
bool
default y
--
config BUSYBOX_DEFAULT_ASH_PRINTF
bool
default y
--
config BUSYBOX_DEFAULT_HUSH_PRINTF
bool
default n

Regards,
-- 

Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] netifd: need help to fix FS#1463 - route with gateway absent or 0.0.0.0

[Luiz Angelo Daros de Luca]

Hello,

Docs are clear that when a route does not have the gateway field, it
will use the one from interface. However, it does not work like that.
When a route does not have a gateway, it is added as an onlink route.

I added a flag to differ between '0.0.0.0' and when gateway is absent.
The problem now is to get interface gateway. It looks like
interface_set_route_info is the place where a route copy missing
information from interface. However, at the time it runs, at least for
proto dhcp, iface->proto_ip->route and iface->config_ip->route are
empty. When interface gets an address from DHCP,
proto_shell_parse_route_list is called to add the default route.

Shouldn't the interface routes be included only after the interface is
up and configured (proto_shell_update_link) and not from the config
init (config_init_routes)?

My WIP is here
https://github.com/luizluca/netifd/commit/7ab84972bda51d34295d1938e07ed7efc3b2215d

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

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

Re: [OpenWrt-Devel] [RFD] sysupgrade and configuration management

[Luiz Angelo Daros de Luca]

Hi Paul,

> Very nice, but having read the mail thread around Luiz' his patch, I want to 
> ask for a discussion, but outside of that patch.
>
> AFAICT from the discussion it follows that sysupgrade, opkg and UCI should be 
> kept (as much as possible) orthogonal. From the thread: opkg cannot always be 
> assumed to be available, external config management may need all 
> configuration files, not just those that changed and not just diffs, config 
> files may need changes, etc.
>
> The backup functionality in sysupgrade serves a common case of keeping config 
> files over upgrades where that's needed because the rootfs/overlay is 
> re-created. Cases where sysupgrade does not destroy the (overlay) filesystem 
> contents also exist and obviously config files aren't lost than.

Is there any case where rootfs/overlay is not destroyed? Even for x86,
sysupgrade uses dd.

> After/during a sysupgrade a normal step is the restoration of the previous 
> configuration, i.e. of config files *and* extra previously installed packages 
> - currently sysupgrade does not handle re-install of extra user installed 
> packages. This functionality could also serve cases where a certain 
> configuration is to be put on a new or other device. Where the filesystem its 
> contents is not lost during sysupgrade, this would just amount to an opkg 
> upgrade of all outdated packages after sysupgrade has upgraded the kernel and 
> possibly the rootfs.
>
> In the more common sysupgrade case though (overlay contents are lost), some 
> means is needed to preserve configuration data in order to be able to restore 
> the configuration. Where this data is preserved during sysupgrade depends 
> completely on the device specific sysupgrade mechanism; *what* data is saved 
> and *how* it is re-applied is preferably opaque to, and independent of, 
> sysupgrade.

IMHO, backup should be a different script. It's strange to ask
sysupgrade for a backup (and worse to restore one). It might be just
legacy calling for a refactoring.

> Also, during upgrades new versions of packages may require updates to the 
> config files. Preserving customisations of the config files cannot just be 
> handled with back-up/restore and may require applying a diff or user 
> intervention. How to deal with that can really only be determined by the 
> package maintainer and so must be handled by the package itself. Anyhow, this 
> clearly is in the domain of opkg and applies to upgrades outside of 
> sysupgrade as well.

RPM, as opkg, simply saves the files and let user solve it manually.
Doing it automagically will require too much resource from maintainers
and the device that we might not have.
I guess we have what we can get. CM might replace the "package
installation and configuration" part of the backup but it is not a
backup. You still might need to save some data.
For me, backup and CM are different beasts.

> In short, factoring out the configuration management functionality (CM) seems 
> a good idea. The sysupgrade subsystem handles with upgrading kernel and 
> rootfs and may invoke CM functions to preserve the user configuration. CM can 
> could also take care of user installed packages. CM calls opkg to install 
> and/or upgrade additional packages. Truly general back-up (e.g. as a defense 
> against data loss) is outside the scope of sysupgrade.
>
> Quite a few efforts have already been made toward some kind of CM, notably by 
> offering this as an external service. The task to factor out generic CM  
> functionality that can be called upon in different contexts is probably quite 
> complicated and comments on that idea are welcome.
>
> What would be a practical API, if any, for CM ?
> What (minimum) configuration data would be needed by CM, i.e. what's needed 
> besides config files to store user install selections ?
> What's needed to enhance opkg so that it can handle in a general way updates 
> to config file while preserving user settings ?
> Compatibility issues ?
>
> Paul

I just opened a ticket for improving opkg
(https://bugs.openwrt.org/index.php?do=details_id=1821).

Another great improvement would be to require that every single file
in /etc/config should be uci generated. Today, some files are manually
edited. So, when (l)uci touches them, every single line is changed,
making diff simply useless. Would it be possible to enforce that rule
in OpenWrt? OpenWrt-packages could do that with travis (uci import
conf1/uci export conf1 to conf2/fail if conf1 and conf2 differ). It
will, although, prohibit any comments in config files from packages.

My patch and these suggestions try to reduce the burden of an upgrade.
Instead of implementing CM, it might be more useful to have tools that
help with the config merging process, like a vimdiff-like app for Luci
(remember, some users does not know how to use CLI).

Regards,

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org

Re: [OpenWrt-Devel] Use DHCP by default on single port devices

[Luiz Angelo Daros de Luca]

Hi Daniel,

I do often that kind of switch: dhcpd off, static -> dhcpc. Even
though I'm not sure about this change.

I read superficially the PR. I looks like a simple change from static
to dhcp on some devices. Correct me if I'm wrong.

I guess it will break some use cases. Imagine that this change is
applied to an AP device (one ethernet, one wireless).
wireless is disable by default, ethernet now requires a DHCP server.
The user will connect that AP to a single port router (that has DHCP).
How could the use configure it? If the user plugs into the router, it
gets an IP address but wireless is still off. If the user plugs into a
computer
ethernet port, it expects a DHCP server. The user will need to install
a DHCP server on the PC. We are coming from "plug the device into
a computer port, get an IP address from device DHCP, configure the
device" to "configure PC to use static address, configure a DHCP
server, plug
the device and configure it". Remember that some home users have
limited network knowledge and no CLI experience.

Will it affect failsafe too?

Most enterprise devices do use DHCP client as default. However, they
still have a static IP address as a fallback.
If that alternative is not available, I'm fully against this change.
Static IP address might give some extra job but it is always there.
Even with a fallback IP address mechanism, DHCP server does help
configure the device the first time without touching PC settings.

"DHCP server + static IP address" still works with enterprise but
"DHCP Client", even with an alternative static IP address, might not
work for some home users.

For enterprise users, maybe it's time to customize their own firmware.
Some simple uci-defaults script can do that job nicely.

Regards,

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

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

Re: [OpenWrt-Devel] [PATCH v3 0/4] base-files: add new backup options

[Luiz Angelo Daros de Luca]

Hi Tom,

> Unrelated to upgrade. I have dnsmasq and ntpd script disabled, i make a 
> backup, then reset my device to defaults or flash some other image without 
> keeping settings. After flashing back image version from which the backup was 
> made and restoring backup, dnsmasq and ntpd are enabled again. So these 
> settings were not backed up. Not even after your changes. I've checked backup 
> file and there are no initscripts inside it.

It's an interesting situation. init system, from sysv to systemd (and
including procd) uses symlinks for service activation. If there is a
link starting with "S" at /etc/rc.d/ and it is executable, service is
enabled and it will run. When you disable a service, you get that link
removed. You can check /etc/rc.common for code.

A backup is just a tarball with files. It does not make sense to have
tarball that removes a file when extracted.

As a (not tested) suggestion, you could replace thoses link with a
broken ones, like:

ln -sf disabled /etc/rc.d/S19dnsmasq
ln -sf disabled /etc/rc.d/K19dnsmasq
ln -sf disabled /etc/rc.d/S98sysntpd
ln -sf disabled /etc/rc.d/K98sysntpd

(maybe this should be the default behavior of rccommon disable())

Another alternative is to create a startup script that tries to
disable those services on every boot.

Both might work.

> I did not apply your patch 4 that concerns packages auto installation. I 
> think you should drop that one.

It does not autoinstall packages. If a user asked for it, it only
saves a list of installed packages to help reinstalling them.

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

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

Re: [OpenWrt-Devel] [LEDE-DEV] 18.06 Status?

[Luiz Angelo Daros de Luca]

> One characteristic from OpenWrt, different from other projects is the
> lack of a leader or a person who can gather others together, make some
> decisions or push for them to happen. If one doesn't like this title it
> can also be "Project Manager" or "Project Coordinator". This, in my
> view, makes a big difference for things to flow in time.

Maybe we just need someone to be the Release Coordinator, that can be
responsible for a single
release. John seems to be doing that job for this one.

ML info about 18.xx release is scarce. Maybe something was discussed
elsewhere (IRC, forum, in person)

I really thing that a time based release would work better without a
central project leader.
The "when" would already be set. The "what" is what was already commited.
It could even be automated. If something is not commited yet, just wait for
the next release.
If we could do it more often (6 or 8 months), it would not matter too much
if a feature was skipped.

I have pending patches both on maillist (improves backup) and github (fixes
easy-rsa) that I would like
to have them commited (or even rejected). Most (if not all) pending patches
on github (77) or patchwork (44)
is from developers without commit access. They are potential future
developers that will keep the project
alive. I'm not specific talking about my patches but it would be kind to
encourage new devs to have their work
considered, even to say "NAK".

Regards,
---
  Luiz Angelo Daros de Luca
 luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH v2 2/4] base-files: add sysupgrade -u to skip unchanged files

[Luiz Angelo Daros de Luca]

> This patch series works very nicely for me on ar71xx, brcm47xx, ipq806x
> and lantiq, -u unclutters the overlay contents quite significantly and
> makes spotting (manual) changes a lot easier.

Thanks Stefan for the feedback. If you want to simply spot changes, I would
recommend '-o -l'.
I normally use '-o -u -k -b mybkp.tgz'.

I use backup like these for years and since last year I'm trying to share
it to everybody. It has already saved me several hours.

For those that want to keep track, I'm using this branch for it:

https://github.com/luizluca/openwrt/raw/better-backups-v2/package/base-files/files/sbin/sysupgrade

It already has some minor fixes on top of sent patches.

And for those that simply want to test it (or use it):

$ wget -O /sbin/sysupgrade.alt
https://raw.githubusercontent.com/luizluca/openwrt/better-backups-v2/package/base-files/files/sbin/sysupgrade
$ chmod +x /sbin/sysupgrade.alt

It's a shame githubusercontent.com forces https.

It is safe to use this "standalone version" even on LEDE 17.01.x for
creating backups (-b) as all used code is in sysupgrade itself.
However, I still use unchanged sysupgrade for flashing (passing the backup
archive using -f). Flashing depends on external files (/lib/upgrade)
whose changes might also depend on a sysupgrade change.

Regards,

---
  Luiz Angelo Daros de Luca
 luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2 4/4] base-files: add sysupgrade -k to save list of pkgs

[Luiz Angelo Daros de Luca]

When '-k' is used, sysupgrade inserts into backup a new file
/etc/sysupgrade.installed which contains pkgname and
origin (rom, overlay, unknown).

It's maily used to reinstall all extra packages:

 # opkg update
 # grep "\toverlay" etc/sysupgrade.installed | cut -f1 | xargs opkg install
 # rm etc/sysupgrade.installed

Signed-off-by: Luiz Angelo Daros de Luca <luizl...@gmail.com>
---
 package/base-files/files/sbin/sysupgrade | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/package/base-files/files/sbin/sysupgrade 
b/package/base-files/files/sbin/sysupgrade
index 01a942bac6..c5067a757b 100755
--- a/package/base-files/files/sbin/sysupgrade
+++ b/package/base-files/files/sbin/sysupgrade
@@ -11,6 +11,7 @@ export SAVE_CONFIG=1
 export SAVE_OVERLAY=0
 export SAVE_OVERLAY_PATH=
 export SAVE_PARTITIONS=1
+export SAVE_INSTALLED_PKGS=0
 export SKIP_UNCHANGED=0
 export CONF_IMAGE=
 export CONF_BACKUP_LIST=0
@@ -31,6 +32,7 @@ while [ -n "$1" ]; do
-c) export SAVE_OVERLAY=1 SAVE_OVERLAY_PATH=/etc;;
-o) export SAVE_OVERLAY=1 SAVE_OVERLAY_PATH=/;;
-p) export SAVE_PARTITIONS=0;;
+   -k) export SAVE_INSTALLED_PKGS=1;;
-u) export SKIP_UNCHANGED=1;;
-b|--create-backup) export CONF_BACKUP="$2" NEED_IMAGE=1; 
shift;;
-r|--restore-backup) export CONF_RESTORE="$2" NEED_IMAGE=1; 
shift;;
@@ -50,6 +52,7 @@ done
 
 export CONFFILES=/tmp/sysupgrade.conffiles
 export CONF_TAR=/tmp/sysupgrade.tgz
+export INSTALLED_PACKAGES=/etc/sysupgrade.installed
 
 IMAGE="$1"
 
@@ -67,6 +70,8 @@ upgrade-option:
-u   skip from backup files that are equals to those in /rom
-n   do not save configuration over reflash
-p   do not attempt to restore the partition table after flash.
+   -k   include in backup a list of current installed packages at
+$INSTALLED_PACKAGES
-T | --test
 Verify image and config .tar.gz but do not actually flash.
-F | --force
@@ -203,6 +208,15 @@ fi
 
 include /lib/upgrade
 
+targz_append() {
+   local tar="$1"
+   local append_tar="$2"
+   (   gunzip -c "$tar" | head -c -1024;
+   gunzip -c $append_tar
+   ) | gzip > $tar.new
+   mv -f $tar.new $tar
+}
+
 do_save_conffiles() {
local conf_tar="$1"
 
@@ -219,6 +233,22 @@ do_save_conffiles() {
[ "$VERBOSE" -gt 1 ] && TAR_V="v" || TAR_V=""
tar c${TAR_V}zf "$conf_tar" -T "$CONFFILES" 2>/dev/null
 
+   if [ "$SAVE_INSTALLED_PKGS" -eq 1 ]; then
+   mkdir -p /tmp/etc
+   cd /tmp/
+
+   # Format: pkg-name{rom,overlay,unkown}
+   # rom is used for pkgs in /rom, even if updated later
+   find /usr/lib/opkg/info -name "*.control" \( \
+   \( -exec test -f /rom/{} \; -exec echo {} rom \; \) -o \
+   \( -exec test -f /overlay/upper/{} \; -exec echo {} 
overlay \; \) -o \
+   \( -exec echo {} unknown \; \) \
+   \) | sed -e 's,.*/,,;s/\.control /\t/' > 
${INSTALLED_PACKAGES:1}
+
+   tar c${TAR_V}zf sysupgrade.installed.packages.tgz 
${INSTALLED_PACKAGES:1}
+   targz_append "$conf_tar" sysupgrade.installed.packages.tgz
+   rm -f sysupgrade.installed.packages.tgz ${INSTALLED_PACKAGES:1}
+   fi
rm -f "$CONFFILES"
 }
 
-- 
2.16.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2 3/4] base-files: add sysupgrade -o to save all overlay files

[Luiz Angelo Daros de Luca]

Add sysupgrade '-o' option in order to include all overlay files in
backup, except for those that are from packages but including files
listed in conffiles, sysupgrade.conf or /lib/upgrade/keep.d.

With '-u' option, it will skip files equals to /rom and conffiles that
were not changed.

Signed-off-by: Luiz Angelo Daros de Luca <luizl...@gmail.com>
---
 package/base-files/files/sbin/sysupgrade | 46 +---
 1 file changed, 43 insertions(+), 3 deletions(-)

diff --git a/package/base-files/files/sbin/sysupgrade 
b/package/base-files/files/sbin/sysupgrade
index 4d221ef5d6..01a942bac6 100755
--- a/package/base-files/files/sbin/sysupgrade
+++ b/package/base-files/files/sbin/sysupgrade
@@ -9,6 +9,7 @@ export INTERACTIVE=0
 export VERBOSE=1
 export SAVE_CONFIG=1
 export SAVE_OVERLAY=0
+export SAVE_OVERLAY_PATH=
 export SAVE_PARTITIONS=1
 export SKIP_UNCHANGED=0
 export CONF_IMAGE=
@@ -27,7 +28,8 @@ while [ -n "$1" ]; do
-v) export VERBOSE="$(($VERBOSE + 1))";;
-q) export VERBOSE="$(($VERBOSE - 1))";;
-n) export SAVE_CONFIG=0;;
-   -c) export SAVE_OVERLAY=1;;
+   -c) export SAVE_OVERLAY=1 SAVE_OVERLAY_PATH=/etc;;
+   -o) export SAVE_OVERLAY=1 SAVE_OVERLAY_PATH=/;;
-p) export SAVE_PARTITIONS=0;;
-u) export SKIP_UNCHANGED=1;;
-b|--create-backup) export CONF_BACKUP="$2" NEED_IMAGE=1; 
shift;;
@@ -60,6 +62,8 @@ upgrade-option:
-f   restore configuration from .tar.gz (file or url)
-i   interactive mode
-c   attempt to preserve all changed files in /etc/
+   -o   attempt to preserve all changed files in /, exept those
+from packages but including changed confs.
-u   skip from backup files that are equals to those in /rom
-n   do not save configuration over reflash
-p   do not attempt to restore the partition table after flash.
@@ -129,12 +133,48 @@ add_conffiles() {
 
 add_overlayfiles() {
local file="$1"
-   ( cd /overlay/upper/; find ./etc \( -type f -o -type l \) $find_filter 
| sed \
+
+   local packagesfiles=$1.packagesfiles
+   touch "$packagesfiles"
+
+   if [ "$SAVE_OVERLAY_PATH" = / ]; then
+   local conffiles=$1.conffiles
+   local keepfiles=$1.keepfiles
+
+   list_conffiles | cut -f2 -d ' ' | sort -u > "$conffiles"
+
+   # backup files from /etc/sysupgrade.conf and 
/lib/upgrade/keep.d, but
+   # ignore those aready controlled by opkg conffiles
+   find $(sed -ne '/^[[:space:]]*$/d; /^#/d; p' \
+   /etc/sysupgrade.conf /lib/upgrade/keep.d/* 2>/dev/null) 
\
+   \( -type f -o -type l \) 2>/dev/null | sort -u |
+   grep -h -v -x -F -f $conffiles > "$keepfiles"
+
+   # backup conffiles, but only those changed if '-u'
+   [ $SKIP_UNCHANGED = 1 ] &&
+   list_changed_conffiles | sort -u > "$conffiles"
+
+   # do not backup files from packages, except those listed
+   # in conffiles and keep.d
+   find /usr/lib/opkg/info -type f -name "*.list" | sort -u |
+   xargs -r grep -h -v -x -F -f $conffiles |
+   grep -v -x -F -f $keepfiles > "$packagesfiles"
+   rm -f "$keepfiles" "$conffiles"
+   fi
+
+   # busybox grep bug when file is empty
+   [ -s "$packagesfiles" ] || echo > $packagesfiles
+
+   ( cd /overlay/upper/; find .$SAVE_OVERLAY_PATH \( -type f -o -type l \) 
$find_filter | sed \
-e 's,^\.,,' \
-e '\,^/etc/board.json$,d' \
-e '\,/[^/]*-opkg$,d' \
-e '\,^/etc/urandom.seed$,d' \
-   )> "$file"
+   -e '\,^/usr/lib/opkg/.*,d' \
+   ) | grep -v -x -F -f $packagesfiles > "$file"
+
+   rm -f "$packagesfiles"
+
return 0
 }
 
-- 
2.16.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2 2/4] base-files: add sysupgrade -u to skip unchanged files

[Luiz Angelo Daros de Luca]

With '-u', for a file /aaa/bbb/ccc enlisted for backup,
it will only get into backup if /rom/aaa/bbb/ccc does not
exist or /aaa/bbb/ccc is different from /rom/aaa/bbb/ccc.

It also works with '-c', but only effective for files touched
but not modified.

Signed-off-by: Luiz Angelo Daros de Luca <luizl...@gmail.com>
---
 package/base-files/files/sbin/sysupgrade | 27 +++
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/package/base-files/files/sbin/sysupgrade 
b/package/base-files/files/sbin/sysupgrade
index 46e46c3342..4d221ef5d6 100755
--- a/package/base-files/files/sbin/sysupgrade
+++ b/package/base-files/files/sbin/sysupgrade
@@ -10,6 +10,7 @@ export VERBOSE=1
 export SAVE_CONFIG=1
 export SAVE_OVERLAY=0
 export SAVE_PARTITIONS=1
+export SKIP_UNCHANGED=0
 export CONF_IMAGE=
 export CONF_BACKUP_LIST=0
 export CONF_BACKUP=
@@ -28,6 +29,7 @@ while [ -n "$1" ]; do
-n) export SAVE_CONFIG=0;;
-c) export SAVE_OVERLAY=1;;
-p) export SAVE_PARTITIONS=0;;
+   -u) export SKIP_UNCHANGED=1;;
-b|--create-backup) export CONF_BACKUP="$2" NEED_IMAGE=1; 
shift;;
-r|--restore-backup) export CONF_RESTORE="$2" NEED_IMAGE=1; 
shift;;
-l|--list-backup) export CONF_BACKUP_LIST=1;;
@@ -52,12 +54,13 @@ IMAGE="$1"
 [ -z "$IMAGE" -a -z "$NEED_IMAGE" -a $CONF_BACKUP_LIST -eq 0 -o $HELP -gt 0 ] 
&& {
cat <...] 
-   $0 [-q] [-i] [-c]  
+   $0 [-q] [-i] [-c] [-u]  
 
 upgrade-option:
-f   restore configuration from .tar.gz (file or url)
-i   interactive mode
-c   attempt to preserve all changed files in /etc/
+   -u   skip from backup files that are equals to those in /rom
-n   do not save configuration over reflash
-p   do not attempt to restore the partition table after flash.
-T | --test
@@ -119,20 +122,19 @@ add_conffiles() {
local file="$1"
( find $(sed -ne '/^[[:space:]]*$/d; /^#/d; p' \
/etc/sysupgrade.conf /lib/upgrade/keep.d/* 2>/dev/null) \
-   -type f -o -type l 2>/dev/null;
+   \( -type f -o -type l \) $find_filter 2>/dev/null;
  list_changed_conffiles ) | sort -u > "$file"
return 0
 }
 
 add_overlayfiles() {
local file="$1"
-   find /overlay/upper/etc/ -type f -o -type l | sed \
-   -e 's,^/overlay\/upper/,/,' \
-   -e '\,/META_[a-zA-Z0-9]*$,d' \
-   -e '\,/functions.sh$,d' \
+   ( cd /overlay/upper/; find ./etc \( -type f -o -type l \) $find_filter 
| sed \
+   -e 's,^\.,,' \
+   -e '\,^/etc/board.json$,d' \
-e '\,/[^/]*-opkg$,d' \
-   -e '\,/etc/urandom.seed$,d' \
-   > "$file"
+   -e '\,^/etc/urandom.seed$,d' \
+   )> "$file"
return 0
 }
 
@@ -150,6 +152,15 @@ else
sysupgrade_init_conffiles="add_conffiles"
 fi
 
+find_filter=""
+if [ $SKIP_UNCHANGED = 1 ]; then
+   [ ! -d /rom/ ] && {
+   echo "'/rom/' is required by '-u'"
+   exit 1
+   }
+   find_filter='( ( -exec test -e /rom/{} ; -exec cmp -s /{} /rom/{} ; ) 
-o -print )'
+fi
+
 include /lib/upgrade
 
 do_save_conffiles() {
-- 
2.16.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2 1/4] base-files: minor cleanups on sysupgrade

[Luiz Angelo Daros de Luca]

Renamed add_uci_conffiles to add_conffiles as it includes
any conffiles listed, not only UCI ones.

Make do_save_conffiles arg mandatory

Allow other options after -l (like -c)

Signed-off-by: Luiz Angelo Daros de Luca <luizl...@gmail.com>
---
 package/base-files/files/sbin/sysupgrade | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/package/base-files/files/sbin/sysupgrade 
b/package/base-files/files/sbin/sysupgrade
index bf5428af25..46e46c3342 100755
--- a/package/base-files/files/sbin/sysupgrade
+++ b/package/base-files/files/sbin/sysupgrade
@@ -30,7 +30,7 @@ while [ -n "$1" ]; do
-p) export SAVE_PARTITIONS=0;;
-b|--create-backup) export CONF_BACKUP="$2" NEED_IMAGE=1; 
shift;;
-r|--restore-backup) export CONF_RESTORE="$2" NEED_IMAGE=1; 
shift;;
-   -l|--list-backup) export CONF_BACKUP_LIST=1; break;;
+   -l|--list-backup) export CONF_BACKUP_LIST=1;;
-f) export CONF_IMAGE="$2"; shift;;
-F|--force) export FORCE=1;;
-T|--test) export TEST=1;;
@@ -49,10 +49,10 @@ export CONF_TAR=/tmp/sysupgrade.tgz
 
 IMAGE="$1"
 
-[ -z "$IMAGE" -a -z "$NEED_IMAGE" -o $HELP -gt 0 ] && {
+[ -z "$IMAGE" -a -z "$NEED_IMAGE" -a $CONF_BACKUP_LIST -eq 0 -o $HELP -gt 0 ] 
&& {
cat <...] 
-   $0 [-q] [-i]  
+   $0 [-q] [-i] [-c]  
 
 upgrade-option:
-f   restore configuration from .tar.gz (file or url)
@@ -115,7 +115,7 @@ list_changed_conffiles() {
done
 }
 
-add_uci_conffiles() {
+add_conffiles() {
local file="$1"
( find $(sed -ne '/^[[:space:]]*$/d; /^#/d; p' \
/etc/sysupgrade.conf /lib/upgrade/keep.d/* 2>/dev/null) \
@@ -131,6 +131,7 @@ add_overlayfiles() {
-e '\,/META_[a-zA-Z0-9]*$,d' \
-e '\,/functions.sh$,d' \
-e '\,/[^/]*-opkg$,d' \
+   -e '\,/etc/urandom.seed$,d' \
> "$file"
return 0
 }
@@ -146,13 +147,13 @@ if [ $SAVE_OVERLAY = 1 ]; then
}
sysupgrade_init_conffiles="add_overlayfiles"
 else
-   sysupgrade_init_conffiles="add_uci_conffiles"
+   sysupgrade_init_conffiles="add_conffiles"
 fi
 
 include /lib/upgrade
 
 do_save_conffiles() {
-   local conf_tar="${1:-$CONF_TAR}"
+   local conf_tar="$1"
 
[ -z "$(rootfs_type)" ] && {
echo "Cannot save config while running from ramdisk."
@@ -247,7 +248,7 @@ if [ -n "$CONF_IMAGE" ]; then
get_image "$CONF_IMAGE" "cat" > "$CONF_TAR"
export SAVE_CONFIG=1
 elif ask_bool $SAVE_CONFIG "Keep config files over reflash"; then
-   [ $TEST -eq 1 ] || do_save_conffiles
+   [ $TEST -eq 1 ] || do_save_conffiles "$CONF_TAR"
export SAVE_CONFIG=1
 else
[ $TEST -eq 1 ] || rm -f "$CONF_TAR"
-- 
2.16.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2 0/4] [RFC] base-files: add new backup options

[Luiz Angelo Daros de Luca]

My previous patch on Nov2017 
(http://lists.infradead.org/pipermail/lede-dev/2017-November/009892.html)
generated some discussion because it depends on the presence of /rom to become
effetive. So I opted to turn it into a new sysupgrade option (-u).

Besides that, I added some more stuff to sysupgrade that I use in
my systems.

Each patch in this series is almost indepenly of each other.
Except for the first one, they add new sysupgrade options:

-u) equivalent to the previous patch. I think that, if adopted as
default in future, it will make upgrades cleaner. For now, it
is optional.

-o) this option tries to save everything that was changed. It includes
all new files, conffiles (works with -u), sysupgrade.conf and
keep.d. This is what I normally use in my backups as it saves both data
and confs, keeping them as clean as possible.

-k) This adds a new file that I use to quickly reinstall all extra
packages. A future improvement would be to use it in a service that installs
install those packages as soon as network is up (similar to uci-default
scripts)

For now, it is still pending to bump package release.

--
Luiz Angelo
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] WiFi client mode leaves router inaccessible if upstream network goes down

[Luiz Angelo Daros de Luca]

Nick, you can try lede-project bug tracker. I recently released rc1.

Em sex, 3 de fev de 2017 22:18, Nick Malyon <n...@fishun.co.uk> escreveu:

> Hi all,
>
> I tried to open the following bug report but Trac's spam filter wouldn't
> let me, so I thought I'd raise it on the mailing list to see what you
> think...
>
> I have a TP-Link TL-MR3020 v1.9 with Chaos Calmer 15.05.01. I'm using it
> to provide a WiFi access point to my phone/tablet while I travel, and it's
> acting as a WiFi client for the various hostels I visit.
>
> If you configure it as a wifi client with a wwan interface using the LuCI
> scan/join wizard, and then you configure a wifi access point on the same
> radio, the router works as expected and when you connect to the router's
> AP, you get Internet via the client connection.
>
> However, if you move out of range of the network the router is a client
> of, or if it goes down, when you power off the OpenWrt router and power
> back on, the access point won't come up.
>
> The AP will only come up if the client network you configured is also
> working; so you have no way to connect to the router over wifi, and no way
> to reconfigure the router, if that client network is down or out of range.
>
> This is a particular problem for a travel router because it will often
> move it out of range of the original upstream network, and you may only
> have a wifi-capable device with which to reconfigure it.
>
> The Ethernet port on the router does remain active, so I can tell it does
> actually boot. It's just the radio that doesn't come up. I managed to get
> back in range of a network once, and the router worked as expected.
>
> It doesn't matter whether the AP or client connection are configured first
> or second on the radio interface, and, unticking "bring up on boot" for the
> wwan interface has no effect on the behaviour.
>
> Steps to reproduce: Connect the router to a wifi network as a client using
> the Join wizard. Add a wifi master-mode access point on the same radio
> interface. Verify you can access the Internet by joining the router's new
> master AP. Reboot the router with the original network it was a client of
> turned off. Notice the router's AP you configured never comes up.
>
> Expected behaviour: The master access point of the router should always
> come up, regardless of the availability of the client network.
>
> If anyone has a workaround that would be great — currently I managed to
> get back in range of a network to make it accessible again, and now I run
> from batteries and delete the wifi client configuration every night before
> the jungle power goes out.
>
> If this is indeed a bug, if you could please raise it in Trac for me —
> sorry, I get a "rejected due to possible spam" error, maybe because of my
> location.
>
> Many thanks!
> - Nick
> ___________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-- 

Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Introducing the LEDE project

[Luiz Angelo Daros de Luca]

I like to take decisions based more on "Realpolitik" than on
ideology/feelings. I have no side and no feelings for any of people
involved. I just want to have a good router distribution.

What is a OSS project? It is the sum of work of people. So, the future of a
project lies on how much people will work on it.

Let's face: if you sum the commits count* of those leaving, you start to
worry about OpenWRT:

Core:
 10815 nbd <<
  4531 juhosg
  3649 blogic <<
  3436 florian
  2654 nico
  2183 jow <<
  1482 kaloz
  1414 hauke <<
   925 wbx
   718 cyrus <<

Packages:
  512 Steven Barth <<
   469 Ted Hess <<
   256 Marcel Denia
   250 Daniel Golle <<
   235 Nikos Mavrogiannopoulos
   230 sbyx
   214 Hannu Nyman
   202 Alexandru Ardelean
   162 Jo-Philipp Wich <<
   154 Nicolas Thill
(git shortlog -s -n | head -10)

*yes, I know that they are not the author of all commits but they were the
ones that reviewed the patches and committed them.

If you lose most of the committers, the project will REALLY lag behind, to
a point of losing its self sustainability. Those leaving represents more
than 50% of commits of all time and, since 2014, they are the top 6 devs
with more than 80% of commits.
(git shortlog -s -n 3328763a8d0abbcbcf79b5a91e6abbb0b55b3119..HEAD  | head
-10)
They are(were) the ones currently working.

One of the complaints was that there were no process of introducing new
devs. So, when a bunch of them leave, what will happen? Ease the process of
including new devs (which is one of the demanded changes)? Do we really
think that there is a suppressed supply of developers wanting to replace
the leaving devs?

It seems that the decision power in OpenWRT does not match the amount of
work each one is currently dedicating to the project.

What might happen with the fork?

OpenWRT loses 80% of its development power (not counting those that leave
to LEDE after).
LEDE might attract more devs with an open politic (as packages are much
better at github). In the end, if LEDE succeeds on balance more devs,
stability and new resources, everybody will use it and OpenWRT will start
to rot. If it fails, both projects might die and everybody loses.

This was already happened with OpenOffice/LibreOffice (I guess with
ffmpeg/libav less devs left). They created a new project because of
disagreement (with Oracle). Devs flew to the new project. The old one
started to rot and ended dropped to the community. I guess most of the
current downloaders of OpenOffice do not know LibreOffice and they are not
power users. With OpenWRT, most of downloaders are power users.

You can replace infrastructure in a matter of weeks. Replace a brand in
months. However, you need years or decades to form a development team.

What are the options for OpenWRT Decision Team (as the development team
just left)?

1) Do nothing. Let LEDE take its chances. If it succeed, it will take the
place of OpenWRT and OpenWRT will rot. If not, we'll might have a version
of mutual assured destruction.

2) The remaining OpenWRT Core Team accept some (or all) terms of the LEDE
Team. Face it. There were already most of the "OpenWRT Core Team". Now give
them the corresponding decision power.

Even if all the remaining of the OpenWRT Core Team resign now and give all
the control to LEDE, OpenWRT will be less affected than the current
situation.

If I felt that my position would put in danger a project on which I
dedicated and care so much, I would rather simply resign than let my work
be gone. OpenWRT should be more than someone's project. However, there is
no need to anyone to leave but a need of power transferring.

The ones with current decision power at OpenWRT will either give away some
of its power or they will lose it all (in favor of a rebooted OpenWRT
leaded by LEAD or because it simply became irrelevant).

Regards,
-- 

Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Introducing the LEDE project

[Luiz Angelo Daros de Luca]

It is really strange that the decision to create a new project was so
opaque when it was motivated to be a more "transparent project".
They could've started to be more transparent already with the decision to
create a new project.

Maybe the answer for the need of an external reboot might be not in the
names that jumped into but on those left behind.
Maybe it was easier to create a new project than to boot out the problems.

My 2 cents,

Em qua, 4 de mai de 2016 às 14:50, Roman Yeryomin <leroi.li...@gmail.com>
escreveu:

> On 4 May 2016 at 19:25, Kathy Giori <kathy.gi...@gmail.com> wrote:
> > On Tue, May 3, 2016 at 10:59 AM, Jo-Philipp Wich <j...@openwrt.org>
> wrote:
> >> Hi,
> >>
> >> we'd like to introduce LEDE, a reboot of the OpenWrt community
> >> .
> >>
> >> The project is founded as a spin-off of the OpenWrt project and shares
> >> many of the same goals.
> >
> > While I appreciate the enthusiasm, I do not see why you cannot apply
> > these same "principles" of openness and transparency to the OpenWrt
> > project. Makes no sense to me to branch the project. That simply
> > divides the resources in the community into fewer numbers working on
> > each fork.
>
> Exactly, tearing down the project and community without any real
> explanations (and plans to solve the stated issues) is just wrong.
>
> > Also wearing my hat within the prpl Foundation, which is funded by
> > industry sponsorships that in turn provides financial support for
> > OpenWrt, no one I have spoken to in prpl understands the reason for
> > this spin-off either. It'll cause more confusion and inefficiency in
> > industry. prpl will stick with OpenWrt, and I expect most companies
> > who follow and/or contribute to OpenWrt will stick with it too.
> >
> > kathy
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-- 

Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] upstream opkg

[Luiz Angelo Daros de Luca]

Thanks Jo,

Do you have any idea how it would be possible to reduce upstream opkg
size? Create
a libarchive-mini?

Maybe we can simply revert libarchive adoption (specially if we turn it
into a ./configure option). I guess it is limited to libopkg/pkg_extract.c
file.
Maybe it is better to keep an openwrt customized pkg_extract.c than to
maintain an full opkg fork (with known issues).

deb and rpm are already possible busybox applet. Maybe opkg could also
become one (and share some code with tar/gzip).

Regards,
-- 

Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] IEEE 802.11s

[Luiz Angelo Daros de Luca]

Prabhu, OpenWRT does not have source code of projects inside its own
source. All needed sources, including the linux kernel, is downloaded
during the build. You'll only find kernel patches and the kernel packages
definition (which packs modules).

If you want to see the result kernel source, build OpenWRT once and check
builddir.

Regards,

Em qui, 21 de abr de 2016 16:34, Prabhu Janakaraj <wsupra...@gmail.com>
escreveu:

> Hi all,
> I am a newbie to embedded devices. I have used openwrt for building mesh
> network. I am able to build firmware from the source code and get it
> working.
>
> But I want to modifying certain things in Mesh Routing algorithm HWMP,
> kind of implementing a new routing algorithm.
>
> In generic linux kernel source code, I am able to figure the location of
> the files for IEEE 802.11. But when I look into the source code of OpenWRT,
> I am unable to find the same. Is there any place where I should look for
> the IEEE 802.11 and IEEE 802.11 Mesh ?
>
> I am kind of what to implement my own routing algorithm for Mesh.
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-- 

Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] opkg upgrade all

[Luiz Angelo Daros de Luca]

Just like any Linux distribution, it is recommended to not mix a kernel
from a different release with runtime from another release. However, if
there is no incompatibility between them, you are free to do as you want.
The more distance each kernel is, the more likely to have
incompatibilities.

OpenWRT, although, is not developed with upgrade in mind. So, packages that
are renamed will be kept at the old version, and new package will not be
installed if not required by an existing package. You might get a mix of
kernel, old and new packages at the end. If, by chance, they are all
compatible, it will work nicely.

You'll need to mix old and new repos as any new kernel module must come
from the old repo. I don't know how well opkg deal with this.

Besides that, there is the extra space used. I guess jffs2 is also worse in
performance and compression.

It is just no good reason to do an upgrade and not a reflash. If you and
the packages are doing the backup correctly, you just need to reinstall all
extra packages after the new system is installed.

Regards,

Em qua, 30 de mar de 2016 02:30, Michal Hrusecky <michal.hruse...@nic.cz>
escreveu:

> Luiz Angelo Daros de Luca -  1:41 30.03.16 wrote:
> > Michal,
> >
> > Google is your friend ;-)
>
> He pretends he is, but didn't provided the answer I was looking for, just
> plenty of workarounds I mentioned ;-)
>
> > But I'll easy your search
> > https://wiki.openwrt.org/doc/techref/opkg
> >
> > Check the upgrade description.
>
> Reread and the only thing that is mentioned there is general discourage to
> do
> upgrades and be careful what you are doing and that there are generally no
> updates available apart from trunk and that opkg will not upgrade kernel.
> No
> technical problem and no specific issue with upgrade all.
>
> > Regards
> >
> > Em ter, 29 de mar de 2016 às 04:45, Michal Hrusecky <
> michal.hruse...@nic.cz>
> > escreveu:
> >
> > > Hi,
> > >
> > > there is a patch in OpenWRT that disables option to upgrade all
> packages
> > > and
> > > allows upgrading only specified packages which leads to plenty of
> answers
> > > online how to do that[1][2][3][...] Does anybody remembers the reason
> for
> > > disabling it? The only thing I can think of is discouraging people from
> > > doing
> > > upgrades and encourage them to reflash new squashfs image as they
> might not
> > > have enough free space. But as you can see, people will try and do it
> > > anyway so
> > > it might be a good idea to let the command there as it will be probably
> > > safer
> > > with integrated command than with random scripts on internet. Or is
> there
> > > some
> > > other reason and some real problem?
> > >
> > > [1] https://sandalov.org/blog/1777/
> > > [2]
> > >
> https://www.codeden.net/2015/05/upgrade-all-openwrt-packages-with-a-single-line-command/
> > > [3] http://blog.vanutsteen.nl/2014/01/12/openwrt-upgrade-all-packages/
> > > ___
> > > openwrt-devel mailing list
> > > openwrt-devel@lists.openwrt.org
> > > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> > >
> > --
> >
> > Luiz Angelo Daros de Luca
> > luizl...@gmail.com
>
-- 

Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] opkg upgrade all

[Luiz Angelo Daros de Luca]

Michal,

Google is your friend ;-)

But I'll easy your search
https://wiki.openwrt.org/doc/techref/opkg

Check the upgrade description.

Regards

Em ter, 29 de mar de 2016 às 04:45, Michal Hrusecky <michal.hruse...@nic.cz>
escreveu:

> Hi,
>
> there is a patch in OpenWRT that disables option to upgrade all packages
> and
> allows upgrading only specified packages which leads to plenty of answers
> online how to do that[1][2][3][...] Does anybody remembers the reason for
> disabling it? The only thing I can think of is discouraging people from
> doing
> upgrades and encourage them to reflash new squashfs image as they might not
> have enough free space. But as you can see, people will try and do it
> anyway so
> it might be a good idea to let the command there as it will be probably
> safer
> with integrated command than with random scripts on internet. Or is there
> some
> other reason and some real problem?
>
> [1] https://sandalov.org/blog/1777/
> [2]
> https://www.codeden.net/2015/05/upgrade-all-openwrt-packages-with-a-single-line-command/
> [3] http://blog.vanutsteen.nl/2014/01/12/openwrt-upgrade-all-packages/
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-- 

Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] cannot boot current x86 snapshot

[Luiz Angelo Daros de Luca]

Hello,

I just tried the
https://downloads.openwrt.org/snapshots/trunk/x86/generic/openwrt-x86-generic-combined-squashfs.img
(r49083) and
it was not able to boot. The kernel cmdline is missing the disk signature:

...block2mtd.block2mtd=PARTUUID=-02,65536,rootfs,5...

It should be PARTUUID=-02 and not PARTUUID=-02.
I'm able to boot if I manually replace PARTUUID=-02 by /dev/sda2.

Regards,
-- 

Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [RFC] fstools/overlayfs race condition

[Luiz Angelo Daros de Luca]

Maybe fsfreeze can avoid the race condition. (if this works with the
involved FS)
http://linux.die.net/man/8/fsfreeze
https://github.com/karelzak/util-linux/blob/master/sys-utils/fsfreeze.c

Or just temporary remount source fs as ro. It might make some writing
process unhappy but I'll keep file filesystem state.

My two cents.

Regards,

Em seg, 7 de mar de 2016 às 10:10, John Crispin <blo...@openwrt.org>
escreveu:

>
>
> On 07/03/2016 14:03, Roman Yeryomin wrote:
> > There is a race between `cp -a /tmp/root/* /rom/overlay` from
> > libfstools/overlay.c and a process creating new file(s) before
> > pivot(/rom, /mnt) occured.
> > That is a process can create a file and it will not be copied.
> >
> > Currently I do additional copy after jffs2 is ready, which is kind of
> > cumbersome (see attached patch), but there are still few potentially
> > erroneous scenarios:
> > 1. a process may recreate the file by the time second cp occurs
> > 2. a process may delete a file (not existing at that moment) and
> > second cp will copy it again
> > 3. a process may want to read created file before second cp occurs
> >
> > If attached patch is the way to go I will properly submit it.
> > Otherwise there should be a more fundamental fix but I don't see a way
> > to fix this properly.
> >
> >
>
> Hi Roman
>
> that race has been there since the day we do overlayfs. i am always
> surprised that it has not exploded in a big way yet. the only way i see
> are workarounds such as yours or sending out lots of SIGSTOP and the
> continues when we copied the files. either way it will be ugly and
> require protective gear.
>
> i'll ponder this and see if we can find a better way
>
> John
> _______________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-- 

Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] prereq: fixes checks that prefix env vars (ex:git)

[Luiz Angelo Daros de Luca]

If a prereq-build command check defines a command env var (ex: MANPAGER=cat git 
...)
prereq SetupHostCommand breaks. This is because it looks for the binary using 
which on
the first space-separated item (which might be the env var definition)

This patch replaces bash substitution by a sed regex that removes both env 
parameters and
command args.
---
 include/prereq.mk | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/prereq.mk b/include/prereq.mk
index 6cb590e..839b663 100644
--- a/include/prereq.mk
+++ b/include/prereq.mk
@@ -92,8 +92,11 @@ define SetupHostCommand
   $(call QuoteHostCommand,$(7)) $(call QuoteHostCommand,$(8)) \
   $(call QuoteHostCommand,$(9)); do \
if [ -n "cmd" ]; then \
+   
regex_rm_vars='s/^(\w+=(\['\'\"]']|'\''[^'\'']*'\''|"[^"]*"|[^ ]*(\\ )?)* 
)*//'; \
+   regex_rm_args='s/[[:space:]].*//'; \
+   
regex_clean_cmd="regex_rm_vars;regex_rm_args"; \
bin="(PATH="$(subst $(space),:,$(filter-out 
$(STAGING_DIR_HOST)/%,$(subst :,$(space),$(PATH" \
-   which "{cmd%% *}")"; \
+   which "(echo cmd | sed -re 
"regex_clean_cmd")")"; \
if [ -x "bin" ] && eval "cmd" 
>/dev/null 2>/dev/null; then \
mkdir -p "$(STAGING_DIR_HOST)/bin"; \
ln -sf "bin" 
"$(STAGING_DIR_HOST)/bin/$(strip $(1))"; \
-- 
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] RFC: dropping oprofile

[Luiz Angelo Daros de Luca]

Thanks Felix. It would take me sometime to debug this.

Regards,

Em qui, 21 de jan de 2016 às 12:12, Felix Fietkau <n...@openwrt.org>
escreveu:

> On 2016-01-21 14:42, Kevin Darbyshire-Bryant wrote:
> > Reverting 0ca8e85462074e713be6468a3ea7259caca1b1ea appears to allow perf
> > to compile again.
> >
> > "
> >  elfutils: bump to 0.165
> >
> > Signed-off-by: Luiz Angelo Daros de Luca <luizl...@gmail.com>
> > git-svn-id: svn://svn.openwrt.org/openwrt/trunk@48393
> > 3c298f89-4303-0410-b956-a3cf2f4a3e73"
> Fixed in r48429.
>
> Luiz, the updated elfutils version assumed you were using glibc 2.22 or
> newer (had some elf compressed header stuff in there).
> The patch that I added backports the missing definitions.
>
> - Felix
>
-- 

Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] elfutils: bump to 0.165

[Luiz Angelo Daros de Luca]

Signed-off-by: Luiz Angelo Daros de Luca <luizl...@gmail.com>
---
 package/libs/elfutils/Makefile  | 8 
 package/libs/elfutils/patches/003-libint-stub.patch | 2 +-
 package/libs/elfutils/patches/005-build_only_libs.patch | 4 ++--
 package/libs/elfutils/patches/006-libdw_LIBS.patch  | 6 +++---
 package/libs/elfutils/patches/100-musl-compat.patch | 4 ++--
 package/libs/elfutils/patches/101-no-fts.patch  | 4 ++--
 6 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/package/libs/elfutils/Makefile b/package/libs/elfutils/Makefile
index b1e52ba..fa7bc55 100644
--- a/package/libs/elfutils/Makefile
+++ b/package/libs/elfutils/Makefile
@@ -7,12 +7,12 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=elfutils
-PKG_VERSION:=0.164
+PKG_VERSION:=0.165
 PKG_RELEASE:=1
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
 PKG_SOURCE_URL:=http://fedorahosted.org/releases/e/l/$(PKG_NAME)/$(PKG_VERSION)
-PKG_MD5SUM:=2e4536c1c48034f188a80789a59114d8
+PKG_MD5SUM:=c37fdbe18e848002b451562cba964679
 PKG_MAINTAINER:=Luiz Angelo Daros de Luca <luizl...@gmail.com>
 PKG_LICENSE:=GPL-3.0+
 PKG_LICENSE_FILES:=COPYING COPYING-GPLV2 COPYING-LGPLV3
@@ -28,7 +28,6 @@ include $(INCLUDE_DIR)/nls.mk
 define Package/elfutils/Default
   SECTION:=libs
   CATEGORY:=Libraries
-  DEPENDS:=$(INTL_DEPENDS)
   TITLE:=ELF manipulation libraries
   URL:=https://fedorahosted.org/elfutils/
 endef
@@ -41,12 +40,13 @@ endef
 
 define Package/libdw
   $(call Package/elfutils/Default)
-  DEPENDS:=libelf1 +zlib +libbz2
+  DEPENDS:=libelf1 +libbz2
   TITLE+= (libdw)
 endef
 
 define Package/libelf1
   $(call Package/elfutils/Default)
+  DEPENDS:=$(INTL_DEPENDS) +zlib
   TITLE+= (libelf)
 endef
 
diff --git a/package/libs/elfutils/patches/003-libint-stub.patch 
b/package/libs/elfutils/patches/003-libint-stub.patch
index cf6539f..d6cc707 100644
--- a/package/libs/elfutils/patches/003-libint-stub.patch
+++ b/package/libs/elfutils/patches/003-libint-stub.patch
@@ -1,6 +1,6 @@
 --- a/libelf/libelfP.h
 +++ b/libelf/libelfP.h
-@@ -42,6 +42,9 @@
+@@ -43,6 +43,9 @@
  #include 
  #include 
  
diff --git a/package/libs/elfutils/patches/005-build_only_libs.patch 
b/package/libs/elfutils/patches/005-build_only_libs.patch
index 0077369..e39b395 100644
--- a/package/libs/elfutils/patches/005-build_only_libs.patch
+++ b/package/libs/elfutils/patches/005-build_only_libs.patch
@@ -1,6 +1,6 @@
 --- a/Makefile.in
 +++ b/Makefile.in
-@@ -372,8 +372,7 @@ ACLOCAL_AMFLAGS = -I m4
+@@ -378,8 +378,7 @@ AM_MAKEFLAGS = --no-print-directory
  pkginclude_HEADERS = version.h
  
  # Add doc back when we have some real content.
@@ -12,7 +12,7 @@
 COPYING COPYING-GPLV2 COPYING-LGPLV3
 --- a/Makefile.am
 +++ b/Makefile.am
-@@ -23,8 +23,7 @@ ACLOCAL_AMFLAGS = -I m4
+@@ -27,8 +27,7 @@ AM_MAKEFLAGS = --no-print-directory
  pkginclude_HEADERS = version.h
  
  # Add doc back when we have some real content.
diff --git a/package/libs/elfutils/patches/006-libdw_LIBS.patch 
b/package/libs/elfutils/patches/006-libdw_LIBS.patch
index bcea100..34c4447 100644
--- a/package/libs/elfutils/patches/006-libdw_LIBS.patch
+++ b/package/libs/elfutils/patches/006-libdw_LIBS.patch
@@ -1,11 +1,11 @@
 --- a/libdw/Makefile.in
 +++ b/libdw/Makefile.in
-@@ -994,7 +994,7 @@ libdw.so$(EXEEXT): $(srcdir)/libdw.map l
+@@ -996,7 +996,7 @@ libdw.so$(EXEEXT): $(srcdir)/libdw.map l
-Wl,--enable-new-dtags,-rpath,$(pkglibdir) \
-Wl,--version-script,$<,--no-undefined \
-Wl,--whole-archive $(filter-out $<,$^) -Wl,--no-whole-archive\
--  -ldl $(argp_LDADD) $(zip_LIBS)
-+  -ldl $(argp_LDADD) $(zip_LIBS) $(LIBS)
+-  -ldl -lz $(argp_LDADD) $(zip_LIBS)
++  -ldl -lz $(argp_LDADD) $(zip_LIBS) $(LIBS)
@$(textrel_check)
$(AM_V_at)ln -fs $@ $@.$(VERSION)
  
diff --git a/package/libs/elfutils/patches/100-musl-compat.patch 
b/package/libs/elfutils/patches/100-musl-compat.patch
index 7427e9a..25e1504 100644
--- a/package/libs/elfutils/patches/100-musl-compat.patch
+++ b/package/libs/elfutils/patches/100-musl-compat.patch
@@ -151,7 +151,7 @@
  #include 
 --- a/src/ldlex.c
 +++ b/src/ldlex.c
-@@ -1099,7 +1099,7 @@ char *ldtext;
+@@ -1106,7 +1106,7 @@ char *ldtext;
  #include 
  #include 
  #include 
@@ -621,7 +621,7 @@
  #include 
 --- a/libcpu/i386_lex.c
 +++ b/libcpu/i386_lex.c
-@@ -571,7 +571,7 @@ char *i386_text;
+@@ -578,7 +578,7 @@ char *i386_text;
  #endif
  
  #include 
diff --git a/package/libs/elfutils/patches/101-no-fts.patch 
b/package/libs/elfutils/patches/101-no-fts.patch
index b1b2308..6a3e940 100644
--- a/package/libs/elfutils/patches/101-no-fts.patch
+++ b/package/libs/elfutils/patches/101-no-fts.patch
@@ -72,7 +72,7 @@
struct parse_opt *opt = state->hook;
 --- a/libdwfl/Makefile.in
 +++ b/libdwfl/Makefile.in
-@@ -121,7 +121,7 @@ am__libdwfl_a_SOURCES_DIST = dwfl_begin.
+@@ -120,7 +120,7 @@ am__libdwfl_a_SOUR

Re: [OpenWrt-Devel] [PATCH][RFC] x86: Save and restore partition table during upgrade

[Luiz Angelo Daros de Luca]

n 1
> +   fi
> +
> +   #if nothing changed, we do not need to restore
> +   if [ "$before" = "$after" ]; then
> +   echo "Parition layout unchanged"
> +   return 0
> +   fi
> +
> +   diff=$(grep -F -x -v -f /tmp/sfdisk.before.nonempty
> /tmp/sfdisk.after.nonempty)
> +
> +   #if partition layout changed, do not restore
> +   if [ -n "$diff" ]; then
> +   echo "Partition layout changed, not restoring."
> +   return 1
> +   fi
> +
> +   echo "Restoring partition table..."
> +   sfdisk $disk --force < /tmp/sfdisk.before >&/dev/null
> +   fi
> +}
> +
>  platform_do_upgrade() {
>     platform_export_bootpart
>
> if [ -b "${BOOTPART%[0-9]}" ]; then
> sync
> +   [ $SAVE_PARTITIONS = "1" ] && save_bootparts
> get_image "$@" | dd of="${BOOTPART%[0-9]}" bs=4096
> conv=fsync
> sleep 1
> +   [ $SAVE_PARTITIONS = "1" ] && restore_bootparts
> fi
>  }
> +
> --
> 2.1.4
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-- 

Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Atomic/failsafe upgrades?

[Luiz Angelo Daros de Luca]

Hi,

I have a client that just asked for this. As their router uses grub, its
script if enough for the fallback logic. I implemented a POC and it worked
perfectly. There is no watchdog integration so the reboot is manually done
when the new firmware fails.

I'm just waiting for them to give me a go in order to implement a complete
solution. I'll post to the list when I get a working patch.

The basic idea is to have two rootfs (and two rootfs data) in flash. I
embed the kernel into squashfs, making rootfs self contained (as grub2 can
read squashfs). If I give to sysupgrade a squashfs image, it writes
alternately into the rootfs areas. It tries to boot the new flash once
(like grub-once). If it works, mark it as permanent. If not, just reboot
and the previous flash will be used.

Now, when I give a full xxx.img file, it overwrite all the system just like
the normal openwrt image does (something like proprietary xxx_boot.img). Of
course, this type of boot firmware does not have the fallback.

Regards,

Em qui, 7 de jan de 2016 18:16, Arthur Davis <silper...@gmail.com> escreveu:

> With failsafe upgrades, there always has to be "the thing that notices"
> when something goes wrong. With a wholesale upgrade, OpenWrt can't be that
> thing. The bootloader is probably the best candidate.
>
> Also, I've worked on projects that used a separate supervisory processor
> that was able to dictate the boot image. In one case, it was a very
> powerful processor that had its own jobs in the system. In another case, it
> was very small and just watched out for system health. One way to dictate
> the boot image is to have the OpenWrt system ask via tftp, but there are
> probably other possibilities depending on your system. (And this probably
> doesn't really apply unless you are able to specify some fundamental bits
> of the hardware.)
>
> Lastly, there is OpenWrt's failsafe mode which doesn't solve all of your
> concerns, but it should be noted:
> https://wiki.openwrt.org/doc/howto/generic.failsafe
>
> Arthur
>
>
> On Thu, Jan 7, 2016 at 11:48 AM, Eric Schultz <eschu...@prplfoundation.org
> > wrote:
>
>> Joshua,
>>
>> I've had some similar interest in this topic.  As far as I know, there
>> isn't anything like this on OpenWrt. There might be some overlap with the
>> discussion of automatic updates from last week as well.
>>
>> Eric
>>
>> On Thu, Jan 7, 2016 at 11:44 AM, Joshua Judson Rosen <
>> jro...@harvestai.com> wrote:
>>
>>> I'm trying to decide on a Linux-based OS to use in a project,
>>> and one of the features that I want is failsafe upgrades--
>>> such that failing to run an upgrade procedure to completion
>>> should be non-catastrophic, and automatically recoverable; the
>>> system should always be able to (re)boot into a state
>>> where it can run normally, either in the upgraded state
>>> or in the pre-upgrade state.
>>>
>>> One option that I've deal with is to keep two parallel
>>> system installs, upgrade whichever one you're not currently using,
>>> try to boot _that one_ after the upgrade finishes,
>>> and fall back to the last-known-good install
>>> if either the upgrade fails in the middle or the boot into
>>> the preferred install fails. IIRC, there's something like this
>>> available with Yocto; and, if I understand it correctly,
>>> NixOS also does something similar in spirit to this
>>> (though perhaps with a different granularity).
>>>
>>> Are there any provisions for doing something like that
>>> with OpenWRT?
>>>
>>> --
>>> "Don't be afraid to ask (λf.((λx.xx) (λr.f(rr."
>>> ___
>>> openwrt-devel mailing list
>>> openwrt-devel@lists.openwrt.org
>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>>
>>
>>
>>
>> --
>> Eric Schultz, Community Manager, prpl Foundation
>> http://www.prplfoundation.org
>> eschu...@prplfoundation.org
>> cell: 920-539-0404
>> skype: ericschultzwi
>> @EricPrpl
>>
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>
>>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-- 

Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Need help with Makefile error *** missing separator

[Luiz Angelo Daros de Luca]

Andy,

Make runs one line per time. Make the "if" inline or backslash each newline
(adding semicolon when needed)

Regards

Em seg, 4 de jan de 2016 11:56, Andy Wong <axisaxi...@163.com> escreveu:

>
> For no misunderstanding.Here is the error now
> http://pastebin.com/t4Rb08kA
>
>
>
>
>
>
> 在 2016-01-04 21:18:14，"Andy Wong" <axisaxi...@163.com> 写道：
> >Thanks.I have indented like this：define 
> >Package/openwrt-dist-luci/install#!/bin/sh$(INSTALL_DIR) 
> >$(1)/usr/lib/lua/luci/controller$(INSTALL_DATA) 
> >./files/luci/controller/$(2).lua 
> >$(1)/usr/lib/lua/luci/controller/$(2).lua $(INSTALL_DIR) 
> >$(1)/usr/lib/lua/luci/model/cbi $(INSTALL_DATA) 
> >./files/luci/model/cbi/$(2).lua 
> >$(1)/usr/lib/lua/luci/model/cbi/$(2).lua   $(INSTALL_DIR) 
> >$(1)/etc/uci-defaults   $(INSTALL_BIN) 
> >./files/root/etc/uci-defaults/luci-$(2) $(1)/etc/uci-defaults/luci-$(2) 
> >if [ -f "./files/luci/i18n/$(2).zh-cn.lmo" ]; then $(INSTALL_DIR) 
> >$(1)/usr/lib/lua/luci/i18n  $(INSTALL_DATA) 
> >./files/luci/i18n/$(2).zh-cn.lmo $(1)/usr/lib/lua/luci/i18n
> >fiendefBut another error 
> >appears:enwrt/build_dir/target-mipsel_24kec+dsp_uClibc-0.9.33.2/openwrt-dist-luci/ipkg-all/luci-app-chinadns/etc/uci-defaults/luci-chinadnsif
> > [ -f "./files/luci/i18n/chinadns.zh-cn.lmo" ]; thenbash: -c: line 1: 
> >syntax error: unexpected end of filemake[2]: *** 
> >[/home/Openwrt/witi-openwrt/bin/ramips/packages/base/luci-app-chinadns_1.3.8-1_all.ipk]
> > Error 1make[2]: Leaving directory 
> >`/home/Openwrt/witi-openwrt/package/my_package/openwrt-dist-luci'make[1]:
> > *** [package/my_package/openwrt-dist-luci/compile] Error 2make[1]: 
> >Leaving directory `/home/Openwrt/witi-openwrt'make: *** 
> >[package/openwrt-dist-luci/compile] 错误 2My if,then course is 
> >intending to find out if *.zh-cn.lmo exist,then install it.
> >At 2016-01-04 20:20:00, "Jo-Philipp Wich" <j...@openwrt.org> wrote:
> >>Hi.
> >>
> >>Lines in the isntall section must be indented with at least one tab
> >>since they're shell instructions.
> >>
> >>~ Jow
> >>___
> >>openwrt-devel mailing list
> >>openwrt-devel@lists.openwrt.org
> >>https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> >_______
> >openwrt-devel mailing list
> >openwrt-devel@lists.openwrt.org
> >https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
>
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-- 

Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] procd: hotplug.json: allow passing hotplug events from all subsystems

[Luiz Angelo Daros de Luca]

John,

How about generate the subsystem list from /etc/hotplug.d dirs. The list
could be loaded at startup and refreshed the same way hotplug.json is (
which might be "never" as procd does not have an "init q").

Regards,

Luiz

Em sáb, 28 de nov de 2015 21:14, John Crispin <blo...@openwrt.org> escreveu:

> Hi Yousong,
>
> On 28/11/2015 05:22, Yousong Zhou wrote:
> > There are time that programs need to be notified of events from
> > subsystems that are not enumerated in the .json definition, e.g. QEMU
> > guest agent by default requires /dev/virtio-ports/org.qemu.guest_agent.0
> > which is a symlink to /dev/vportMpN from virtio-ports subsystem.
> >
>
> i am not sure if this is a good idea. there are thousands of events
> being broadcast, specially during boot and we really want to avoid
> respawning the script helper for each one of them. i was under the
> impression that we had an include directive that allowed us to include
> board/target specific json files. however i am failing to find the code
> that does this so the feature might not actually be implemented yet.
> i'll need to have a closer look at this the next days.
>
> John
>
> > Signed-off-by: Yousong Zhou <yszhou4t...@gmail.com>
> > ---
> >  package/system/procd/files/hotplug.json | 9 ++---
> >  1 file changed, 2 insertions(+), 7 deletions(-)
> >
> > diff --git a/package/system/procd/files/hotplug.json
> b/package/system/procd/files/hotplug.json
> > index 27b4836..bad2340 100644
> > --- a/package/system/procd/files/hotplug.json
> > +++ b/package/system/procd/files/hotplug.json
> > @@ -69,18 +69,13 @@
> >   [ "button", "/etc/rc.button/%BUTTON%" ]
> >   ],
> >   [ "if",
> > - [ "eq", "SUBSYSTEM",
> > - [ "net", "input", "usb", "usbmisc", "ieee1394",
> "block", "atm", "zaptel", "tty", "button" ]
> > - ],
> > - [ "exec", "/sbin/hotplug-call", "%SUBSYSTEM%" ]
> > - ],
> > - [ "if",
> >   [ "and",
> >   [ "eq", "SUBSYSTEM", "usb-serial" ],
> >   [ "regex", "DEVNAME",
> >           [ "^ttyUSB", "^ttyACM" ]
> >   ],
> >   ],
> > - [ "exec", "/sbin/hotplug-call", "tty" ]
> > + [ "exec", "/sbin/hotplug-call", "tty" ],
> > + [ "exec", "/sbin/hotplug-call", "%SUBSYSTEM%" ]
> >   ],
> >  ]
> >
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-- 

Luiz Angelo Daros de Luca
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] mac80211: Add dependency on ip (iproute2) to cfg80211

[Luiz Angelo Daros de Luca]

Is there a way to add "provides" to a package? In RPM, I would solve this
adding "Provides: ip" to busybox.

This could also help when a kern module gets built-in. Kernel package could
provide the incorporated kmod-xxx module. It would be better if both kernel
and kmod-xxx could automatically provide every single module it provides,
so packages could requires modules and not their packages, whether it is
built-in or loadable module.

Just like the case of busybox, if someone changes a module to not be
built-in (a configuration), it will require a code (makefile) change in
order to fix broken deps.

Luiz

Em ter, 17 de nov de 2015 06:11, Cristian Morales Vega <
crist...@samknows.com> escreveu:

> On 16 November 2015 at 23:40, Felix Fietkau <n...@openwrt.org> wrote:
> > On 2015-11-16 20:28, Ted Hess wrote:
> >> Changes to netifd/wireless/mac80211.sh in r46832 invoke 'ip' when making
> >> a client association. 'ip' is not automatically included with cfg80211
> >> custom builds -- association fails.
> >>
> >> Signed-off-by: Ted Hess <th...@kitschensync.net>
> > NACK. These changes were added because the busybox ip applet was enabled
> > by default recently.
>
> So there is a dependency (ip package OR ip support in Busybox), but no
> way to express it?
>
> Not that it would make sense for anybody to disable the new default in
> busybox without enabling the ip package at the same time. Just
> curious.
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-- 

Luiz Angelo Daros de Luca
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] elfutils: bump to 0.164

[Luiz Angelo Daros de Luca]

Patches are refreshed except for elfutils-portability, which is gone:
https://lists.fedorahosted.org/pipermail/elfutils-devel/2015-October/005290.html

Signed-off-by: Luiz Angelo Daros de Luca <luizl...@gmail.com>
---
 package/libs/elfutils/Makefile |4 +-
 .../patches/001-elfutils-portability.patch | 2059 
 .../elfutils/patches/004-maybe-uninitialized.patch |2 +-
 package/libs/elfutils/patches/004-memcpy_def.patch |2 +-
 .../elfutils/patches/005-build_only_libs.patch |2 +-
 package/libs/elfutils/patches/006-libdw_LIBS.patch |4 +-
 .../libs/elfutils/patches/100-musl-compat.patch|   28 +-
 package/libs/elfutils/patches/101-no-fts.patch |8 +-
 8 files changed, 25 insertions(+), 2084 deletions(-)
 delete mode 100644 package/libs/elfutils/patches/001-elfutils-portability.patch

diff --git a/package/libs/elfutils/Makefile b/package/libs/elfutils/Makefile
index 5303e9e..b1e52ba 100644
--- a/package/libs/elfutils/Makefile
+++ b/package/libs/elfutils/Makefile
@@ -7,12 +7,12 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=elfutils
-PKG_VERSION:=0.163
+PKG_VERSION:=0.164
 PKG_RELEASE:=1
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
 PKG_SOURCE_URL:=http://fedorahosted.org/releases/e/l/$(PKG_NAME)/$(PKG_VERSION)
-PKG_MD5SUM:=77ce87f259987d2e54e4d87b86cbee41
+PKG_MD5SUM:=2e4536c1c48034f188a80789a59114d8
 PKG_MAINTAINER:=Luiz Angelo Daros de Luca <luizl...@gmail.com>
 PKG_LICENSE:=GPL-3.0+
 PKG_LICENSE_FILES:=COPYING COPYING-GPLV2 COPYING-LGPLV3
diff --git a/package/libs/elfutils/patches/001-elfutils-portability.patch 
b/package/libs/elfutils/patches/001-elfutils-portability.patch
deleted file mode 100644
index 46954aa..000
--- a/package/libs/elfutils/patches/001-elfutils-portability.patch
+++ /dev/null
@@ -1,2059 +0,0 @@
-diffelfutils/backends/ChangeLog git-portable/backends/ChangeLog
 a/backends/ChangeLog
-+++ b/backends/ChangeLog
-@@ -498,6 +498,10 @@
-   * ppc_attrs.c (ppc_check_object_attribute): Handle tag
-   GNU_Power_ABI_Struct_Return.
- 
-+2009-01-23  Roland McGrath  <rol...@redhat.com>
-+
-+  * Makefile.am (libebl_%.so): Use $(LD_AS_NEEDED).
-+
- 2008-10-04  Ulrich Drepper  <drep...@redhat.com>
- 
-   * i386_reloc.def: Fix entries for TLS_GOTDESC, TLS_DESC_CALL, and
-@@ -825,6 +829,11 @@
-   * sparc_init.c: Likewise.
-   * x86_64_init.c: Likewise.
- 
-+2005-11-22  Roland McGrath  <rol...@redhat.com>
-+
-+  * Makefile.am (LD_AS_NEEDED): New variable, substituted by configure.
-+  (libebl_%.so rule): Use it in place of -Wl,--as-needed.
-+
- 2005-11-19  Roland McGrath  <rol...@redhat.com>
- 
-   * ppc64_reloc.def: REL30 -> ADDR30.
-@@ -847,6 +856,9 @@
-   * Makefile.am (uninstall): Don't try to remove $(pkgincludedir).
-   (CLEANFILES): Add libebl_$(m).so.
- 
-+  * Makefile.am (WEXTRA): New variable, substituted by configure.
-+  (AM_CFLAGS): Use it in place of -Wextra.
-+
-   * ppc_reloc.def: Update bits per Alan Modra <amo...@bigpond.net.au>.
-   * ppc64_reloc.def: Likewise.
- 
 a/backends/Makefile.am
-+++ b/backends/Makefile.am
-@@ -119,7 +119,7 @@ libebl_%.so libebl_%.map: libebl_%_pic.a
-   $(LINK) -shared -o $(@:.map=.so) \
-   -Wl,--whole-archive $< $(cpu_$*) -Wl,--no-whole-archive \
-   -Wl,--version-script,$(@:.so=.map) \
--  -Wl,-z,defs -Wl,--as-needed $(libelf) $(libdw)
-+  -Wl,-z,defs $(LD_AS_NEEDED) $(libelf) $(libdw)
-   @$(textrel_check)
- 
- libebl_i386.so: $(cpu_i386)
 a/backends/Makefile.in
-+++ b/backends/Makefile.in
-@@ -90,7 +90,8 @@ PRE_UNINSTALL = :
- POST_UNINSTALL = :
- build_triplet = @build@
- host_triplet = @host@
--@SYMBOL_VERSIONING_TRUE@am__append_1 = -DSYMBOL_VERSIONING
-+@BUILD_WERROR_TRUE@am__append_1 = $(if $($(*F)_no_Werror),,-Werror)
-+@SYMBOL_VERSIONING_TRUE@am__append_2 = -DSYMBOL_VERSIONING
- subdir = backends
- ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
- am__aclocal_m4_deps = $(top_srcdir)/m4/biarch.m4 \
-@@ -300,6 +301,7 @@ INSTALL_PROGRAM = @INSTALL_PROGRAM@
- INSTALL_SCRIPT = @INSTALL_SCRIPT@
- INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
- LDFLAGS = @LDFLAGS@
-+LD_AS_NEEDED = @LD_AS_NEEDED@
- LEX = @LEX@
- LEXLIB = @LEXLIB@
- LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
-@@ -331,6 +333,7 @@ SHELL = @SHELL@
- STRIP = @STRIP@
- USE_NLS = @USE_NLS@
- VERSION = @VERSION@
-+WEXTRA = @WEXTRA@
- XGETTEXT = @XGETTEXT@
- XGETTEXT_015 = @XGETTEXT_015@
- XGETTEXT_EXTRA_OPTIONS = @XGETTEXT_EXTRA_OPTIONS@
-@@ -398,14 +401,14 @@ AM_CPPFLAGS = -I. -I$(srcdir) -I$(top_sr
- 
- # Warn about stack usage of more than 256K = 262144 bytes.
- @ADD_STACK_USAGE_WARNING_TRUE@STACK_USAGE_WARNING = -Wstack-usage=262144
--AM_CFLAGS = -std=gnu99 -Wall -Wshadow -Wformat=2 \
--  $(if $($(*F)_no_Werror),,-Werror) \
--  $(if $($(*F)_no_Wunused),,-Wunused -Wextra) \
--  $(if $($(*F)_no_Wstack_usage),,$(STACK_USAGE_WARNING)) \
-

Re: [OpenWrt-Devel] Git mirror with branches, tags and full history

[Luiz Angelo Daros de Luca]

Hello Steven,

Thanks for the mirror!
Wouldn't it be possible to integrate PR with the maillist?
A quick google gave me this:
https://github.com/google/pull-request-mailer

Regards,

Em seg, 9 de nov de 2015 10:54, Emmanuel Deloget <log...@free.fr> escreveu:

> Hello,
>
> Same here - this is really appreciated.
>
> BR,
>
> -- Emmanuel Deloget
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-- 

Luiz Angelo Daros de Luca
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWRT www version banner a security risk

[Luiz Angelo Daros de Luca]

While openwrt doesn't offer security release, hiding version in banner is
not very effective. If the attacker can detect it is OpenWRT and if there
is a known security issue for any major version, it is enough to try an
attack.

Robot.txt is effective as Google is a common tool to look for targets. I
guess brute force scanners would not care to detect luci open to web as it
is a rare target (if Google does not list them). If they care, again, they
would just try the known attack.

Regards,

Em dom, 13 de set de 2015 17:05, Daniel Dickinson <
open...@daniel.thecshore.com> escreveu:

> I do think allowing to choose to disable the banner is a minor benefit,
> however, as I've said, there are much more effective means of preventing
> accidential exposure, and quite frankly if the user is *choosing* to
> open the web interface I think an warning and disabling the banner if
> the user foolishly insists on opening the interface despite the warning
> is more useful thank disabling the banner by default.
>
> If you're going to argue it prevents against internal threats than I
> would argue that if your internal network is hostile enough that you
> need to worry about attacks on openwrt from your internal network AND
> you're not skilled enough to limit access to LuCI (or better, build an
> image without LuCI and just use SSH) to the specific trusted hosts
> (preferably by combination of MAC address and IP address) in the
> firewall, or (better) to use a 'management' VPN or VLAN that only
> trusted hosts can get on, then you're in a lot more trouble than
> eliminating the banner for LuCI will solve.
>
> Regards,
>
> Daniel
>
> On 2015-09-13 10:21 AM, MauritsVB wrote:
> > At the moment the OpenWRT www login screen provides *very* detailed
> version information before anyone has even entered a password. It displays
> not just “15.05” or “Chaos Calmer” but even the exact git version on the
> banner.
> >
> > While it’s not advised to open this login screen to the world, fact is
> that it does happen intentionally or accidentally. Just a Google search for
> “Powered by LuCI Master (git-“ will provide many accessible OpenWRT login
> screens, including exact version information.
> >
> > As soon as someone discovers a vulnerability in a OpenWRT version all an
> attacker needs to do is perform a Google search to find many installations
> with versions that are vulnerable (even if a patch is already available).
> >
> > In the interest of hardening the default OpenWRT install, can I suggest
> that by default OpenWRT doesn’t disclose the version (not even 15.05 or
> “Chaos Calmer”) on the login screen? For extra safety I would even suggest
> to leave “OpenWRT” off the login screen, the only people who should use
> this screen already know it’s running OpenWRT.
> >
> > Any thoughts?
> >
> > Maurits
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> >
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Renaming trunk to Dxx Dxx ? Or seperate name for Trunk?

[Luiz Angelo Daros de Luca]

IMHO, I would avoid "normal releases" rule as, at some time in future,
OpenWRT might hopefully hit T..T.. name.

Trunk, unstable or anything like this might be better.

Regards,

Em qui, 10 de set de 2015 às 17:58,  escreveu:

> How about Trusty Trunk.. no cocktail though.. so far.. ede
>
>
> On 10.09.2015 22:08, Tobias Welz wrote:
> > Just following up with the T... T... idea - I found some T T Cocktails:
> >
> > Tahitian Tea
> > Tahitian Treat
> > Tanqueray Tonic
> > Tanzanian Tonic
> >
> >
> >
> > Am 09.09.2015 um 19:57 schrieb Hannu Nyman:
> >> Tobias Welz wrote at Wed Sep 9 17:24:14 CEST 2015:
> >> > So I absolutely vote for some clear consistent naming of the trunk
> and seperate names for the releases. (What about some Cocktail with a
> letter from the end of the alphabet like Z Z or X X in case
> there exists one)
> >>
> >> On that idea, the possible permanent name for the trunk could be
> something Txx Trunk. There are over 20 releases until TT is reached, so not
> for soon. I didn't find any really suitable drink names, but below are some
> ideas:
> >> Trekking Trunk
> >> Tasty Trunk
> >> Tricky Trunk
> >> Tempting Trunk
> >> Twisty Trunk
> >> Trunk Thrill
> >> Thrilling Trunk
> >>
> >> But until that, renaming trunk to something Dxxx Dxxx would be enough
> to decrease confusion.
> >> ___
> >> openwrt-devel mailing list
> >> openwrt-devel@lists.openwrt.org
> >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> >
> >
> >
> >
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> >
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v4] base-files: add /etc/profile.d support

[Luiz Angelo Daros de Luca]

Normally I like to use find instead of glob
With minpath, maxpath, name and etc, you get safe empty result when dir is
empty.

Regards,

Em sex, 4 de set de 2015 10:10, Bastian Bittorf 
escreveu:

> * Karl Palsson  [04.09.2015 15:02]:
> > So let's -d test the directory instead of -e testing every file just in
> > case the directory didn't exist?
>
> even if the directory exists but is empty, the globbing fails.
> but i get your point. what about:
>
> [ -n "$( ls -1 $dir )" ] && {
>   for FILE in $dir/*; do
> . "$FILE"
>   done
> }
>
> but i dont like it! any other comments
>
> bye, bastian
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] package makefile help

[Luiz Angelo Daros de Luca]

The first command compiles all subpackages listed in radvd/Makefile. You
never compile subpackages directly.


Em sex, 31 de jul de 2015 às 08:39, Pratik Prajapati 
pratik.prajapat...@gmail.com escreveu:

 Hi,

 I we write makefile using this approach
 https://dev.openwrt.org/browser/packages/ipv6/radvd/Makefile

 make package/radvd/compile V=s   works
 but
 make package/radvdump/compile V=s doesn't work

 Why?
 How to correct this?
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

Re: [OpenWrt-Devel] Syntax error in radvd.conf

[Luiz Angelo Daros de Luca]

This is a question for openwrt-users.

Anyway, interface is the logical openwrt interface (lan, wan), not Linux
devices.
http://wiki.openwrt.org/doc/uci/radvd

Regards,

Em sex, 24 de jul de 2015 09:36, Pratik Prajapati 
pratik.prajapat...@gmail.com escreveu:

 Hi,

 I want to run radvd on OpenWrt but its giving me syntax error in radvd.conf

 radvd.conf:

 config 'interface'
 option 'interface'  'eth0'
 option 'AdvSendAdvert'  '1'
 option 'AdvManagedFlag' '0'
 option 'AdvOtherConfigFlag' '0'

 config 'prefix'
 option 'interface' 'eth0'
 option 'AdvOnLink' '1'
 option 'AdvAutonomous' '1'
 option 'AdvRouterAddr' '0'

 config 'route'
 option 'interface''eth0'
 option 'prefix'   '2001:0DB8:1234:5677::/64'
 option 'AdvRouteLifetime' 'infinity'


 Error on running: radvd start

 /etc/radvd.conf:1 error: syntax error, unexpected STRING, expecting
 T_INTERFACE
 [Jul 24 12:28:09] radvd (1202): exiting, failed to read config file

 What needs to be corrected in radvd.conf ?

 Thanks,
 Pratik
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

Re: [OpenWrt-Devel] [PATCH] x86/xen_domu: enable image generation

[Luiz Angelo Daros de Luca]

This was already accepted in trunk. Is there any chance to backport to cc?

Em seg, 15 de jun de 2015 04:10, Luiz Angelo Daros de Luca 
luizl...@gmail.com escreveu:

 Add features ext4 targz to target x86/xen_domu in order to
 generate images in defconfig.

 This fixes #18074.

 Signed-off-by: Luiz Angelo Daros de Luca luizl...@gmail.com
 ---
  target/linux/x86/xen_domu/target.mk | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/target/linux/x86/xen_domu/target.mk
 b/target/linux/x86/xen_domu/target.mk
 index 80bac3b..f7a69bf 100644
 --- a/target/linux/x86/xen_domu/target.mk
 +++ b/target/linux/x86/xen_domu/target.mk
 @@ -1,3 +1,3 @@
  BOARDNAME:=Xen Paravirt Guest
  DEFAULT_PACKAGES += kmod-xen-fs kmod-xen-evtchn kmod-xen-netdev
 kmod-xen-kbddev
 -FEATURES:=display
 +FEATURES:=display ext4 targz
 --
 2.1.4


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

[OpenWrt-Devel] TEXTREL in x86 with musl

[Luiz Angelo Daros de Luca]

Hello,

SInce x86 started to compile with musl, elfutils package becomes broken.
http://buildbot.openwrt.org:8010/broken_packages/x86/elfutils/compile.txt

During linking, elfutils checks if there is TEXTREL in its .so files, and
it fatally fails if so. I guess this is the only package that does this
kind of test.

I'm new to PIE binary but google says that the presence of TEXTREL in an
readelf -d indicates that one of more files linked were not compiled with
-fPIC.  Following https://wiki.gentoo.org/wiki/Hardened/Textrels_Guide, I
tried to locale the offending file with scanelf and got this:

$ trunk/build_dir/target-i386_i486_musl-1.1.10/elfutils-0.163 $ scanelf -qT
*.so libelf/*.so
  libelf.so: __func__.3897 [0xE1F1] in (optimized out: previous
__stack_chk_fail_local) [0xE1F0]
  libelf/libelf.so

I checked all .so files generated with musl and most of them (or all) got
the same output. I still have the uclibc binaries and none have TEXTREL.

What is the best way to deal with this? Turn TEXTREL into non-fatal for
elfutils?

Regards,
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] elfutils: bump to 0.163

[Luiz Angelo Daros de Luca]

Bugfix only release.

Signed-off-by: Luiz Angelo Daros de Luca luizl...@gmail.com
---
 package/libs/elfutils/Makefile |   4 +-
 .../patches/001-elfutils-portability.patch | 263 +++--
 .../elfutils/patches/005-build_only_libs.patch |   2 +-
 package/libs/elfutils/patches/006-libdw_LIBS.patch |   2 +-
 .../libs/elfutils/patches/100-musl-compat.patch|   2 +-
 package/libs/elfutils/patches/101-no-fts.patch |   8 +-
 6 files changed, 141 insertions(+), 140 deletions(-)

diff --git a/package/libs/elfutils/Makefile b/package/libs/elfutils/Makefile
index d13e15d..5303e9e 100644
--- a/package/libs/elfutils/Makefile
+++ b/package/libs/elfutils/Makefile
@@ -7,12 +7,12 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=elfutils
-PKG_VERSION:=0.162
+PKG_VERSION:=0.163
 PKG_RELEASE:=1
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
 PKG_SOURCE_URL:=http://fedorahosted.org/releases/e/l/$(PKG_NAME)/$(PKG_VERSION)
-PKG_MD5SUM:=9334cbcc0df7669b7bf07cf7fc3ad52c
+PKG_MD5SUM:=77ce87f259987d2e54e4d87b86cbee41
 PKG_MAINTAINER:=Luiz Angelo Daros de Luca luizl...@gmail.com
 PKG_LICENSE:=GPL-3.0+
 PKG_LICENSE_FILES:=COPYING COPYING-GPLV2 COPYING-LGPLV3
diff --git a/package/libs/elfutils/patches/001-elfutils-portability.patch 
b/package/libs/elfutils/patches/001-elfutils-portability.patch
index 068235a..46954aa 100644
--- a/package/libs/elfutils/patches/001-elfutils-portability.patch
+++ b/package/libs/elfutils/patches/001-elfutils-portability.patch
@@ -1,3 +1,4 @@
+diffelfutils/backends/ChangeLog git-portable/backends/ChangeLog
 --- a/backends/ChangeLog
 +++ b/backends/ChangeLog
 @@ -498,6 +498,10 @@
@@ -46,17 +47,17 @@
  libebl_i386.so: $(cpu_i386)
 --- a/backends/Makefile.in
 +++ b/backends/Makefile.in
-@@ -83,7 +83,8 @@ host_triplet = @host@
- DIST_COMMON = $(top_srcdir)/config/eu.am $(srcdir)/Makefile.in \
-   $(srcdir)/Makefile.am $(top_srcdir)/config/depcomp \
-   $(noinst_HEADERS) ChangeLog
+@@ -90,7 +90,8 @@ PRE_UNINSTALL = :
+ POST_UNINSTALL = :
+ build_triplet = @build@
+ host_triplet = @host@
 -@SYMBOL_VERSIONING_TRUE@am__append_1 = -DSYMBOL_VERSIONING
 +@BUILD_WERROR_TRUE@am__append_1 = $(if $($(*F)_no_Werror),,-Werror)
 +@SYMBOL_VERSIONING_TRUE@am__append_2 = -DSYMBOL_VERSIONING
  subdir = backends
  ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
  am__aclocal_m4_deps = $(top_srcdir)/m4/biarch.m4 \
-@@ -289,6 +290,7 @@ INSTALL_PROGRAM = @INSTALL_PROGRAM@
+@@ -300,6 +301,7 @@ INSTALL_PROGRAM = @INSTALL_PROGRAM@
  INSTALL_SCRIPT = @INSTALL_SCRIPT@
  INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
  LDFLAGS = @LDFLAGS@
@@ -64,7 +65,7 @@
  LEX = @LEX@
  LEXLIB = @LEXLIB@
  LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
-@@ -320,6 +322,7 @@ SHELL = @SHELL@
+@@ -331,6 +333,7 @@ SHELL = @SHELL@
  STRIP = @STRIP@
  USE_NLS = @USE_NLS@
  VERSION = @VERSION@
@@ -72,7 +73,7 @@
  XGETTEXT = @XGETTEXT@
  XGETTEXT_015 = @XGETTEXT_015@
  XGETTEXT_EXTRA_OPTIONS = @XGETTEXT_EXTRA_OPTIONS@
-@@ -387,14 +390,14 @@ AM_CPPFLAGS = -I. -I$(srcdir) -I$(top_sr
+@@ -398,14 +401,14 @@ AM_CPPFLAGS = -I. -I$(srcdir) -I$(top_sr
  
  # Warn about stack usage of more than 256K = 262144 bytes.
  @ADD_STACK_USAGE_WARNING_TRUE@STACK_USAGE_WARNING = -Wstack-usage=262144
@@ -94,7 +95,7 @@
  CLEANFILES = *.gcno *.gcda $(foreach m,$(modules), libebl_$(m).map \
libebl_$(m).so $(am_libebl_$(m)_pic_a_OBJECTS))
  textrel_msg = echo WARNING: TEXTREL found in '$@'
-@@ -900,7 +903,7 @@ libebl_%.so libebl_%.map: libebl_%_pic.a
+@@ -912,7 +915,7 @@ libebl_%.so libebl_%.map: libebl_%_pic.a
$(LINK) -shared -o $(@:.map=.so) \
-Wl,--whole-archive $ $(cpu_$*) -Wl,--no-whole-archive \
-Wl,--version-script,$(@:.so=.map) \
@@ -105,7 +106,7 @@
  libebl_i386.so: $(cpu_i386)
 --- a/ChangeLog
 +++ b/ChangeLog
-@@ -253,6 +253,8 @@
+@@ -258,6 +258,8 @@
  
  2012-01-24  Mark Wielaard  m...@redhat.com
  
@@ -114,7 +115,7 @@
* COPYING: Fix address. Updated version from gnulib.
  
  2012-01-23  Mark Wielaard  m...@redhat.com
-@@ -271,6 +273,9 @@
+@@ -276,6 +278,9 @@
  
  2011-10-08  Mike Frysinger  vap...@gentoo.org
  
@@ -124,7 +125,7 @@
* configure.ac: Fix use of AC_ARG_ENABLE to handle $enableval correctly.
  
  2011-10-02  Ulrich Drepper  drep...@gmail.com
-@@ -292,6 +297,10 @@
+@@ -297,6 +302,10 @@
  
* configure.ac (LOCALEDIR, DATADIRNAME): Removed.
  
@@ -135,7 +136,7 @@
  2009-09-21  Ulrich Drepper  drep...@redhat.com
  
* configure.ac: Update for more modern autoconf.
-@@ -300,6 +309,10 @@
+@@ -305,6 +314,10 @@
  
* configure.ac (zip_LIBS): Check for liblzma too.
  
@@ -146,7 +147,7 @@
  2009-04-19  Roland McGrath  rol...@redhat.com
  
* configure.ac (eu_version): Round down here, not in version.h macros.
-@@ -311,6 +324,8 @@
+@@ -316,6 +329,8 @@
  
  2009-01-23  Roland McGrath  rol...@redhat.com
  
@@ -155,7 +156,7 @@
* configure.ac (zlib check): Check for gzdirect, need zlib = 1.2.2.3.
  
* configure.ac (__thread check): Use

Re: [OpenWrt-Devel] [PATCH 3/5] elfutils: import package from packages.git

[Luiz Angelo Daros de Luca]

OK, Sent the PR in order to remove it.

I already have a update patch that I'll send to list.
However, I guess that perf pkg maintainer (or other) should
be the one to keep the maintenance as I have no current uses
for elfutils and probably I'll not give the love it desires.

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

2015-06-14 14:22 GMT-03:00 Felix Fietkau n...@openwrt.org:

 On 2015-05-19 03:43, Luiz Angelo Daros de Luca wrote:
  I'm curious, as current elfutils packager, how I should play in this
 import?
 
  Should this package be removed from package.git (but there is no PR for
 it)?
 
  Or will it be periodically synchronized with packages.git?
 
  Also, as I'm not a core developer, maybe it would be better to a core
  developer to take its maintainance.
 I will apply this package. When you have updates to it, please send them
 as patches to this list. The package should be removed from github
 afterwards.

 - Felix

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