[LEDE-DEV] [PATCH] base-files: expand ucidef_set_interface_raw to allow custom configuration

[Roman Yeryomin]

This allows custom config generation.
E.g. setting lan adrress from eeprom or random address
(so that routers can be chained by default) or configuring
a fully custom interface.

Signed-off-by: Roman Yeryomin 
---
 .../base-files/files/lib/functions/uci-defaults.sh | 26 +-
 .../linux/ar71xx/base-files/etc/board.d/02_network |  4 ++--
 2 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/package/base-files/files/lib/functions/uci-defaults.sh 
b/package/base-files/files/lib/functions/uci-defaults.sh
index 82ac1d2a4d..0cd519a147 100755
--- a/package/base-files/files/lib/functions/uci-defaults.sh
+++ b/package/base-files/files/lib/functions/uci-defaults.sh
@@ -88,8 +88,32 @@ ucidef_set_interfaces_lan_wan() {
 }
 
 ucidef_set_interface_raw() {
+   local opt=";"
+   local val=""
+
+   [ -z "$1" ] && return
+
json_select_object network
-   _ucidef_set_interface "$@"
+
+   for i in "$@"; do
+   [ "$opt" == ";" ] && {
+   json_select_object "$i"
+   opt=""
+   continue
+   }
+   [ -z $opt ] && {
+   opt="$i"
+   continue
+   }
+   [ -z $val ] && val="$i"
+
+   json_add_string "$opt" "$val"
+
+   opt=""
+   val=""
+   done
+
+   json_select ..
json_select ..
 }
 
diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network 
b/target/linux/ar71xx/base-files/etc/board.d/02_network
index 7cf4212ac7..f6c7c90738 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -427,7 +427,7 @@ ar71xx_setup_interfaces()
;;
tellstick-znet-lite)
ucidef_set_interface_wan "eth0"
-   ucidef_set_interface_raw "wlan" "wlan0" "dhcp"
+   ucidef_set_interface_raw "wlan" iface "wlan0" proto "dhcp"
;;
tl-mr3420-v2|\
tl-wr841n-v8|\
@@ -458,7 +458,7 @@ ar71xx_setup_interfaces()
;;
tl-wr841n-v1|\
tl-wr941nd)
-   ucidef_set_interface_raw "eth" "eth0"
+   ucidef_set_interface_raw "eth" iface "eth0"
ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4" "wan"
;;
tl-wr741nd|\
-- 
2.14.1


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 1/5] build: append metadata for supported images.gz

[Christian Lamparter]

On Tuesday, November 28, 2017 11:20:23 PM CET Christian Lamparter wrote:
> On Tuesday, November 28, 2017 11:07:54 PM CET Matthias Schiffer wrote:
> > On 11/28/2017 10:51 PM, Christian Lamparter wrote:
> > > Targets that either directly or indirectly set
> > > CONFIG_TARGET_IMAGES_GZIP currently have no way
> > > to append the metadata at the end of new image
> > > creation process. And this is going to be
> > > necessary in order to convert the targets to use
> > > the new fwtool assisted platform check.
> > > 
> > > These will include for example x86(_64), RPI, and
> > > MyBook Live images.
> > > 
> > > Note: append-metadata does internally check if
> > > SUPPORTED_DEVICES is set, before adding the
> > > metadata. Hence, it will not interfere with
> > > existing targets that have not been converted.
> > > 
> > > Cc: Felix Fietkau 
> > > Signed-off-by: Christian Lamparter 
> > > ---
> > 
> > It should not matter if the images are gzipped or not; the metadata should
> > be appended before gzipping. All image checks are done after zcat; if this
> > is not the case for the fwtool checks, IMO the checks need to be adjusted,
> > not the image generation.
> 
> Hm, why is then the raw metadata appended to the sysupgrade.tar files
> in the first place? Shouldn't it be a inside a file in the .tar as well?
> Or what's your solution supposed to look like otherwise? Add gzip handling
> to the fwtool?
> 
Mathias Kresin had a great idea and it solved the problem in a better way.
This patch is therefore obsolete. \o/

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] ar71xx: add support for TP-Link TL-WDR7500v6

[Bill Moffitt]

Piotr-

Good points all...


On 11/29/2017 12:03 PM, Piotr Dymacz wrote:

Hello Bill,

On 29.11.2017 20:17, Bill Moffitt wrote:

Hello Piotr and Karol,


[snip]

Please, include in commit message how to install LEDE on this 
device as

described under "commit description" section on [1].


Ok, will prepare manual how to change bootloader to non-RSA one, 
move art and

install LEDE.


I'm sorry but I'm against accepting support for devices which 
requires such invasive modifications. We always try to make it 
possible for users to get back to the stock firmware which wouldn't 
be easy (or possible at all) with your changes in mtd layout and 
after bootloader swap.



In general, of course, I agree. However, we are seeing an increasing
number of vendors (TP-Link and Ubiquiti, to name 2) using some form of
locking in the bootloader to prevent loading of third-party firmware.


Then buy and use hardware from vendors who are open source friendly 
and allow users to actually fully own the hardware they paid for! :)
Hey, THERE'S a good idea!!! Suggestions??? :-D (especially for outdoors 
- that's why I'm working with the Comfast devices...)



The only option for loading OpenWRT (permanently - not using initramfs)
on these devices will be replacing the bootloader, as Karol does in this
patch.


Swapping bootloader isn't the only issue I see here. Moving ART which 
is essential and unique per device might end up in a data loss which 
cannot be recovered in any way.

Yes, that's true. But the only other option is not use the hardware.



If the only objection is that it involves invasive modifications that
may not (probably won't) allow the device to be re-flashed to stock, I
would prefer we accept the patch and make a very strongly-worded note in
the ToH and the device's wiki page explaining the situation.


This is not the only one objection. Personally I don't have problems 
with swapping bootloader and for ar71xx target we already have a 
dedicated package with old U-Boot sources: [1]


The problem here is that the bootloader the user has to use for this 
device comes from some random GitHub repository which exist today but 
may disappear tomorrow. Who will make sure that the bootloader image 
the author of the support mentions in his patch will be still 
available in next years and is correct and won't break users device?
If the bootloader code was in our repository or in upstream, I would 
be first one accepting support for this device.

Good point.


What's also important to notice here, devices with QCA WiSoCs and SPI 
NOR flash chips aren't easy to recover from a failed bootloader flash. 
If there is no JTAG on the board the only way to bring device back to 
life is to use flash chip programmer.

Very good point.


[1] 
https://github.com/lede-project/source/tree/master/package/boot/uboot-ar71xx


But I'd still rather endorse a notation in the ToH and the wiki than 
just prevent the patch from being accepted.


Everything in OpenWRT is pretty much "use at your own risk." Could we 
make a distinction between "Use at your own risk - might cause problems 
that will be hard to get around" and "Use at your own risk - you have a 
pretty good chance of bricking this thing?" Or, put another way, instead 
of just saying "supported" could we have platforms that are "Supported 
and easy" to "Supported, but, hey, this thing is ugly and will hurt you 
if you're not careful?"


We should do everything we can to reduce the risk of a repo going away, 
etc., but I'd endorse using some sketchy sources if necessary to gain 
support of a particular device.


It is good and necessary to look out for the naive beginner (as we all 
were at one time). But, at the same time, there is value in supporting 
the wisened and experienced user who can go to some extra effort and 
undertake some risk for a particular purpose.


That's how I feel about it. As always, FWIW.

-Bill

--
Bill Moffitt
Ayrstone Productivity
http://ayrstone.com


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Trouble with dnsmasq

[e9hack]

Am 22.11.2017 um 18:01 schrieb e9hack:

> It look likes that reload_service()/start_service() is called twice. The 
> first call generates the host file properly and
> starts dnsmasq. Before dnsmasq is able to read the host file, the second call 
> of reload_service()/start_service()
> overwrites the host file. Now the host file contains the first line only, 
> which is a comment.

I could solve the issue for me. I do the same for the host file like the config 
file. A temp host file is initialized.
Before dnsmasq is started, this file is renamed by mv to the required name of 
the host file.

> Independently of this, the reload_service()/start_service() functions are 
> called every 2..10min which
> overwrites/generates the host file again.

It comes from odhcpd6. It calls very often dhcpv6.script which generates an 
action ifupdate for interface wan_6.

Regards,
Hartmut


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH packages] rpcd-mod-lxc: info: return NOT_FOUND if container doesn't exist

[Rafał Miłecki]

From: Rafał Miłecki 

It allow distinction between not existing and stopped container. So far
querying for not existing container was resulting in:
> ubus call lxc info '{ "name": "foo" }'
{
"name": "foo",
"state": "STOPPED",
"ips": [

]
}

Now it's an error and it matches lxc-info command line:

> ubus call lxc info '{ "name": "foo" }'
Command failed: Not found

> lxc-info --name foo
foo doesn't exist

Signed-off-by: Rafał Miłecki 
---
 utils/rpcd-mod-lxc/files/lxc.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/utils/rpcd-mod-lxc/files/lxc.c b/utils/rpcd-mod-lxc/files/lxc.c
index 6db1b311..a98fcfc5 100644
--- a/utils/rpcd-mod-lxc/files/lxc.c
+++ b/utils/rpcd-mod-lxc/files/lxc.c
@@ -332,6 +332,11 @@ rpc_lxc_info(struct ubus_context *ctx, struct ubus_object 
*obj,
l = rpc_lxc_init(tb);
if (!l)
return UBUS_STATUS_INVALID_ARGUMENT;
+
+   if (!l->container->is_running(l->container) &&
+   !l->container->is_defined(l->container))
+   return UBUS_STATUS_NOT_FOUND;
+
blob_buf_init(, 0);
 
blobmsg_add_string(, "name", l->container->name);
-- 
2.11.0


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [RFC] filesystem-agnostic sysupgrade backup system

[Felix Fietkau]

On 2017-11-16 14:05, Thibaut VARÈNE wrote:
> Hi,
> 
> Following up on [1], I propose a different way of handling sysupgrade backups 
> that would no longer rely on a filesystem stub (jffs2, ubifs or otherwise).
> 
> Note: the following elements describe squashfs with jffs2 overlay images, but 
> I suspect they apply to more cases (ubifs…).
> 
> Current status:
> - When sysupgrade is asked to preserve the device configuration over reflash, 
> the process will:
>   - prepare a tarball of the config data onto tmpfs
>   - embed it into a filesystem stub appended after the squashfs data
>   - append a specific marker (deadc0de) to designate the end of the valid 
> jffs2 segment
> - When the new image boots:
>   - the squashfs mtdsplitter locates the end of the squashfs image and 
> places the beginning of the rootfs_data partition after it
>   - the jffs2 stub is now located at the beginning of the rootfs_data 
> partition (the writeable overlay)
>   - a LEDE-specific patch to the jffs2 driver clears the nodes located 
> after the marker
>   - the overlay is then mounted and the data it contains is recovered.
> 
> This has several drawbacks, as [1] illustrates: in particular it makes it 
> complicated, if not impossible, to change the filesystem used on the overlay 
> or any of its parameters - such as sector size in the case of jffs2 - without 
> losing the backup data.
I'll take another look at your proposal for the new format soon when I
have time, but I would like to comment on the issue of switching between
images with different sector sizes.
I think this is entirely fixable without switching to a different
format, and would mostly require solving things you need to solve for
your suggested format change as well.
The mtd jffs2write functionality looks for the right place to store its
data by finding the deadc0de marker. Thus if you want to make images
agnostic of sector size changes, you could pad them with 0xff to 64 KiB
size first, and then append the deadc0de marker afterwards. When
switching from 64K sectors to 4K sectors, jffs2 will treat the padding
as empty sectors and re-format them and will parse the stored config
data afterwards.
When switching from 4K to 64K sectors, the padding will simply be
skipped over and everything should work just fine.
I think it should be possible to solve this entirely within the image
building code, with no further changes to user space or kernel space
code. Thoughts?

To get started on making it possible to change the format, I would
suggest getting rid of pure-jffs2 images in all targets first.

- Felix

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Invalid hash for usbip package

[Nuno Gonçalves]

That I can do. Thanks for pointing the direction.

Thanks,
Nuno

On Thu, Nov 30, 2017 at 10:40 AM, Felix Fietkau  wrote:
> On 2017-11-30 10:21, Nuno Gonçalves wrote:
>> I need some help on this.
>>
>> This file changes frequently, and there is no versioned URL to keep it
>> stable, so just updating the hash is not a permanent fix.
>>
>> So first I don't understand how this problem didn't come up before. I
>> am also (unfortunately) not current usbip, while I'm listed as the
>> maintainer.
>>
>> Maybe this usb.ids file is now part of Linux?
>>
>> Any inputs?
> Hi Nuno,
>
> it seems that usbutils already contains a copy of usb.ids, but it pulls
> it from the gentoo hwids repository. While not always fully up to date,
> it is probably much better to use that instead of trying to download
> from the moving target that the usbip makefile is using right now.
> My suggestion would be to change the usbutils Makefile to package
> usb.ids separately and make usbip depend on that new package (and add an
> appropriate symlink if necessary).
>
> - Felix

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Invalid hash for usbip package

[Felix Fietkau]

On 2017-11-30 10:21, Nuno Gonçalves wrote:
> I need some help on this.
> 
> This file changes frequently, and there is no versioned URL to keep it
> stable, so just updating the hash is not a permanent fix.
> 
> So first I don't understand how this problem didn't come up before. I
> am also (unfortunately) not current usbip, while I'm listed as the
> maintainer.
> 
> Maybe this usb.ids file is now part of Linux?
> 
> Any inputs?
Hi Nuno,

it seems that usbutils already contains a copy of usb.ids, but it pulls
it from the gentoo hwids repository. While not always fully up to date,
it is probably much better to use that instead of trying to download
from the moving target that the usbip makefile is using right now.
My suggestion would be to change the usbutils Makefile to package
usb.ids separately and make usbip depend on that new package (and add an
appropriate symlink if necessary).

- Felix

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] base-files: do not backup unchanged files

[Moritz M]

Hi,

However, maybe a configuration backup is not the best way to keep track 
of changes on configuration files.


I get it, but are there better options?

The list of "configuration file" can change as long as their 
configuration are not listed in /lib/upgrade/keep.d.
Backup consists of files listed in /etc/sysupgrade.conf, 
/lib/upgrade/keep.d and changed config files (tracked by opkg).
For example, /etc/firewall.user will not appear in backup if not 
modified (or opkg is missing) because it is not mentioned in

/lib/upgrade/keep.d. There are many more examples. Try yourself:

# find $(cat /lib/upgrade/keep.d/*) -type f -o type l 2>/dev/null | sort 
-u >/tmp/a.txt

# cat /usr/lib/opkg/info/*.conffiles | sort -u>/tmp/b.txt
# diff -u /tmp/a.txt /tmp/b.txt  | grep +

So, even today, it is already expected that a backup after fresh 
installation to have less files than a backup

after some packages where installed. I just made the difference bigger.

Yes I see it. Takes a bit to see how the backup process works ;)

I could add a new option for sysupgrade in order to keep all files 
listed, even those untouched, in order to get the old behaviour.
However, in order to use it, you'll need to call it using a terminal. In 
this case, you could also retrieve those files using ssh+tar, or rsync 
if avaiable.
Anyway, this option would only make sense if I grab also all config 
files mentioned in any installed package, even those untouched.


For me, that would be fine. But on the other hand it is not that often 
that I install new LEDE boxes. And the more I think about it:
I would be ok with the new backup behaviour (just 5 files after fresh 
install). Because those are the only files which are changed on 
installation.



A better fix (that would also be closer to what "normal Linux
distributions" do) would be to reduce the use of /lib/upgrade/keep.d, 
and
instead rely on opkg's config hash tracking for a lot more files (we 
should
make this work without opkg itself first though). This would also work 
with

Moritz's usecase of initial config files supplied in the image build via
/files, as these files would not match the hashes known to opkg.

To me this sounds reasonable but I'm not aware of potential side 
effects.



Moritz

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Invalid hash for usbip package

[Nuno Gonçalves]

I need some help on this.

This file changes frequently, and there is no versioned URL to keep it
stable, so just updating the hash is not a permanent fix.

So first I don't understand how this problem didn't come up before. I
am also (unfortunately) not current usbip, while I'm listed as the
maintainer.

Maybe this usb.ids file is now part of Linux?

Any inputs?

Thanks,
Nuno

On Thu, Nov 30, 2017 at 12:53 AM, Nicholas Smith
 wrote:
> Hi,
>
> When compiling the usbip package in the latest snapshot, the hash of the 
> downloaded file is not the expected hash, causing the compilation to fail.
>
> I propose changing the hash in $build/feeds/packages/net/usbip/Makefile from 
> the current value to the value below:
> 312d411c21404a16516cb4d33dcda4cb1c7ed43c003a8736db274de655e418d7
>
>

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v2] uqmi: fix raw-ip mode for newer lte modems

[Koen Vandeputte]

On 2017-11-30 09:45, Nicholas Smith wrote:
No, thank you, Koen, for researching and developing the patch! 
Actually I am running the latest snapshot build. I suppose there in 
could lie the issue.
On Thu, 30 Nov 2017 at 6:41 pm, Koen Vandeputte 
> 
wrote:





Hi Nicholas,

As a shortcut, replace following script on your device with the one 
attached:


/lib/netifd/proto/qmi.sh


Make sure you set it executable:
chmod +rwx /lib/netifd/proto/qmi.sh


Then reboot & test


Koen


qmi.sh
Description: application/shellscript
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v2] uqmi: fix raw-ip mode for newer lte modems

[Koen Vandeputte]

On 2017-11-30 04:53, Nicholas Smith wrote:

Here is the VID:PID of the MC7430, if it helps.
Bus 001 Device 002: ID 1199:9071 Sierra Wireless, Inc.



On 30 Nov 2017, at 1:49 pm, Nicholas Smith  wrote:

Hi Koen,

I would like to report that it is attempting, but it is unable to change 
/sys/class/wwan0/qmi/raw_ip to a “Y” on it’s own.  I have to bring the 
interface down myself, set raw_ip to Y, then bring it back up.  Manual, but it 
works every time.

[   40.40] qmi_wwan 1-2:1.8 wwan0: Cannot change a running device

Here’s what I do to work around:

In LuCI go to wwan0 and stop the interface.
echo “Y” > /sys/class/wwan0/qmi/raw_ip
In LuCI go to wwan0 and connect the interface.





Hi Nicholas,

Thanks for your time in testing this.

Just to be sure:
Can you confirm you've used the latest master and applied my patch 
before seeing this error?


I'm not able to simulate your error here currently, and the script 
manages to adapt this flag on each run.



Besides the error you notice, is your modem fully working now providing 
a working uplink?



Thanks again,

Koen

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev