[LEDE-DEV] add a router brand

[163 mailbox]

i want to add a router brand to openwrt
the brand is “wavlink”
and my router is wavlink wl-wn527g4
it is not supported by openwrt and lede

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

[LEDE-DEV] [PATCH] mvebu: Get rid of RTC hack for Turris Omnia.

[Rosen Penev]

As Solidrun's RTC patch got merged, this hack is no longer needed.

Signed-off-by: Rosen Penev 
---
 target/linux/mvebu/base-files/lib/upgrade/sdcard.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/mvebu/base-files/lib/upgrade/sdcard.sh 
b/target/linux/mvebu/base-files/lib/upgrade/sdcard.sh
index fbf121f33d..a05df834ba 100644
--- a/target/linux/mvebu/base-files/lib/upgrade/sdcard.sh
+++ b/target/linux/mvebu/base-files/lib/upgrade/sdcard.sh
@@ -28,7 +28,7 @@ platform_do_upgrade_sdcard() {
fw_setenv openwrt_bootargs 'earlyprintk console=ttyS0,115200 
root=/dev/mmcblk0p2 rootfstype=auto rootwait'
fw_setenv openwrt_mmcload 'setenv bootargs "$openwrt_bootargs 
cfg80211.freg=$regdomain"; fatload mmc 0 0x0100 zImage; fatload mmc 0 
0x0200 armada-385-turris-omnia.dtb'
fw_setenv factory_mmcload 'setenv bootargs "$bootargs 
cfg80211.freg=$regdomain"; btrload mmc 0 0x0100 boot/zImage @; btrload mmc 
0 0x0200 boot/dtb @'
-   fw_setenv mmcboot 'mw 0xf10184a0 0xfd4d4cfa; run 
openwrt_mmcload || run factory_mmcload; bootz 0x0100 - 0x0200'
+   fw_setenv mmcboot 'run openwrt_mmcload || run factory_mmcload; 
bootz 0x0100 - 0x0200'
;;
esac
 
-- 
2.16.2


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

[LEDE-DEV] Duplicates in bind subpackages?

[Philip Prindeville]

Anyone else seeing this issue with Bind?

Collected errors:
 * check_data_file_clashes: Package bind-check wants to install file 
/home/philipp/lede/build_dir/target-x86_64_musl/root-x86/usr/sbin/named-checkconf
But that file is already provided by package  * bind-tools
 * check_data_file_clashes: Package bind-check wants to install file 
/home/philipp/lede/build_dir/target-x86_64_musl/root-x86/usr/sbin/named-checkzone
But that file is already provided by package  * bind-tools
 * opkg_install_cmd: Cannot install package bind-check.
 * check_data_file_clashes: Package bind-dig wants to install file 
/home/philipp/lede/build_dir/target-x86_64_musl/root-x86/usr/bin/dig
But that file is already provided by package  * bind-tools
 * opkg_install_cmd: Cannot install package bind-dig.
package/Makefile:65: recipe for target 'package/install’ failed

Here’s more info on what’s getting packaged where:

% find  bind-check bind-tools bind-dig -type f -print
bind-check/CONTROL/control
bind-check/CONTROL/postinst
bind-check/CONTROL/prerm
bind-check/usr/sbin/named-checkzone
bind-check/usr/sbin/named-checkconf
bind-tools/CONTROL/control
bind-tools/CONTROL/postinst
bind-tools/CONTROL/prerm
bind-tools/usr/bin/dig
bind-tools/usr/bin/host
bind-tools/usr/sbin/rndc
bind-tools/usr/sbin/named-checkzone
bind-tools/usr/sbin/dnssec-signzone
bind-tools/usr/sbin/dnssec-settime
bind-tools/usr/sbin/dnssec-keygen
bind-tools/usr/sbin/rndc-confgen
bind-tools/usr/sbin/named-checkconf
bind-dig/CONTROL/control
bind-dig/CONTROL/postinst
bind-dig/CONTROL/prerm
bind-dig/usr/bin/dig


Also, should sub-packages within the same package have the right to overlap 
contents?  I can think of cases where you might want to bundle utilities, for 
instance, in slightly different ways with overlap…

You just need to be careful to not remove a file when removing a subpackage 
until the last subpackage containing it (i.e. reference count goes to zero) 
gets removed.

-Philip


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

Re: [LEDE-DEV] Duplicates in bind subpackages?

[Philip Prindeville]

> On Mar 25, 2018, at 2:38 PM, Noah Meyerhans  wrote:
> 
> On Sun, Mar 25, 2018 at 02:24:57PM -0600, Philip Prindeville wrote:
>> Collected errors:
>> * check_data_file_clashes: Package bind-check wants to install file 
>> /home/philipp/lede/build_dir/target-x86_64_musl/root-x86/usr/sbin/named-checkconf
>>  But that file is already provided by package  * bind-tools
>> * check_data_file_clashes: Package bind-check wants to install file 
>> /home/philipp/lede/build_dir/target-x86_64_musl/root-x86/usr/sbin/named-checkzone
>>  But that file is already provided by package  * bind-tools
>> * opkg_install_cmd: Cannot install package bind-check.
>> * check_data_file_clashes: Package bind-dig wants to install file 
>> /home/philipp/lede/build_dir/target-x86_64_musl/root-x86/usr/bin/dig
>>  But that file is already provided by package  * bind-tools
>> * opkg_install_cmd: Cannot install package bind-dig.
>> package/Makefile:65: recipe for target 'package/install’ failed
> 
> Yeah, the intent is that the bind-tools package is a single package that
> includes all the tools, while packages such as bind-dig only contain a
> single specific tool. In theory bind-tools could be replaced by an empty
> package that simply declares dependencies on all the other tool
> packages.
> 
> I'm not sure when this configuration was originally introduced; it's
> been present since before I was involved in maintaining the packages. It
> always felt a little odd to me, but never so much so that I felt
> compelled to remove it. I'm happy to consider doing so if people feel
> strongly about it.
> 
> noah
> 


Yeah, a virtual package definitely sounds like the way to go.

Not urgent, but having clean builds is always nice…

-Philip


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

Re: [LEDE-DEV] Duplicates in bind subpackages?

[Noah Meyerhans via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Sun, Mar 25, 2018 at 02:24:57PM -0600, Philip Prindeville wrote:
> Collected errors:
>  * check_data_file_clashes: Package bind-check wants to install file 
> /home/philipp/lede/build_dir/target-x86_64_musl/root-x86/usr/sbin/named-checkconf
>   But that file is already provided by package  * bind-tools
>  * check_data_file_clashes: Package bind-check wants to install file 
> /home/philipp/lede/build_dir/target-x86_64_musl/root-x86/usr/sbin/named-checkzone
>   But that file is already provided by package  * bind-tools
>  * opkg_install_cmd: Cannot install package bind-check.
>  * check_data_file_clashes: Package bind-dig wants to install file 
> /home/philipp/lede/build_dir/target-x86_64_musl/root-x86/usr/bin/dig
>   But that file is already provided by package  * bind-tools
>  * opkg_install_cmd: Cannot install package bind-dig.
> package/Makefile:65: recipe for target 'package/install’ failed

Yeah, the intent is that the bind-tools package is a single package that
includes all the tools, while packages such as bind-dig only contain a
single specific tool. In theory bind-tools could be replaced by an empty
package that simply declares dependencies on all the other tool
packages.

I'm not sure when this configuration was originally introduced; it's
been present since before I was involved in maintaining the packages. It
always felt a little odd to me, but never so much so that I felt
compelled to remove it. I'm happy to consider doing so if people feel
strongly about it.

noah



signature.asc
Description: PGP signature
--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] uci: fix a potential use-after-free in uci_set()

[Jordan Miner]

When calling uci_set() to update an option, if ptr->o != NULL and
ptr->option == NULL, then uci_expand_ptr() will set ptr->option to
ptr->o->e.name (or the caller could set ptr->option to that value). In
this case, the option will be freed just before calling
uci_alloc_option() with ptr->option, which was just freed.

Signed-off-by: Jordan Miner 
---
 list.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/list.c b/list.c
index 0347138..3c46a0b 100644
--- a/list.c
+++ b/list.c
@@ -666,6 +666,7 @@ int uci_set(struct uci_context *ctx, struct uci_ptr *ptr)
 {
/* NB: UCI_INTERNAL use means without delta tracking */
bool internal = ctx && ctx->internal;
+   struct uci_option *o;
 
UCI_HANDLE_ERR(ctx);
uci_expand_ptr(ctx, ptr, false);
@@ -698,8 +699,9 @@ int uci_set(struct uci_context *ctx, struct uci_ptr *ptr)
if ((ptr->o->type == UCI_TYPE_STRING) &&
!strcmp(ptr->o->v.string, ptr->value))
return 0;
-   uci_free_option(ptr->o);
+   o = ptr->o;
ptr->o = uci_alloc_option(ptr->s, ptr->option, ptr->value);
+   uci_free_option(o);
ptr->last = >o->e;
} else if (ptr->s && ptr->section) { /* update section */
char *s = uci_strdup(ctx, ptr->value);
-- 
2.7.4


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

Re: [LEDE-DEV] DNS split horizon *without* dnsmasq

[Philip Prindeville]

Thinking Bind, probably.



> On Mar 23, 2018, at 5:38 PM, Eric Luehrsen  wrote:
> 
> What do you want to serve your dns then? Unbound or Bind?
> 
> - Eric
> 
> On Fri, Mar 23, 2018, 1:31 PM Philip Prindeville 
>  wrote:
> Hi all,
> 
> As the ISC-DHCP maintainer, I need to eat my own dogfood so I run that here, 
> before anyone quips, “Why don’t you just run dnsmasq instead?”
> 
> So… I have some internal names that I want to be able to resolve internally, 
> but I also need to provide DNS service for all of my DHCP clients.
> 
> Is there a way to prime a “fake” local zone (or cache) and run a caching only 
> nameserver that’s been primed with this “split-horizon” info (i.e. the local 
> names for machines on 192.168.1.0/24, etc)?
> 
> Or equally, have DHCP prime the local names into the DNS as they get 
> allocated (well, that wouldn’t fully solve my problem as my mail server has a 
> statically allocated IP address, so DHCP wouldn’t know about that).
> 
> Any ideas?
> 
> Thanks,
> 
> -Philip


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

[LEDE-DEV] Questions regarding rootfs loading

[Alpha Sparc]

Hi,

I have a question regarding lantiq targets, how do you transfer
control to load a squashfs rootfs after loading the kernel when the
rootfs partition offset is in front of the kernel?

Thanks

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