Re: [PATCH] busybox: enable whois by default

2020-11-17 Thread Philip Prindeville
I liked the idea of including whois.

I think it should be one of those things that gets enabled if we’re not doing a 
super-skinny-build.

And if I’m at a remote location and OpenWRT isn’t coming up enough for me to 
run “whois” on a laptop behind it, then having it on OpenWRT itself makes it 
that much more self-contained.



> On Nov 18, 2020, at 12:22 AM, Josef Schlehofer  
> wrote:
> 
> Hi guys,
> 
> Thank you for your feedback.
> I was surprised how fast this was rejected and I thought that there is
> going to be some vote or discussion about it. My bad.
> 
> I noticed that on OpenWrt forum, there are some requests like this [1]
> to have whois present on their routers. We can be thinking about which
> tools are essentials to you and which are you using. On the other hand,
> why we should be using whois on a mobile phone or on websites. Because
> in my opinion, It's all just a matter of taste.
> 
> For now, I am satisfied with enabled whois in busybox and as I was doing
> compile and run tests. I thought that it was a nice idea to share it
> with you.
> 
> Anyway, there isn't anything wrong with that! At least we have it
> documented on the mailing list, so we can refer to it in the future.
> 
> [1]
> https://forum.openwrt.org/t/whois-binary-cannot-find-providing-package/31274
> 
> Regards,
> 
> Josef
> 
> 
> On 17. 11. 20 21:18, Paul Spooren wrote:
>> On Mon Nov 16, 2020 at 9:14 PM HST, Petr Štetiar wrote:
>>> Josef Schlehofer  [2020-11-17 02:07:09]:
>>> 
>>> Hi,
>>> 
 Whois can identify who owns a domain and how to get reach owner.  Providing
 this tool in OpenWrt someone does not need to use websites for everything.
>>> I don't think, that this tool is essential enough to be shipped by
>>> default.
>> I agree.
>> 
>>> One can use whois on desktop or mobile phone for example. I think, that
>>> packaging whois[1] shouldn't be that hard, then you've it one `opkg
>>> install`
>>> away.
>>> 
>>> 1. https://github.com/rfc1036/whois
>>> 
>>> Cheers,
>>> 
>>> Petr
>>> 
>>> ___
>>> openwrt-devel mailing list
>>> openwrt-devel@lists.openwrt.org
>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


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


Re: [PATCH] busybox: enable whois by default

2020-11-17 Thread Josef Schlehofer
Hi guys,

Thank you for your feedback.
I was surprised how fast this was rejected and I thought that there is
going to be some vote or discussion about it. My bad.

I noticed that on OpenWrt forum, there are some requests like this [1]
to have whois present on their routers. We can be thinking about which
tools are essentials to you and which are you using. On the other hand,
why we should be using whois on a mobile phone or on websites. Because
in my opinion, It's all just a matter of taste.

For now, I am satisfied with enabled whois in busybox and as I was doing
compile and run tests. I thought that it was a nice idea to share it
with you.

Anyway, there isn't anything wrong with that! At least we have it
documented on the mailing list, so we can refer to it in the future.

[1]
https://forum.openwrt.org/t/whois-binary-cannot-find-providing-package/31274

Regards,

Josef


On 17. 11. 20 21:18, Paul Spooren wrote:
> On Mon Nov 16, 2020 at 9:14 PM HST, Petr Štetiar wrote:
>> Josef Schlehofer  [2020-11-17 02:07:09]:
>>
>> Hi,
>>
>>> Whois can identify who owns a domain and how to get reach owner.  Providing
>>> this tool in OpenWrt someone does not need to use websites for everything.
>> I don't think, that this tool is essential enough to be shipped by
>> default.
> I agree.
>
>> One can use whois on desktop or mobile phone for example. I think, that
>> packaging whois[1] shouldn't be that hard, then you've it one `opkg
>> install`
>> away.
>>
>> 1. https://github.com/rfc1036/whois
>>
>> Cheers,
>>
>> Petr
>>
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel



signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH v2] build: create $(PKG_SYMVERS_DIR) if non-existent

2020-11-17 Thread Felix Fietkau

On 2020-11-18 06:54, Oldřich Jedlička wrote:
> út 17. 11. 2020 v 23:00 odesílatel Sebastian Kemper
>  napsal:
>>
>> Commit 5d76065 moved the creation of the symvers directory to
>> include/kernel-build.mk. This is fine when building from scratch. But
>> when unpacking an SDK the directory doesn't exist and because the kernel
>> won't be built (again) this directory will not be created by the build
>> system, causing build failure if make tries to copy files into it.
>>
>> This moves the creation of the symvers directory back into
>> include/kernel.mk so that the directory is created in any case.
>>
>> Signed-off-by: Sebastian Kemper 
>> ---
>>  include/kernel-build.mk | 1 -
>>  include/kernel.mk   | 1 +
>>  2 files changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/kernel-build.mk b/include/kernel-build.mk
>> index a698deec3c..22f7c4c7c7 100644
>> --- a/include/kernel-build.mk
>> +++ b/include/kernel-build.mk
>> @@ -136,7 +136,6 @@ define BuildKernel
>>$(LINUX_DIR)/.modules: export 
>> PKG_CONFIG_LIBDIR=$$(STAGING_DIR_HOST)/lib/pkgconfig
>>$(LINUX_DIR)/.modules: $(STAMP_CONFIGURED) $(LINUX_DIR)/.config FORCE
>> $(Kernel/CompileModules)
>> -   mkdir -p $(PKG_SYMVERS_DIR)
>> touch $$@
>>
>>$(LINUX_DIR)/.image: export STAGING_PREFIX=$$(STAGING_DIR_HOST)
>> diff --git a/include/kernel.mk b/include/kernel.mk
>> index 1ae9c6be29..e803ff44e7 100644
>> --- a/include/kernel.mk
>> +++ b/include/kernel.mk
>> @@ -140,6 +140,7 @@ endif
>>  PKG_EXTMOD_SUBDIRS ?= .
>>
>>  PKG_SYMVERS_DIR = $(KERNEL_BUILD_DIR)/symvers
>> +$(shell mkdir -p $(PKG_SYMVERS_DIR))
> 
> Wouldn't it be better to move this few lines below to the place which actually
> uses the folder - into collect_module_symvers? Just before
> 
>   mv $(PKG_BUILD_DIR)/Module.symvers $(PKG_SYMVERS_DIR)/$(PKG_NAME).symvers
Yes, that's a much better solution. Running mkdir inside make context
shell expansion can easily trigger some really nasty build system
performance issues.

- Felix

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


Re: [PATCH v2] build: create $(PKG_SYMVERS_DIR) if non-existent

2020-11-17 Thread Oldřich Jedlička
út 17. 11. 2020 v 23:00 odesílatel Sebastian Kemper
 napsal:
>
> Commit 5d76065 moved the creation of the symvers directory to
> include/kernel-build.mk. This is fine when building from scratch. But
> when unpacking an SDK the directory doesn't exist and because the kernel
> won't be built (again) this directory will not be created by the build
> system, causing build failure if make tries to copy files into it.
>
> This moves the creation of the symvers directory back into
> include/kernel.mk so that the directory is created in any case.
>
> Signed-off-by: Sebastian Kemper 
> ---
>  include/kernel-build.mk | 1 -
>  include/kernel.mk   | 1 +
>  2 files changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/kernel-build.mk b/include/kernel-build.mk
> index a698deec3c..22f7c4c7c7 100644
> --- a/include/kernel-build.mk
> +++ b/include/kernel-build.mk
> @@ -136,7 +136,6 @@ define BuildKernel
>$(LINUX_DIR)/.modules: export 
> PKG_CONFIG_LIBDIR=$$(STAGING_DIR_HOST)/lib/pkgconfig
>$(LINUX_DIR)/.modules: $(STAMP_CONFIGURED) $(LINUX_DIR)/.config FORCE
> $(Kernel/CompileModules)
> -   mkdir -p $(PKG_SYMVERS_DIR)
> touch $$@
>
>$(LINUX_DIR)/.image: export STAGING_PREFIX=$$(STAGING_DIR_HOST)
> diff --git a/include/kernel.mk b/include/kernel.mk
> index 1ae9c6be29..e803ff44e7 100644
> --- a/include/kernel.mk
> +++ b/include/kernel.mk
> @@ -140,6 +140,7 @@ endif
>  PKG_EXTMOD_SUBDIRS ?= .
>
>  PKG_SYMVERS_DIR = $(KERNEL_BUILD_DIR)/symvers
> +$(shell mkdir -p $(PKG_SYMVERS_DIR))

Wouldn't it be better to move this few lines below to the place which actually
uses the folder - into collect_module_symvers? Just before

  mv $(PKG_BUILD_DIR)/Module.symvers $(PKG_SYMVERS_DIR)/$(PKG_NAME).symvers

To have the same usage pattern as it is in ModuleAutoload (creation of
/etc/modules-boot.d before usage) and kmod-*/install (creation of MODULES_SUBDIR
before usage),

Or are there any other dependencies on PKG_SYMBERS_DIR existence before the
actual install step?

>
>  define collect_module_symvers
> for subdir in $(PKG_EXTMOD_SUBDIRS); do \
> --
> 2.26.2
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Oldrich.

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


Re: [PATCH] tools: sstrip: update to latest version

2020-11-17 Thread Paul Spooren
On Wed Nov 11, 2020 at 1:53 PM HST, Rui Salvaterra wrote:
> Drop our local sstrip copy and use the current ELFKickers upstream
> version.
> Patch the original makefile in order to avoid building elftoc, since it
> fails
> with musl's elf.h. This is fine, since we only need sstrip anyway.
> Finally, add the possibility to pass additional arguments to sstrip (-z
> being
> the obvious candidate).
>
> Signed-off-by: Rui Salvaterra 

LGTM, tested and works fine.

Could you please create a slightly more verbose patch name for
001-compile.patch?

Do you see any possible success in pinging upstream to unify their
versioning? sstrip 3.1a still outputs version 2.0.

Please create an additional patch to enable -z by default.

> ---
> config/Config-build.in | 8 +
> rules.mk | 2 +-
> tools/sstrip/Makefile | 15 +-
> tools/sstrip/patches/001-compile.patch | 19 +
> tools/sstrip/src/sstrip.c | 466 -
> 5 files changed, 36 insertions(+), 474 deletions(-)
> create mode 100644 tools/sstrip/patches/001-compile.patch
> delete mode 100644 tools/sstrip/src/sstrip.c
>
> diff --git a/config/Config-build.in b/config/Config-build.in
> index 178afbdb94..c54bc243c5 100644
> --- a/config/Config-build.in
> +++ b/config/Config-build.in
> @@ -182,6 +182,14 @@ menu "Global build settings"
> help
> Specifies arguments passed to the strip command when stripping binaries.
>  
> + config SSTRIP_ARGS
> + string
> + prompt "Sstrip arguments"
> + depends on USE_SSTRIP
> + default ""
> + help
> + Specifies arguments passed to the sstrip command when stripping
> binaries.
> +
> config STRIP_KERNEL_EXPORTS
> bool "Strip unnecessary exports from the kernel image"
> help
> diff --git a/rules.mk b/rules.mk
> index e416126030..5c1c141c11 100644
> --- a/rules.mk
> +++ b/rules.mk
> @@ -328,7 +328,7 @@ else
> STRIP:=$(TARGET_CROSS)strip $(call qstrip,$(CONFIG_STRIP_ARGS))
> else
> ifneq ($(CONFIG_USE_SSTRIP),)
> - STRIP:=$(STAGING_DIR_HOST)/bin/sstrip
> + STRIP:=$(STAGING_DIR_HOST)/bin/sstrip $(call
> qstrip,$(CONFIG_SSTRIP_ARGS))
> endif
> endif
> RSTRIP= \
> diff --git a/tools/sstrip/Makefile b/tools/sstrip/Makefile
> index bab172a95a..590d183db0 100644
> --- a/tools/sstrip/Makefile
> +++ b/tools/sstrip/Makefile
> @@ -6,18 +6,19 @@
> #
> include $(TOPDIR)/rules.mk
>  
> -PKG_NAME:=sstrip
> -PKG_VERSION:=2.0
> +PKG_NAME:=ELFkickers
> +PKG_VERSION:=3.1a
> +
> +PKG_SOURCE_URL:=https://www.muppetlabs.com/~breadbox/pub/software
> +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
> +PKG_HASH:=06430880aaf4919c5f99fc629da7000347421668c2cf32bced2d401aac276508
> +
> PKG_RELEASE:=1
>  
> include $(INCLUDE_DIR)/host-build.mk
>  
> -define Host/Compile
> - $(HOSTCC) $(HOST_CFLAGS) -include endian.h -o $(HOST_BUILD_DIR)/sstrip
> src/sstrip.c
> -endef
> -
> define Host/Install
> - $(CP) $(HOST_BUILD_DIR)/sstrip $(STAGING_DIR_HOST)/bin/
> + $(CP) $(HOST_BUILD_DIR)/bin/sstrip $(STAGING_DIR_HOST)/bin/
> endef
>  
> define Host/Clean
> diff --git a/tools/sstrip/patches/001-compile.patch
> b/tools/sstrip/patches/001-compile.patch
> new file mode 100644
> index 00..9d3346edfb
> --- /dev/null
> +++ b/tools/sstrip/patches/001-compile.patch
> @@ -0,0 +1,19 @@
> +--- a/Makefile
>  b/Makefile
> +@@ -2,7 +2,7 @@
> +
> + prefix = /usr/local
> +
> +-PROGRAMS = elfls objres rebind sstrip elftoc ebfc infect
> ++PROGRAMS = elfls objres rebind sstrip ebfc infect
> +
> + all: $(PROGRAMS)
> +
> +@@ -19,7 +19,6 @@ elfls: bin/elfls doc/elfls.1
> + objres: bin/objres doc/objres.1
> + rebind: bin/rebind doc/rebind.1
> + sstrip: bin/sstrip doc/sstrip.1
> +-elftoc: bin/elftoc doc/elftoc.1
> + ebfc: bin/ebfc doc/ebfc.1
> + infect: bin/infect doc/infect.1
> +
> diff --git a/tools/sstrip/src/sstrip.c b/tools/sstrip/src/sstrip.c
> deleted file mode 100644
> index 12cf12e095..00
> --- a/tools/sstrip/src/sstrip.c
> +++ /dev/null
> @@ -1,466 +0,0 @@
> -/* http://www.muppetlabs.com/~breadbox/software/elfkickers.html */
> -
> -/* sstrip: Copyright (C) 1999-2001 by Brian Raiter, under the GNU
> - * General Public License. No warranty. See COPYING for details.
> - *
> - * Aug 23, 2004 Hacked by Manuel Novoa III  to
> - * handle targets of different endianness and/or elf class, making
> - * it more useful in a cross-devel environment.
> - */
> -
> -/* == original README ===
> - *
> - * sstrip is a small utility that removes the contents at the end of an
> - * ELF file that are not part of the program's memory image.
> - *
> - * Most ELF executables are built with both a program header table and
> a
> - * section header table. However, only the former is required in order
> - * for the OS to load, link and execute a program. sstrip attempts to
> - * extract the ELF header, the program header table, and its contents,
> - * leaving everything else in the bit bucket. It can only remove parts
> of
> - * the file that occur at the end, after the parts to be saved.
> However,
> - * this almost always includes the section header table, and
> occasi

Re: [PATCH v2] build: create $(PKG_SYMVERS_DIR) if non-existent

2020-11-17 Thread Paul Spooren
On Tue Nov 17, 2020 at 11:59 AM HST, Sebastian Kemper wrote:
> Commit 5d76065 moved the creation of the symvers directory to
> include/kernel-build.mk. This is fine when building from scratch. But
> when unpacking an SDK the directory doesn't exist and because the kernel
> won't be built (again) this directory will not be created by the build
> system, causing build failure if make tries to copy files into it.
>
> This moves the creation of the symvers directory back into
> include/kernel.mk so that the directory is created in any case.
>
> Signed-off-by: Sebastian Kemper 

Acked-by: Paul Spooren 

> ---
> include/kernel-build.mk | 1 -
> include/kernel.mk | 1 +
> 2 files changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/kernel-build.mk b/include/kernel-build.mk
> index a698deec3c..22f7c4c7c7 100644
> --- a/include/kernel-build.mk
> +++ b/include/kernel-build.mk
> @@ -136,7 +136,6 @@ define BuildKernel
> $(LINUX_DIR)/.modules: export
> PKG_CONFIG_LIBDIR=$$(STAGING_DIR_HOST)/lib/pkgconfig
> $(LINUX_DIR)/.modules: $(STAMP_CONFIGURED) $(LINUX_DIR)/.config FORCE
> $(Kernel/CompileModules)
> - mkdir -p $(PKG_SYMVERS_DIR)
> touch $$@
>
> $(LINUX_DIR)/.image: export STAGING_PREFIX=$$(STAGING_DIR_HOST)
> diff --git a/include/kernel.mk b/include/kernel.mk
> index 1ae9c6be29..e803ff44e7 100644
> --- a/include/kernel.mk
> +++ b/include/kernel.mk
> @@ -140,6 +140,7 @@ endif
> PKG_EXTMOD_SUBDIRS ?= .
>
> PKG_SYMVERS_DIR = $(KERNEL_BUILD_DIR)/symvers
> +$(shell mkdir -p $(PKG_SYMVERS_DIR))
>
> define collect_module_symvers
> for subdir in $(PKG_EXTMOD_SUBDIRS); do \
> --
> 2.26.2
>
>
> ___
> 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


回复: kernel: remove mvsw61xx swconfig driver

2020-11-17 Thread DENG Qingfang
Hi Georgi,

> 2. WRT3200ACM has two Ethernet interfaces. Isn’t it more efficient to have
> dedicated interfaces for LAN and WAN compared to the DSA model which uses
> only one of them, and creates multiple interfaces using VLANs?

You only have to worry about that if you have (upload + download) > 1Gbps 
connection.

FYI, there is a patch in Turris OS that added multiple CPU ports support
https://gitlab.nic.cz/turris/turris-build/-/blob/hbd/patches/openwrt/wip/0005-mvebu-initial-support-for-Omnia-on-5.4-kernel.patch

I have tested that on my WRT1900AC v2, with some modification (delegate the 
second CPU port to WAN).




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


Re: kernel: remove mvsw61xx swconfig driver

2020-11-17 Thread Rosen Penev
On Tue, Nov 17, 2020 at 2:15 PM Georgi Valkov  wrote:
>
> Dear DENG Qingfang,
>
> Can you please take a moment to discuss the switch from mvsw61xx swconfig 
> driver to DSA?
> While I like the simplicity of having lan1 lan2 lan3 lan4 wan interfaces for 
> each port, there are a few important issues that remain to be addressed:
> 1. Since the new DSA does not support swconfig, it is no longer possible to 
> use port mirroring.
> 2. WRT3200ACM has two Ethernet interfaces. Isn’t it more efficient to have 
> dedicated interfaces for LAN and WAN compared to the DSA model which uses 
> only one of them, and creates multiple interfaces using VLANs?
The Turris people have a patch for this. I ported it to master here:
https://github.com/neheb/openwrt/commit/b8c124c08b12cebf71cf80078ab688feff4ae796

I have not tested it.
>
> Would it be possible to enable the missing functionality in DSA? 1 is very 
> important to me. If not, then would it be possible to have a menuconfig 
> setting, so users can choose whether they want DSA or prefer swconfig? In my 
> fork of OpenWRT I keep a commit that restores the swconfig mode for 
> WRT3200ACM. Everything works correctly and the interfaces are named lan wan.
>
> --
> Georgi Valkov
> github.com/httpstorm/
> httpstorm.com
>
>
> ___
> 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


kernel: remove mvsw61xx swconfig driver

2020-11-17 Thread dengqf6
Hi,
 
> I assume this will land in kernel 5.11.
> 
> At a minimum, it needs to be backported.

I already backported it, see commit 24410595e91c.

But there is no uci configuration available yet, you have to use `tc' in 
command line.
Refer to 
https://github.com/Mellanox/mlxsw/wiki/Port-Mirroring#user-content-basic-configuration
 for the configuration.





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


Re: kernel: remove mvsw61xx swconfig driver

2020-11-17 Thread Rosen Penev
On Tue, Nov 17, 2020 at 2:15 PM Georgi Valkov  wrote:
>
> Dear DENG Qingfang,
>
> Can you please take a moment to discuss the switch from mvsw61xx swconfig 
> driver to DSA?
> While I like the simplicity of having lan1 lan2 lan3 lan4 wan interfaces for 
> each port, there are a few important issues that remain to be addressed:
> 1. Since the new DSA does not support swconfig, it is no longer possible to 
> use port mirroring.
> 2. WRT3200ACM has two Ethernet interfaces. Isn’t it more efficient to have 
> dedicated interfaces for LAN and WAN compared to the DSA model which uses 
> only one of them, and creates multiple interfaces using VLANs?
>
> Would it be possible to enable the missing functionality in DSA? 1 is very 
> important to me. If not, then would it be possible to have a menuconfig 
> setting, so users can choose whether they want DSA or prefer swconfig? In my 
> fork of OpenWRT I keep a commit that restores the swconfig mode for 
> WRT3200ACM. Everything works correctly and the interfaces are named lan wan.
Quick google search:
https://lore.kernel.org/netdev/2019110724.106310-1-irtim...@gmail.com/

I assume this will land in kernel 5.11.

At a minimum, it needs to be backported.
>
> --
> Georgi Valkov
> github.com/httpstorm/
> httpstorm.com
>
>
> ___
> 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


Re: perl/host/compile: fails on macOS 11 Big Sur, workaround

2020-11-17 Thread Rosen Penev
On Tue, Nov 17, 2020 at 3:16 PM Georgi Valkov  wrote:
>
> Dear OpenWRT team,
>
> I just updated my laptop to macOS 11 Big Sur. Presently only the perl hostpkg 
> package fails during the build. Once I get past perl, everything else 
> compiles correctly. Below is a patch, workaround, and details from my 
> research. My target is Marvell EBU Armada, Linksys WRT3200ACM.
>
> Before applying the patch, make package/feeds/packages/perl/host/compile V=sc 
> fails with the following error:
> Which of these apply, if any? [darwin]
>
> *** Unexpected product version 11.0.
> ***
> *** Try running sw_vers and see what its ProductVersion says.
>
> After the patch, make package/feeds/packages/perl/host/compile succeeds, 
> however when multiple workers are used: make 
> package/feeds/packages/perl/host/compile -j 12 V=sc, the build fails:
> Writing Makefile for CPAN
> make[4]: Entering directory 
> '/Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/cpan/Archive-Tar'
> make[4]: Entering directory 
> '/Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/cpan/CPAN'
> Generating a Unix-style Makefile
> Writing Makefile for Errno
> make[4]: Entering directory 
> '/Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/ext/Errno'
> "../../miniperl" "-I../../lib" Errno_pm.PL Errno.pm
> Can't locate Errno.pm in @INC (you may need to install the Errno module) 
> (@INC contains: 
> /Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/cpan/AutoLoader/lib 
> /Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/dist/Carp/lib 
> /Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/dist/PathTools 
> /Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/dist/PathTools/lib 
> /Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/cpan/ExtUtils-Install/lib
>  
> /Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/cpan/ExtUtils-MakeMaker/lib
>  
> /Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/cpan/ExtUtils-Manifest/lib
>  /Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/cpan/File-Path/lib 
> /Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/ext/re 
> /Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/dist/Term-ReadLine/lib
>  /Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/dist/Exporter/lib 
> /Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/ext/File-Find/lib 
> /Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/cpan/Text-Tabs/lib 
> /Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/dist/constant/lib 
> /Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/cpan/version/lib 
> /Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/lib .) at 
> /Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/dist/PathTools/Cwd.pm
>  line 444.
> Unsuccessful Makefile.PL(cpan/ExtUtils-MakeMaker): code=512 at make_ext.pl 
> line 518.
> make[3]: *** [GNUmakefile:599: cpan/ExtUtils-MakeMaker/pm_to_blib] Error 2
>
> I have also seen errors where the build is trying to use /miniperl instead of 
> ./miniperl, as well as /build_dir/hostpkg/perl/perl-5.28.1/perl instead of 
> /Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/perl. The will occur 
> if we try to build perl without host/clean and clean. Seems like a race 
> condition due to dependency misconfiguration.
>
> Here is the list of all commands in order to compile OpenWRT starting from a 
> clean build root:
> make -j 12
> make package/feeds/packages/perl/host/clean
> make package/feeds/packages/perl/clean
> make package/feeds/packages/perl/compile
> make -j 12
>
> The first make fails, then we perform host-clean and clean for perl, next 
> compile will also do host-compile - we have to use a single worker here. 
> Finally we can complete the rest of the build process. I should note that 
> Languages, Perl, perl is not selected in menuconfig. I can understand if the 
> hostpkg/perl is required during the build process, however 
> perl/host{clean,compile} is not enough, I also need to perform 
> perl/{clean,compile}.
>
> Here is the quick patch I made in order to verify if there are any other 
> broken packages: no. Only perl fails to compile. I am also not sure how to 
> handle patches and pull-requests for feeds, so I thought I should rather 
> share my research here and ask for help.
>
> feeds/packages/lang/perl/patches/302-macos_11_support.patch
> Index: perl-5.28.1/hints/darwin.sh
> ===
> --- perl-5.28.1.orig/hints/darwin.sh
> +++ perl-5.28.1/hints/darwin.sh
> @@ -327,7 +327,7 @@ EOM
>  # "ProductVersion:10.11" "10.11"
>  prodvers=`sw_vers|awk '/^ProductVersion:/{print $2}'|awk -F. '{print 
> $1"."$2}'`
>  case "$prodvers" in
> -10.*)
> +10.*|11.*)
>add_macosx_version_min ccflags $prodvers
>add_macosx_version_min ldflags $prodvers
>;;
>
This patch is for https://github.com/openwrt/packages

Please submit a PR there.

Speaking of perl, it could probably use an update.
>
>

perl/host/compile: fails on macOS 11 Big Sur, workaround

2020-11-17 Thread Georgi Valkov
Dear OpenWRT team,

I just updated my laptop to macOS 11 Big Sur. Presently only the perl hostpkg 
package fails during the build. Once I get past perl, everything else compiles 
correctly. Below is a patch, workaround, and details from my research. My 
target is Marvell EBU Armada, Linksys WRT3200ACM.

Before applying the patch, make package/feeds/packages/perl/host/compile V=sc 
fails with the following error:
Which of these apply, if any? [darwin]  

*** Unexpected product version 11.0.
***
*** Try running sw_vers and see what its ProductVersion says.

After the patch, make package/feeds/packages/perl/host/compile succeeds, 
however when multiple workers are used: make 
package/feeds/packages/perl/host/compile -j 12 V=sc, the build fails:
Writing Makefile for CPAN
make[4]: Entering directory 
'/Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/cpan/Archive-Tar'
make[4]: Entering directory 
'/Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/cpan/CPAN'
Generating a Unix-style Makefile
Writing Makefile for Errno
make[4]: Entering directory 
'/Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/ext/Errno'
"../../miniperl" "-I../../lib" Errno_pm.PL Errno.pm
Can't locate Errno.pm in @INC (you may need to install the Errno module) (@INC 
contains: 
/Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/cpan/AutoLoader/lib 
/Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/dist/Carp/lib 
/Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/dist/PathTools 
/Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/dist/PathTools/lib 
/Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/cpan/ExtUtils-Install/lib
 
/Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/cpan/ExtUtils-MakeMaker/lib
 
/Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/cpan/ExtUtils-Manifest/lib
 /Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/cpan/File-Path/lib 
/Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/ext/re 
/Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/dist/Term-ReadLine/lib 
/Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/dist/Exporter/lib 
/Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/ext/File-Find/lib 
/Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/cpan/Text-Tabs/lib 
/Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/dist/constant/lib 
/Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/cpan/version/lib 
/Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/lib .) at 
/Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/dist/PathTools/Cwd.pm 
line 444.
Unsuccessful Makefile.PL(cpan/ExtUtils-MakeMaker): code=512 at make_ext.pl line 
518.
make[3]: *** [GNUmakefile:599: cpan/ExtUtils-MakeMaker/pm_to_blib] Error 2

I have also seen errors where the build is trying to use /miniperl instead of 
./miniperl, as well as /build_dir/hostpkg/perl/perl-5.28.1/perl instead of 
/Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/perl. The will occur 
if we try to build perl without host/clean and clean. Seems like a race 
condition due to dependency misconfiguration.

Here is the list of all commands in order to compile OpenWRT starting from a 
clean build root:
make -j 12
make package/feeds/packages/perl/host/clean
make package/feeds/packages/perl/clean
make package/feeds/packages/perl/compile
make -j 12

The first make fails, then we perform host-clean and clean for perl, next 
compile will also do host-compile - we have to use a single worker here. 
Finally we can complete the rest of the build process. I should note that 
Languages, Perl, perl is not selected in menuconfig. I can understand if the 
hostpkg/perl is required during the build process, however 
perl/host{clean,compile} is not enough, I also need to perform 
perl/{clean,compile}.

Here is the quick patch I made in order to verify if there are any other broken 
packages: no. Only perl fails to compile. I am also not sure how to handle 
patches and pull-requests for feeds, so I thought I should rather share my 
research here and ask for help.

feeds/packages/lang/perl/patches/302-macos_11_support.patch
Index: perl-5.28.1/hints/darwin.sh
===
--- perl-5.28.1.orig/hints/darwin.sh
+++ perl-5.28.1/hints/darwin.sh
@@ -327,7 +327,7 @@ EOM
 # "ProductVersion:10.11" "10.11"
 prodvers=`sw_vers|awk '/^ProductVersion:/{print $2}'|awk -F. '{print 
$1"."$2}'`
 case "$prodvers" in
-10.*)
+10.*|11.*)
   add_macosx_version_min ccflags $prodvers
   add_macosx_version_min ldflags $prodvers
   ;;


Thank you for any help!
Georgi Valkov

https://bugs.openwrt.org/index.php?do=details&task_id=3458


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


Re: [PATCH] build: create $(PKG_SYMVERS_DIR) if non-existent

2020-11-17 Thread Hannu Nyman

Paul Spooren wrote at Tue Nov 17 16:53:29 EST 2020:
> Could you please provide an example when that fails? E.g. what package
> makes the SDK copy things there?

Pretty much all kernel related packages, like I already disgnosed a few days 
ago in

http://lists.openwrt.org/pipermail/openwrt-devel/2020-November/032115.html

Examples that I used then were cryptodev-linux and exfat.

Buildbot has been broken regarding the kernel packages for the last 3-4 days.

Kernel packages failing cause then carnage with other packages

https://downloads.openwrt.org/snapshots/faillogs/x86_64/base/
https://downloads.openwrt.org/snapshots/faillogs/x86_64/packages/



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


kernel: remove mvsw61xx swconfig driver

2020-11-17 Thread Georgi Valkov
Dear DENG Qingfang,

Can you please take a moment to discuss the switch from mvsw61xx swconfig 
driver to DSA?
While I like the simplicity of having lan1 lan2 lan3 lan4 wan interfaces for 
each port, there are a few important issues that remain to be addressed:
1. Since the new DSA does not support swconfig, it is no longer possible to use 
port mirroring.
2. WRT3200ACM has two Ethernet interfaces. Isn’t it more efficient to have 
dedicated interfaces for LAN and WAN compared to the DSA model which uses only 
one of them, and creates multiple interfaces using VLANs?

Would it be possible to enable the missing functionality in DSA? 1 is very 
important to me. If not, then would it be possible to have a menuconfig 
setting, so users can choose whether they want DSA or prefer swconfig? In my 
fork of OpenWRT I keep a commit that restores the swconfig mode for WRT3200ACM. 
Everything works correctly and the interfaces are named lan wan.

--
Georgi Valkov
github.com/httpstorm/
httpstorm.com


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


Re: [PATCH] build: create $(PKG_SYMVERS_DIR) if non-existent

2020-11-17 Thread Sebastian Kemper
On Tue, Nov 17, 2020 at 11:53:29AM -1000, Paul Spooren wrote:
> On Tue Nov 17, 2020 at 11:36 AM HST, Sebastian Kemper wrote:
> > Commit 5d76065 moved the creation of the symvers directory to
> > include/kernel-build.mk. This is fine when building from scratch. But
> > when unpacking an SDK the directory doesn't exist and because the kernel
> > won't be built (again) this directory will not be created by the build
> > system, causing build failure if make tries to copy files into it.
> >
> > Signed-off-by: Sebastian Kemper 
>
> Could you please provide an example when that fails? E.g. what package
> makes the SDK copy things there?

Hi Paul,

All kernel module packages I suppose. Look at the failures on the build
bots these days, since the mentioned commit hit master. I.e. [1] fails
and then there is follow-up breakage. Or download an SDK, unpack it,
install cryptodev-linux and try to package it. It'll fail, obviously,
because the build bots are using the SDK and so are you :)

Kind regards,
Seb

[1] 
https://downloads.openwrt.org/snapshots/faillogs/aarch64_cortex-a53/base/cryptodev-linux/compile.txt
>
> > ---
> > include/kernel.mk | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/include/kernel.mk b/include/kernel.mk
> > index 1ae9c6be29..e803ff44e7 100644
> > --- a/include/kernel.mk
> > +++ b/include/kernel.mk
> > @@ -140,6 +140,7 @@ endif
> > PKG_EXTMOD_SUBDIRS ?= .
> >
> > PKG_SYMVERS_DIR = $(KERNEL_BUILD_DIR)/symvers
> > +$(shell mkdir -p $(PKG_SYMVERS_DIR))
> >
> > define collect_module_symvers
> > for subdir in $(PKG_EXTMOD_SUBDIRS); do \
> > --
> > 2.26.2
> >
> >
> > ___
> > 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


[PATCH v2] build: create $(PKG_SYMVERS_DIR) if non-existent

2020-11-17 Thread Sebastian Kemper
Commit 5d76065 moved the creation of the symvers directory to
include/kernel-build.mk. This is fine when building from scratch. But
when unpacking an SDK the directory doesn't exist and because the kernel
won't be built (again) this directory will not be created by the build
system, causing build failure if make tries to copy files into it.

This moves the creation of the symvers directory back into
include/kernel.mk so that the directory is created in any case.

Signed-off-by: Sebastian Kemper 
---
 include/kernel-build.mk | 1 -
 include/kernel.mk   | 1 +
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/kernel-build.mk b/include/kernel-build.mk
index a698deec3c..22f7c4c7c7 100644
--- a/include/kernel-build.mk
+++ b/include/kernel-build.mk
@@ -136,7 +136,6 @@ define BuildKernel
   $(LINUX_DIR)/.modules: export 
PKG_CONFIG_LIBDIR=$$(STAGING_DIR_HOST)/lib/pkgconfig
   $(LINUX_DIR)/.modules: $(STAMP_CONFIGURED) $(LINUX_DIR)/.config FORCE
$(Kernel/CompileModules)
-   mkdir -p $(PKG_SYMVERS_DIR)
touch $$@

   $(LINUX_DIR)/.image: export STAGING_PREFIX=$$(STAGING_DIR_HOST)
diff --git a/include/kernel.mk b/include/kernel.mk
index 1ae9c6be29..e803ff44e7 100644
--- a/include/kernel.mk
+++ b/include/kernel.mk
@@ -140,6 +140,7 @@ endif
 PKG_EXTMOD_SUBDIRS ?= .

 PKG_SYMVERS_DIR = $(KERNEL_BUILD_DIR)/symvers
+$(shell mkdir -p $(PKG_SYMVERS_DIR))

 define collect_module_symvers
for subdir in $(PKG_EXTMOD_SUBDIRS); do \
--
2.26.2


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


Re: [PATCH] build: create $(PKG_SYMVERS_DIR) if non-existent

2020-11-17 Thread Paul Spooren
On Tue Nov 17, 2020 at 11:36 AM HST, Sebastian Kemper wrote:
> Commit 5d76065 moved the creation of the symvers directory to
> include/kernel-build.mk. This is fine when building from scratch. But
> when unpacking an SDK the directory doesn't exist and because the kernel
> won't be built (again) this directory will not be created by the build
> system, causing build failure if make tries to copy files into it.
>
> Signed-off-by: Sebastian Kemper 

Could you please provide an example when that fails? E.g. what package
makes the SDK copy things there?

> ---
> include/kernel.mk | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/kernel.mk b/include/kernel.mk
> index 1ae9c6be29..e803ff44e7 100644
> --- a/include/kernel.mk
> +++ b/include/kernel.mk
> @@ -140,6 +140,7 @@ endif
> PKG_EXTMOD_SUBDIRS ?= .
>
> PKG_SYMVERS_DIR = $(KERNEL_BUILD_DIR)/symvers
> +$(shell mkdir -p $(PKG_SYMVERS_DIR))
>
> define collect_module_symvers
> for subdir in $(PKG_EXTMOD_SUBDIRS); do \
> --
> 2.26.2
>
>
> ___
> 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


[PATCH] build: create $(PKG_SYMVERS_DIR) if non-existent

2020-11-17 Thread Sebastian Kemper
Commit 5d76065 moved the creation of the symvers directory to
include/kernel-build.mk. This is fine when building from scratch. But
when unpacking an SDK the directory doesn't exist and because the kernel
won't be built (again) this directory will not be created by the build
system, causing build failure if make tries to copy files into it.

Signed-off-by: Sebastian Kemper 
---
 include/kernel.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/kernel.mk b/include/kernel.mk
index 1ae9c6be29..e803ff44e7 100644
--- a/include/kernel.mk
+++ b/include/kernel.mk
@@ -140,6 +140,7 @@ endif
 PKG_EXTMOD_SUBDIRS ?= .

 PKG_SYMVERS_DIR = $(KERNEL_BUILD_DIR)/symvers
+$(shell mkdir -p $(PKG_SYMVERS_DIR))

 define collect_module_symvers
for subdir in $(PKG_EXTMOD_SUBDIRS); do \
--
2.26.2


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


Re: Merging /usr

2020-11-17 Thread Paul Spooren
Hi,

> It appears most of the major distros (Debian/Ubuntu, Fedora, Arch,
> Solaris) have moved to merge the contents of /{bin,sbin,lib}/ into
> /usr/{bin,sbin,lib}/, with top-level symbolic links added for
> compatibility.

Sounds good to me, do you have an estimate how much work this is?

> There is a wiki page on freedesktop.org[1] that goes into the
> reasoning, and LWN[2][3] has also written about it.
>
> Is this something we would like to consider as well? It may be too
> late for 20.x but this change does appear to simplify things (at least
> for package maintainers).

I hope the 20.xx branch happens within the next "decision maker" call,
so one could already start some work on this to get things going just
after the branch.

Paul

> [1]: > 
> https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
> [2]: https://lwn.net/Articles/670071/
> [3]: https://lwn.net/Articles/483921/

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


Re: [PATCH] busybox: enable whois by default

2020-11-17 Thread Paul Spooren
On Mon Nov 16, 2020 at 9:14 PM HST, Petr Štetiar wrote:
> Josef Schlehofer  [2020-11-17 02:07:09]:
>
> Hi,
>
> > Whois can identify who owns a domain and how to get reach owner.  Providing
> > this tool in OpenWrt someone does not need to use websites for everything.
>
> I don't think, that this tool is essential enough to be shipped by
> default.

I agree.

> One can use whois on desktop or mobile phone for example. I think, that
> packaging whois[1] shouldn't be that hard, then you've it one `opkg
> install`
> away.
>
> 1. https://github.com/rfc1036/whois
>
> Cheers,
>
> Petr
>
> ___
> 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


Merging /usr

2020-11-17 Thread Jeffery To
Hi,

It appears most of the major distros (Debian/Ubuntu, Fedora, Arch,
Solaris) have moved to merge the contents of /{bin,sbin,lib}/ into
/usr/{bin,sbin,lib}/, with top-level symbolic links added for
compatibility.

There is a wiki page on freedesktop.org[1] that goes into the
reasoning, and LWN[2][3] has also written about it.

Is this something we would like to consider as well? It may be too
late for 20.x but this change does appear to simplify things (at least
for package maintainers).

Jeff

[1]: https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
[2]: https://lwn.net/Articles/670071/
[3]: https://lwn.net/Articles/483921/

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


RE: [PATCH v1 3/4] generic: add DTR quirk patch for MR400 LTE

2020-11-17 Thread Adrian Schmutzler
Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Filip Moc
> Sent: Dienstag, 17. November 2020 12:33
> To: openwrt-devel@lists.openwrt.org
> Subject: [PATCH v1 3/4] generic: add DTR quirk patch for MR400 LTE
> 
> This is required for LTE module MR400 in TL-MR6400 v4.
> 
> Signed-off-by: Filip Moc 
> ---
> 
> Notes:
> Perhaps it would be better to go upstream with this?

Always :-)

If accepted, you could add it in the backports folder ...

Best

Adrian

> 
>  ...usb-qmi_wwan-Set-DTR-quirk-for-MR400.patch | 28
> +++
>  1 file changed, 28 insertions(+)
>  create mode 100644 target/linux/generic/hack-5.4/789-net-usb-qmi_wwan-
> Set-DTR-quirk-for-MR400.patch
> 
> diff --git a/target/linux/generic/hack-5.4/789-net-usb-qmi_wwan-Set-DTR-
> quirk-for-MR400.patch b/target/linux/generic/hack-5.4/789-net-usb-
> qmi_wwan-Set-DTR-quirk-for-MR400.patch
> new file mode 100644
> index 00..9c15f01345
> --- /dev/null
> +++ b/target/linux/generic/hack-5.4/789-net-usb-qmi_wwan-Set-DTR-quirk-
> f
> +++ or-MR400.patch
> @@ -0,0 +1,28 @@
> +From a661d0b88c6de286f0b861ace670cb31776aadd6 Mon Sep 17 00:00:00
> 2001
> +From: Filip Moc 
> +Date: Wed, 11 Nov 2020 20:39:09 +0100
> +Subject: [PATCH] net: usb: qmi_wwan: Set DTR quirk for MR400
> +
> +LTE module MR400 embedded in TL-MR6400 v4 requires DTR to be set.
> +
> +Signed-off-by: Filip Moc 
> +---
> + drivers/net/usb/qmi_wwan.c | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
> +index 21d905d..da6f10a 100644
> +--- a/drivers/net/usb/qmi_wwan.c
>  b/drivers/net/usb/qmi_wwan.c
> +@@ -1092,7 +1092,7 @@ static const struct usb_device_id products[] = {
> + {QMI_FIXED_INTF(0x05c6, 0x9011, 4)},
> + {QMI_FIXED_INTF(0x05c6, 0x9021, 1)},
> + {QMI_FIXED_INTF(0x05c6, 0x9022, 2)},
> +-{QMI_FIXED_INTF(0x05c6, 0x9025, 4)},/* Alcatel-sbell ASB
> TL131 TDD LTE  (China Mobile) */
> ++{QMI_QUIRK_SET_DTR(0x05c6, 0x9025, 4)}, /* Alcatel-sbell ASB
> TL131 TDD LTE  (China Mobile) */
> + {QMI_FIXED_INTF(0x05c6, 0x9026, 3)},
> + {QMI_FIXED_INTF(0x05c6, 0x902e, 5)},
> + {QMI_FIXED_INTF(0x05c6, 0x9031, 5)},
> +--
> +2.28.0
> +
> --
> 2.28.0
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


RE: [PATCH v1 2/4] uqmi: set device-operating-mode to online

2020-11-17 Thread Adrian Schmutzler
Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Filip Moc
> Sent: Dienstag, 17. November 2020 12:33
> To: openwrt-devel@lists.openwrt.org
> Subject: [PATCH v1 2/4] uqmi: set device-operating-mode to online
> 
> This is required for LTE module MR400 (in TL-MR6400 v4).
> Otherwise LTE module won't register to GSM network.

Please bump PKG_RELEASE for this package.

Can't review the change itself.

Best

Adrian

> 
> Signed-off-by: Filip Moc 
> ---
>  package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
> b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
> index 7870eb7382..dbfcdcb098 100755
> --- a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
> +++ b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
> @@ -174,6 +174,9 @@ proto_qmi_setup() {
>   # Cleanup current state if any
>   uqmi -s -d "$device" --stop-network 0x --autoconnect >
> /dev/null 2>&1
> 
> + # Go online
> + uqmi -s -d "$device" --set-device-operating-mode online > /dev/null
> 2>&1
> +
>   # Set IP format
>   uqmi -s -d "$device" --set-data-format 802.3 > /dev/null 2>&1
>   uqmi -s -d "$device" --wda-set-data-format 802.3 > /dev/null 2>&1
> --
> 2.28.0
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


RE: [PATCH v1 4/4] ramips: add support for TP-Link MR6400 v4

2020-11-17 Thread Adrian Schmutzler
Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Filip Moc
> Sent: Dienstag, 17. November 2020 12:34
> To: openwrt-devel@lists.openwrt.org
> Subject: [PATCH v1 4/4] ramips: add support for TP-Link MR6400 v4
> 
> You can flash via tftp recovery:
>  - serve tftp-recovery image as /tp_recovery.bin on 192.168.0.225/24
>  - connect to any ethernet port
>  - power on the device while holding the reset button
>  - wait at least 8 seconds before releasing reset button
> 
> Flashing via OEM web interface does not work.
> 
> LTE module does not support DHCP so it must be configured via QMI.
> 
> Hardware Specification (v4.0 EU):
>  - SoC: MT7628NN
>  - Flash: Winbond W25Q64JVS (8MiB)
>  - RAM: ESMT M14D5121632A (64MiB)
>  - Wireless: SoC platform only (2.4GHz b/g/n, 2x internal antenna)
>  - Ethernet: 1NIC (4x100M)
>  - WWAN: TP-LINK LTE MODULE (2x external detachable antenna)
>  - Power: DC 9V 0.85A
> 
> Signed-off-by: Filip Moc 
> ---
> 
> Notes:
> Bugs:
>   This device is affected by first uqmi command hang.
>   This causes qmi proto to hang sometimes when setting up wwan
> connection for
>   the first time after boot.
>   There is already a patch [1] which aims to fix this.
>   So far it can be manually restarted or workarounded by editing qmi.sh 
> [2].
> 
> There are also some other issues with LTE module which are addressed by
> preceding patches.
> 
> [1]
> https://patchwork.ozlabs.org/project/openwrt/patch/20191107115408.1301
> 3-1-zefir.kurt...@neratec.com/
> [2] https://forum.openwrt.org/t/solved-lte-qmi-troubles/28379
> 
>  .../dts/mt7628an_tplink_tl-mr6400-v4.dts  | 97 +++
>  target/linux/ramips/image/mt76x8.mk   | 16 +++
>  .../mt76x8/base-files/etc/board.d/01_leds |  5 +
>  .../mt76x8/base-files/etc/board.d/02_network  |  4 +
>  4 files changed, 122 insertions(+)
>  create mode 100644 target/linux/ramips/dts/mt7628an_tplink_tl-mr6400-
> v4.dts
> 
> diff --git a/target/linux/ramips/dts/mt7628an_tplink_tl-mr6400-v4.dts
> b/target/linux/ramips/dts/mt7628an_tplink_tl-mr6400-v4.dts
> new file mode 100644
> index 00..9dc71ffd9e
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7628an_tplink_tl-mr6400-v4.dts
> @@ -0,0 +1,97 @@
> +#include "mt7628an_tplink_8m.dtsi"
> +
> +/ {
> + compatible = "tplink,tl-mr6400-v4", "mediatek,mt7628an-soc";
> + model = "TP-Link TL-MR6400 v4";
> +
> + aliases {
> + led-boot = &led_power;
> + led-failsafe = &led_power;
> + led-running = &led_power;
> + led-upgrade = &led_power;
> + };
> +
> + keys {
> + compatible = "gpio-keys";
> +
> + reset {
> + label = "reset";
> + gpios = <&gpio 38 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + rfkill {
> + label = "rfkill";
> + gpios = <&gpio 46 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led_power: power {
> + label = "white:power";
> + gpios = <&gpio 37 GPIO_ACTIVE_LOW>;
> + };
> +
> + wan {
> + label = "white:wan";
> + gpios = <&gpio 39 GPIO_ACTIVE_LOW>;
> + };
> +
> + wlan {
> + label = "white:wlan";
> + gpios = <&gpio 40 GPIO_ACTIVE_LOW>;
> + };
> +
> + lan {
> + label = "white:lan";
> + gpios = <&gpio 41 GPIO_ACTIVE_LOW>;
> + };
> +
> + signal1 {
> + label = "white:signal1";
> + gpios = <&gpio 42 GPIO_ACTIVE_LOW>;
> + };
> +
> + signal2 {
> + label = "white:signal2";
> + gpios = <&gpio 43 GPIO_ACTIVE_LOW>;
> + };
> +
> + signal3 {
> + label = "white:signal3";
> + gpios = <&gpio 44 GPIO_ACTIVE_LOW>;
> + };
> + };
> +};
> +
> +&ehci {
> + status = "okay";
> +};
> +
> +&ohci {
> + status = "okay";
> +};
> +
> +&state_default {
> + gpio {
> + groups = "p0led_an", "p1led_an", "p2led_an", "p3led_an",
> "p4led_an", "refclk", "uart1", "wdt", "wled_an";
> + function = "gpio";
> + };
> +};
> +
> +&esw {
> + mediatek,portmap = <0x2f>;
> + mediatek,portdisable = <0x21>;
> +};
> +
> +

Remove second empty line here.

> +&wmac {
> + mtd-mac-address = <&factory 0x1f100>;
> +};
> +
> +ðernet {
> + mtd-mac-address = <&factory 0x1f100>;
> +};
> diff --git a/target/linux/ramips/image/mt76x8.mk
> b/target/linux/ramips/image/mt76x8.mk
> index 6327c95bb0..f3b25bf189 100644
> --- a/t

[PATCH v1 4/4] ramips: add support for TP-Link MR6400 v4

2020-11-17 Thread Filip Moc
You can flash via tftp recovery:
 - serve tftp-recovery image as /tp_recovery.bin on 192.168.0.225/24
 - connect to any ethernet port
 - power on the device while holding the reset button
 - wait at least 8 seconds before releasing reset button

Flashing via OEM web interface does not work.

LTE module does not support DHCP so it must be configured via QMI.

Hardware Specification (v4.0 EU):
 - SoC: MT7628NN
 - Flash: Winbond W25Q64JVS (8MiB)
 - RAM: ESMT M14D5121632A (64MiB)
 - Wireless: SoC platform only (2.4GHz b/g/n, 2x internal antenna)
 - Ethernet: 1NIC (4x100M)
 - WWAN: TP-LINK LTE MODULE (2x external detachable antenna)
 - Power: DC 9V 0.85A

Signed-off-by: Filip Moc 
---

Notes:
Bugs:
  This device is affected by first uqmi command hang.
  This causes qmi proto to hang sometimes when setting up wwan connection 
for
  the first time after boot.
  There is already a patch [1] which aims to fix this.
  So far it can be manually restarted or workarounded by editing qmi.sh [2].

There are also some other issues with LTE module which are addressed by
preceding patches.

[1] 
https://patchwork.ozlabs.org/project/openwrt/patch/20191107115408.13013-1-zefir.kurt...@neratec.com/
[2] https://forum.openwrt.org/t/solved-lte-qmi-troubles/28379

 .../dts/mt7628an_tplink_tl-mr6400-v4.dts  | 97 +++
 target/linux/ramips/image/mt76x8.mk   | 16 +++
 .../mt76x8/base-files/etc/board.d/01_leds |  5 +
 .../mt76x8/base-files/etc/board.d/02_network  |  4 +
 4 files changed, 122 insertions(+)
 create mode 100644 target/linux/ramips/dts/mt7628an_tplink_tl-mr6400-v4.dts

diff --git a/target/linux/ramips/dts/mt7628an_tplink_tl-mr6400-v4.dts 
b/target/linux/ramips/dts/mt7628an_tplink_tl-mr6400-v4.dts
new file mode 100644
index 00..9dc71ffd9e
--- /dev/null
+++ b/target/linux/ramips/dts/mt7628an_tplink_tl-mr6400-v4.dts
@@ -0,0 +1,97 @@
+#include "mt7628an_tplink_8m.dtsi"
+
+/ {
+   compatible = "tplink,tl-mr6400-v4", "mediatek,mt7628an-soc";
+   model = "TP-Link TL-MR6400 v4";
+
+   aliases {
+   led-boot = &led_power;
+   led-failsafe = &led_power;
+   led-running = &led_power;
+   led-upgrade = &led_power;
+   };
+
+   keys {
+   compatible = "gpio-keys";
+
+   reset {
+   label = "reset";
+   gpios = <&gpio 38 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+
+   rfkill {
+   label = "rfkill";
+   gpios = <&gpio 46 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   led_power: power {
+   label = "white:power";
+   gpios = <&gpio 37 GPIO_ACTIVE_LOW>;
+   };
+
+   wan {
+   label = "white:wan";
+   gpios = <&gpio 39 GPIO_ACTIVE_LOW>;
+   };
+
+   wlan {
+   label = "white:wlan";
+   gpios = <&gpio 40 GPIO_ACTIVE_LOW>;
+   };
+
+   lan {
+   label = "white:lan";
+   gpios = <&gpio 41 GPIO_ACTIVE_LOW>;
+   };
+
+   signal1 {
+   label = "white:signal1";
+   gpios = <&gpio 42 GPIO_ACTIVE_LOW>;
+   };
+
+   signal2 {
+   label = "white:signal2";
+   gpios = <&gpio 43 GPIO_ACTIVE_LOW>;
+   };
+
+   signal3 {
+   label = "white:signal3";
+   gpios = <&gpio 44 GPIO_ACTIVE_LOW>;
+   };
+   };
+};
+
+&ehci {
+   status = "okay";
+};
+
+&ohci {
+   status = "okay";
+};
+
+&state_default {
+   gpio {
+   groups = "p0led_an", "p1led_an", "p2led_an", "p3led_an", 
"p4led_an", "refclk", "uart1", "wdt", "wled_an";
+   function = "gpio";
+   };
+};
+
+&esw {
+   mediatek,portmap = <0x2f>;
+   mediatek,portdisable = <0x21>;
+};
+
+
+&wmac {
+   mtd-mac-address = <&factory 0x1f100>;
+};
+
+ðernet {
+   mtd-mac-address = <&factory 0x1f100>;
+};
diff --git a/target/linux/ramips/image/mt76x8.mk 
b/target/linux/ramips/image/mt76x8.mk
index 6327c95bb0..f3b25bf189 100644
--- a/target/linux/ramips/image/mt76x8.mk
+++ b/target/linux/ramips/image/mt76x8.mk
@@ -473,6 +473,22 @@ define Device/tplink_tl-mr3420-v5
 endef
 TARGET_DEVICES += tplink_tl-mr3420-v5
 
+define Device/tplink_tl-mr6400-v4
+  $(Device/tplink-v2)
+  IMAGE_SIZE := 7808k
+  DEVICE_MODEL := TL-MR6400
+  DEVICE_VARIANT := v4
+  TPLINK_FLASHLAYOUT := 8Mmtk
+  TPLINK_HWID := 0x6404
+  TPLINK_HWREV := 0x4
+  TPLINK_HWREVADD := 0x4
+  DEVICE_PACKAGES := kmod-usb2 kmod-usb-ohci kmod-usb-ledtrig-usbport 

[PATCH v1 2/4] uqmi: set device-operating-mode to online

2020-11-17 Thread Filip Moc
This is required for LTE module MR400 (in TL-MR6400 v4).
Otherwise LTE module won't register to GSM network.

Signed-off-by: Filip Moc 
---
 package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh 
b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
index 7870eb7382..dbfcdcb098 100755
--- a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
+++ b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
@@ -174,6 +174,9 @@ proto_qmi_setup() {
# Cleanup current state if any
uqmi -s -d "$device" --stop-network 0x --autoconnect > 
/dev/null 2>&1
 
+   # Go online
+   uqmi -s -d "$device" --set-device-operating-mode online > /dev/null 2>&1
+
# Set IP format
uqmi -s -d "$device" --set-data-format 802.3 > /dev/null 2>&1
uqmi -s -d "$device" --wda-set-data-format 802.3 > /dev/null 2>&1
-- 
2.28.0


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


[PATCH v1 3/4] generic: add DTR quirk patch for MR400 LTE

2020-11-17 Thread Filip Moc
This is required for LTE module MR400 in TL-MR6400 v4.

Signed-off-by: Filip Moc 
---

Notes:
Perhaps it would be better to go upstream with this?

 ...usb-qmi_wwan-Set-DTR-quirk-for-MR400.patch | 28 +++
 1 file changed, 28 insertions(+)
 create mode 100644 
target/linux/generic/hack-5.4/789-net-usb-qmi_wwan-Set-DTR-quirk-for-MR400.patch

diff --git 
a/target/linux/generic/hack-5.4/789-net-usb-qmi_wwan-Set-DTR-quirk-for-MR400.patch
 
b/target/linux/generic/hack-5.4/789-net-usb-qmi_wwan-Set-DTR-quirk-for-MR400.patch
new file mode 100644
index 00..9c15f01345
--- /dev/null
+++ 
b/target/linux/generic/hack-5.4/789-net-usb-qmi_wwan-Set-DTR-quirk-for-MR400.patch
@@ -0,0 +1,28 @@
+From a661d0b88c6de286f0b861ace670cb31776aadd6 Mon Sep 17 00:00:00 2001
+From: Filip Moc 
+Date: Wed, 11 Nov 2020 20:39:09 +0100
+Subject: [PATCH] net: usb: qmi_wwan: Set DTR quirk for MR400
+
+LTE module MR400 embedded in TL-MR6400 v4 requires DTR to be set.
+
+Signed-off-by: Filip Moc 
+---
+ drivers/net/usb/qmi_wwan.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
+index 21d905d..da6f10a 100644
+--- a/drivers/net/usb/qmi_wwan.c
 b/drivers/net/usb/qmi_wwan.c
+@@ -1092,7 +1092,7 @@ static const struct usb_device_id products[] = {
+   {QMI_FIXED_INTF(0x05c6, 0x9011, 4)},
+   {QMI_FIXED_INTF(0x05c6, 0x9021, 1)},
+   {QMI_FIXED_INTF(0x05c6, 0x9022, 2)},
+-  {QMI_FIXED_INTF(0x05c6, 0x9025, 4)},/* Alcatel-sbell ASB TL131 TDD 
LTE  (China Mobile) */
++  {QMI_QUIRK_SET_DTR(0x05c6, 0x9025, 4)}, /* Alcatel-sbell ASB TL131 TDD 
LTE  (China Mobile) */
+   {QMI_FIXED_INTF(0x05c6, 0x9026, 3)},
+   {QMI_FIXED_INTF(0x05c6, 0x902e, 5)},
+   {QMI_FIXED_INTF(0x05c6, 0x9031, 5)},
+-- 
+2.28.0
+
-- 
2.28.0


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


[PATCH v1 1/4] uqmi: add support for IPv4 autoconf from QMI

2020-11-17 Thread Filip Moc
There already was an option for autoconfiguring IPv4 from QMI but this
was removed by commit 3b9b963e6e08 ("uqmi: always use DHCP for IPv4").

DHCP does not work on MR400 LTE module (in TL-MR6400 v4) so let's readd
support for IPv4 autoconf from QMI but this time allow to configure this
for IPv4 and IPv6 independently and keep DHCP default on IPv4.

Signed-off-by: Filip Moc 
---
 .../utils/uqmi/files/lib/netifd/proto/qmi.sh  | 49 ++-
 1 file changed, 38 insertions(+), 11 deletions(-)

diff --git a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh 
b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
index 8cbe9e97e7..7870eb7382 100755
--- a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
+++ b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
@@ -19,6 +19,7 @@ proto_qmi_init_config() {
proto_config_add_string modes
proto_config_add_string pdptype
proto_config_add_int profile
+   proto_config_add_boolean dhcp
proto_config_add_boolean dhcpv6
proto_config_add_boolean autoconnect
proto_config_add_int plmn
@@ -31,13 +32,13 @@ proto_qmi_setup() {
local interface="$1"
local dataformat connstat
local device apn auth username password pincode delay modes pdptype
-   local profile dhcpv6 autoconnect plmn timeout mtu $PROTO_DEFAULT_OPTIONS
+   local profile dhcp dhcpv6 autoconnect plmn timeout mtu 
$PROTO_DEFAULT_OPTIONS
local ip4table ip6table
local cid_4 pdh_4 cid_6 pdh_6
local ip_6 ip_prefix_length gateway_6 dns1_6 dns2_6
 
json_get_vars device apn auth username password pincode delay modes
-   json_get_vars pdptype profile dhcpv6 autoconnect plmn ip4table
+   json_get_vars pdptype profile dhcp dhcpv6 autoconnect plmn ip4table
json_get_vars ip6table timeout mtu $PROTO_DEFAULT_OPTIONS
 
[ "$timeout" = "" ] && timeout="10"
@@ -353,15 +354,41 @@ proto_qmi_setup() {
}
 
[ -n "$pdh_4" ] && {
-   json_init
-   json_add_string name "${interface}_4"
-   json_add_string ifname "@$interface"
-   json_add_string proto "dhcp"
-   [ -n "$ip4table" ] && json_add_string ip4table "$ip4table"
-   proto_add_dynamic_defaults
-   [ -n "$zone" ] && json_add_string zone "$zone"
-   json_close_object
-   ubus call network add_dynamic "$(json_dump)"
+   if [ "$dhcp" = 0 ]; then
+   json_load "$(uqmi -s -d $device --set-client-id 
wds,$cid_4 --get-current-settings)"
+   json_select ipv4
+   json_get_var ip_4 ip
+   json_get_var gateway_4 gateway
+   json_get_var dns1_4 dns1
+   json_get_var dns2_4 dns2
+   json_get_var subnet_4 subnet
+
+   proto_init_update "$ifname" 1
+   proto_set_keep 1
+   proto_add_ipv4_address "$ip_4" "$subnet_4"
+   proto_add_ipv4_route "$gateway_4" "128"
+   [ "$defaultroute" = 0 ] || proto_add_ipv4_route 
"0.0.0.0" 0 "$gateway_4"
+   [ "$peerdns" = 0 ] || {
+   proto_add_dns_server "$dns1_4"
+   proto_add_dns_server "$dns2_4"
+   }
+   [ -n "$zone" ] && {
+   proto_add_data
+   json_add_string zone "$zone"
+   proto_close_data
+   }
+   proto_send_update "$interface"
+   else
+   json_init
+   json_add_string name "${interface}_4"
+   json_add_string ifname "@$interface"
+   json_add_string proto "dhcp"
+   [ -n "$ip4table" ] && json_add_string ip4table 
"$ip4table"
+   proto_add_dynamic_defaults
+   [ -n "$zone" ] && json_add_string zone "$zone"
+   json_close_object
+   ubus call network add_dynamic "$(json_dump)"
+   fi
}
 }
 
-- 
2.28.0


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


[no subject]

2020-11-17 Thread Paul Oranje via openwrt-devel
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 ---
Op 14 nov. 2020, om 12:14 heeft Jo-Philipp Wich  het volgende 
geschreven:
> 
> Hi,
> 
>> Are there any real blockers left?
> 
> LuCI support for bridge-vlan config is unmerged/unpolished yet.
> 
> I'd rather not ship 20.x without functioning switch config support in
> the ui.
Which platforms still have to make the switch to DSA in master ?

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


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


[no subject]

2020-11-17 Thread Filip Moc via openwrt-devel
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 ---
There already was an option for autoconfiguring IPv4 from QMI but this
was removed by commit 3b9b963e6e08 ("uqmi: always use DHCP for IPv4").

DHCP does not work on MR400 LTE module (in TL-MR6400 v4) so let's readd
support for IPv4 autoconf from QMI but this time allow to configure this
for IPv4 and IPv6 independently and keep DHCP default on IPv4.

Signed-off-by: Filip Moc 
---
 .../utils/uqmi/files/lib/netifd/proto/qmi.sh  | 49 ++-
 1 file changed, 38 insertions(+), 11 deletions(-)

diff --git a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh 
b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
index 8cbe9e97e7..7870eb7382 100755
--- a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
+++ b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
@@ -19,6 +19,7 @@ proto_qmi_init_config() {
proto_config_add_string modes
proto_config_add_string pdptype
proto_config_add_int profile
+   proto_config_add_boolean dhcp
proto_config_add_boolean dhcpv6
proto_config_add_boolean autoconnect
proto_config_add_int plmn
@@ -31,13 +32,13 @@ proto_qmi_setup() {
local interface="$1"
local dataformat connstat
local device apn auth username password pincode delay modes pdptype
-   local profile dhcpv6 autoconnect plmn timeout mtu $PROTO_DEFAULT_OPTIONS
+   local profile dhcp dhcpv6 autoconnect plmn timeout mtu 
$PROTO_DEFAULT_OPTIONS
local ip4table ip6table
local cid_4 pdh_4 cid_6 pdh_6
local ip_6 ip_prefix_length gateway_6 dns1_6 dns2_6
 
json_get_vars device apn auth username password pincode delay modes
-   json_get_vars pdptype profile dhcpv6 autoconnect plmn ip4table
+   json_get_vars pdptype profile dhcp dhcpv6 autoconnect plmn ip4table
json_get_vars ip6table timeout mtu $PROTO_DEFAULT_OPTIONS
 
[ "$timeout" = "" ] && timeout="10"
@@ -353,15 +354,41 @@ proto_qmi_setup() {
}
 
[ -n "$pdh_4" ] && {
-   json_init
-   json_add_string name "${interface}_4"
-   json_add_string ifname "@$interface"
-   json_add_string proto "dhcp"
-   [ -n "$ip4table" ] && json_add_string ip4table "$ip4table"
-   proto_add_dynamic_defaults
-   [ -n "$zone" ] && json_add_string zone "$zone"
-   json_close_object
-   ubus call network add_dynamic "$(json_dump)"
+   if [ "$dhcp" = 0 ]; then
+   json_load "$(uqmi -s -d $device --set-client-id 
wds,$cid_4 --get-current-settings)"
+   json_select ipv4
+   json_get_var ip_4 ip
+   json_get_var gateway_4 gateway
+   json_get_var dns1_4 dns1
+   json_get_var dns2_4 dns2
+   json_get_var subnet_4 subnet
+
+   proto_init_update "$ifname" 1
+   proto_set_keep 1
+   proto_add_ipv4_address "$ip_4" "$subnet_4"
+   proto_add_ipv4_route "$gateway_4" "128"
+   [ "$defaultroute" = 0 ] || proto_add_ipv4_route 
"0.0.0.0" 0 "$gateway_4"
+   [ "$peerdns" = 0 ] || {
+   proto_add_dns_server "$dns1_4"
+   proto_add_dns_server "$dns2_4"
+   }
+   [ -n "$zone" ] && {
+   proto_add_data
+   json_add_string zone "$zone"
+   proto_close_data
+   }
+   proto_send_update "$interface"
+   else
+   json_init
+   json_add_string name "${interface}_4"
+   json_add_string ifname "@$interface"
+   json_add_string proto "dhcp"
+   [ -n "$ip4table" ] && json_add_string ip4table 
"$ip4table"
+   proto_add_dynamic_defaults
+   [ -n "$zone" ] && json_add_string zone "$zone"
+   json_close_object
+   ubus call network add_dynamic "$(json_dump)"
+   fi
}
 }
 
-- 
2.28.0


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