Re: BUG: as of 2967e24d0 "ramips: switch to Linux 6.6' ERX kernel is too big

[Alexandru Ardelean]

On Mon, May 20, 2024 at 4:51 AM Russell Senior
 wrote:
>
> (try#2, damn you gmail)
>
> I mentioned this on IRC and as a github comment on the commit
> (https://github.com/openwrt/openwrt/commit/2967e24d02775f63d9e363e6e0d351716dcc3f7c)
>
> My build started failing on the commit. The message I get from the
> build system is:
>
>   "WARNING: Image file
> /home/openwrt/src/lede/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/ubnt_edgerouter-x-kernel.bin
> is too big: 3165615 > 3145728"
>
> I tried a vanilla config:
>
>   CONFIG_TARGET_ramips=y
>   CONFIG_TARGET_ramips_mt7621=y
>   CONFIG_TARGET_ramips_mt7621_DEVICE_ubnt_edgerouter-x=y
>   CONFIG_DEVEL=y
>   CONFIG_BUILD_LOG=y
>
>   "WARNING: Image file
> /home/openwrt/src/lede/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/ubnt_edgerouter-x-kernel.bin
> is too big: 3165361 > 3145728"
>
> I notice that there are two kernel partitions on the NAND flash, each
> of which is 3MB:
>
> [1.011604] 6 fixed-partitions partitions found on MTD device mt7621-nand
> [1.025136] Creating 6 MTD partitions on "mt7621-nand":
> [1.035552] 0x-0x0008 : "u-boot"
> [1.054525] 0x0008-0x000e : "u-boot-env"
> [1.072180] 0x000e-0x0014 : "factory"
> [1.089606] 0x0014-0x0044 : "kernel1"
> [1.147424] 0x0044-0x0074 : "kernel2"
> [1.204979] 0x0074-0x0ff0 : "ubi"
>
> Which suggests two possible fixes:
>
>  a) cannibalize the second kernel parition (might require a different
> u-boot?); or
>
>  b) use an intermediate u-boot that looks for the kernel in a ubi partition.
>
> or
>
>  c) make the damn kernel smaller.
>
> Thoughts?

d) Start looking into Zephyr as an alternative, until it may get too
bloated (in 10-20-30 years?)

On a similar note, there were these ar71xx tiny images (up until
2018), which (before) were just normal images (on which) OpenWrt would
run on.
i.e. the 4 MB flash, 32 MB RAM configuration (and maybe before that
even 2 MB flash and 16 MB of RAM)
When those (4/32 MB images) were dropped, it seemed (to me at least)
to trigger this notion that Linux (the kernel), got fat.
You can still fit a Linux kernel onto those old images, but it's
(more) like a weight-loss exercise, which doesn't fit most users.
There used to be this joke, that you can run linux on a potato [1]
Oh well  ¯\_(ツ)_/¯

[1] https://www.bbspot.com/News/2008/12/linux-on-a-potato.html
(for your own amusement, there's also these)
   [2] https://www.bbspot.com/News/2001/06/gates.html
   [3] https://www.bbspot.com/News/2000/4/linux_distros.html
   [4] (this might be slightly offensive today, but ¯\_(ツ)_/¯ )
https://www.bbspot.com/News/2000/9/linux_laid.html

>
> --
> Russell Senior
> russ...@personaltelco.net
>
> ___
> 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: hotplug deficiency -- HW network interfaces not generating events

[Alexandru Ardelean]

On Tue, Aug 29, 2023 at 7:42 PM Philip Prindeville
 wrote:
>
> Hi,
>
> I was looking at a way to address 
> https://github.com/openwrt/openwrt/issues/13329 by leveraging hotplug instead 
> (per Gorki's suggestion).
>
> Then it wouldn't matter if the drivers were loaded at preinit time (marked as 
> "required to boot" in netdevices.mk) or not.
>
> But when I went to look into this, I noticed that "ifup" actions are 
> generated for interfaces, but not for the device creation itself.
>
> If I look for devices generating ADD events, I only see dummy, loopback, SQM, 
> XFRM, et. but not actual Ethernet NIC's.  And /sys/class/net/eth0 has a 
> uevent entry.
>
> Why are we not seeing hotplug events for actual network hardware?
>
> Any ideas what's required to have network interfaces generate ADD events?

To my knowledge, this comes from netifd in system-linux.c.
There are a bunch of netlink events handling.
RTM_NEWLINK should be investigated if it works.
If the kernel sends this message type, there should be a hotplug event
(unless some message parsing decides against it).

I've seen a case (many years back) that the linux ethernet driver (for
a Freescale eth driver) wasn't working properly, and there were no
netlink events.
Luckily, this was fixed by a kernel update.

I'm not sure if this can also be a case of netifd starting too late
(in the boot process) to be able to trigger hotplug events.
i.e. the interface is up, and then no events are set?

But, that (netifd/system-linux.c) is where I would start an
investigation to see if the hotplug events are working for network
devices/interfaces.

>
> Thanks,
>
> -Philip
>
>
> ___
> 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: [RFC] dropping of $(AUTORELEASE) feature

[Alexandru Ardelean]

On Mon, Nov 7, 2022 at 10:29 AM Jo-Philipp Wich  wrote:
>
> Hi,
>
> > The AUTORELEASE has been a nice feature from the package PR maintenance
> > perspective.
> >
> > Earlier there was constant trouble with concurrent PRs for the same package
> > having the same PKG_RELEASE bump, or the maintainer doing a small change 
> > with
> > a bump while there was an open PR with the same bump. The led to trivial
> > conflicts and rebase needs for PRs. AUTORELEASE has tackled that nicely.
>
> it tackled it by sweeping the problem under the carpet and hiding the fact
> that those concurrent PRs were indeed conflicting. If the version targeted by
> a PR has been changed in the meanwhile it should not be made trivially
> mergable by hiding the actual revision from the sources.
>
> I agree that this increases maintenance burden but I believe that a CI side
> solution for those conflicting-because-of-deviating-PKG_RELEASE situations
> would be the better course of action.
>

So, is there a proposal/conclusion on how to proceed?
Or do we need/wait for a further discussion?
I'm fine either way, and whatever is decided, I will implement it.

I have a bunch of packages that I've been maintaining and been slowly
switching to the AUTORELEASE feature.
And I need to start doing some updates (for some packages that have
new releases).
And would like (if possible) to know what to do.

I will not add AUTORELEASE (if any packages have the case).
But, it will be a slow transition back to manual PKG_RELEASE.
I mean, I would do it in a not-very-fast-manner.
There's 469 packages using AUTORELEASE in the packages repo.
And 70 in openwrt core. Core has a different speed/rythm.

But for the packages feed, I think, in the course of 2-4 weeks and a
few PRs, we should be able to remove it (if needed).

> ~ Jo
>
> ___
> 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: [RFC] dropping of $(AUTORELEASE) feature

[Alexandru Ardelean]

On Mon, Nov 7, 2022 at 9:41 AM Josef Schlehofer
 wrote:
>
>
> On 06. 11. 22 21:22, Hannu Nyman wrote:
> > Paul Spooren kirjoitti 6.11.2022 klo 18.15:
> >> While I initially thought that $(AUTORELEASE) would be a nice feature
> >> to avoid the standard review comment “Please bump the PKG_RELEASE”,
> >> it turned into a massive increase of bandwidth usage: Every checkout
> >> of openwrt.git and package feeds needs to be a full clone instead of
> >> a shallow one to have all commits in place.
> >>
> >> I’m suggesting dropping that feature and instead implement a (GitHub)
> >> CI workflow which fails if the commit did not bump the PKG_RELEASE.
> >>
> >> It wasn’t a fully thought through idea and I think it’s time to
> >> revert it - sorry for the inconvenience.
> >>
> >> Other thoughts?
> >
> >
> > The AUTORELEASE has been a nice feature from the package PR
> > maintenance perspective.
> >
> > Earlier there was constant trouble with concurrent PRs for the same
> > package having the same PKG_RELEASE bump, or the maintainer doing a
> > small change with a bump while there was an open PR with the same
> > bump. The led to trivial conflicts and rebase needs for PRs.
> > AUTORELEASE has tackled that nicely.
> +1
>

Awww.
I liked the idea of AUTORELEASE.
I'll admit I was a bit hesitant about the git black-magic underneath,
but as long as I did not have to manage it, I was fine with it.

We can try to find some other way (that git history) to manage AUTORELEASE
I'm also fine to drop it, if it simplifies other things.

> ___
> 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: tcpdump looks broken

[Alexandru Ardelean]

On Fri, Sep 2, 2022 at 5:35 PM e9hack  wrote:
>
> Hi,
>
> it looks like, that tcpdump (mini) is broken. It is used by adblock to 
> generate reports.
>
> tcpdump -nn -p -s0 -i any port 53
>
> version 4.99.1
> 16:11:26.070312 UNSUPPORTED
> 0x:  0800   0020 0001 0306 f8e4 e37c  ...|

Looks like some VLAN 0 in-there?
Maybe tcpdump (mini) doesn't know VLANs?

> 0x0010:  4db3  4500 0047 8910  8011 6241  M...E..G..bA
> 0x0020:  c0a8 0102 c0a8 0101 d6f9 0035 0033 f8cf  ...5.3..
> 0x0030:  0002 0100 0001    0377   .www
> 0x0040:  0568 6569 7365 0264 6508     .heise.de.xx
> 0x0050:   036c 616e  0100 01  xx.lan.
>
> version 4.9.3
> 16:11:47.879165 IP 192.168.1.2.57308 > 192.168.1.1.53: 2+ A? 
> www.heise.de..lan. (43)
>
> Adblock doesn't generate reports anymore.
>
> Regards,
> Hartmut
>
> ___
> 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: libubox: How to terminate uloop orderly?

[Alexandru Ardelean]

On Tue, May 17, 2022 at 12:06 PM Koch, Alexander via openwrt-devel
 wrote:
>
> 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.
>
>
> -- Forwarded message --
> From: "Koch, Alexander" 
> To: "openwrt-devel@lists.openwrt.org" 
> Cc:
> Bcc:
> Date: Tue, 17 May 2022 09:04:13 +
> Subject: libubox: How to terminate uloop orderly?
> Hi openwrt-devel,
>
> I'm writing a small daemon in C that talks to a specific IC and shall offer 
> its
> functionality to other OpenWRT components via ubus.
>
> It spawns a separate pthread for all ubus related things, which ends up 
> calling
> `uloop_run()`. So far everything works fine and I can see all objects exposed 
> by
> my daemon on the bus.
>
> The issue I'm facing now is that I cannot seem to find a way of orderly 
> shutting
> down the daemon, as the thread calling `uloop_run()` never returns from it. 
> I've
> tried calling `uloop_end()` as well as replacing `uloop_run()` by
> `uloop_run_timeout(10)` but that didn't help.

I never thought/knew that uloop_run() & threads mixed well.
I never tried it too much either.

I always thought of uloop_run() being the main process loop and then
"maybe" starting some threads from there.
And I think uloop is kind of designed to be more single-process than
multi-process.

So, if you have one uloop somewhere and try to do some uloop calls in
a thread, it's kind of race-y and potentially buggy.
Also because they work on the same main loop data.

>
> So I'm wondering: what is the correct way to terminate the uloop?
>
> One thing that does seem to work is sending the thread a SIGTERM via
> `pthread_kill()`. But that makes `uloop_run()` return a non-zero value (15) 
> and,
> as signals are delivered to the entire process, can have side-effects on other
> parts of the daemon, so I'd prefer to avoid this method.
>
>
> Thanks in advance for any hints!
>
>
> Best regards,
>
> Alex
>
> ___
> 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

[firmware-utils][PATCH 2/2] build, cmake: switch OPENSSL_CRYPTO_LIBRARY -> OPENSSL_CRYPTO_LIBRARIES

[Alexandru Ardelean]

OPENSSL_CRYPTO_LIBRARY returns just the full path to libcrypto.a
OPENSSL_CRYPTO_LIBRARIES returns also any other libraries required to fully
link an executable with libcrypto.a. This can be -lpthread, or -ldl, or
something else.

The FindOpenSSL.cmake module does a good job of identifying these dependent
libs, but the OPENSSL_CRYPTO_LIBRARIES variable must be used (same as using
ZLIB_LIBRARIES).

Signed-off-by: Alexandru Ardelean 
---
 CMakeLists.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 3e206a2..f406520 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -62,7 +62,7 @@ FW_UTIL(mkedimaximg "" "" "")
 FW_UTIL(mkfwimage "" "-Wextra -D_FILE_OFFSET_BITS=64" "${ZLIB_LIBRARIES}")
 FW_UTIL(mkfwimage2 "" "" "${ZLIB_LIBRARIES}")
 FW_UTIL(mkheader_gemtek "" "" "${ZLIB_LIBRARIES}")
-FW_UTIL(mkhilinkfw "" "" "${OPENSSL_CRYPTO_LIBRARY}")
+FW_UTIL(mkhilinkfw "" "" "${OPENSSL_CRYPTO_LIBRARIES}")
 FW_UTIL(mkmerakifw src/sha1.c "" "")
 FW_UTIL(mkmerakifw-old "" "" "")
 FW_UTIL(mkmylofw "" "" "")
-- 
2.31.1


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

[firmware-utils][PATCH 1/2] build, cmake: add quotes for FW_UTIL variable arguments

[Alexandru Ardelean]

CMake macro arguments are special, so when passing ${ZLIB_LIBRARIES} as
an argument, this can actually be a list of strings.
In this case, the first library (for zlib) will be added to
TARGET_LINK_LIBRARIES() and the others will be discarded. This is likely
due to some expansion from the FW_UTIL macro.

So, if FindZLIB returns more libraries for linking, they will not be
considered.

This is the case when trying to change OPENSSL_CRYPTO_LIBRARY ->
OPENSSL_CRYPTO_LIBRARIES.
OPENSSL_CRYPTO_LIBRARY is just libcrypto.a
OPENSSL_CRYPTO_LIBRARIES can also include -ldl

There's a few points made here about macros:
  https://cmake.org/cmake/help/latest/command/macro.html#argument-caveats

Signed-off-by: Alexandru Ardelean 
---
 CMakeLists.txt | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 556ec72..3e206a2 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -18,10 +18,10 @@ ADD_DEFINITIONS(-Wall -Wno-unused-parameter)
 MACRO(FW_UTIL util deps extra_cflags libs)
   ADD_EXECUTABLE(${util} src/${util}.c ${deps})
   INSTALL(TARGETS ${util} RUNTIME)
-  IF(NOT ${ARGV2} STREQUAL "")
+  IF(NOT "${extra_cflags}" STREQUAL "")
 SET_TARGET_PROPERTIES(${util} PROPERTIES COMPILE_FLAGS ${extra_cflags})
   ENDIF()
-  IF(NOT ${ARGV3} STREQUAL "")
+  IF(NOT "${libs}" STREQUAL "")
 TARGET_LINK_LIBRARIES(${util} ${libs})
   ENDIF()
 ENDMACRO(FW_UTIL)
@@ -42,9 +42,9 @@ FW_UTIL(encode_crc "" "" "")
 FW_UTIL(fix-u-media-header src/cyg_crc32.c "" "")
 FW_UTIL(hcsmakeimage src/bcmalgo.c "" "")
 FW_UTIL(imagetag "src/imagetag_cmdline.c;src/cyg_crc32.c" "" "")
-FW_UTIL(jcgimage "" "" ${ZLIB_LIBRARIES})
+FW_UTIL(jcgimage "" "" "${ZLIB_LIBRARIES}")
 FW_UTIL(lxlfw "" "" "")
-FW_UTIL(lzma2eva "" "" ${ZLIB_LIBRARIES})
+FW_UTIL(lzma2eva "" "" "${ZLIB_LIBRARIES}")
 FW_UTIL(makeamitbin "" "" "")
 FW_UTIL(mkbrncmdline "" "" "")
 FW_UTIL(mkbrnimg "" "" "")
@@ -56,20 +56,20 @@ FW_UTIL(mkcsysimg "" "" "")
 FW_UTIL(mkdapimg "" "" "")
 FW_UTIL(mkdapimg2 "" "" "")
 FW_UTIL(mkdhpimg src/buffalo-lib.c "" "")
-FW_UTIL(mkdlinkfw src/mkdlinkfw-lib.c --std=c99 ${ZLIB_LIBRARIES})
+FW_UTIL(mkdlinkfw src/mkdlinkfw-lib.c --std=c99 "${ZLIB_LIBRARIES}")
 FW_UTIL(mkdniimg "" "" "")
 FW_UTIL(mkedimaximg "" "" "")
-FW_UTIL(mkfwimage "" "-Wextra -D_FILE_OFFSET_BITS=64" ${ZLIB_LIBRARIES})
-FW_UTIL(mkfwimage2 "" "" ${ZLIB_LIBRARIES})
-FW_UTIL(mkheader_gemtek "" "" ${ZLIB_LIBRARIES})
-FW_UTIL(mkhilinkfw "" "" ${OPENSSL_CRYPTO_LIBRARY})
+FW_UTIL(mkfwimage "" "-Wextra -D_FILE_OFFSET_BITS=64" "${ZLIB_LIBRARIES}")
+FW_UTIL(mkfwimage2 "" "" "${ZLIB_LIBRARIES}")
+FW_UTIL(mkheader_gemtek "" "" "${ZLIB_LIBRARIES}")
+FW_UTIL(mkhilinkfw "" "" "${OPENSSL_CRYPTO_LIBRARY}")
 FW_UTIL(mkmerakifw src/sha1.c "" "")
 FW_UTIL(mkmerakifw-old "" "" "")
 FW_UTIL(mkmylofw "" "" "")
 FW_UTIL(mkplanexfw src/sha1.c "" "")
 FW_UTIL(mkporayfw "" "" "")
 FW_UTIL(mkrasimage "" --std=gnu99 "")
-FW_UTIL(mkrtn56uimg "" "" ${ZLIB_LIBRARIES})
+FW_UTIL(mkrtn56uimg "" "" "${ZLIB_LIBRARIES}")
 FW_UTIL(mksenaofw src/md5.c --std=gnu99 "")
 FW_UTIL(mksercommfw "" "" "")
 FW_UTIL(mktitanimg "" "" "")
@@ -96,8 +96,8 @@ FW_UTIL(tplink-safeloader src/md5.c --std=gnu99 "")
 FW_UTIL(trx "" "" "")
 FW_UTIL(trx2edips "" "" "")
 FW_UTIL(trx2usr "" "" "")
-FW_UTIL(uimage_padhdr "" "" ${ZLIB_LIBRARIES})
-FW_UTIL(uimage_sgehdr "" "" ${ZLIB_LIBRARIES})
+FW_UTIL(uimage_padhdr "" "" "${ZLIB_LIBRARIES}")
+FW_UTIL(uimage_sgehdr "" "" "${ZLIB_LIBRARIES}")
 FW_UTIL(wrt400n src/cyg_crc32.c "" "")
 FW_UTIL(xiaomifw "" "" "")
 FW_UTIL(xorimage "" "" "")
-- 
2.31.1


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

Re: Integration of DPDK with OpenWRT

[Alexandru Ardelean]

On Tue, Mar 16, 2021 at 11:03 AM Supriya Shekhar Mane
 wrote:
>
> Hi Maintainers,
>
> We are working on DPDK with the OpenWRT build system. As of now
> OpenWRT doesn't have DPDK support enabled. Kindly let us know the
> procedure to integrate DPDK to OpenWRT master branch.
>

Hey,

Please take a look at this:
https://github.com/commodo/packages/tree/dpdk/net/dpdk

It was done a few years ago, but I have not tested it fully.
And it requires some polish.
I did not want to maintain DPDK [nor do I want to maintain it now].
I did maintain OVS for some time, and that proved to be a hassle after
a while, especially because I was no longer using it.


> Regards,
> Supriya Mane
>
> --
> Disclaimer:This message is intended only for the designated recipient(s).
> It may contain confidential or proprietary information and may be subject
> to other confidentiality protections. If you are not a designated
> recipient, you may not review, copy or distribute this message. Please
> notify the sender by e-mail and delete this message. GlobalEdge does not
> accept any liability for virus infected mails.
>
>
> ___
> 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: OpenWrt / master build failure with Python 3.9

[Alexandru Ardelean]

On Mon, Mar 8, 2021 at 2:17 PM Moritz Warning  wrote:
>
> Hi,
>
> OpenWrt master does not build for me, because the isntalled Python version is 
> too new (/usr/bin/python3.9 exists).
> OpenWrt create link to /usr/bin/python3.7, but that does not exist. See error 
> message down below.
>
> $ ls -al /home/mwarning/openwrt/staging_dir/host/bin/python
> lrwxrwxrwx 1 mwarning mwarning 18 Mar  8 08:56 
> /home/mwarning/openwrt/staging_dir/host/bin/python -> /usr/bin/python3.7
>
> $ ls /usr/bin/python3.7
> ls: cannot access '/usr/bin/python3.7': No such file or directory
>
> $ python --version
> Python 3.9.2

This looks like you upgraded your system [just recently], but did not
do a "make dirclean" in your OpenWrt tree.
Maybe start from a clean checkout?

>
> $ make
> [..]
> mkdir -p 
> /home/mwarning/openwrt/staging_dir/target-arc_arc700_glibc/root-arc770/stamp
> SHELL= flock /home/mwarning/openwrt/tmp/.root-copy.flock -c 'cp -fpR 
> /home/mwarning/openwrt/build_dir/target-arc_arc700_glibc/openwrt-keyring-2021-02-20-49283916/.pkgdir/openwrt-keyring/.
>  /home/mwarning/openwrt/staging_dir/target-arc_arc700_glibc/root-arc770/'
> touch 
> /home/mwarning/openwrt/staging_dir/target-arc_arc700_glibc/root-arc770/stamp/.openwrt-keyring_installed
> echo "openwrt-keyring" >> 
> /home/mwarning/openwrt/staging_dir/target-arc_arc700_glibc/pkginfo/openwrt-keyring.default.install
> make[3]: Leaving directory 
> '/home/mwarning/openwrt/package/system/openwrt-keyring'
> time: package/system/openwrt-keyring/compile#0.12#0.10#0.21
> make[3]: Entering directory '/home/mwarning/openwrt/package/system/usign'
> mkdir -p /home/mwarning/openwrt/dl
> SHELL= flock 
> /home/mwarning/openwrt/tmp/.usign-2020-05-23-f1f65026.tar.xz.flock -c '
> /home/mwarning/openwrt/scripts/download.pl "/home/mwarning/openwrt/dl" 
> "usign-2020-05-23-f1f65026.tar.xz" 
> "3f6569a5e63fdfd032976ac0f79d736d3935101ac1b97fb370514b013c5e6bb6" "" || (
> echo "Checking out files from the git repository..."; mkdir -p 
> /home/mwarning/openwrt/tmp/dl && cd /home/mwarning/openwrt/tmp/dl && rm -rf 
> usign-2020-05-23-f1f65026 && [ \! -d usign-2020-05-23-f1f65026 ] && git clone 
>  https://git.openwrt.org/project/usign.git usign-2020-05-23-f1f65026 && (cd 
> usign-2020-05-23-f1f65026 && git checkout 
> f1f65026a94137c91b5466b149ef3ea3f20091e9 && git submodule update --init 
> --recursive) && echo "Packing checkout..." && export TAR_TIMESTAMP=`cd 
> usign-2020-05-23-f1f65026 && git log -1 --format='\''@%ct'\''` && rm -rf 
> usign-2020-05-23-f1f65026/.git &&tar --numeric-owner --owner=0 
> --group=0 --mode=a-s --sort=name ${TAR_TIMESTAMP:+--mtime="$TAR_TIMESTAMP"} 
> -c usign-2020-05-23-f1f65026 |xz -zc -7e > 
> /home/mwarning/openwrt/tmp/dl/usign-2020-05-23-f1f65026.tar.xz && mv 
> /home/mwarning/openwrt/tmp/dl/usign-2020-05-23-f1f65026.tar.xz 
> /home/mwarning/openwrt/dl/ && rm -rf usign-2020-05-23-f1f65026;  )'
> mkdir -p 
> /home/mwarning/openwrt/staging_dir/target-arc_arc700_glibc/root-arc770/stamp
> SHELL= flock /home/mwarning/openwrt/tmp/.root-copy.flock -c 'cp -fpR 
> /home/mwarning/openwrt/build_dir/target-arc_arc700_glibc/usign-2020-05-23-f1f65026/.pkgdir/usign/.
>  /home/mwarning/openwrt/staging_dir/target-arc_arc700_glibc/root-arc770/'
> touch 
> /home/mwarning/openwrt/staging_dir/target-arc_arc700_glibc/root-arc770/stamp/.usign_installed
> echo "usign" >> 
> /home/mwarning/openwrt/staging_dir/target-arc_arc700_glibc/pkginfo/usign.default.install
> make[3]: Leaving directory '/home/mwarning/openwrt/package/system/usign'
> time: package/system/usign/compile#0.16#0.11#0.24
> make[3]: Entering directory '/home/mwarning/openwrt/package/base-files'
> mkdir -p 
> /home/mwarning/openwrt/staging_dir/target-arc_arc700_glibc/root-arc770/stamp
> SHELL= flock /home/mwarning/openwrt/tmp/.root-copy.flock -c 'cp -fpR 
> /home/mwarning/openwrt/build_dir/target-arc_arc700_glibc/linux-arc770_generic/base-files/.pkgdir/base-files/.
>  /home/mwarning/openwrt/staging_dir/target-arc_arc700_glibc/root-arc770/'
> touch 
> /home/mwarning/openwrt/staging_dir/target-arc_arc700_glibc/root-arc770/stamp/.base-files_installed
> echo "base-files" >> 
> /home/mwarning/openwrt/staging_dir/target-arc_arc700_glibc/pkginfo/base-files.default.install
> make[3]: Leaving directory '/home/mwarning/openwrt/package/base-files'
> time: package/base-files/compile#0.68#0.14#0.89
> make[3]: Entering directory 
> '/home/mwarning/openwrt/package/firmware/wireless-regdb'
> mkdir -p /home/mwarning/openwrt/dl
> SHELL= flock 
> /home/mwarning/openwrt/tmp/.wireless-regdb-2020.11.20.tar.xz.flock -c '
> /home/mwarning/openwrt/scripts/download.pl "/home/mwarning/openwrt/dl" 
> "wireless-regdb-2020.11.20.tar.xz" 
> "b4164490d82ff7b0086e812ac42ab27baf57be24324d4c0ee1c5dd6ba27f2a52" "" 
> "@KERNEL/software/network/wireless-regdb/"'
> rm -f 
> /home/mwarning/openwrt/build_dir/target-arc_arc700_glibc/wireless-regdb-2020.11.20/.built
> touch 
> 

Re: Build openwrt with clang

[Alexandru Ardelean]

On Sat, Mar 6, 2021 at 10:17 AM Michael Fuckner  wrote:
>
> Hi,
>
> I'm not exactly sure if this is trivial or totally insane- I have the idea to 
> compile the whole openwrt with clang instead of gcc. I could not get a point 
> to start at. Can you help me?
>

It isn't trivial.
And "insane" depends on who you ask.
But it is some amount of work.

I'm not sure where you want to take this.
To build OpenWrt you need a host gcc/clang that will build the tools
that will build the final image.

So,
1. host-cc   builds gcc, binutils, patch, other tools
here; some people have managed to use Clang [even Apple Clang] to build
Usually this works easy when clang is symlinked to gcc ; I don't
know about any clear hints on this
On MacOS, gcc usually points to Apple Clang
But if you search in rules.mk for HOSTCC and HOSTCXX, you can edit those.
Not sure how that works
2. the gcc built in step 1, builds the final image

I'm thinking you want to do 2.

The quickest way to do this, is to try to setup an external toolchain.
1. make menuconfig
2. select  ['*] Advanced configuration options (for developers)  --->'
 and enter menu
3. select '[*]   Use external toolchain  --->'  and enter menu
4. configure all the paths are toolchain prefixes

But you do need to configure a clang compiler specific for the target
you are building for.

I don't know how well this works. Never tried it.

The other method would be to fully-integrate clang along-side gcc.
Which means, a lot of editing in this folder to make sure that you can
hook up clang [in a similar fashion as gcc]:
https://github.com/openwrt/openwrt/tree/master/toolchain

Reading around the comments/code, this may help as a grand view:
https://github.com/openwrt/openwrt/blob/master/toolchain/Makefile#L9

This would be interesting.
It sounds like a fun project to do; but it requires some time/effort.

> Any hints?
>
> Regards,
>  Michael!
>
> ___
> 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: [OpenWrt-Devel] building python3 packages outside of lang/python3

[Alexandru Ardelean]

On Fri, May 1, 2020 at 7:04 PM Michael Richardson  wrote:
>
> hi,
> python packages include ../python3-package.mk, and pypi.mk
>
> But I can't do that from my own feed directory.
> I don't want to copy the file!!
>
> Is there a relative path that would get me to feeds/packages/lang/python3?

long-story-short: no

you'll have to settle for some sort of absolute path if you need those
files from the packages feed in some other feed
if you take a look at
https://github.com/openwrt/packages/blob/master/lang/python/README.md
there's a suggestion:
PYTHON3_PACKAGE_MK:=$(wildcard $(TOPDIR)/feeds/*/lang/python/python3-package.mk)
[ similar can be done for pypi.mk ]

reason for the wildcard, is in case the "packages" feed is not named
literally 'packages', it picks up the first feed where that mk file is
found;
if there's only one, all is fine; if there's more than one, then
[anyone doing this] it's asking for trouble anyway;

now, i've thought [and maybe Jeffery as well] about maybe doing a
helper that makes a short-hand to the python3-package.mk path somehow
[into the 'packages' feed], but there isn't a good reason to do it;
you still need to know exactly in which feed the 'python3-package.mk'
is found; and that helper needs to be done in OpenWrt core; and core
always needs good reasons to be modified;
so, some people do 'include
$(TOPDIR)/feeds/packages/lang/python/python3-package.mk' directly;
[1]

maybe if [one day] these 2 files move into OpenWrt core, things will
be a bit simpler; but I don't think it's very soon, and I don't feel
it's a big problem [anyway], but that's my opinion;

> I tried the whole thing, but that didn't work.
>
> I settled on:
> include $(INCLUDE_DIR)/../feeds/packages/lang/python/python3-package.mk
>
> which I found ugly, but it worked.

yes & no;
you can choose to do a direct include like [1]

>
> --
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works|IoT architect   [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [
>
>
> ___
> 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: [OpenWrt-Devel] Open vSwitch integration with netifd

[Alexandru Ardelean]

Hey,

The idea isn't really new, and it's been done before, but did not make
it upstream.
See here:
https://openwrt-devel.openwrt.narkive.com/iX384VOa/rfc-rft-netifd-initial-openvswitch-support

Essentially, the OVS integration is a clone of netifd's bridge integration.
The implementation has some popen() calls to OVS utils, because that
was easier to do really quick.
Ideally, you would use libovs to talk to the OVS daemon that doing
popen(), which [I suspect] was one reason for the patch to not be
acceptable.

There was a discussion [internally] about whether OVS would be better
suited as netifd proto-handler vs as a system-ovs.c file.
Proto-handlers can be done in shell completely and are fine to call
other processes.
Also, proto-handlers can be installed when the OVS package gets
installed, so the proto-handler files would sit here:
https://github.com/openwrt/packages/tree/master/net/openvswitch/files
I don't remember a conclusion about it, or whether that could be done
[as a proto-handler].
I think the system-ovs.c approach was chosen to better integrate with
netifd's event handler for bridges [or similar to bridges].
I don't think we dug too deep to compare the 2 approaches.
But I guess the implementation [as done in that patch] should still
work to some degree.
I don't remember what bugs were fixed with it [or which bugs].
Since it wasn't upstreamed, everything was done in an internal repo.

Funny story. Patch [1] was created to accommodate the size reduction for OVS.
[1] https://mail.openvswitch.org/pipermail/ovs-dev/2013-December/278590.html
Before that patch, OVS would link statically libovs into all it's utils.

Not sure how much this helps you.
The current maintainer of the OVS package may have more [recent] ideas/thoughts.

Some personal conclusions:
Depending on what you want to do with OVS, OVS can be useful or not.
We used it more like a replacement for kernel bridges [because in
theory OVS would scale better],
and since we used netifd + uci to configure it, it sometimes made
things more complicated.
The reason is: OVS has it's own control/controller logic; and we never
used it back then.

We wanted to use it implement L2 switches; some things were done via
OVS, STP/RSTP via mstpd, LLDP via lldpd.
And for that, OVS [being used mostly as a replacement for Linux
bridges] took quite a bit more RAM than I would have liked.
100+ bridges would fill up 128 MB or RAM [for example];
But, at the time, it did fit into 8 MB of flash [some basic OpenWrt +
some userland + OVS]. You may need more now.

On Tue, Mar 3, 2020 at 5:12 PM Kevin Mahoney  wrote:
>
> I am exploring the idea of extending netifd to support Open vSwitch. I'm 
> curious if anyone has thought of doing this, or has looked into what all it 
> would take to do so. From my limited research, it seems that only a new 
> system-.c would need to be added to netifd while keeping the rest of the 
> logic the same. Please share your thoughts.
>
> Regards,
>
> Kevin Mahoney
>
> ZenoTec LLC
> 720-864-4320
> kevin.maho...@zenotec.net
> www.zenotec.net
>
> This e-mail and any attachments are intended solely for the use of the 
> intended recipient(s) and may contain legally privileged, proprietary and/or 
> confidential information. Any use, disclosure, dissemination, distribution or 
> copying of this e-mail and any attachments for any purposes that have not 
> been specifically authorized by the sender is strictly prohibited. If you are 
> not the intended recipient, please immediately notify the sender by reply 
> e-mail and permanently delete all copies and attachments.
> ___
> 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: [OpenWrt-Devel] [PATCH 3/4] build: Add KCOV kernel code coverage for fuzzing

[Alexandru Ardelean]

On Wed, Feb 12, 2020 at 12:50 PM Hauke Mehrtens
 wrote:
>
> The adds an option to activate KCOV (Code coverage for fuzzing).
>

Reviewed-by: Alexandru Ardelean 

> Signed-off-by: Hauke Mehrtens 
> ---
>  config/Config-kernel.in | 33 +
>  1 file changed, 33 insertions(+)
>
> diff --git a/config/Config-kernel.in b/config/Config-kernel.in
> index 3059a45f48..8e9e3518bf 100644
> --- a/config/Config-kernel.in
> +++ b/config/Config-kernel.in
> @@ -172,6 +172,39 @@ config KERNEL_KASAN_INLINE
>
>  endchoice
>
> +config KERNEL_KCOV
> +   bool "Compile the kernel with code coverage for fuzzing"
> +   select KERNEL_DEBUG_FS
> +   help
> + KCOV exposes kernel code coverage information in a form suitable
> + for coverage-guided fuzzing (randomized testing).
> +
> + If RANDOMIZE_BASE is enabled, PC values will not be stable across
> + different machines and across reboots. If you need stable PC values,
> + disable RANDOMIZE_BASE.
> +
> + For more details, see Documentation/kcov.txt.
> +
> +config KERNEL_KCOV_ENABLE_COMPARISONS
> +   bool "Enable comparison operands collection by KCOV"
> +   depends on KERNEL_KCOV
> +   help
> + KCOV also exposes operands of every comparison in the instrumented
> + code along with operand sizes and PCs of the comparison 
> instructions.
> + These operands can be used by fuzzing engines to improve the quality
> + of fuzzing coverage.
> +
> +config KERNEL_KCOV_INSTRUMENT_ALL
> +   bool "Instrument all code by default"
> +   depends on KERNEL_KCOV
> +   default y if KERNEL_KCOV
> +   help
> + If you are doing generic system call fuzzing (like e.g. syzkaller),
> + then you will want to instrument the whole kernel and you should
> + say y here. If you are doing more targeted fuzzing (like e.g.
> + filesystem fuzzing with AFL) then you will want to enable coverage
> + for more specific subsets of files, and should say n here.
> +
>  config KERNEL_TASKSTATS
> bool "Compile the kernel with task resource/io statistics and 
> accounting"
> default n
> --
> 2.17.1
>
>
> ___
> 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: [OpenWrt-Devel] [PATCH 1/4] build: Add option KERNEL_UBSAN

[Alexandru Ardelean]

On Wed, Feb 12, 2020 at 12:49 PM Hauke Mehrtens
 wrote:
>
> The kernel Undefined Behavior Sanitizer is able to detect some memory
> bugs in the kernel like out of range array accesses.
>

Did some basic testing for the series to see that the symbol gets
enabled in the final .config of the kernel.
Both 4.14 & 4.19 on x86_64

Reviewed-by: Alexandru Ardelean 

> Signed-off-by: Hauke Mehrtens 
> ---
>  config/Config-kernel.in  | 35 
>  target/linux/generic/config-4.14 |  4 
>  target/linux/generic/config-4.19 |  3 +++
>  3 files changed, 42 insertions(+)
>
> diff --git a/config/Config-kernel.in b/config/Config-kernel.in
> index 20930326ca..bf1c1055f1 100644
> --- a/config/Config-kernel.in
> +++ b/config/Config-kernel.in
> @@ -85,6 +85,41 @@ config KERNEL_PROFILING
>   Enable the extended profiling support mechanisms used by profilers 
> such
>   as OProfile.
>
> +config KERNEL_UBSAN
> +   bool "Compile the kernel with undefined behaviour sanity checker"
> +   help
> + This option enables undefined behaviour sanity checker
> + Compile-time instrumentation is used to detect various undefined
> + behaviours in runtime. Various types of checks may be enabled
> + via boot parameter ubsan_handle
> + (see: Documentation/dev-tools/ubsan.rst).
> +
> +config KERNEL_UBSAN_SANITIZE_ALL
> +   bool "Enable instrumentation for the entire kernel"
> +   depends on KERNEL_UBSAN
> +   default y
> +   help
> + This option activates instrumentation for the entire kernel.
> + If you don't enable this option, you have to explicitly specify
> + UBSAN_SANITIZE := y for the files/directories you want to check for 
> UB.
> + Enabling this option will get kernel image size increased
> + significantly.
> +
> +config KERNEL_UBSAN_ALIGNMENT
> +   bool "Enable checking of pointers alignment"
> +   depends on KERNEL_UBSAN
> +   help
> + This option enables detection of unaligned memory accesses.
> + Enabling this option on architectures that support unaligned
> + accesses may produce a lot of false positives.
> +
> +config KERNEL_UBSAN_NULL
> +   bool "Enable checking of null pointers"
> +   depends on KERNEL_UBSAN
> +   help
> + This option enables detection of memory accesses via a
> + null pointer.
> +
>  config KERNEL_TASKSTATS
> bool "Compile the kernel with task resource/io statistics and 
> accounting"
> default n
> diff --git a/target/linux/generic/config-4.14 
> b/target/linux/generic/config-4.14
> index 9681d9c278..73b0d77155 100644
> --- a/target/linux/generic/config-4.14
> +++ b/target/linux/generic/config-4.14
> @@ -1516,6 +1516,10 @@ CONFIG_GACT_PROB=y
>  # CONFIG_GAMEPORT is not set
>  # CONFIG_GATEWORKS_GW16083 is not set
>  # CONFIG_GCC_PLUGINS is not set
> +# CONFIG_GCC_PLUGIN_CYC_COMPLEXITY is not set
> +# CONFIG_GCC_PLUGIN_LATENT_ENTROPY is not set
> +# CONFIG_GCC_PLUGIN_RANDSTRUCT is not set
> +# CONFIG_GCC_PLUGIN_STRUCTLEAK is not set
>  # CONFIG_GCOV is not set
>  # CONFIG_GCOV_KERNEL is not set
>  # CONFIG_GDB_SCRIPTS is not set
> diff --git a/target/linux/generic/config-4.19 
> b/target/linux/generic/config-4.19
> index d8ea243fc7..aba7bccaf6 100644
> --- a/target/linux/generic/config-4.19
> +++ b/target/linux/generic/config-4.19
> @@ -1605,6 +1605,8 @@ CONFIG_GACT_PROB=y
>  # CONFIG_GAMEPORT is not set
>  # CONFIG_GATEWORKS_GW16083 is not set
>  # CONFIG_GCC_PLUGINS is not set
> +# CONFIG_GCC_PLUGIN_CYC_COMPLEXITY is not set
> +# CONFIG_GCC_PLUGIN_LATENT_ENTROPY is not set
>  # CONFIG_GCOV is not set
>  # CONFIG_GCOV_KERNEL is not set
>  # CONFIG_GDB_SCRIPTS is not set
> @@ -5197,6 +5199,7 @@ CONFIG_TCP_CONG_CUBIC=y
>  # CONFIG_TEST_STATIC_KEYS is not set
>  # CONFIG_TEST_STRING_HELPERS is not set
>  # CONFIG_TEST_SYSCTL is not set
> +# CONFIG_TEST_UBSAN is not set
>  # CONFIG_TEST_UDELAY is not set
>  # CONFIG_TEST_USER_COPY is not set
>  # CONFIG_TEST_UUID is not set
> --
> 2.17.1
>
>
> ___
> 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: [OpenWrt-Devel] [PATCH 4/4] build: Add additional kernel debug options

[Alexandru Ardelean]

On Wed, Feb 12, 2020 at 12:50 PM Hauke Mehrtens
 wrote:
>
> Make it possible to activate some additional kernel debug options.
> This can be used to debug some problems in kernel drivers.
>

Reviewed-by: Alexandru Ardelean 

> Signed-off-by: Hauke Mehrtens 
> ---
>  config/Config-kernel.in  | 68 
>  target/linux/generic/config-4.14 |  5 +++
>  target/linux/generic/config-4.19 |  5 +++
>  3 files changed, 78 insertions(+)
>
> diff --git a/config/Config-kernel.in b/config/Config-kernel.in
> index 8e9e3518bf..4330d9fa5c 100644
> --- a/config/Config-kernel.in
> +++ b/config/Config-kernel.in
> @@ -377,6 +377,74 @@ config KERNEL_PROVE_LOCKING
> select KERNEL_DEBUG_KERNEL
> default n
>
> +config KERNEL_LOCKUP_DETECTOR
> +   bool "Compile the kernel with detect Hard and Soft Lockups"
> +   depends on KERNEL_DEBUG_KERNEL
> +   help
> + Say Y here to enable the kernel to act as a watchdog to detect
> + hard and soft lockups.
> +
> + Softlockups are bugs that cause the kernel to loop in kernel
> + mode for more than 20 seconds, without giving other tasks a
> + chance to run.  The current stack trace is displayed upon
> + detection and the system will stay locked up.
> +
> + Hardlockups are bugs that cause the CPU to loop in kernel mode
> + for more than 10 seconds, without letting other interrupts have a
> + chance to run.  The current stack trace is displayed upon detection
> + and the system will stay locked up.
> +
> + The overhead should be minimal.  A periodic hrtimer runs to
> + generate interrupts and kick the watchdog task every 4 seconds.
> + An NMI is generated every 10 seconds or so to check for hardlockups.
> +
> + The frequency of hrtimer and NMI events and the soft and hard lockup
> + thresholds can be controlled through the sysctl watchdog_thresh.
> +
> +config KERNEL_DETECT_HUNG_TASK
> +   bool "Compile the kernel with detect Hung Tasks"
> +   depends on KERNEL_DEBUG_KERNEL
> +   default KERNEL_LOCKUP_DETECTOR
> +   help
> + Say Y here to enable the kernel to detect "hung tasks",
> + which are bugs that cause the task to be stuck in
> + uninterruptible "D" state indefinitely.
> +
> + When a hung task is detected, the kernel will print the
> + current stack trace (which you should report), but the
> + task will stay in uninterruptible state. If lockdep is
> + enabled then all held locks will also be reported. This
> + feature has negligible overhead.
> +
> +config KERNEL_WQ_WATCHDOG
> +   bool "Compile the kernel with detect Workqueue Stalls"
> +   depends on KERNEL_DEBUG_KERNEL
> +   help
> + Say Y here to enable stall detection on workqueues.  If a
> + worker pool doesn't make forward progress on a pending work
> + item for over a given amount of time, 30s by default, a
> + warning message is printed along with dump of workqueue
> + state.  This can be configured through kernel parameter
> + "workqueue.watchdog_thresh" and its sysfs counterpart.
> +
> +config KERNEL_DEBUG_ATOMIC_SLEEP
> +   bool "Compile the kernel with sleep inside atomic section checking"
> +   depends on KERNEL_DEBUG_KERNEL
> +   help
> + If you say Y here, various routines which may sleep will become very
> + noisy if they are called inside atomic sections: when a spinlock is
> + held, inside an rcu read side critical section, inside preempt 
> disabled
> + sections, inside an interrupt, etc...
> +
> +config KERNEL_DEBUG_VM
> +   bool "Compile the kernel with debug VM"
> +   depends on KERNEL_DEBUG_KERNEL
> +   help
> + Enable this to turn on extended checks in the virtual-memory system
> +  that may impact performance.
> +
> + If unsure, say N.
> +
>  config KERNEL_PRINTK_TIME
> bool "Enable printk timestamps"
> default y
> diff --git a/target/linux/generic/config-4.14 
> b/target/linux/generic/config-4.14
> index 5a9b82db80..d1ce30d2f7 100644
> --- a/target/linux/generic/config-4.14
> +++ b/target/linux/generic/config-4.14
> @@ -594,6 +594,7 @@ CONFIG_BLOCK=y
>  # CONFIG_BONDING is not set
>  # CONFIG_BOOKE_WDT is not set
>  CONFIG_BOOKE_WDT_DEFAULT_TIMEOUT=3
> +# CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set
>  # CONFIG_BOOT_PRINTK_DELAY is not set
>  CONFIG_BOOT_RAW=y
>  CONFIG_BPF=y
> @@ -1073,6

Re: [OpenWrt-Devel] [PATCH 2/4] build: Add option KERNEL_KASAN

[Alexandru Ardelean]

On Wed, Feb 12, 2020 at 12:50 PM Hauke Mehrtens
 wrote:
>
> The kernel kernel address sanitizer is able to detect some memory
> bugs in the kernel like out of range array accesses.
>

Reviewed-by: Alexandru Ardelean 

> Signed-off-by: Hauke Mehrtens 
> ---
>  config/Config-kernel.in  | 52 
>  target/linux/generic/config-4.14 |  1 +
>  target/linux/generic/config-4.19 |  1 +
>  3 files changed, 54 insertions(+)
>
> diff --git a/config/Config-kernel.in b/config/Config-kernel.in
> index bf1c1055f1..3059a45f48 100644
> --- a/config/Config-kernel.in
> +++ b/config/Config-kernel.in
> @@ -120,6 +120,58 @@ config KERNEL_UBSAN_NULL
>   This option enables detection of memory accesses via a
>   null pointer.
>
> +config KERNEL_KASAN
> +   bool "Compile the kernel with KASan: runtime memory debugger"
> +   select KERNEL_SLUB_DEBUG
> +   depends on (x86_64 || aarch64)
> +   help
> + Enables kernel address sanitizer - runtime memory debugger,
> + designed to find out-of-bounds accesses and use-after-free bugs.
> + This is strictly a debugging feature and it requires a gcc version
> + of 4.9.2 or later. Detection of out of bounds accesses to stack or
> + global variables requires gcc 5.0 or later.
> + This feature consumes about 1/8 of available memory and brings about
> + ~x3 performance slowdown.
> + For better error detection enable CONFIG_STACKTRACE.
> + Currently CONFIG_KASAN doesn't work with CONFIG_DEBUG_SLAB
> + (the resulting kernel does not boot).
> +
> +config KERNEL_KASAN_EXTRA
> +   bool "KAsan: extra checks"
> +   depends on KERNEL_KASAN && KERNEL_DEBUG_KERNEL
> +   help
> + This enables further checks in the kernel address sanitizer, for now
> + it only includes the address-use-after-scope check that can lead
> + to excessive kernel stack usage, frame size warnings and longer
> + compile time.
> + https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 has more
> +
> +
> +choice
> +   prompt "Instrumentation type"
> +   depends on KERNEL_KASAN
> +   default KERNEL_KASAN_OUTLINE
> +
> +config KERNEL_KASAN_OUTLINE
> +   bool "Outline instrumentation"
> +   help
> + Before every memory access compiler insert function call
> + __asan_load*/__asan_store*. These functions performs check
> + of shadow memory. This is slower than inline instrumentation,
> + however it doesn't bloat size of kernel's .text section so
> + much as inline does.
> +
> +config KERNEL_KASAN_INLINE
> +   bool "Inline instrumentation"
> +   help
> + Compiler directly inserts code checking shadow memory before
> + memory accesses. This is faster than outline (in some workloads
> + it gives about x2 boost over outline instrumentation), but
> + make kernel's .text size much bigger.
> + This requires a gcc version of 5.0 or later.
> +
> +endchoice
> +
>  config KERNEL_TASKSTATS
> bool "Compile the kernel with task resource/io statistics and 
> accounting"
> default n
> diff --git a/target/linux/generic/config-4.14 
> b/target/linux/generic/config-4.14
> index 73b0d77155..5a9b82db80 100644
> --- a/target/linux/generic/config-4.14
> +++ b/target/linux/generic/config-4.14
> @@ -4927,6 +4927,7 @@ CONFIG_TCP_CONG_CUBIC=y
>  # CONFIG_TEST_FIRMWARE is not set
>  # CONFIG_TEST_HASH is not set
>  # CONFIG_TEST_HEXDUMP is not set
> +# CONFIG_TEST_KASAN is not set
>  # CONFIG_TEST_KMOD is not set
>  # CONFIG_TEST_KSTRTOX is not set
>  # CONFIG_TEST_LIST_SORT is not set
> diff --git a/target/linux/generic/config-4.19 
> b/target/linux/generic/config-4.19
> index aba7bccaf6..372cad70a6 100644
> --- a/target/linux/generic/config-4.19
> +++ b/target/linux/generic/config-4.19
> @@ -5187,6 +5187,7 @@ CONFIG_TCP_CONG_CUBIC=y
>  # CONFIG_TEST_HASH is not set
>  # CONFIG_TEST_HEXDUMP is not set
>  # CONFIG_TEST_IDA is not set
> +# CONFIG_TEST_KASAN is not set
>  # CONFIG_TEST_KMOD is not set
>  # CONFIG_TEST_KSTRTOX is not set
>  # CONFIG_TEST_LIST_SORT is not set
> --
> 2.17.1
>
>
> ___
> 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: [OpenWrt-Devel] x86: Add missing kernel option CONFIG_X86_DECODER_SELFTEST

[Alexandru Ardelean]

On Tue, Feb 11, 2020 at 8:20 PM Hauke Mehrtens  wrote:
>
> This option has now a different dependency and can be activated, set a
> default value.
>
> Fixes: 20b5a4ca01ca ("kernel: bump 4.19 to 4.19.101")

Tested-by: Alexandru Ardelean 
[ both x86 4.14 & 4.19 ]

> Signed-off-by: Hauke Mehrtens 
> ---
>  target/linux/x86/config-4.14 | 1 +
>  target/linux/x86/config-4.19 | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/target/linux/x86/config-4.14 b/target/linux/x86/config-4.14
> index 18b7de832f..8d358aacac 100644
> --- a/target/linux/x86/config-4.14
> +++ b/target/linux/x86/config-4.14
> @@ -469,6 +469,7 @@ CONFIG_X86_CMPXCHG64=y
>  # CONFIG_X86_CPUFREQ_NFORCE2 is not set
>  # CONFIG_X86_CPUID is not set
>  # CONFIG_X86_DEBUG_FPU is not set
> +# CONFIG_X86_DECODER_SELFTEST is not set
>  # CONFIG_X86_EXTENDED_PLATFORM is not set
>  CONFIG_X86_F00F_BUG=y
>  CONFIG_X86_FAST_FEATURE_TESTS=y
> diff --git a/target/linux/x86/config-4.19 b/target/linux/x86/config-4.19
> index ecfaf45d90..afc8d6af57 100644
> --- a/target/linux/x86/config-4.19
> +++ b/target/linux/x86/config-4.19
> @@ -453,6 +453,7 @@ CONFIG_X86_CMPXCHG64=y
>  # CONFIG_X86_CPUFREQ_NFORCE2 is not set
>  # CONFIG_X86_CPUID is not set
>  # CONFIG_X86_DEBUG_FPU is not set
> +# CONFIG_X86_DECODER_SELFTEST is not set
>  # CONFIG_X86_EXTENDED_PLATFORM is not set
>  CONFIG_X86_F00F_BUG=y
>  CONFIG_X86_FEATURE_NAMES=y
> --
> 2.17.1
>
>
> ___
> 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: [OpenWrt-Devel] brcm2708: add kernel 4.14 support

[Alexandru Ardelean]

On Fri, Dec 7, 2018 at 10:57 AM Stijn Tintel  wrote:
>
> On 7/12/18 10:17, Alexandru Ardelean wrote:
> > On Fri, Dec 7, 2018 at 5:06 AM Stijn Tintel  wrote:
> >> On 11/11/18 18:37, Stijn Tintel wrote:
> >>> Hi,
> >>>
> >>> I have just pushed support for the 4.14 kernel on the brcm2708 target to
> >>> my staging tree [1], and would like to get some feedback before pushing
> >>> it to master. It would also be nice if people could do runtime tests on
> >>> bcm2709 and bcm2710, as I don't own such hardware.
> >>>
> >>> Thanks,
> >>> Stijn
> >>>
> >>> [1]
> >>> https://git.openwrt.org/?p=openwrt/staging/stintel.git;a=shortlog;h=refs/heads/brcm2708-4_14
> >>>
> >> Updated [1]:
> >> - based on 4.14.86
> >> - split kmod changes in separate commits
> >> - kept lan78xx patches except those that are superseded by upstream
> >> changes, added another one that attempts to fix broken ethernet and
> >> "kevent 4 may have been dropped" flood
> >> - added missing compatible strings using upstream names for compute modules
> >> - no longer removing the sense HAT patch, I might add kmod packages for
> >> that later
> >>
> >> Compile-tested all 3 subtargets again with CONFIG_ALL_KMODS=y, and
> >> runtime-tested bcm2708 on RPi0W and bcm2710 on RPi3B+. The wired
> >> interface on the latter seems to be usable now.
> >>
> >> I'm planning to push this to master as soon as Koen pushed the 4.14.86
> >> bump. If there are any objections, please speak up ASAP.
> >>
> > This one booted fine on a RPi 3.
> > I used the 32 bit image.
> >
> > root@OpenWrt:~# uname -a
> > Linux OpenWrt 4.14.86 #0 SMP Fri Dec 7 03:03:39 2018 armv7l GNU/Linux
> Thanks for testing, I added your "Tested-by".
Ack.

> >
> > A few minor/ignorable errors:
> > [0.769743] Error: Driver 'sdhost-bcm2835' is already registered, 
> > aborting...
> Fixed by disabling CONFIG_MMC_BCM2835_MMC since we want to prefer
> upstream when possible.
> > [8.689456] brcmfmac mmc1:0001:1: Direct firmware load for
> > brcm/brcmfmac43455-sdio.raspberrypi,3-model-b-plus.txt failed with
> > error -2
> >
> Similar error appeared for me with 4.9. Since it's non-fatal, I'm going
> to ignore this for now.
I assumed as much, but I was a bit lazy to re-create or flash an
SD-card with a 4.9 image.

>
> Thanks,
> Stijn
>

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

Re: [OpenWrt-Devel] brcm2708: add kernel 4.14 support

[Alexandru Ardelean]

On Fri, Dec 7, 2018 at 5:06 AM Stijn Tintel  wrote:
>
> On 11/11/18 18:37, Stijn Tintel wrote:
> > Hi,
> >
> > I have just pushed support for the 4.14 kernel on the brcm2708 target to
> > my staging tree [1], and would like to get some feedback before pushing
> > it to master. It would also be nice if people could do runtime tests on
> > bcm2709 and bcm2710, as I don't own such hardware.
> >
> > Thanks,
> > Stijn
> >
> > [1]
> > https://git.openwrt.org/?p=openwrt/staging/stintel.git;a=shortlog;h=refs/heads/brcm2708-4_14
> >
> Updated [1]:
> - based on 4.14.86
> - split kmod changes in separate commits
> - kept lan78xx patches except those that are superseded by upstream
> changes, added another one that attempts to fix broken ethernet and
> "kevent 4 may have been dropped" flood
> - added missing compatible strings using upstream names for compute modules
> - no longer removing the sense HAT patch, I might add kmod packages for
> that later
>
> Compile-tested all 3 subtargets again with CONFIG_ALL_KMODS=y, and
> runtime-tested bcm2708 on RPi0W and bcm2710 on RPi3B+. The wired
> interface on the latter seems to be usable now.
>
> I'm planning to push this to master as soon as Koen pushed the 4.14.86
> bump. If there are any objections, please speak up ASAP.
>

This one booted fine on a RPi 3.
I used the 32 bit image.

root@OpenWrt:~# uname -a
Linux OpenWrt 4.14.86 #0 SMP Fri Dec 7 03:03:39 2018 armv7l GNU/Linux

A few minor/ignorable errors:
[0.769743] Error: Driver 'sdhost-bcm2835' is already registered, aborting...
[8.689456] brcmfmac mmc1:0001:1: Direct firmware load for
brcm/brcmfmac43455-sdio.raspberrypi,3-model-b-plus.txt failed with
error -2

Full dmesg log below
/START dmesg 
--/
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.14.86 (sandu@saturn) (gcc version 7.3.0
(OpenWrt GCC 7.3.0 r8039+640-0317fc3658)) #0 SMP Fri Dec 7 03:03:39
2018
[0.00] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d
[0.00] CPU: div instructions available: patching division code
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[0.00] OF: fdt: Machine model: Raspberry Pi 3 Model B Plus Rev 1.3
[0.00] Memory policy: Data cache writealloc
[0.00] cma: Reserved 16 MiB at 0x3a40
[0.00] On node 0 totalpages: 242688
[0.00] free_area_init_node: node 0, pgdat 80824bc0,
node_mem_map b9c88000
[0.00]   Normal zone: 1896 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 242688 pages, LIFO batch:31
[0.00] random: get_random_bytes called from
start_kernel+0x84/0x35c with crng_init=0
[0.00] percpu: Embedded 16 pages/cpu @b9c34000 s33932 r8192
d23412 u65536
[0.00] pcpu-alloc: s33932 r8192 d23412 u65536 alloc=16*4096
[0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 240792
[0.00] Kernel command line: 8250.nr_uarts=1
bcm2708_fb.fbwidth=1824 bcm2708_fb.fbheight=984 bcm2708_fb.fbswap=1
vc_mem.mem_base=0x3ec0 vc_mem.mem_size=0x4000
dwc_otg.lpm_enable=0 console=ttyS0,115200 kgdboc=ttyS0,115200
console=tty1 root=/dev/mmcblk0p2 rootfstype=squashfs,ext4 rootwait
[0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Memory: 937852K/970752K available (4656K kernel code,
148K rwdata, 1212K rodata, 1024K init, 351K bss, 16516K reserved,
16384K cma-reserved)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[0.00] vmalloc : 0xbb80 - 0xff80   (1088 MB)
[0.00] lowmem  : 0x8000 - 0xbb40   ( 948 MB)
[0.00] modules : 0x7f00 - 0x8000   (  16 MB)
[0.00]   .text : 0x80008000 - 0x8058c324   (5649 kB)
[0.00]   .init : 0x8070 - 0x8080   (1024 kB)
[0.00]   .data : 0x8080 - 0x808253c0   ( 149 kB)
[0.00].bss : 0x8082a1a8 - 0x80881e08   ( 352 kB)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[0.00] Hierarchical RCU implementation.
[0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[0.00] arch_timer: cp15 timer(s) running at 19.20MHz (phys).
[0.00] clocksource: arch_sys_counter: mask: 0xff
max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns
[0.07] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps
every 4398046511078ns
[0.21] Switching to timer-based delay loop, resolution 52ns
[0.000222] Console: colour dummy device 80x30
[0.000675] console [tty1] enabled

Re: [OpenWrt-Devel] brcm2708: add kernel 4.14 support

[Alexandru Ardelean]

Hey,

The lan78xx stuff you removed seems to cause some endless prints like this:
** 10 printk messages dropped ** [ timestamp ] lan78xx 1-1.1.1:1.0
eth0: kevent 4 may have been dropped

This happens shortly after booting up.

I tested on a RPi 3 Model B+.
The kernel is 32bit .

[Related to RPi] The RPi kernel seems a bit hard to maintain in the
OpenWrt tree, because if you pull patches from the RPi github tree
(branch rpi-4.14.y) you need to periodically check & update them.
I tried to keep a 4.14 of OpenWrt in my own tree, and it's a pain to
maintain [just for my personal need].
Every couple of 4.14.xxx bumps, some of the patches don't apply
anymore, because some of them are too big [thrown in], and conflict
with upstream stuff.
So, if going forward with OpenWrt + RPi [which I would love to see],
this will be a somewhat hefty work-load.

Thanks
Alex

On Sun, Nov 11, 2018 at 6:37 PM Stijn Tintel  wrote:
>
> Hi,
>
> I have just pushed support for the 4.14 kernel on the brcm2708 target to
> my staging tree [1], and would like to get some feedback before pushing
> it to master. It would also be nice if people could do runtime tests on
> bcm2709 and bcm2710, as I don't own such hardware.
>
> Thanks,
> Stijn
>
> [1]
> https://git.openwrt.org/?p=openwrt/staging/stintel.git;a=shortlog;h=refs/heads/brcm2708-4_14
>

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

[OpenWrt-Devel] [PATCH] wolfssl: remove myself as maintainer

[Alexandru Ardelean]

I no longer have the time, nor the desire to maintain this package.
Remove myself as maintainer.

Signed-off-by: Alexandru Ardelean 
---
 package/libs/wolfssl/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/package/libs/wolfssl/Makefile b/package/libs/wolfssl/Makefile
index e08b6f3929..87ce9328e7 100644
--- a/package/libs/wolfssl/Makefile
+++ b/package/libs/wolfssl/Makefile
@@ -40,7 +40,6 @@ define Package/libwolfssl
   CATEGORY:=Libraries
   TITLE:=wolfSSL library
   URL:=http://www.wolfssl.com/
-  MAINTAINER:=Alexandru Ardelean 
   MENU:=1
   PROVIDES:=libcyassl
 endef
-- 
2.17.1


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

Re: [OpenWrt-Devel] /etc/board.json

[Alexandru Ardelean]

On Mon, Jun 25, 2018 at 6:41 PM, Levente  wrote:
> Hi,
>
>
> Could you tell me how is /etc/board.json generated? There might be a
> bug in this file, I'd like to fix.
>

It's the config_generate script that creates it:
https://github.com/openwrt/openwrt/blob/master/package/base-files/files/bin/config_generate

Alex

>
> Thanks,
> Levente
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/listinfo/openwrt-devel

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

Re: [OpenWrt-Devel] [PATCH] wolfssl: reorganized build options

[Alexandru Ardelean]

On Mon, Jun 18, 2018 at 5:07 AM, Eneas U de Queiroz via openwrt-devel
 wrote:
> 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.
>

Let's have the discussion on Github on your PR
https://github.com/openwrt/openwrt/pull/1069

Thanks
Alex

> -- Forwarded message --
> From: Eneas U de Queiroz 
> To: openwrt-devel@lists.openwrt.org
> Cc: Eneas U de Queiroz 
> Bcc:
> Date: Sun, 17 Jun 2018 23:05:58 -0300
> Subject: [PATCH] wolfssl: reorganized build options
> Removed options that can't be turned off because we're building
> with --enable-stunnel, some of which affected hostpad's Config.in.
> Adjusted the title of OCSP option, as OCSP itself can't be turned off,
> only the stapling part is selectable.
> Fixed poly1035 build.
> Mark options turned on when wpad support is selected.
> Add building with TLS v1.0 support as an option.
>
> Signed-off-by: Eneas U de Queiroz 
>
> PS: Is there any reason to split up chacha and poly1305 options?
> I would merge them in to a single option, but haven't done this here.
> ---
>  package/libs/wolfssl/Config.in | 17 ++-
>  package/libs/wolfssl/Makefile  | 33 
> --
>  package/network/services/hostapd/Config.in |  3 ---
>  3 files changed, 15 insertions(+), 38 deletions(-)
>
> diff --git a/package/libs/wolfssl/Config.in b/package/libs/wolfssl/Config.in
> index 50b0bb9cdf..45750a5892 100644
> --- a/package/libs/wolfssl/Config.in
> +++ b/package/libs/wolfssl/Config.in
> @@ -12,10 +12,6 @@ config WOLFSSL_HAS_CHACHA
> bool "Include ChaCha cipher suite support"
> default n
>
> -config WOLFSSL_HAS_ECC
> -   bool "Include ECC (Elliptic Curve Cryptography) support"
> -   default y
> -
>  config WOLFSSL_HAS_DH
> bool "Include DH (Diffie-Hellman) support"
> default y
> @@ -24,12 +20,8 @@ config WOLFSSL_HAS_ARC4
> bool "Include ARC4 support"
> default y
>
> -config WOLFSSL_HAS_DES3
> -   bool "Include DES3 (Tripple-DES) support"
> -   default y
> -
> -config WOLFSSL_HAS_PSK
> -   bool "Include PKS (Pre Share Key) support"
> +config WOLFSSL_HAS_TLSV10
> +   bool "Include TLS 1.0 support"
> default y
>
>  config WOLFSSL_HAS_SESSION_TICKET
> @@ -41,11 +33,14 @@ config WOLFSSL_HAS_DTLS
> default n
>
>  config WOLFSSL_HAS_OCSP
> -   bool "Include OSCP support"
> +   bool "Include OSCP stapling support"
> default y
>
>  config WOLFSSL_HAS_WPAS
> bool "Include wpa_supplicant support"
> +   select WOLFSSL_HAS_ARC4
> +   select WOLFSSL_HAS_OCSP
> +   select WOLFSSL_HAS_SESSION_TICKET
> default y
>
>  config WOLFSSL_HAS_ECC25519
> diff --git a/package/libs/wolfssl/Makefile b/package/libs/wolfssl/Makefile
> index e08b6f3929..6e121330f4 100644
> --- a/package/libs/wolfssl/Makefile
> +++ b/package/libs/wolfssl/Makefile
> @@ -26,11 +26,10 @@ PKG_CPE_ID:=cpe:/a:yassl:cyassl
>  PKG_CONFIG_DEPENDS:=\
> CONFIG_WOLFSSL_HAS_AES_CCM CONFIG_WOLFSSL_HAS_AES_GCM \
> CONFIG_WOLFSSL_HAS_ARC4 CONFIG_WOLFSSL_HAS_CHACHA \
> -   CONFIG_WOLFSSL_HAS_DES3 CONFIG_WOLFSSL_HAS_DH CONFIG_WOLFSSL_HAS_DTLS 
> \
> -   CONFIG_WOLFSSL_HAS_ECC CONFIG_WOLFSSL_HAS_ECC25519 \
> +   CONFIG_WOLFSSL_HAS_DH CONFIG_WOLFSSL_HAS_DTLS \
> +   CONFIG_WOLFSSL_HAS_ECC25519 CONFIG_WOLFSSL_HAS_TLSV10 \
> CONFIG_WOLFSSL_HAS_OCSP CONFIG_WOLFSSL_HAS_POLY_1305 \
> -   CONFIG_WOLFSSL_HAS_PSK CONFIG_WOLFSSL_HAS_SESSION_TICKET \
> -   CONFIG_WOLFSSL_HAS_WPAS
> +   CONFIG_WOLFSSL_HAS_SESSION_TICKET CONFIG_WOLFSSL_HAS_WPAS
>
>  include $(INCLUDE_DIR)/package.mk
>
> @@ -85,15 +84,9 @@ CONFIGURE_ARGS += \
> --disable-chacha
>  endif
>
> -ifeq ($(CONFIG_WOLFSSL_HAS_ECC),y)
> +ifneq ($(CONFIG_WOLFSSL_HAS_DH),y)
>  CONFIGURE_ARGS += \
> -   --enable-ecc \
> -   --enable-supportedcurves
> -endif
> -
> -ifeq ($(CONFIG_WOLFSSL_HAS_DH),y)
> -CONFIGURE_ARGS += \
> -   --enable-dh
> +   --disable-dh
>  endif
>
>  ifneq ($(CONFIG_WOLFSSL_HAS_ARC4),y)
> @@ -104,17 +97,9 @@ CONFIGURE_ARGS += \
> --enable-arc4
>  endif
>
> -ifneq ($(CONFIG_WOLFSSL_HAS_DES3),y)
> -CONFIGURE_ARGS += \
> -   --disable-des3
> -else
> -CONFIGURE_ARGS += \
> -   --enable-des3
> -endif
> -
> -ifeq ($(CONFIG_WOLFSSL_HAS_PSK),y)
> +ifeq ($(CONFIG_WOLFSSL_HAS_TLSV10),y)
>  CONFIGURE_ARGS += \
> -   --enable-psk
> +   --enable-tlsv10
>  endif
>
>  ifeq ($(CONFIG_WOLFSSL_HAS_SESSION_TICKET),y)
> @@ -142,9 +127,9 @@ CONFIGURE_ARGS += \
> --enable-curve25519
>  endif
>
> -ifneq ($(CONFIG_WOLFSSL_HAS_POLY1305),y)
> +ifneq ($(CONFIG_WOLFSSL_HAS_POLY_1305),y)
>  CONFIGURE_ARGS += \
> -   --enable-poly1305
> +   --disable-poly1305
>  endif
>
>  #ifneq ($(CONFIG_TARGET_x86),)
> diff 

Re: [OpenWrt-Devel] dnscrypt-proxy package missing in snapshot

[Alexandru Ardelean]

On Wed, Jun 6, 2018 at 7:38 PM, Maciej Soltysiak  wrote:
> Hi,
>
> It doesn't look like there are any takers for this task.
> Can anyone guide me to a 101 tutorial on making a brand new package?

I guess you can start with a wiki page for this:
https://openwrt.org/docs/guide-developer/helloworld/chapter3

When doing that, you can use these rules for build speed-up:
https://openwrt.org/docs/guide-developer/build.a.package

You can also add adjustments with this stuff [1]:
https://openwrt.org/docs/guide-developer/packages.flags

Note that in Makefile, the Build/Prepare and Build/Compile build rules
[and also a few others], are sometimes omitted.
That's because for many of them, the default build rules work perfectly.
You only need to adjust build variables like mentioned in [1].

I usually try to look at other packages and how they do things.
Copying knowledge is a fun/natural way [for me] to do things/learn.
So, personally I'd start with this file and adjust it:
https://github.com/openwrt/packages/blob/master/net/dnscrypt-proxy/Makefile

When building, I'd recommend starting with an SDK.
It saves time initially. But it is a good idea to also go the
full-route sometimes [i.e. clone the openwrt repo and build everything
from scratch].

For building a package from scratch, I guess any SDK is fine, so I'd
say go with ar71xx [it's still the more popular target].
Link page [go at the bottom]:
http://downloads.openwrt.org/snapshots/targets/ar71xx/generic/
Filename: openwrt-sdk-ar71xx-generic_gcc-7.3.0_musl.Linux-x86_64.tar.xz

You typically, untar this, run
./script/feeds update -a
./script/feeds install -a

If I need to be quick, I just add the package in the "package" folder.
[ Example: package/dnscrypt2/Makefile ]
Then

:Edit_Makefile
Then:  make menuconfig   [select your package to be built]
Runmake
Examine errors
If not ok,  goto Edit_Makefile

That's pretty much my 101 [with a combination of other 101s gathered
from around other places]

> dnscrypt-proxy 2 is completely different from its predecessor. There are
> sources, as well as pre-build binaries for 20+ architectures.
> go is required to build.

Pre-built binaries are not preferred for things like dnscrypt-proxy;
or I am misunderstanding something about pre-built binaries.
Usually in OpenWrt external binaries are preferred for things like
special firmware for chips, where really there is no alternative for
controlling the chip.
Even if you have pre-built binaries for userspace stuff, it's still
preferable to build them from scratch in OpenWrt, to avoid headaches
with maintaining consistency between GCC, libc, architecture and other
stuff.
Well, if it's a internal package [that won't be upstreamed], then it's
fine to have pre-built stuff.

>
> I'd very much appreciate for helping do this,
> Maciej
>
> On Sun, Feb 18, 2018 at 12:24 AM, Maciej Soltysiak 
> wrote:
>>
>> On my MIPS32 (WNDR3800) system, I noticed the C binary was <100k.
>> The GO binary is 6.5MB, I ran upx on it and it went down to 1.5M.
>> It incurs about 1s of delay for unpacking, but it works.
>>
>> I don't know much about packaging this around the uci scripting, etc, but
>> I hope this helps the maintainer a bit.
>>
>> Best regards,
>> Maciej
>>
>> On Sat, Feb 17, 2018 at 11:40 PM, Maciej Soltysiak 
>> wrote:
>>>
>>> The OpenWrt Makefile aims to get dnscrypt-proxy 1.9.5 from a mirror at
>>> https://github.com/dyne/dnscrypt-proxy
>>>
>>> However, the upstream (Frank Denis) recently released a 2.0 which is
>>> significantly different.
>>> It's now written in go, instead of C and it support the new version of
>>> the protocol (v2).
>>>
>>> If we're going to get this package fixed we should see if we can get the
>>> new one to run.
>>> Probably should come from upstream at:
>>> https://github.com/jedisct1/dnscrypt-proxy
>>>
>>> Best regards,
>>> Maciej
>>>
>>> On Mon, May 1, 2017 at 12:48 PM, Alexandru Ardelean
>>>  wrote:
>>>>
>>>> On Mon, May 1, 2017 at 12:04 PM, Mangesh Bhamre
>>>>  wrote:
>>>> >
>>>> > Hello,
>>>> >
>>>> > Last time I reported this issue was for MT7620.  dnscrypt-proxy now
>>>> > failing for MT7621.
>>>> >
>>>> >
>>>> > http://buildbot.openwrt.org:8010/broken_packages/ramips.mt7621/dnscrypt-proxy/compile.txt
>>>> >
>>>> > I am not sure what was the fix made. Likely was related to SSL cert
>>>> > check. Can anyone please look at this and fix it same way as MT7620 ?
>>>> >
>>>> > Regards,
>>>> > Mangesh
>>>> &

Re: [OpenWrt-Devel] [PATCH] wolfssl: update to version 3.14.4

[Alexandru Ardelean]

On Fri, May 25, 2018 at 1:18 AM, Daniel Golle <dan...@makrotopia.org> wrote:
> Hi!
>
> On Thu, May 24, 2018 at 10:38:45PM +0300, Alexandru Ardelean wrote:
>> On Thu, May 24, 2018 at 7:34 PM, Daniel Golle <dan...@makrotopia.org> wrote:
>> > Use download from github archive corresponding to v3.14.4 tag because
>> > the project's website apparently only offers 3.14.0-stable release
>> > downloads.
>> > Drop local patch for CVE-2017-13099 as it was merged upstream.
>> >
>>
>> Looks good.
>> On a related note, would you like to take over the package ?
>> I don't seem to find time for it at the moment.
>
> You had that nice patch to improve the build-time configuration half-
> ready. It'd really be nice to still incooperate that...
> I do believe you are doing a good job as a maintainer, however, if you
> feel burdened by the maintainership I'm also ok to take over.
>

Not so much burdened as much as I don't want to block other people.
So, if you don't feel blocked, I can still keep maintaining it.

I will make time for that configuration patch.

Thanks
Alex

>
> Cheers
>
>
> Daniel

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

Re: [OpenWrt-Devel] [PATCH] wolfssl: update to version 3.14.4

[Alexandru Ardelean]

On Thu, May 24, 2018 at 7:34 PM, Daniel Golle  wrote:
> Use download from github archive corresponding to v3.14.4 tag because
> the project's website apparently only offers 3.14.0-stable release
> downloads.
> Drop local patch for CVE-2017-13099 as it was merged upstream.
>

Looks good.
On a related note, would you like to take over the package ?
I don't seem to find time for it at the moment.

> Signed-off-by: Daniel Golle 
> ---
>  package/libs/wolfssl/Makefile |   9 +-
>  .../wolfssl/patches/001-CVE-2017-13099.patch  | 144 --
>  .../patches/100-disable-hardening-check.patch |   2 +-
>  3 files changed, 6 insertions(+), 149 deletions(-)
>  delete mode 100644 package/libs/wolfssl/patches/001-CVE-2017-13099.patch
>
> diff --git a/package/libs/wolfssl/Makefile b/package/libs/wolfssl/Makefile
> index d0bd3b5a35..41296dd0f2 100644
> --- a/package/libs/wolfssl/Makefile
> +++ b/package/libs/wolfssl/Makefile
> @@ -8,12 +8,13 @@
>  include $(TOPDIR)/rules.mk
>
>  PKG_NAME:=wolfssl
> -PKG_VERSION:=3.12.2
> -PKG_RELEASE:=2
> +PKG_VERSION:=3.14.4
> +PKG_RELEASE:=1
>
>  PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).zip
> -PKG_SOURCE_URL:=https://www.wolfssl.com/
> -PKG_HASH:=4993844c4b7919007c4511ec3f987fb06543536c3fc933cb53491bffe9150e49
> +# PKG_SOURCE_URL:=https://www.wolfssl.com/
> +PKG_SOURCE_URL:=https://github.com/wolfSSL/wolfssl/archive/v$(PKG_VERSION)
> +PKG_HASH:=1da1b45dec4a455716c8547074ad883c737865225f69443bb173c0dc21683fd1
>
>  PKG_FIXUP:=libtool
>  PKG_INSTALL:=1
> diff --git a/package/libs/wolfssl/patches/001-CVE-2017-13099.patch 
> b/package/libs/wolfssl/patches/001-CVE-2017-13099.patch
> deleted file mode 100644
> index e7b63cb8d4..00
> --- a/package/libs/wolfssl/patches/001-CVE-2017-13099.patch
> +++ /dev/null
> @@ -1,144 +0,0 @@
> -From fd455d5a5e9fef24c208e7ac7d3a4bc58834cbf1 Mon Sep 17 00:00:00 2001
> -From: David Garske 
> -Date: Tue, 14 Nov 2017 14:05:50 -0800
> -Subject: [PATCH] Fix for handling of static RSA PKCS formatting failures so
> - they are indistinguishable from from correctly formatted RSA blocks (per
> - RFC5246 section 7.4.7.1). Adjusted the static RSA preMasterSecret RNG
> - creation for consistency in client case. Removed obsolete
> - `PMS_VERSION_ERROR`.
> -
> 
> - src/internal.c  | 70 
> +
> - wolfssl/error-ssl.h |  2 +-
> - 2 files changed, 61 insertions(+), 11 deletions(-)
> -
>  a/src/internal.c
> -+++ b/src/internal.c
> -@@ -14190,9 +14190,6 @@ const char* wolfSSL_ERR_reason_error_str
> - case NOT_READY_ERROR :
> - return "handshake layer not ready yet, complete first";
> -
> --case PMS_VERSION_ERROR :
> --return "premaster secret version mismatch error";
> --
> - case VERSION_ERROR :
> - return "record layer version error";
> -
> -@@ -18758,8 +18755,10 @@ int SendClientKeyExchange(WOLFSSL* ssl)
> - #ifndef NO_RSA
> - case rsa_kea:
> - {
> -+/* build PreMasterSecret with RNG data */
> - ret = wc_RNG_GenerateBlock(ssl->rng,
> --ssl->arrays->preMasterSecret, SECRET_LEN);
> -+>arrays->preMasterSecret[VERSION_SZ],
> -+SECRET_LEN - VERSION_SZ);
> - if (ret != 0) {
> - goto exit_scke;
> - }
> -@@ -23545,6 +23544,9 @@ static int DoSessionTicket(WOLFSSL* ssl,
> - word32 idx;
> - word32 begin;
> - word32 sigSz;
> -+#ifndef NO_RSA
> -+intlastErr;
> -+#endif
> - } DckeArgs;
> -
> - static void FreeDckeArgs(WOLFSSL* ssl, void* pArgs)
> -@@ -23770,6 +23772,14 @@ static int DoSessionTicket(WOLFSSL* ssl,
> - ERROR_OUT(BUFFER_ERROR, exit_dcke);
> - }
> -
> -+/* pre-load PreMasterSecret with RNG data */
> -+ret = wc_RNG_GenerateBlock(ssl->rng,
> -+>arrays->preMasterSecret[VERSION_SZ],
> -+SECRET_LEN - VERSION_SZ);
> -+if (ret != 0) {
> -+goto exit_dcke;
> -+}
> -+
> - args->output = NULL;
> - break;
> - } /* rsa_kea */
> -@@ -24234,6 +24244,20 @@ static int DoSessionTicket(WOLFSSL* ssl,
> - NULL, 0, NULL
> - #endif
> - );
> -+
> -+/*  Errors that can occur here that should be
> -+ *  indistinguishable:
> -+ *   RSA_BUFFER_E, RSA_PAD_E and 
> RSA_PRIVATE_ERROR
> -+ */
> -+if (ret < 0 && ret != BAD_FUNC_ARG) {
> -+

Re: [OpenWrt-Devel] [PATCH] wolfssl: fix options and add support for wpa_supplicant features

[Alexandru Ardelean]

On Sat, Apr 28, 2018 at 9:55 PM, Daniel Golle  wrote:
> Some options' default values have been changed upstream, others were
> accidentally inverted (CONFIG_WOLFSSL_HAS_DES3). Also add options
> needed to build hostapd/wpa_supplicant against wolfssl.

Sorry for the late reply.
I wanted to take a look at the patch and check it a bit.
I noticed that your patch is applied now to master.

Overall this is good.
I've been wanting for a while to rework this.
Your approach is better right now before the release [than my rework].

Something like this:
https://github.com/commodo/openwrt/commit/d41ea4f342de7dbb02c9cfb0b19373c39ec24f81
I'll test it a bit more.

One more comment inline below.

>
> Signed-off-by: Daniel Golle 
> ---
>  package/libs/wolfssl/Config.in | 12 
>  package/libs/wolfssl/Makefile  | 33 -
>  2 files changed, 40 insertions(+), 5 deletions(-)
>
> diff --git a/package/libs/wolfssl/Config.in b/package/libs/wolfssl/Config.in
> index 7e8a4b6cee..9b88914516 100644
> --- a/package/libs/wolfssl/Config.in
> +++ b/package/libs/wolfssl/Config.in
> @@ -32,10 +32,22 @@ config WOLFSSL_HAS_PSK
> bool "Include PKS (Pre Share Key) support"
> default n
>
> +config WOLFSSL_HAS_SESSION_TICKET
> +   bool "Include session ticket support"
> +   default n
> +
>  config WOLFSSL_HAS_DTLS
> bool "Include DTLS support"
> default n
>
> +config WOLFSSL_HAS_OCSP
> +   bool "Include OSCP support"
> +   default n
> +
> +config WOLFSSL_HAS_WPAS
> +   bool "Include wpa_supplicant support"
> +   default n
> +
>  config WOLFSSL_HAS_ECC25519
> bool "Include ECC Curve 22519 support"
> depends on WOLFSSL_HAS_ECC
> diff --git a/package/libs/wolfssl/Makefile b/package/libs/wolfssl/Makefile
> index 1d4b7f5579..d0bd3b5a35 100644
> --- a/package/libs/wolfssl/Makefile
> +++ b/package/libs/wolfssl/Makefile
> @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
>
>  PKG_NAME:=wolfssl
>  PKG_VERSION:=3.12.2
> -PKG_RELEASE:=1
> +PKG_RELEASE:=2
>
>  PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).zip
>  PKG_SOURCE_URL:=https://www.wolfssl.com/
> @@ -51,7 +51,9 @@ CONFIGURE_ARGS += \
> --enable-opensslextra \
> --enable-sni \
> --enable-stunnel \
> -   --disable-examples
> +   --disable-examples \
> +   --disable-leanpsk \
> +   --disable-leantls \

Nitpick: these are disabled by default.
No need to disable them here.

>
>  ifeq ($(CONFIG_IPV6),y)
>  CONFIGURE_ARGS += \
> @@ -79,19 +81,25 @@ CONFIGURE_ARGS += \
> --enable-supportedcurves
>  endif
>
> -ifneq ($(CONFIG_WOLFSSL_HAS_DH),y)
> +ifeq ($(CONFIG_WOLFSSL_HAS_DH),y)
>  CONFIGURE_ARGS += \
> --enable-dh
>  endif
>
> -ifeq ($(CONFIG_WOLFSSL_HAS_ARC4),n)
> +ifneq ($(CONFIG_WOLFSSL_HAS_ARC4),y)
>  CONFIGURE_ARGS += \
> --disable-arc4
> +else
> +CONFIGURE_ARGS += \
> +   --enable-arc4
>  endif
>
> -ifeq ($(CONFIG_WOLFSSL_HAS_DES3),y)
> +ifneq ($(CONFIG_WOLFSSL_HAS_DES3),y)
>  CONFIGURE_ARGS += \
> --disable-des3
> +else
> +CONFIGURE_ARGS += \
> +   --enable-des3
>  endif
>
>  ifeq ($(CONFIG_WOLFSSL_HAS_PSK),y)
> @@ -99,11 +107,26 @@ CONFIGURE_ARGS += \
> --enable-psk
>  endif
>
> +ifeq ($(CONFIG_WOLFSSL_HAS_SESSION_TICKET),y)
> +CONFIGURE_ARGS += \
> +   --enable-session-ticket
> +endif
> +
>  ifeq ($(CONFIG_WOLFSSL_HAS_DTLS),y)
>  CONFIGURE_ARGS += \
> --enable-dtls
>  endif
>
> +ifeq ($(CONFIG_WOLFSSL_HAS_OCSP),y)
> +CONFIGURE_ARGS += \
> +   --enable-ocsp --enable-ocspstapling --enable-ocspstapling2
> +endif
> +
> +ifeq ($(CONFIG_WOLFSSL_HAS_WPAS),y)
> +CONFIGURE_ARGS += \
> +   --enable-wpas --enable-sha512 --enable-fortress --enable-fastmath
> +endif
> +
>  ifeq ($(CONFIG_WOLFSSL_HAS_ECC25519),y)
>  CONFIGURE_ARGS += \
> --enable-curve25519

Thanks for this patch :)
Alex

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

Re: [OpenWrt-Devel] [LEDE-DEV] kernel version status

[Alexandru Ardelean]

On Sun, Apr 1, 2018 at 5:48 PM, Hauke Mehrtens  wrote:
> The next OpenWrt release will use kernel 4.9 and kernel 4.14 depending
> on the target. All targets that are *not* on either kernel 4.9 or 4.14
> will not be included in the next release.
>
> I did some overview of the kernel version some months ago here:
> http://lists.infradead.org/pipermail/lede-dev/2017-October/009446.html
> http://lists.infradead.org/pipermail/lede-dev/2018-February/011308.html
>
> Here is the current situation as of today:
>
>
> The following targets are on kernel 4.14 and are fine:
> * apm821xx
> * archs38
> * armvirt
> * bcm53xx
> * cns3xxx
> * imx6
> * ipq40xx
> * kirkwood
> * malta
> * mediatek
> * mvebu
> * mxs
> * octeon
> * octeontx
> * pistachio
> * sunxi
> * x86
>
>
> The following targets are on kernel 4.9 and are fine:
> * ar71xx
> * ar7
> * arc770
> * at91
> There are some patches for kernel 4.14 on the mailing list,
> but it looks like nobody with the hardware wants to take care
> of them.
> * ath25
> * brcm2708
> * brcm47xx
> There is a pull request with kernel 4.14 patches on github, we
> will probably stay with kernel 4.9 for the next release.
> * brcm63xx
> patches for 4.14 are available in master
> * ipq806x
> * ixp4xx
> * lantiq
> patches for 4.14 are available in master, we will probably stay
> with kernel 4.9 for the next release.
> * layerscape
> * mpc85xx
> * omap
> There is a pull request with kernel 4.14 patches on github.
> * orion
> * ramips
> patches for 4.14 are available in master, we will probably stay
> with kernel 4.9 for the next release.
> * rb532
> * uml
>
>
> The following targets are on kernel 4.4 and will probably not be
> included in the next release:
> * gemini
> There are patches for kernel 4.14 on the mailing list, we will
> probably get them in before the release and ship this with 4.14
> * oxnas
> * zynq

Will these targets be dropped/removed from the tree ?
I'd be interested in upgrading the zynq target.
And I also have a partial work/effort in a repo, but not enough time
to test + push it.

I don't need this to be part of the 18.xx release, just curios if it
will still be in the tree, and then I can alloc time for it at a later
time.

Thanks
Alex

>
> The following targets are on kernel 3.18 and will probably not be
> included in the next release:
> * adm5120
> * adm8668
> * au1000
> * mcs814x
> * ppc40x
> * ppc44x
> * xburst
>
>
> This target is on kernel 4.1 (WTF):
> * omap24xx
>
>
> All the targets which are not on kernel 4.9 or 4.14 will probably not be
> included in the next release, I also haven't seen any activity for any
> of them expected the gemini target to get support for more recent kernel
> versions, if you need them please take care now.
>
> I am fine with the current status and do not see this as a blocker for
> the next release, all important targets are on either 4.9 or 4.14, if
> someone wants to see his target on a more recent version we are still
> open for patches.
>
> Hauke
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] How to get OpenWRT to leave kernel .config the f alone?

[Alexandru Ardelean]

On Fri, Mar 9, 2018 at 7:24 AM, Daniel Santos  wrote:
> Hello. I'm not very good with make and I need to make many changes to my
> kernel .config for debugging. I wrote a patch to add an option to tell
> OpenWRT to leave it alone, but I don't understand this build system very
> well and it seems to always prevent the kernel .config from being
> modified as well as leading to modules & kernel always being rebuilt.
> Would somebody be kind enough to fix it for me? :)
>

The problem is not the OpenWrt build system here.
It's likely the kernel's Kconfig system and dependency chain.
Your patch is going about it from the wrong angle.

Most symbols in the .config [whether OpenWrt's .config or kernel's
.config] have a dependency chain.
Example: driver bcm2708-spi [don't remember the actual driver name
here] will not be built/installed if CONFIG_SPI is not enabled in
.config.

So, if the symbol for building bcm2708-spi [let's call it
CONFIG_BCM2708_SPI] disappears during build, it's a symptom that the
dependency chain is not correct.
In a way, you may want this behavior, versus leaving it there and not
building it anyway.

What you can do is [in the OpenWrt context]:
* make kernel_menuconfig
* hit the slash key " / "
* type/search for the symbol you want to enable
* once you find it, it will list all symbols it depends on ; and which
you also want enabled
* add those symbols to your kernel config, or enable them via this
menuconfig you are in

Note that this Kconfig build-system is present in many projects [
Linux kernel, OpenWrt, buildroot, etc ].
So, if you learn to use it, the skill will be useful later on.

Typically, what I've noticed, is that the Linux kernel [in newer
versions] will enforce dependencies in drivers/code that were
previously not there, and when you update your kernel, stuff
disappears/gets disabled.
So, if you using an older .config in a newer kernel, or some other
mix, this is possible.

> I'm new to this project and I'm working with a device that has a crappy
> u-boot build installed on it. I need to run a debug kernel, but any time
> I attempt to tftp it to the device (directly to RAM) it fails to boot.
> If I send the whole damn sysupgrade via lcui then it works. Thus, if I
> upload a bad sysupgrade, I can potentially get locked out of the device
> until I manually flash the SPI (and I don't know how to do that yet, I
> guess some type of jtag?). So rather than just manually building my
> kernel and building a sysupgrade by hand, I would rather the build do it
> out of caution for messing it up.
>
> Oh yeah, and I'm using CC at this commit:
> 0625aaa6f37dcf6a2ffb611245fa9b6477642b78 -- of which I have no choice
> about. But if anybody can get that to work for the 17.x head, I can
> backport it.
>
> Thanks in advance!
> Daniel
>

Alex

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

Re: [OpenWrt-Devel] openwrt twitter account

[Alexandru Ardelean]

On Wed, Feb 14, 2018 at 9:27 AM, John Crispin  wrote:

> Hi,
>
> who can tell me the passwd please ? would be nice if we were able to
> retweet stuff like the FF GSoC stuff
>
>
I think in the worst-case you can reset the passwd, if you have access to
the email with which it was registered.


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

Re: [OpenWrt-Devel] patchwork

[Alexandru Ardelean]

On Thu, Jan 18, 2018 at 10:31 AM, John Crispin  wrote:
> Hi,
>
> I would like to close all ~1000 un-handled patches from the last 3 years and
> only keep stuff from the last 6 months. any problem with that ?
>

To add here.
Would it be possible/desire-able to add an auto-timeout to patchwork &
github PRs, issues to close after X time ?
Maybe make it official as part of the submission process.

Reason is: they pile up ; number of stuff can be too much for the same
number of core people that have to handle them.
And I bet it can be psychologically daunting/depressing to open up
Github/patchwork and see 1000 unresolved stuff, and then people have
to work up the mood/will to start going through them.

Naturally, an auto-message can be added saying "please re-submit this
as the auto-timeout has been reached", as to reduce
offending/pissing-off people.

This can work nicely as an auto-triaging of stuff, since people will
make an effort to re-open PRs, resubmit patches.
This shows interest and effort for something to go in.

Obviously, it's just an idea/proposal.
Feel free to disagree/discard/etc :)

> John

Alex

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

[OpenWrt-Devel] partial port of DPDK

[Alexandru Ardelean]

Hey,

I remember seeing some interest a while back in DPDK.

I started a port of DPDK for some experiment I wanted to do, but in
the meantime I stopped because of reasons.

Here's the current code so far:
https://github.com/commodo/packages/tree/dpdk/net/dpdk

It should build in the current master of OpenWrt. I tried it real quick now.
I did not manage to try it much.
It compiles on x86_64 ; I haven't tried to compile it on any other
platform/target,

If anyone wants to take this and maintain it, feel free to do so ; you
don't even need to mention me anywhere.

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

Re: [OpenWrt-Devel] Question for configuring OVS on OpenWRT

[Alexandru Ardelean]

On Wed, Nov 29, 2017 at 1:00 PM, Nam Bong Ha  wrote:
> Hi, all
>
> I am using an OpenWRT device that is configured to use ovs.
>
> I want to communicate between wireless devices and wired devices.
> Is the following connection possible?
>
>
>  ONOS
>  l
>  l
>  l
>  l
> Device1(lan)-(lan)OpenWRT-OVS(wireless)---(wireless)Device2
>
>
>
>
> I tried connecting the controller to OpenWRT (ovs).
> However, ssh connection was disconnected at the moment of connection.
>
> root@Controller$ ssh root@[OpenWRT IP]
> root@OpenWrt:~# ovs-vsctl show
> 0ca359f7-74f-420f-b0a5-dfbb6f79
> Bridge br-lan
> Port "eth0.1"
> Interface "eth0.1"
> Port br-lan
> Interface br-lan
> type: internal

I don't know if OVS works with Linux bridges.
In the past it didn't ; it was also recommended to disable the Linux
bridge kmod.

Maybe instead of trying to use br-lan, add all interfaces that are in
the br-lan bridge directly to OVS.

OVS bridges should work just like Linux bridges.
There are some things that are slightly neater with OVS bridges though.


> root@OpenWrt:~# ovs-vsctl set-controller br-lan  tcp:[ONOS IP]:6633
>
>
> The following is the configuration file for openwrt.
>
> /etc/config/wireless
> config wifi-device 'radio0'
> option type 'mac80211'
> option macaddr ':ae:99'
> list ht_capab 'LDPC'
> list ht_capab 'SHORT-GI-20'
> list ht_capab 'SHORT-GI-40'
> list ht_capab 'TX-STBC'
> list ht_capab 'RX-STBC1'
> list ht_capab 'DSSS_CCK-40'
> option disabled '0'
> option country 'KR'
> option hwmode '11ng'
> option htmode 'HT20'
> option txpower '11'
> option channel '1'
>
> config wifi-iface
> option device 'radio0'
> option mode 'ap'
> option ssid 'OpenWrt'
> option encryption 'none'
>
>
> /etc/config/network
> config interface 'loopback'
> option ifname 'lo'
> option proto 'static'
> option ipaddr '127.0.0.1'
> option netmask '255.0.0.0'
>
> config interface 'lan'
> option type 'bridge'
> option proto 'static'
> option netmask '255.255.255.0'
> option _orig_ifname 'eth0.1 radio0.network1'
> option _orig_bridge 'true'
> option ipaddr '192.168.30.1'
> option ifname 'eth0.1 tap0 wlan0'
>
> config interface 'wan'
> option ifname 'eth0.2'
> option _orig_ifname 'eth0.2'
> option _orig_bridge 'false'
> option proto 'static'
> option ipaddr '192.168.0.230'
> option netmask '255.255.254.0'
> option gateway '192.168.0.1'
>
> config switch
> option name 'switch0'
> option reset '1'
> option enable_vlan '1'
> option enable_learning '0'
>
> config switch_vlan
> option device 'switch0'
> option vlan '1'
> option ports '0t 2 3 4 5'
> option vid '1'
>
> config switch_vlan
> option device 'switch0'
> option vlan '2'
> option ports '0t 1'
> option vid '2'
>
> Thank you:)
> Have a good day :)
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [LEDE-DEV] openwrt and lede - remerge proposal V3

[Alexandru Ardelean]

On Tue, May 30, 2017 at 8:38 AM, Felix Fietkau  wrote:
> On 2017-05-29 09:03, John Crispin wrote:
>> (resend, this time as plain text)
>>
>> Hi,
>>
>> here is a V3 of the remerge proposal, I tried to fold all the comments
>> people made into it, if anything is missing let me know. Please remeber
>> that post remerge anything can be voted on, so cluttering the proposal
>> with many details will delay the remerge even more.
>>
>> Ideally we manage to vote during this week.
> ACK.
>
> - Felix

ack

[forgot that GMail app does not support plain text mode, or is really
hidden somewhere ]

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

Re: [OpenWrt-Devel] [LEDE-DEV] openwrt and lede - remerge proposal V3

[Alexandru Ardelean]

On Tue, 30 May 2017 at 08:38, Felix Fietkau  wrote:

> On 2017-05-29 09:03, John Crispin wrote:
> > (resend, this time as plain text)
> >
> > Hi,
> >
> > here is a V3 of the remerge proposal, I tried to fold all the comments
> > people made into it, if anything is missing let me know. Please remeber
> > that post remerge anything can be voted on, so cluttering the proposal
> > with many details will delay the remerge even more.
> >
> > Ideally we manage to vote during this week.
> ACK.
>
> - Felix


Ack


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

Re: [OpenWrt-Devel] OpenWRT: how to include byte-compile .pyc files into sysupgrade image?

[Alexandru Ardelean]

Well, you might be able to just copy the package files over and it may
just work.
Not sure.

On Mon, Mar 27, 2017 at 10:01 AM, Xuebing Wang <xbi...@gmail.com> wrote:
> Hi Alex,
>
> Thank you very much for your help. Apologies for the late response. I have
> been very busy recently. I do hope that I can find some time to backport
> these changes to CC 15.05.
>
> xuebing
>
>
> On 2017年03月10日 03:46, Alexandru Ardelean wrote:
>>
>> Hey Xuebing,
>>
>> Apologies for the late response.
>> Short version: please checkout this PR
>> https://github.com/openwrt/packages/pull/4130
>> I am hoping you can backport these changes to OpenWrt CC 15.05
>>
>> I've managed to package Python & Python3 with .pyc bytecodes.
>> And it seems to work fine. I tested with mpc85xx & x86_64, but please
>> come back with a reply if it does not work for you and I can
>> investigate.
>> Maybe it's different for your architecture.
>>
>> That PR may be a bit more than you need, since it splits Python
>> packages into Python Source packages and Python packages [ which now
>> ship with .pyc files ].
>> Funny story: I was approached about another user about this, but he
>> was happy with just using  `python -m compileall`
>>
>> I tested both Python & Python3 versions.
>> All looked good from what I could tell.
>>
>> Also, please notice anything in that PR that you could use to save
>> some space on your flash device.
>> I noticed that packages were shipping with test files ; I removed them.
>>
>> Hope this helps.
>>
>> Thanks
>> Alex
>>
>> On Sat, Feb 18, 2017 at 1:26 AM, Xuebing Wang <xbi...@gmail.com> wrote:
>>>
>>> Hi Alex,
>>>
>>> Thank you so much for your help.
>>>
>>> xuebing wang
>>>
>>>
>>>
>>> On 2017年02月17日 23:37, Alexandru Ardelean wrote:
>>>>
>>>> @Xuebing: so, there doesn't seem to be a very easy way to do this at
>>>> build
>>>> time.
>>>> I mean, at first, it can seem easy, because all that is needed, is to
>>>> add script that compiles here:
>>>>
>>>>
>>>> https://github.com/openwrt/packages/blob/for-15.05/lang/python/files/python-package.mk#L94
>>>>
>>>> That script needs to recursively compile all .py files and
>>>> [optionally]  remove them.
>>>> So, feel free to try/hack something for your case.
>>>>
>>>> Maybe a shell script that uses this:
>>>> http://effbot.org/zone/python-compile.htm
>>>>
>>>>> compile.py
>>>>
>>>> import os
>>>> import sys
>>>> import py_compile
>>>> for file in sys.argv:
>>>>   py_compile.compile(file)
>>>>   os.remove(file)
>>>>
>>>> find . -name "\.py" | xargs compile.py
>>>>
>>>>
>>>> For the general case [in trunk], I think I have to start considering
>>>> splitting the Python source files and Python byte-compiled files into
>>>> 2 package types.
>>>> There was a older discussion about this ; the idea is to package the
>>>> byte coded files, and offer the sources and python source packages.
>>>> Example: Have `python` package and `python-sources`  package.
>>>> `python` == byte-compiled .pyc files, `python-sources` .py files
>>>>
>>>> Will try to make an effort in the next couple of days to implement the
>>>> general solution for this.
>>>> But, it's Friday now here, and I usually don't do much in the weekend.
>>>> So, hopefully next week I could allocate some time for this.
>>>>
>>>> Thanks
>>>> Alex
>>>>
>>>> On Fri, Feb 17, 2017 at 9:42 AM, Xuebing Wang <xbi...@gmail.com> wrote:
>>>>>
>>>>> Hi Alex,
>>>>>
>>>>> Thanks a lot for your help.  I am using Python 2.7.12, branch
>>>>> chaos_calmer
>>>>> from (git://github.com/openwrt/openwrt.git), feeds branch is for-15.05.
>>>>>
>>>>> Also, I am using Atheros platform based on MIPS architecture.
>>>>>
>>>>> Thanks again.
>>>>>
>>>>> xuebing wang
>>>>>
>>>>>
>>>>> On 2017年02月17日 15:31, Alexandru Ardelean wrote:
>>>>>>
>>>>>> Oh.
>>>>>>
>>>>>> This is

Re: [OpenWrt-Devel] OpenWRT: how to include byte-compile .pyc files into sysupgrade image?

[Alexandru Ardelean]

Hey Xuebing,

Apologies for the late response.
Short version: please checkout this PR
https://github.com/openwrt/packages/pull/4130
I am hoping you can backport these changes to OpenWrt CC 15.05

I've managed to package Python & Python3 with .pyc bytecodes.
And it seems to work fine. I tested with mpc85xx & x86_64, but please
come back with a reply if it does not work for you and I can
investigate.
Maybe it's different for your architecture.

That PR may be a bit more than you need, since it splits Python
packages into Python Source packages and Python packages [ which now
ship with .pyc files ].
Funny story: I was approached about another user about this, but he
was happy with just using  `python -m compileall`

I tested both Python & Python3 versions.
All looked good from what I could tell.

Also, please notice anything in that PR that you could use to save
some space on your flash device.
I noticed that packages were shipping with test files ; I removed them.

Hope this helps.

Thanks
Alex

On Sat, Feb 18, 2017 at 1:26 AM, Xuebing Wang <xbi...@gmail.com> wrote:
> Hi Alex,
>
> Thank you so much for your help.
>
> xuebing wang
>
>
>
> On 2017年02月17日 23:37, Alexandru Ardelean wrote:
>>
>> @Xuebing: so, there doesn't seem to be a very easy way to do this at build
>> time.
>> I mean, at first, it can seem easy, because all that is needed, is to
>> add script that compiles here:
>>
>> https://github.com/openwrt/packages/blob/for-15.05/lang/python/files/python-package.mk#L94
>>
>> That script needs to recursively compile all .py files and
>> [optionally]  remove them.
>> So, feel free to try/hack something for your case.
>>
>> Maybe a shell script that uses this:
>> http://effbot.org/zone/python-compile.htm
>>
>>> compile.py
>>
>> import os
>> import sys
>> import py_compile
>> for file in sys.argv:
>>  py_compile.compile(file)
>>  os.remove(file)
>>
>> find . -name "\.py" | xargs compile.py
>>
>>
>> For the general case [in trunk], I think I have to start considering
>> splitting the Python source files and Python byte-compiled files into
>> 2 package types.
>> There was a older discussion about this ; the idea is to package the
>> byte coded files, and offer the sources and python source packages.
>> Example: Have `python` package and `python-sources`  package.
>> `python` == byte-compiled .pyc files, `python-sources` .py files
>>
>> Will try to make an effort in the next couple of days to implement the
>> general solution for this.
>> But, it's Friday now here, and I usually don't do much in the weekend.
>> So, hopefully next week I could allocate some time for this.
>>
>> Thanks
>> Alex
>>
>> On Fri, Feb 17, 2017 at 9:42 AM, Xuebing Wang <xbi...@gmail.com> wrote:
>>>
>>> Hi Alex,
>>>
>>> Thanks a lot for your help.  I am using Python 2.7.12, branch
>>> chaos_calmer
>>> from (git://github.com/openwrt/openwrt.git), feeds branch is for-15.05.
>>>
>>> Also, I am using Atheros platform based on MIPS architecture.
>>>
>>> Thanks again.
>>>
>>> xuebing wang
>>>
>>>
>>> On 2017年02月17日 15:31, Alexandru Ardelean wrote:
>>>>
>>>> Oh.
>>>>
>>>> This is an old topic.
>>>> Let me think about it, for a bit.
>>>>
>>>> Quick q: which Python version are you using and from which repo/branch ?
>>>> I usually test against trunk.
>>>>
>>>> Thanks
>>>> Alex
>>>>
>>>> On Fri, Feb 17, 2017 at 8:40 AM, Xuebing Wang <xbi...@gmail.com> wrote:
>>>>>
>>>>> Hi Community and Alexandru:
>>>>>
>>>>> I am using OpenWrt chaos_calmer for an Atheros based platform, we have
>>>>> a
>>>>> complicated Python application which takes time to run.
>>>>> - On the target board, I can "python -m compileall ." for Python
>>>>> standard
>>>>> libraries in directories "/usr/lib/python2.7", and boot time can
>>>>> improve
>>>>> significantly.
>>>>>
>>>>> Would you please advise how can I change in files
>>>>> feeds/packages/lang/python
>>>>> to byte-compile Python libraries and include .pyc files in the
>>>>> sysupgrade
>>>>> image?
>>>>>
>>>>> I am using below packages:
>>>>> CONFIG_PACKAGE_python-base=y
>>>>> CONFIG_PACKAGE_python-light=y
>>>>> CONFIG_PACKAGE_python-codecs=y
>>>>> CONFIG_PACKAGE_python-openssl=y
>>>>> CONFIG_PACKAGE_python-sqlite3=y
>>>>> CONFIG_PACKAGE_python-logging=y
>>>>>
>>>>> Thanks.
>>>>> xuebing wang
>>>>>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWRT: how to include byte-compile .pyc files into sysupgrade image?

[Alexandru Ardelean]

@Xuebing: so, there doesn't seem to be a very easy way to do this at build time.
I mean, at first, it can seem easy, because all that is needed, is to
add script that compiles here:
https://github.com/openwrt/packages/blob/for-15.05/lang/python/files/python-package.mk#L94

That script needs to recursively compile all .py files and
[optionally]  remove them.
So, feel free to try/hack something for your case.

Maybe a shell script that uses this: http://effbot.org/zone/python-compile.htm

> compile.py
import os
import sys
import py_compile
for file in sys.argv:
py_compile.compile(file)
os.remove(file)

find . -name "\.py" | xargs compile.py


For the general case [in trunk], I think I have to start considering
splitting the Python source files and Python byte-compiled files into
2 package types.
There was a older discussion about this ; the idea is to package the
byte coded files, and offer the sources and python source packages.
Example: Have `python` package and `python-sources`  package.
`python` == byte-compiled .pyc files, `python-sources` .py files

Will try to make an effort in the next couple of days to implement the
general solution for this.
But, it's Friday now here, and I usually don't do much in the weekend.
So, hopefully next week I could allocate some time for this.

Thanks
Alex

On Fri, Feb 17, 2017 at 9:42 AM, Xuebing Wang <xbi...@gmail.com> wrote:
> Hi Alex,
>
> Thanks a lot for your help.  I am using Python 2.7.12, branch chaos_calmer
> from (git://github.com/openwrt/openwrt.git), feeds branch is for-15.05.
>
> Also, I am using Atheros platform based on MIPS architecture.
>
> Thanks again.
>
> xuebing wang
>
>
> On 2017年02月17日 15:31, Alexandru Ardelean wrote:
>>
>> Oh.
>>
>> This is an old topic.
>> Let me think about it, for a bit.
>>
>> Quick q: which Python version are you using and from which repo/branch ?
>> I usually test against trunk.
>>
>> Thanks
>> Alex
>>
>> On Fri, Feb 17, 2017 at 8:40 AM, Xuebing Wang <xbi...@gmail.com> wrote:
>>>
>>> Hi Community and Alexandru:
>>>
>>> I am using OpenWrt chaos_calmer for an Atheros based platform, we have a
>>> complicated Python application which takes time to run.
>>> - On the target board, I can "python -m compileall ." for Python standard
>>> libraries in directories "/usr/lib/python2.7", and boot time can improve
>>> significantly.
>>>
>>> Would you please advise how can I change in files
>>> feeds/packages/lang/python
>>> to byte-compile Python libraries and include .pyc files in the sysupgrade
>>> image?
>>>
>>> I am using below packages:
>>> CONFIG_PACKAGE_python-base=y
>>> CONFIG_PACKAGE_python-light=y
>>> CONFIG_PACKAGE_python-codecs=y
>>> CONFIG_PACKAGE_python-openssl=y
>>> CONFIG_PACKAGE_python-sqlite3=y
>>> CONFIG_PACKAGE_python-logging=y
>>>
>>> Thanks.
>>> xuebing wang
>>>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWRT: how to include byte-compile .pyc files into sysupgrade image?

[Alexandru Ardelean]

Oh.

This is an old topic.
Let me think about it, for a bit.

Quick q: which Python version are you using and from which repo/branch ?
I usually test against trunk.

Thanks
Alex

On Fri, Feb 17, 2017 at 8:40 AM, Xuebing Wang  wrote:
> Hi Community and Alexandru:
>
> I am using OpenWrt chaos_calmer for an Atheros based platform, we have a
> complicated Python application which takes time to run.
> - On the target board, I can "python -m compileall ." for Python standard
> libraries in directories "/usr/lib/python2.7", and boot time can improve
> significantly.
>
> Would you please advise how can I change in files feeds/packages/lang/python
> to byte-compile Python libraries and include .pyc files in the sysupgrade
> image?
>
> I am using below packages:
> CONFIG_PACKAGE_python-base=y
> CONFIG_PACKAGE_python-light=y
> CONFIG_PACKAGE_python-codecs=y
> CONFIG_PACKAGE_python-openssl=y
> CONFIG_PACKAGE_python-sqlite3=y
> CONFIG_PACKAGE_python-logging=y
>
> Thanks.
> xuebing wang
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] dnscrypt-proxy package missing in snapshot

[Alexandru Ardelean]

If I got this correctly it's broken for that target as well

http://buildbot.openwrt.org:8010/broken_packages/ramips.mt7620/

It looks like an issue with the source tar ball not being present in any
OpenWrt mirror.

Well, that was the error when it tried to build.
Looks like dnscrypt-proxy was updated on the 7th of Feb 2017.

No idea how the artifact caching works on OpenWrt buildbot.

But, it could be that the issue may resolve itself, after triggering a
rebuild.
It doesn't look like it failed on all targets.


On Sat, 11 Feb 2017 at 14:14, Mangesh Bhamre <mang...@opennetware.com>
wrote:

> Hi Alex,
>
> ramips architecture. Mt7620 make file.
>
> Regards
> Mangesh
>
> On 11-Feb-2017 4:56 PM, "Alexandru Ardelean" <ardeleana...@gmail.com>
> wrote:
>
> Hey Mangesh,
>
> So, I don't use much ImageBuilder.
> I don't even know how that works.
>
> I usually just do
>
> < get OpenWrt repo >
> ./scripts/feeds update packages
> ./scripts/feeds install -a
> make menuconfig
> < select packages I need, configure arch, etc >
> make V=99 -j8
> < extract image from the bin directory >
>
> Looking through
> https://github.com/openwrt/packages/tree/master/net/dnscrypt-proxy
> It looks like dnscrypt-proxy should be there.
> But that's just the Makefile that builds the package.
>
> Does ImageBuilder install pre-built packages from an OpenWrt mirror ?
> Because on some architectures, dnscrypt-proxy looks broken.
>
> Example:
> http://buildbot.openwrt.org:8010/broken_packages/mpc85xx/
> http://buildbot.openwrt.org:8010/broken_packages/kirkwood/
> http://buildbot.openwrt.org:8010/broken_packages/bcm53xx/
> http://buildbot.openwrt.org:8010/broken_packages/ar71xx.mikrotik/
> http://buildbot.openwrt.org:8010/broken_packages/adm8668/
>
> On which architecture are you trying to build ?
> I understand you're trying to build on CC 15.05.1
>
> So, a bit more info about your setup could help.
>
>
> On Sat, Feb 11, 2017 at 7:35 AM, Mangesh Bhamre <mang...@opennetware.com>
> wrote:
> > Hi Alex and OpenWRT Team,
> >
> > Any help on getting  dnscrypt-proxy package into snapshot will be
> helpful.
> > It is working fine with 15.05.1 - but not snapshot ImageBuilder.
> >
> > Regards,
> > Mangesh Bhamre
> >
> > On Tue, Feb 7, 2017 at 10:32 PM, Mangesh Bhamre <mang...@opennetware.com
> >
> > wrote:
> >>
> >> Hi Alex,
> >>
> >> Snapshot don't have any reference of 'dnscrypt-proxy'. It is supported
> in
> >> CC 15.05.1 and I am able to add 'dnscrypt-proxy' in list of packages to
> >> include while building with CC Image-builder.
> >>
> >> I scanned through all snapshot image-builder and no reference there. I
> run
> >> following command to build - same works fine for CC 15.05.1
> >>
> >> make image PROFILE=Default PACKAGES="-wpad-mini wpad luci curl
> >> ca-certificates dnscrypt-proxy" FILES=/home/mangesh/files
> >>
> >> Surely no typo there.
> >>
> >> Regards,
> >> Mangesh
> >>
> >>
> >> On Tue, Feb 7, 2017 at 10:23 PM, Alexandru Ardelean
> >> <ardeleana...@gmail.com> wrote:
> >>>
> >>> Do you have a Package/dnscrypt-proxy/install rule ?
> >>> Are you calling the BuildPackage rule ?
> >>>
> >>> Do you have Package/dnscrypt-proxy/description rule ?
> >>>
> >>> And check for typos if above stuff is checked.
> >>>
> >>> Thanks
> >>> Alex
> >>>
> >>>
> >>> On Tue, 7 Feb 2017 at 18:21, Mangesh Bhamre <mang...@opennetware.com>
> >>> wrote:
> >>>>
> >>>> Hello OpenWRT team,
> >>>>
> >>>> I wish to bundle dnscrypt-proxy package using latest snapshot
> >>>> Image-builder. I get below errors. Please recommend a fix or address
> it in
> >>>> snapshot.
> >>>>
> >>>> Collected errors:
> >>>>  * opkg_install_cmd: Cannot install package dnscrypt-proxy.
> >>>> Makefile:146: recipe for target 'package_install' failed
> >>>>
> >>>> Regards,
> >>>> Mangesh
> >>>> ___
> >>>> openwrt-devel mailing list
> >>>> openwrt-devel@lists.openwrt.org
> >>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> >>
> >>
> >
>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] dnscrypt-proxy package missing in snapshot

[Alexandru Ardelean]

Do you have a Package/dnscrypt-proxy/install rule ?
Are you calling the BuildPackage rule ?

Do you have Package/dnscrypt-proxy/description rule ?

And check for typos if above stuff is checked.

Thanks
Alex


On Tue, 7 Feb 2017 at 18:21, Mangesh Bhamre  wrote:

> Hello OpenWRT team,
>
> I wish to bundle dnscrypt-proxy package using latest snapshot
> Image-builder. I get below errors. Please recommend a fix or address it in
> snapshot.
>
> Collected errors:
>  * opkg_install_cmd: Cannot install package dnscrypt-proxy.
> Makefile:146: recipe for target 'package_install' failed
>
> Regards,
> Mangesh
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] python ctypes.util.find_library cannot find libc

[Alexandru Ardelean]

Cool.

Then, a fix I'm proposing to LEDE, and will also spin up a PR for OpenWrt:
https://github.com/lede-project/source/pull/722/commits/6e0844540355c89e7f39504db374278d1c6cf05c

Feel free to use it.
It should apply on top of OpenWrt.
Though, be aware ; it's not yet been discussed whether this method is
completely sane.

I'm hoping some sort of elegant solution will come out of that.
In the worst case, you'll need to patch python-iptables [ add a patch
in python-iptables' folder ] to use /usr/sbin/modprobe directly.

Which may not be a bad idea either.
I think it may come down to preferences.

In any case, since it's not a issue with Python, I'll just keep an eye
on that PR, and update OpenWrt if needed.

Thanks
Alex



On Thu, Jan 19, 2017 at 8:20 PM, Andrew McConachie <and...@depht.com> wrote:
> Hi Alexandru,
>
> Yes, I'm sorry I didn't respond earlier. Having the correct binary location
> in /proc/sys/kernel/modprobe resolves any problems with python-iptables.
> It's really just a problem with the kernel not populating that file
> correctly.
>
> Thanks,
> Andrew
>
>
> On 1/19/17 11:49, Alexandru Ardelean wrote:
>>
>> I'm pretty sure the driver was selected.
>> I'll try to check a bit more in-depth.
>>
>> In the meantime, did you try the
>>
>>
>> echo /usr/sbin/modprobe > /proc/sys/kernel/modprobe
>>
>>
>> ?
>>
>>
>> On Thu, Jan 19, 2017 at 4:07 PM, Andrew McConachie <and...@depht.com>
>> wrote:
>>>
>>> Hi Alexandru,
>>>
>>> You're missing some kernel hardware driver. I'm not sure if the default
>>> compile options include kernel drivers for all HDDs, or for SATA/AHCI.
>>> You
>>> probably just need to include some extra kernel drivers in make
>>> menuconfig.
>>>
>>> --Andrew
>>>
>>>
>>> On 1/19/17 04:31, Alexandru Ardelean wrote:
>>>>
>>>> Hey,
>>>>
>>>> So, I've tried to run  an OpenWrt system, x86_64,
>>>>
>>>>
>>>> https://github.com/openwrt/openwrt/commit/4e53a6e9c560b54361f9ed3639e8d12f9ab8939d
>>>>
>>>> It was hanging on boot.
>>>> I've ran in Virtual Machine Manager with QEMU/KVM.
>>>> HDD emulation is SATA/AHCI [ I checked it's SATA/AHCI ]
>>>>
>>>> It looks to me that it's hanging at  trying to mount root device
>>>> /dev/mtdblock0
>>>> Any thoughts ?
>>>>
>>>> [1.213897] ata4: SATA link down (SStatus 0 SControl 300)
>>>> [1.214781] ata2: SATA link down (SStatus 0 SControl 300)
>>>> [1.215572] ata6: SATA link down (SStatus 0 SControl 300)
>>>> [1.216359] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>>> [1.217229] ata1.00: ATA-7: QEMU HARDDISK, 2.3.1, max UDMA/100
>>>> [1.217976] ata1.00: 31233 sectors, multi 16: LBA48 NCQ (depth 31/32)
>>>> [1.218787] ata1.00: applying bridge limits
>>>> [1.233284] ata1.00: configured for UDMA/100
>>>> [1.234233] ata5: SATA link down (SStatus 0 SControl 300)
>>>> [1.235915] ata3: SATA link down (SStatus 0 SControl 300)
>>>> [1.237371] scsi 0:0:0:0: Direct-Access ATA  QEMU HARDDISK
>>>> 1PQ: 0 ANSI: 5
>>>> [1.239155] sd 0:0:0:0: [sda] 31233 512-byte logical blocks: (16.0
>>>> MB/15.3 MiB)
>>>> [1.241487] sd 0:0:0:0: [sda] Write Protect is off
>>>> [1.242882] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
>>>> enabled, doesn't support DPO or FUA
>>>> [1.245329]  sda: sda1 sda2
>>>> [1.245887] sda: p2 size 262144 extends beyond EOD, enabling native
>>>> capacity
>>>> [1.247232]  sda: sda1 sda2
>>>> [1.247784] sda: p2 size 262144 extends beyond EOD, truncated
>>>> [1.248864] sd 0:0:0:0: [sda] Attached SCSI disk
>>>> [1.256721] block2mtd: erasesize must be a divisor of device size
>>>> [1.259958] rtc_cmos 00:00: setting system clock to 2017-01-19
>>>> 09:27:33 UTC (1484818053)
>>>> [1.261388] Waiting for root device /dev/mtdblock0...
>>>>
>>>> On Wed, Jan 18, 2017 at 6:05 PM, Alexandru Ardelean
>>>> <ardeleana...@gmail.com> wrote:
>>>>>
>>>>> Hey,
>>>>>
>>>>> So, if you try on the system.
>>>>>
>>>>> echo /usr/sbin/modprobe > /proc/sys/kernel/modprobe
>>>>>
>>>>> Does it work ? I mean to just  import iptc ?
>>>>

Re: [OpenWrt-Devel] python ctypes.util.find_library cannot find libc

[Alexandru Ardelean]

I'm pretty sure the driver was selected.
I'll try to check a bit more in-depth.

In the meantime, did you try the


echo /usr/sbin/modprobe > /proc/sys/kernel/modprobe


?


On Thu, Jan 19, 2017 at 4:07 PM, Andrew McConachie <and...@depht.com> wrote:
> Hi Alexandru,
>
> You're missing some kernel hardware driver. I'm not sure if the default
> compile options include kernel drivers for all HDDs, or for SATA/AHCI. You
> probably just need to include some extra kernel drivers in make menuconfig.
>
> --Andrew
>
>
> On 1/19/17 04:31, Alexandru Ardelean wrote:
>>
>> Hey,
>>
>> So, I've tried to run  an OpenWrt system, x86_64,
>>
>> https://github.com/openwrt/openwrt/commit/4e53a6e9c560b54361f9ed3639e8d12f9ab8939d
>>
>> It was hanging on boot.
>> I've ran in Virtual Machine Manager with QEMU/KVM.
>> HDD emulation is SATA/AHCI [ I checked it's SATA/AHCI ]
>>
>> It looks to me that it's hanging at  trying to mount root device
>> /dev/mtdblock0
>> Any thoughts ?
>>
>> [1.213897] ata4: SATA link down (SStatus 0 SControl 300)
>> [1.214781] ata2: SATA link down (SStatus 0 SControl 300)
>> [1.215572] ata6: SATA link down (SStatus 0 SControl 300)
>> [1.216359] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>> [1.217229] ata1.00: ATA-7: QEMU HARDDISK, 2.3.1, max UDMA/100
>> [1.217976] ata1.00: 31233 sectors, multi 16: LBA48 NCQ (depth 31/32)
>> [1.218787] ata1.00: applying bridge limits
>> [1.233284] ata1.00: configured for UDMA/100
>> [1.234233] ata5: SATA link down (SStatus 0 SControl 300)
>> [1.235915] ata3: SATA link down (SStatus 0 SControl 300)
>> [1.237371] scsi 0:0:0:0: Direct-Access ATA  QEMU HARDDISK
>>1PQ: 0 ANSI: 5
>> [1.239155] sd 0:0:0:0: [sda] 31233 512-byte logical blocks: (16.0
>> MB/15.3 MiB)
>> [1.241487] sd 0:0:0:0: [sda] Write Protect is off
>> [1.242882] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
>> enabled, doesn't support DPO or FUA
>> [1.245329]  sda: sda1 sda2
>> [1.245887] sda: p2 size 262144 extends beyond EOD, enabling native
>> capacity
>> [1.247232]  sda: sda1 sda2
>> [1.247784] sda: p2 size 262144 extends beyond EOD, truncated
>> [1.248864] sd 0:0:0:0: [sda] Attached SCSI disk
>> [    1.256721] block2mtd: erasesize must be a divisor of device size
>> [1.259958] rtc_cmos 00:00: setting system clock to 2017-01-19
>> 09:27:33 UTC (1484818053)
>> [1.261388] Waiting for root device /dev/mtdblock0...
>>
>> On Wed, Jan 18, 2017 at 6:05 PM, Alexandru Ardelean
>> <ardeleana...@gmail.com> wrote:
>>>
>>> Hey,
>>>
>>> So, if you try on the system.
>>>
>>> echo /usr/sbin/modprobe > /proc/sys/kernel/modprobe
>>>
>>> Does it work ? I mean to just  import iptc ?
>>> It worked for me, but I tried on a LEDE system (x86_64), which I'm
>>> hoping may be similar to OpenWrt.
>>>
>>> For me, the part that interests me the most, is if this is a bug
>>> within Python [ since I maintain it ], and it runs on both LEDE &
>>> OpenWrt.
>>>
>>> Will try to spin up a OpenWrt [just cloned trunk from Github ].
>>>
>>> And I'll try to reproduce.
>>> For reference ; Python is version 2.7.13
>>> It's from here: https://github.com/openwrt/packages
>>>
>>> I could not find hash 5ba298c   in OpenWrt [
>>> https://github.com/openwrt/openwrt ]  nor in packages [ link above ].
>>>
>>> Will come back with findings for OpenWrt.
>>>
>>> In the meantime, I will see about proposing a solution for updating
>>> /proc/sys/kernel/modprobe   correctly for both LEDE & OpenWrt.
>>>
>>> Thanks
>>> Alex
>>>
>>>
>>>
>>> On Wed, Jan 18, 2017 at 4:38 PM, Andrew McConachie <and...@depht.com>
>>> wrote:
>>>>
>>>> Hi 郭涛 and Alexandru,
>>>>
>>>> ldconfig depends on using eglibc to fulfill libc requirement.
>>>>
>>>> Symbol: PACKAGE_ldconfig [=n]
>>>> Type  : tristate
>>>> Prompt: ldconfig... Shared library path
>>>> configuration
>>>> Location:
>>>> (3) -> Utilities
>>>> Defined at tmp/.config-package.in:82365
>>>> Depends on: !USE_MUSL [=y]
>>>>
>>>> If we make python depend on ldconfig, then are we saying python cannot
>>>> be
>>>> used with MUSL libc? I don't

Re: [OpenWrt-Devel] python ctypes.util.find_library cannot find libc

[Alexandru Ardelean]

Hey,

So, I've tried to run  an OpenWrt system, x86_64,
https://github.com/openwrt/openwrt/commit/4e53a6e9c560b54361f9ed3639e8d12f9ab8939d

It was hanging on boot.
I've ran in Virtual Machine Manager with QEMU/KVM.
HDD emulation is SATA/AHCI [ I checked it's SATA/AHCI ]

It looks to me that it's hanging at  trying to mount root device  /dev/mtdblock0
Any thoughts ?

[1.213897] ata4: SATA link down (SStatus 0 SControl 300)
[1.214781] ata2: SATA link down (SStatus 0 SControl 300)
[1.215572] ata6: SATA link down (SStatus 0 SControl 300)
[1.216359] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[1.217229] ata1.00: ATA-7: QEMU HARDDISK, 2.3.1, max UDMA/100
[1.217976] ata1.00: 31233 sectors, multi 16: LBA48 NCQ (depth 31/32)
[1.218787] ata1.00: applying bridge limits
[1.233284] ata1.00: configured for UDMA/100
[1.234233] ata5: SATA link down (SStatus 0 SControl 300)
[1.235915] ata3: SATA link down (SStatus 0 SControl 300)
[1.237371] scsi 0:0:0:0: Direct-Access ATA  QEMU HARDDISK
  1PQ: 0 ANSI: 5
[1.239155] sd 0:0:0:0: [sda] 31233 512-byte logical blocks: (16.0
MB/15.3 MiB)
[1.241487] sd 0:0:0:0: [sda] Write Protect is off
[1.242882] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[1.245329]  sda: sda1 sda2
[1.245887] sda: p2 size 262144 extends beyond EOD, enabling native capacity
[1.247232]  sda: sda1 sda2
[1.247784] sda: p2 size 262144 extends beyond EOD, truncated
[1.248864] sd 0:0:0:0: [sda] Attached SCSI disk
[1.256721] block2mtd: erasesize must be a divisor of device size
[1.259958] rtc_cmos 00:00: setting system clock to 2017-01-19
09:27:33 UTC (1484818053)
[1.261388] Waiting for root device /dev/mtdblock0...

On Wed, Jan 18, 2017 at 6:05 PM, Alexandru Ardelean
<ardeleana...@gmail.com> wrote:
> Hey,
>
> So, if you try on the system.
>
> echo /usr/sbin/modprobe > /proc/sys/kernel/modprobe
>
> Does it work ? I mean to just  import iptc ?
> It worked for me, but I tried on a LEDE system (x86_64), which I'm
> hoping may be similar to OpenWrt.
>
> For me, the part that interests me the most, is if this is a bug
> within Python [ since I maintain it ], and it runs on both LEDE &
> OpenWrt.
>
> Will try to spin up a OpenWrt [just cloned trunk from Github ].
>
> And I'll try to reproduce.
> For reference ; Python is version 2.7.13
> It's from here: https://github.com/openwrt/packages
>
> I could not find hash 5ba298c   in OpenWrt [
> https://github.com/openwrt/openwrt ]  nor in packages [ link above ].
>
> Will come back with findings for OpenWrt.
>
> In the meantime, I will see about proposing a solution for updating
> /proc/sys/kernel/modprobe   correctly for both LEDE & OpenWrt.
>
> Thanks
> Alex
>
>
>
> On Wed, Jan 18, 2017 at 4:38 PM, Andrew McConachie <and...@depht.com> wrote:
>> Hi 郭涛 and Alexandru,
>>
>> ldconfig depends on using eglibc to fulfill libc requirement.
>>
>> Symbol: PACKAGE_ldconfig [=n]
>> Type  : tristate
>> Prompt: ldconfig... Shared library path
>> configuration
>> Location:
>> (3) -> Utilities
>> Defined at tmp/.config-package.in:82365
>> Depends on: !USE_MUSL [=y]
>>
>> If we make python depend on ldconfig, then are we saying python cannot be
>> used with MUSL libc? I don't know what the default libc is for OpenWRT or
>> whether one is considered experimental more than the other. But this is
>> something to consider.
>>
>> Thanks,
>> Andrew
>>
>>
>> On 1/18/17 03:32, 郭涛 wrote:
>>>
>>> Hi Andrew & Alexandru
>>>
>>> Forget the patch in prev mail, use attached patch instead.
>>>
>>> To use ctypes.util.find_library, you need one of gcc, ldconfig or
>>> objdump. I suggest you use ldconfig
>>>
>>> After install ldconfig,  run ldconfig first to update cache
>>> then run ldconfig -p to show all of your libraries
>>> in my case, it shows:
>>>
>>> 195 libs found in cache `/etc/ld.so.cache' (version 1.7.0)
>>>  uhttpd_tls.so (libc0) => /usr/lib/uhttpd_tls.so
>>>  rclibrary.so (libc0) => /usr/lib/rclibrary.so
>>>  libz.so.1 (libc0) => /usr/lib/libz.so.1
>>>  libz.so (libc0) => /usr/lib/libz.so
>>>  libyaml-0.so.2 (libc0) => /usr/lib/libyaml-0.so.2
>>>  ..
>>>
>>> All libraries are libc0, that's why ctypes.util.find_library does not
>>> work on my platform
>>>
>>> You need to run 'uname -m' to get your matchine name and run 'ldconfig
>>> -p' to get library type

Re: [OpenWrt-Devel] python ctypes.util.find_library cannot find libc

[Alexandru Ardelean]

Hey,

So, if you try on the system.

echo /usr/sbin/modprobe > /proc/sys/kernel/modprobe

Does it work ? I mean to just  import iptc ?
It worked for me, but I tried on a LEDE system (x86_64), which I'm
hoping may be similar to OpenWrt.

For me, the part that interests me the most, is if this is a bug
within Python [ since I maintain it ], and it runs on both LEDE &
OpenWrt.

Will try to spin up a OpenWrt [just cloned trunk from Github ].

And I'll try to reproduce.
For reference ; Python is version 2.7.13
It's from here: https://github.com/openwrt/packages

I could not find hash 5ba298c   in OpenWrt [
https://github.com/openwrt/openwrt ]  nor in packages [ link above ].

Will come back with findings for OpenWrt.

In the meantime, I will see about proposing a solution for updating
/proc/sys/kernel/modprobe   correctly for both LEDE & OpenWrt.

Thanks
Alex



On Wed, Jan 18, 2017 at 4:38 PM, Andrew McConachie <and...@depht.com> wrote:
> Hi 郭涛 and Alexandru,
>
> ldconfig depends on using eglibc to fulfill libc requirement.
>
> Symbol: PACKAGE_ldconfig [=n]
> Type  : tristate
> Prompt: ldconfig... Shared library path
> configuration
> Location:
> (3) -> Utilities
> Defined at tmp/.config-package.in:82365
> Depends on: !USE_MUSL [=y]
>
> If we make python depend on ldconfig, then are we saying python cannot be
> used with MUSL libc? I don't know what the default libc is for OpenWRT or
> whether one is considered experimental more than the other. But this is
> something to consider.
>
> Thanks,
> Andrew
>
>
> On 1/18/17 03:32, 郭涛 wrote:
>>
>> Hi Andrew & Alexandru
>>
>> Forget the patch in prev mail, use attached patch instead.
>>
>> To use ctypes.util.find_library, you need one of gcc, ldconfig or
>> objdump. I suggest you use ldconfig
>>
>> After install ldconfig,  run ldconfig first to update cache
>> then run ldconfig -p to show all of your libraries
>> in my case, it shows:
>>
>> 195 libs found in cache `/etc/ld.so.cache' (version 1.7.0)
>>  uhttpd_tls.so (libc0) => /usr/lib/uhttpd_tls.so
>>  rclibrary.so (libc0) => /usr/lib/rclibrary.so
>>  libz.so.1 (libc0) => /usr/lib/libz.so.1
>>  libz.so (libc0) => /usr/lib/libz.so
>>  libyaml-0.so.2 (libc0) => /usr/lib/libyaml-0.so.2
>>  ..
>>
>> All libraries are libc0, that's why ctypes.util.find_library does not
>> work on my platform
>>
>> You need to run 'uname -m' to get your matchine name and run 'ldconfig
>> -p' to get library type.
>> Atter all, append  '$machine' : '$type'  to  mach_map list in
>> ctypes/util.py and try find_library('pthread')
>>
>>
>>>>> from ctypes.util import find_library
>>>>>
>>>>> find_library('pthread')
>>
>> 'libpthread.so.0'
>>
>>
>>
>>
>>
>>
>> 2017-01-17 22:22 GMT+08:00 Alexandru Ardelean <ardeleana...@gmail.com>:
>>>
>>> Will give it a try.
>>>
>>> On Mon, Jan 16, 2017 at 9:41 PM, Andrew McConachie <and...@depht.com>
>>> wrote:
>>>>
>>>> Hi Alexandru and 郭涛,
>>>>
>>>> Attached is the Makefile I made for python-iptables. I can work around
>>>> this
>>>> by hardwiring library locations in the source of python-iptables, but
>>>> I'd
>>>> rather do it the correct way. To reproduce this build an OpenWrt system
>>>> with
>>>> this Makefile and then just create a simple Python script with 'import
>>>> iptc'.
>>>>
>>>> I am cloning OpenWrt from Github and running make menuconfig;make to
>>>> build
>>>> everything. My Github version is about 6 days old with the last commit
>>>> at
>>>> 5ba298c.
>>>>
>>>> I also found that /proc/sys/kernel/modprobe contains /sbin/modprobe,
>>>> while
>>>> the modprobe binary is at /usr/sbin/modprobe. According to the Debian
>>>> man
>>>> page on proc(5), /proc/sys/kernel/modprobe should point to the modprobe
>>>> binary. Googling about seems also to suggest that this file should
>>>> contain
>>>> the location of the modprobe binary. So I would say this is also a bug.
>>>>
>>>> Thanks!
>>>> --Andrew
>>>>
>>>>
>>>> On 1/16/17 07:23, Alexandru Ardelean wrote:
>>>>>
>>>>> Hey Andrew & 郭涛
>>>>>
>>>>> Sorry I did not answer sooner.
>>>>>
>

Re: [OpenWrt-Devel] python ctypes.util.find_library cannot find libc

[Alexandru Ardelean]

Will give it a try.

On Mon, Jan 16, 2017 at 9:41 PM, Andrew McConachie <and...@depht.com> wrote:
> Hi Alexandru and 郭涛,
>
> Attached is the Makefile I made for python-iptables. I can work around this
> by hardwiring library locations in the source of python-iptables, but I'd
> rather do it the correct way. To reproduce this build an OpenWrt system with
> this Makefile and then just create a simple Python script with 'import
> iptc'.
>
> I am cloning OpenWrt from Github and running make menuconfig;make to build
> everything. My Github version is about 6 days old with the last commit at
> 5ba298c.
>
> I also found that /proc/sys/kernel/modprobe contains /sbin/modprobe, while
> the modprobe binary is at /usr/sbin/modprobe. According to the Debian man
> page on proc(5), /proc/sys/kernel/modprobe should point to the modprobe
> binary. Googling about seems also to suggest that this file should contain
> the location of the modprobe binary. So I would say this is also a bug.
>
> Thanks!
> --Andrew
>
>
> On 1/16/17 07:23, Alexandru Ardelean wrote:
>>
>> Hey Andrew & 郭涛
>>
>> Sorry I did not answer sooner.
>>
>> @Andrew: do you have a Makefile for the python-iptables packages ?
>> I'd like to try to build it and see the issue. Or, are you just using
>> that .py file ?
>> Can you give a bit more input on which Python version you're using,
>> and which OpenWrt version?
>>
>> If the issue is still present in the current packages trunk, I'd like to
>> fix it.
>> And if  郭涛's fix works, we can apply it to trunk.
>>
>> Thanks
>> Alex
>>
>>
>> On Mon, Jan 16, 2017 at 6:23 AM, 郭涛 <guotao...@gmail.com> wrote:
>>>
>>> I also meet this issue.
>>> I fixed it using below change
>>>
>>>
>>> https://github.com/gt945/Netgear-D7800-Openwrt-Packages/commit/fab71ca0ebf36d5f7b495b96f14d459e794b7224
>>>
>>>
>>> 2017-01-13 0:43 GMT+08:00 Andrew McConachie <and...@depht.com>:
>>>>
>>>> Hi OpenWRT Devs,
>>>>
>>>> I'm building an OpenWRT package for python-iptables for a project I'm
>>>> working on and getting this error message when attempting to use it.
>>>>
>>>>  import iptc
>>>>File "/usr/lib/python2.7/site-packages/iptc/__init__.py", line 10, in
>>>> 
>>>>  from ip4tc import (is_table_available, Table, Chain, Rule, Match,
>>>> Target,
>>>>File "/usr/lib/python2.7/site-packages/iptc/ip4tc.py", line 13, in
>>>> 
>>>>  from xtables import (XT_INV_PROTO, NFPROTO_IPV4, XTablesError,
>>>> xtables,
>>>>File "/usr/lib/python2.7/site-packages/iptc/xtables.py", line 677, in
>>>> 
>>>>  _optind = ct.c_long.in_dll(_libc, "optind")
>>>> AttributeError: 'NoneType' object has no attribute '_handle'
>>>>
>>>> You can view xtables.py here if you're curious.
>>>> https://github.com/ldx/python-iptables/blob/master/iptc/xtables.py
>>>>
>>>> The problem is that my python-iptables package cannot find libc
>>>> functions
>>>> using ctypes.util.find_library(). I've tried building OpenWRT using both
>>>> musl and eglibc but neither work. I've also tried building OpenWRT with
>>>> objdump and ldconfig. When I include ldconfig via 'make menuconfig' it
>>>> doesn't actually populate my OpenWRT image with an ldconfig binary.
>>>> Maybe
>>>> this is the problem?
>>>>
>>>> This bug report looks similar to my problem, but it's about MIPS and
>>>> marked
>>>> as closed.
>>>> https://dev.openwrt.org/ticket/20123
>>>>
>>>> Any help or pointers would be much appreciated.
>>>>
>>>> Thanks,
>>>> Andrew
>>>> ___
>>>> openwrt-devel mailing list
>>>> openwrt-devel@lists.openwrt.org
>>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>>
>>> ___
>>> openwrt-devel mailing list
>>> openwrt-devel@lists.openwrt.org
>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] python ctypes.util.find_library cannot find libc

[Alexandru Ardelean]

Hey Andrew & 郭涛

Sorry I did not answer sooner.

@Andrew: do you have a Makefile for the python-iptables packages ?
I'd like to try to build it and see the issue. Or, are you just using
that .py file ?
Can you give a bit more input on which Python version you're using,
and which OpenWrt version?

If the issue is still present in the current packages trunk, I'd like to fix it.
And if  郭涛's fix works, we can apply it to trunk.

Thanks
Alex


On Mon, Jan 16, 2017 at 6:23 AM, 郭涛  wrote:
> I also meet this issue.
> I fixed it using below change
>
> https://github.com/gt945/Netgear-D7800-Openwrt-Packages/commit/fab71ca0ebf36d5f7b495b96f14d459e794b7224
>
>
> 2017-01-13 0:43 GMT+08:00 Andrew McConachie :
>> Hi OpenWRT Devs,
>>
>> I'm building an OpenWRT package for python-iptables for a project I'm
>> working on and getting this error message when attempting to use it.
>>
>> import iptc
>>   File "/usr/lib/python2.7/site-packages/iptc/__init__.py", line 10, in
>> 
>> from ip4tc import (is_table_available, Table, Chain, Rule, Match,
>> Target,
>>   File "/usr/lib/python2.7/site-packages/iptc/ip4tc.py", line 13, in
>> 
>> from xtables import (XT_INV_PROTO, NFPROTO_IPV4, XTablesError, xtables,
>>   File "/usr/lib/python2.7/site-packages/iptc/xtables.py", line 677, in
>> 
>> _optind = ct.c_long.in_dll(_libc, "optind")
>> AttributeError: 'NoneType' object has no attribute '_handle'
>>
>> You can view xtables.py here if you're curious.
>> https://github.com/ldx/python-iptables/blob/master/iptc/xtables.py
>>
>> The problem is that my python-iptables package cannot find libc functions
>> using ctypes.util.find_library(). I've tried building OpenWRT using both
>> musl and eglibc but neither work. I've also tried building OpenWRT with
>> objdump and ldconfig. When I include ldconfig via 'make menuconfig' it
>> doesn't actually populate my OpenWRT image with an ldconfig binary. Maybe
>> this is the problem?
>>
>> This bug report looks similar to my problem, but it's about MIPS and marked
>> as closed.
>> https://dev.openwrt.org/ticket/20123
>>
>> Any help or pointers would be much appreciated.
>>
>> Thanks,
>> Andrew
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Problem building modules out-of-tree (kbuild) for x86

[Alexandru Ardelean]

On Mon, Dec 19, 2016 at 1:41 AM, Philip Prindeville
 wrote:
> Hi.
>
> I’m trying to add the Intel e1000e, igb, and ixgbe drivers that are on Source 
> Forge.
>
> A snapshot of my work is here:
>
> https://github.com/pprindeville/packages/tree/sf-ether
>
> When I build this as “make -j1 V=s” using a mostly unmodified x86_64 generic 
> configuration, I get:
>
>
>
> make[3]: Entering directory 
> `/home/philip/bertram/bmu-philip.sanity/openwrt/feeds/packages/kernel/e1000e'
> . /home/philip/bertram/bmu-philip.sanity/openwrt/include/shell.sh; gzip -dc 
> /home/philip/bertram/bmu-philip.sanity/openwrt/dl/e1000e-3.3.5.3.tar.gz | tar 
> -C 
> /home/philip/bertram/bmu-philip.sanity/openwrt/build_dir/target-x86_64_musl-1.1.15_powercode-bmu/linux-x86_64/e1000e-3.3.5.3/..
>  -xf -
> touch 
> /home/philip/bertram/bmu-philip.sanity/openwrt/build_dir/target-x86_64_musl-1.1.15_powercode-bmu/linux-x86_64/e1000e-3.3.5.3/.prepared_b318088b5b0515ca987313e94558d492
> rm -f 
> /home/philip/bertram/bmu-philip.sanity/openwrt/staging_dir/target-x86_64_musl-1.1.15_powercode-bmu/stamp/.e1000e_installed
> (cd 
> /home/philip/bertram/bmu-philip.sanity/openwrt/build_dir/target-x86_64_musl-1.1.15_powercode-bmu/linux-x86_64/e1000e-3.3.5.3/./;
>  if [ -x ./configure ]; then find 
> /home/philip/bertram/bmu-philip.sanity/openwrt/build_dir/target-x86_64_musl-1.1.15_powercode-bmu/linux-x86_64/e1000e-3.3.5.3/
>  -name config.guess | xargs -r chmod u+w; find 
> /home/philip/bertram/bmu-philip.sanity/openwrt/build_dir/target-x86_64_musl-1.1.15_powercode-bmu/linux-x86_64/e1000e-3.3.5.3/
>  -name config.guess | xargs -r -n1 cp --remove-destination 
> /home/philip/bertram/bmu-philip.sanity/openwrt/scripts/config.guess; find 
> /home/philip/bertram/bmu-philip.sanity/openwrt/build_dir/target-x86_64_musl-1.1.15_powercode-bmu/linux-x86_64/e1000e-3.3.5.3/
>  -name config.sub | xargs -r chmod u+w; find 
> /home/philip/bertram/bmu-philip.sanity/openwrt/build_dir/target-x86_64_musl-1.1.15_powercode-bmu/linux-x86_64/e1000e-3.3.5.3/
>  -name config.sub | xargs -r -n1 cp --remove-destination 
> /home/philip/bertram/bmu-philip.sanity/openwrt/scripts/config.sub; 
> AR="x86_64-openwrt-linux-musl-gcc-ar" AS="x86_64-openwrt-linux-musl-gcc -c 
> -Os -pipe -fno-caller-saves -fno-plt -fhonour-copts 
> -Wno-error=unused-but-set-variable -Wno-error=unused-result -iremap 
> /home/philip/bertram/bmu-philip.sanity/openwrt/build_dir/target-x86_64_musl-1.1.15_powercode-bmu/linux-x86_64/e1000e-3.3.5.3:e1000e-3.3.5.3
>  -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro" 
> LD=x86_64-openwrt-linux-musl-ld NM="x86_64-openwrt-linux-musl-gcc-nm" 
> CC="x86_64-openwrt-linux-musl-gcc" GCC="x86_64-openwrt-linux-musl-gcc" 
> CXX="x86_64-openwrt-linux-musl-g++" 
> RANLIB="x86_64-openwrt-linux-musl-gcc-ranlib" 
> STRIP=x86_64-openwrt-linux-musl-strip 
> OBJCOPY=x86_64-openwrt-linux-musl-objcopy 
> OBJDUMP=x86_64-openwrt-linux-musl-objdump SIZE=x86_64-openwrt-linux-musl-size 
> CFLAGS="-Os -pipe -fno-caller-saves -fno-plt -fhonour-copts 
> -Wno-error=unused-but-set-variable -Wno-error=unused-result -iremap 
> /home/philip/bertram/bmu-philip.sanity/openwrt/build_dir/target-x86_64_musl-1.1.15_powercode-bmu/linux-x86_64/e1000e-3.3.5.3:e1000e-3.3.5.3
>  -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro " 
> CXXFLAGS="-Os -pipe -fno-caller-saves -fno-plt -fhonour-copts 
> -Wno-error=unused-but-set-variable -Wno-error=unused-result -iremap 
> /home/philip/bertram/bmu-philip.sanity/openwrt/build_dir/target-x86_64_musl-1.1.15_powercode-bmu/linux-x86_64/e1000e-3.3.5.3:e1000e-3.3.5.3
>  -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro " 
> CPPFLAGS="-I/home/philip/bertram/bmu-philip.sanity/openwrt/staging_dir/target-x86_64_musl-1.1.15_powercode-bmu/usr/include
>  
> -I/home/philip/bertram/bmu-philip.sanity/openwrt/staging_dir/target-x86_64_musl-1.1.15_powercode-bmu/include
>  
> -I/home/philip/bertram/bmu-philip.sanity/openwrt/staging_dir/toolchain-x86_64_gcc-5.3.0_musl-1.1.15/usr/include
>  
> -I/home/philip/bertram/bmu-philip.sanity/openwrt/staging_dir/toolchain-x86_64_gcc-5.3.0_musl-1.1.15/include/fortify
>  
> -I/home/philip/bertram/bmu-philip.sanity/openwrt/staging_dir/toolchain-x86_64_gcc-5.3.0_musl-1.1.15/include
>  " 
> LDFLAGS="-L/home/philip/bertram/bmu-philip.sanity/openwrt/staging_dir/target-x86_64_musl-1.1.15_powercode-bmu/usr/lib
>  
> -L/home/philip/bertram/bmu-philip.sanity/openwrt/staging_dir/target-x86_64_musl-1.1.15_powercode-bmu/lib
>  
> -L/home/philip/bertram/bmu-philip.sanity/openwrt/staging_dir/toolchain-x86_64_gcc-5.3.0_musl-1.1.15/usr/lib
>  
> -L/home/philip/bertram/bmu-philip.sanity/openwrt/staging_dir/toolchain-x86_64_gcc-5.3.0_musl-1.1.15/lib
>  -znow -zrelro "   ./configure --target=x86_64-openwrt-linux 
> --host=x86_64-openwrt-linux --build=x86_64-linux-gnu --program-prefix="" 
> --program-suffix="" --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin 
> --sbindir=/usr/sbin 

Re: [OpenWrt-Devel] Unable to opkg install openvswitch

[Alexandru Ardelean]

On Tue, Jun 28, 2016 at 4:38 PM, Alexandru Ardelean
<ardeleana...@gmail.com> wrote:
> On Tue, Jun 28, 2016 at 4:29 PM, 조동규 <cho4...@gmail.com> wrote:
>> At first, i reset my router using tftp with ArcherC7v2_tp_recovery.bin file.
>> I set it internet works, and then I did opkg update and opkg install
>> openvswitch.
>>
>> then i saw that error message.
>>
>> FYI, here is a link that someone already asked, it looks similar with my
>> problem  but i couldn't find an answer.
>> https://dev.openwrt.org/ticket/22212
>>
>> Thanks
>> DongGyu Cho
>>
>>
>>
>> 2016-06-28 21:37 GMT+09:00 Alexandru Ardelean <ardeleana...@gmail.com>:
>>>
>>> On Tue, Jun 28, 2016 at 1:05 PM, 조동규 <cho4...@gmail.com> wrote:
>>> > Hi,
>>> >
>>> > I'm trying to install openvswitch on OpenWRT in Archer C7.
>>> >
>>> > When i try to install openvswitch, error message below had came up.
>>> >
>>> > Downloading
>>> >
>>> > http://downloads.openwrt.org/chaos_calmer/15.05.1/ar71xx/generic/packages/packages/kmod-openvswitch_3.18.21+2.3.90-58be9c9fd732b5bdd3d4c2e9b8cc2313f570094d_ar71xx.ipk.
>>> > Collected errors:
>>> >
>>> > satisfy_dependencies_for: Cannot satisfy the following dependencies for
>>> > kmod-openvswitch:
>>> > kernel (= 3.18.21-1-3d4bd113f3f10b8986a142b8792db9c5) *
>>> > opkg_install_cmd: Cannot install package kmod-openvswitch.
>>> >
>>> > root@OpenWrt:~#
>>> >
>>> >
>>> > How can i solve it? If anyone know, please let me know.
>>> >
>>> >
>>> > Regards,
>>> >
>>> > DongGyu Cho
>>> >
>>> >
>>> >
>>> > ___
>>> > openwrt-devel mailing list
>>> > openwrt-devel@lists.openwrt.org
>>> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>> >
>>>
>>> So, did you do a
>>>
>>> opkg update
>>>
>>> first ?
>>>
>>> Can you give tell me which command series did you try ?
>>>
>>> Thanks
>>> Alex
>>
>>
>
> Oh.
> Will check

It seems that the kernel version for OpenWrt 15.05.1 is 3.18.23.
While the OVS kernel module expects 3.18.21.

I just started reading more in-depth the tickets and that seems to be the case.
And it seems to be more kernel modules having this issue.

So, you either build OpenVswitch manually for CC, or you wait for a
re-spin of the CC release.
I cannot help out more on this, since I am only a package maintainer
for the OVS package.
I am not too involved in the big release process to help out more.

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

Re: [OpenWrt-Devel] Unable to opkg install openvswitch

[Alexandru Ardelean]

On Tue, Jun 28, 2016 at 1:05 PM, 조동규  wrote:
> Hi,
>
> I'm trying to install openvswitch on OpenWRT in Archer C7.
>
> When i try to install openvswitch, error message below had came up.
>
> Downloading
> http://downloads.openwrt.org/chaos_calmer/15.05.1/ar71xx/generic/packages/packages/kmod-openvswitch_3.18.21+2.3.90-58be9c9fd732b5bdd3d4c2e9b8cc2313f570094d_ar71xx.ipk.
> Collected errors:
>
> satisfy_dependencies_for: Cannot satisfy the following dependencies for
> kmod-openvswitch:
> kernel (= 3.18.21-1-3d4bd113f3f10b8986a142b8792db9c5) *
> opkg_install_cmd: Cannot install package kmod-openvswitch.
>
> root@OpenWrt:~#
>
>
> How can i solve it? If anyone know, please let me know.
>
>
> Regards,
>
> DongGyu Cho
>
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>

So, did you do a

opkg update

first ?

Can you give tell me which command series did you try ?

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

Re: [OpenWrt-Devel] [PATCH] target/linux/mpc85xx: fix talitos crypto driver init

[Alexandru Ardelean]

On Thu, Apr 28, 2016 at 6:18 PM, Jonas Eymann <j.eym...@gmx.net> wrote:

> Hi Alexandru,
>
> >
> > Crypto hash algorithms must provide the statesize for
> > kernel 4.2+
> >
> > Referencing commit in the kernel:
> >
> > commit 8996eafdcbad149ac0f772fb1649fbb75c482a6a
> > Author: Russell King <rmk+ker...@arm.linux.org.uk>
> > Date:   Fri Oct 9 20:43:33 2015 +0100
> >
> > crypto: ahash - ensure statesize is non-zero
> >
> > Unlike shash algorithms, ahash drivers must implement export
> > and import as their descriptors may contain hardware state and
> > cannot be exported as is.  Unfortunately some ahash drivers did
> > not provide them and end up causing crashes with algif_hash.
> >
> > This patch adds a check to prevent these drivers from registering
> > ahash algorithms until they are fixed.
> >
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Russell King <rmk+ker...@arm.linux.org.uk>
> > Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
> >
> > Signed-off-by: Alexandru Ardelean <ardeleana...@gmail.com>
> > ---
> >  .../302-add-statesize-to-talitos-crypto-driver.sh  | 100
> +
> >  1 file changed, 100 insertions(+)
> >  create mode 100644
> target/linux/mpc85xx/patches-4.4/302-add-statesize-to-talitos-crypto-driver.sh
> >
> > diff --git
> a/target/linux/mpc85xx/patches-4.4/302-add-statesize-to-talitos-crypto-driver.sh
> b/target/linux/mpc85xx/patches-4.4/302-add-statesize-to-talitos-crypto-driver.sh
> > new file mode 100644
> > index 000..4d77c19
> > --- /dev/null
> > +++
> b/target/linux/mpc85xx/patches-4.4/302-add-statesize-to-talitos-crypto-driver.sh
> > @@ -0,0 +1,100 @@
> > +diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
> > +index b6f9f42..b786b21 100644
> > +--- a/drivers/crypto/talitos.c
> >  b/drivers/crypto/talitos.c
> > +@@ -2334,6 +2334,7 @@ static struct talitos_alg_template driver_algs[]
> = {
> > + {   .type = CRYPTO_ALG_TYPE_AHASH,
> > + .alg.hash = {
> > + .halg.digestsize = MD5_DIGEST_SIZE,
> > ++.halg.statesize  = sizeof(struct
> talitos_ahash_req_ctx),
> > + .halg.base = {
> > + .cra_name = "md5",
> > + .cra_driver_name = "md5-talitos",
> > +@@ -2349,6 +2350,7 @@ static struct talitos_alg_template driver_algs[]
> = {
> > + {   .type = CRYPTO_ALG_TYPE_AHASH,
> > + .alg.hash = {
> > + .halg.digestsize = SHA1_DIGEST_SIZE,
> > ++.halg.statesize  = sizeof(struct
> talitos_ahash_req_ctx),
> > + .halg.base = {
> > + .cra_name = "sha1",
> > + .cra_driver_name = "sha1-talitos",
> > +@@ -2364,6 +2366,7 @@ static struct talitos_alg_template driver_algs[]
> = {
> > + {   .type = CRYPTO_ALG_TYPE_AHASH,
> > + .alg.hash = {
> > + .halg.digestsize = SHA224_DIGEST_SIZE,
> > ++.halg.statesize  = sizeof(struct
> talitos_ahash_req_ctx),
> > + .halg.base = {
> > + .cra_name = "sha224",
> > + .cra_driver_name = "sha224-talitos",
> > +@@ -2379,6 +2382,7 @@ static struct talitos_alg_template driver_algs[]
> = {
> > + {   .type = CRYPTO_ALG_TYPE_AHASH,
> > + .alg.hash = {
> > + .halg.digestsize = SHA256_DIGEST_SIZE,
> > ++.halg.statesize  = sizeof(struct
> talitos_ahash_req_ctx),
> > + .halg.base = {
> > + .cra_name = "sha256",
> > + .cra_driver_name = "sha256-talitos",
> > +@@ -2394,6 +2398,7 @@ static struct talitos_alg_template driver_algs[]
> = {
> > + {   .type = CRYPTO_ALG_TYPE_AHASH,
> > + .alg.hash = {
> > + .halg.digestsize = SHA384_DIGEST_SIZE,
> > ++.halg.statesize  = sizeof(struct
> talitos_ahash_req_ctx),
> > + .halg.base = {
> > + .cra_name = "sha384",
> > + .cra_driver_name = "sha384-talitos",
> > +@@ -2409,6 +2414,7 @@ static struct talitos_alg_template driver_algs[]
> = {
> 

[OpenWrt-Devel] [PATCH] target/linux/mpc85xx: fix talitos crypto driver init

[Alexandru Ardelean]

Crypto hash algorithms must provide the statesize for
kernel 4.2+

Referencing commit in the kernel:

commit 8996eafdcbad149ac0f772fb1649fbb75c482a6a
Author: Russell King <rmk+ker...@arm.linux.org.uk>
Date:   Fri Oct 9 20:43:33 2015 +0100

crypto: ahash - ensure statesize is non-zero

Unlike shash algorithms, ahash drivers must implement export
and import as their descriptors may contain hardware state and
cannot be exported as is.  Unfortunately some ahash drivers did
not provide them and end up causing crashes with algif_hash.

This patch adds a check to prevent these drivers from registering
ahash algorithms until they are fixed.

Cc: sta...@vger.kernel.org
Signed-off-by: Russell King <rmk+ker...@arm.linux.org.uk>
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>

Signed-off-by: Alexandru Ardelean <ardeleana...@gmail.com>
---
 .../302-add-statesize-to-talitos-crypto-driver.sh  | 100 +
 1 file changed, 100 insertions(+)
 create mode 100644 
target/linux/mpc85xx/patches-4.4/302-add-statesize-to-talitos-crypto-driver.sh

diff --git 
a/target/linux/mpc85xx/patches-4.4/302-add-statesize-to-talitos-crypto-driver.sh
 
b/target/linux/mpc85xx/patches-4.4/302-add-statesize-to-talitos-crypto-driver.sh
new file mode 100644
index 000..4d77c19
--- /dev/null
+++ 
b/target/linux/mpc85xx/patches-4.4/302-add-statesize-to-talitos-crypto-driver.sh
@@ -0,0 +1,100 @@
+diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
+index b6f9f42..b786b21 100644
+--- a/drivers/crypto/talitos.c
 b/drivers/crypto/talitos.c
+@@ -2334,6 +2334,7 @@ static struct talitos_alg_template driver_algs[] = {
+   {   .type = CRYPTO_ALG_TYPE_AHASH,
+   .alg.hash = {
+   .halg.digestsize = MD5_DIGEST_SIZE,
++  .halg.statesize  = sizeof(struct talitos_ahash_req_ctx),
+   .halg.base = {
+   .cra_name = "md5",
+   .cra_driver_name = "md5-talitos",
+@@ -2349,6 +2350,7 @@ static struct talitos_alg_template driver_algs[] = {
+   {   .type = CRYPTO_ALG_TYPE_AHASH,
+   .alg.hash = {
+   .halg.digestsize = SHA1_DIGEST_SIZE,
++  .halg.statesize  = sizeof(struct talitos_ahash_req_ctx),
+   .halg.base = {
+   .cra_name = "sha1",
+   .cra_driver_name = "sha1-talitos",
+@@ -2364,6 +2366,7 @@ static struct talitos_alg_template driver_algs[] = {
+   {   .type = CRYPTO_ALG_TYPE_AHASH,
+   .alg.hash = {
+   .halg.digestsize = SHA224_DIGEST_SIZE,
++  .halg.statesize  = sizeof(struct talitos_ahash_req_ctx),
+   .halg.base = {
+   .cra_name = "sha224",
+   .cra_driver_name = "sha224-talitos",
+@@ -2379,6 +2382,7 @@ static struct talitos_alg_template driver_algs[] = {
+   {   .type = CRYPTO_ALG_TYPE_AHASH,
+   .alg.hash = {
+   .halg.digestsize = SHA256_DIGEST_SIZE,
++  .halg.statesize  = sizeof(struct talitos_ahash_req_ctx),
+   .halg.base = {
+   .cra_name = "sha256",
+   .cra_driver_name = "sha256-talitos",
+@@ -2394,6 +2398,7 @@ static struct talitos_alg_template driver_algs[] = {
+   {   .type = CRYPTO_ALG_TYPE_AHASH,
+   .alg.hash = {
+   .halg.digestsize = SHA384_DIGEST_SIZE,
++  .halg.statesize  = sizeof(struct talitos_ahash_req_ctx),
+   .halg.base = {
+   .cra_name = "sha384",
+   .cra_driver_name = "sha384-talitos",
+@@ -2409,6 +2414,7 @@ static struct talitos_alg_template driver_algs[] = {
+   {   .type = CRYPTO_ALG_TYPE_AHASH,
+   .alg.hash = {
+   .halg.digestsize = SHA512_DIGEST_SIZE,
++  .halg.statesize  = sizeof(struct talitos_ahash_req_ctx),
+   .halg.base = {
+   .cra_name = "sha512",
+   .cra_driver_name = "sha512-talitos",
+@@ -2424,6 +2430,7 @@ static struct talitos_alg_template driver_algs[] = {
+   {   .type = CRYPTO_ALG_TYPE_AHASH,
+   .alg.hash = {
+   .halg.digestsize = MD5_DIGEST_SIZE,
++  .halg.statesize  = sizeof(struct talitos_ahash_req_ctx),
+   .halg.base = {
+   .cra_name = "hmac(md5)",
+   .cra_driver_name = "hmac-md5-talitos",
+@@ -2439,6 +2446,7 @@ static

[OpenWrt-Devel] [PATCH] ubi-utils: package mkfs.ubifs and mtdinfo into ubi-utils

[Alexandru Ardelean]

This is a partial backport from mtd-utils.
mtd-utils exposed multiple sub-packages.

I think mtd-utils was part of the oldpackages ; I haven't checked.
But it seems that mtd-utils and ubi-utils are pretty much the same.

The only thing we need on top of ubi-utils are the 'mkfs.ubifs' and
'mtdinfo' commands.

I had thought about just adding the 2 cmds to the ubi-utils install rule
but maybe for a more generic use-case they might not be needed.

Signed-off-by: Alexandru Ardelean <ardeleana...@gmail.com>
---
 package/utils/ubi-utils/Makefile | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/package/utils/ubi-utils/Makefile b/package/utils/ubi-utils/Makefile
index b89a5d2..c34e1a2 100644
--- a/package/utils/ubi-utils/Makefile
+++ b/package/utils/ubi-utils/Makefile
@@ -30,6 +30,10 @@ PKG_MAINTAINER:=John Crispin <blo...@openwrt.org>
 
 include $(INCLUDE_DIR)/package.mk
 
+FILES:= \
+   mkfs.ubifs:+libuuid:+liblzo:+zlib \
+   mtdinfo
+
 define Package/ubi-utils
   TITLE:=Utilities for ubi info/debug
   SECTION:=utils
@@ -42,6 +46,18 @@ define Package/ubi-utils/description
   Utilities for manipulating memory technology devices.
 endef
 
+define PartGen
+define Package/ubi-utils-$(subst _,-,$(firstword $(subst :, ,$(1
+  TITLE:=$(firstword $(subst :, ,$(1))) package from ubi-utils
+  URL:=http://www.linux-mtd.infradead.org/
+  SECTION:=utils
+  CATEGORY:=Utilities
+  DEPENDS:=@NAND_SUPPORT +ubi-utils $(wordlist 2,$(words $(subst :, 
,$(1))),$(subst :, ,$(1)))
+endef
+endef
+
+$(foreach file,$(FILES),$(eval $(call PartGen,$(file
+
 MAKE_FLAGS += \
DESTDIR="$(PKG_INSTALL_DIR)" \
BUILDDIR="$(PKG_BUILD_DIR)" \
@@ -57,5 +73,16 @@ define Package/ubi-utils/install

$(PKG_INSTALL_DIR)/usr/sbin/{ubinfo,ubinize,ubirename,ubirmvol,ubirsvol,ubiupdatevol}
 $(1)/usr/sbin/
 endef
 
+define PartInstall
+define Package/ubi-utils-$(subst _,-,$(firstword $(subst :, ,$(1/install
+   $(INSTALL_DIR) $$(1)/usr/sbin
+   $(INSTALL_BIN) \
+   $(PKG_INSTALL_DIR)/usr/sbin/$(firstword $(subst :, ,$(1))) \
+   $$(1)/usr/sbin/
+endef
+endef
+
+$(foreach file,$(FILES),$(eval $(call PartInstall,$(file
 
 $(eval $(call BuildPackage,ubi-utils))
+$(foreach file,$(FILES),$(eval $(call BuildPackage,ubi-utils-$(subst 
_,-,$(firstword $(subst :, ,$(file)))
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] strace: fix build on mpc85xx target

[Alexandru Ardelean]

This is another issue with musl and kernel headers colliding.
However this one cannot seem to be fixed with header guards
as my last 2 patches for mpc85xx.

Patch 1: http://patchwork.ozlabs.org/patch/614830/
Patch 2: http://patchwork.ozlabs.org/patch/615669/

It seems that doing a bit inclusion black-magic
in the strace package fixes this.

Adding header guards in musl seems a bit tricky, because
strace requires some reg definitions from the kernel headers
which are not in the musl headers.

The ar71xx target seems to build fine with this change.
It's the only I've manually tested (other than mpc85xx).

Build failure is (from buildbot):
===
process.Tpo -c -o strace-process.o `test -f 'process.c' || echo './'`process.c
In file included from 
/store/buildbot/slave/mpc85xx/build/staging_dir/toolchain-powerpc_8540_gcc-5.3.0_musl-1.1.14/include/linux/ptrace.h:100:0,
 from ptrace.h:55,
 from process.c:46:
/store/buildbot/slave/mpc85xx/build/staging_dir/toolchain-powerpc_8540_gcc-5.3.0_musl-1.1.14/include/asm/ptrace.h:31:8:
 error: redefinition of 'struct pt_regs'
 struct pt_regs {
^
In file included from 
/store/buildbot/slave/mpc85xx/build/staging_dir/toolchain-powerpc_8540_gcc-5.3.0_musl-1.1.14/include/sys/user.h:11:0,
 from regs.h:1,
 from process.c:45:
/store/buildbot/slave/mpc85xx/build/staging_dir/toolchain-powerpc_8540_gcc-5.3.0_musl-1.1.14/include/bits/user.h:1:8:
 note: originally defined here
 struct pt_regs {
^
Makefile:3141: recipe for target 'strace-process.o' failed
===

Signed-off-by: Alexandru Ardelean <ardeleana...@gmail.com>
---
 .../ocedo-001-workaround-pt_regs-collisions-ppc.patch | 15 +++
 1 file changed, 15 insertions(+)
 create mode 100644 
package/devel/strace/patches/ocedo-001-workaround-pt_regs-collisions-ppc.patch

diff --git 
a/package/devel/strace/patches/ocedo-001-workaround-pt_regs-collisions-ppc.patch
 
b/package/devel/strace/patches/ocedo-001-workaround-pt_regs-collisions-ppc.patch
new file mode 100644
index 000..3a56003
--- /dev/null
+++ 
b/package/devel/strace/patches/ocedo-001-workaround-pt_regs-collisions-ppc.patch
@@ -0,0 +1,15 @@
+diff --git a/ptrace.h b/ptrace.h
+index d8af976..f767378 100644
+--- a/ptrace.h
 b/ptrace.h
+@@ -52,7 +52,10 @@ extern long ptrace(int, int, char *, long);
+ # define ptrace_peeksiginfo_args XXX_ptrace_peeksiginfo_args
+ #endif
+ 
++#include 
++#define __ASSEMBLY__
+ #include 
++#undef __ASSEMBLY__
+ 
+ #ifdef HAVE_STRUCT_IA64_FPREG
+ # undef ia64_fpreg
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] [RFC] toolchain/musl/ppc: add header guards for EDEADLOCK define

[Alexandru Ardelean]

The header guard is the same as in:
 linux/arch/powerpc/include/uapi/asm/errno.h

I've sent another patch for this issue, but reconsidered on it.
Patch is here: http://patchwork.ozlabs.org/patch/614830/

The issue is a collision on the EDEADLOCK define between
musl's  and the kernel's  when building
perf, libbpf and other stuff in the kernel/tools folder.
It only occurs on the PowerPc arch.

I still don't know what's best:
1. Patch musl for PowerPc (as this patch does)
2. Patch the kernel for PowerPc (as with above mentioned patch)
3. Fix perf, libbpf, etc individually etc

Hence the RFC on this patch.

Signed-off-by: Alexandru Ardelean <ardeleana...@gmail.com>
---
 .../musl/patches/301-ppc-add-header-guards-user-h.patch | 17 +
 1 file changed, 17 insertions(+)
 create mode 100644 
toolchain/musl/patches/301-ppc-add-header-guards-user-h.patch

diff --git a/toolchain/musl/patches/301-ppc-add-header-guards-user-h.patch 
b/toolchain/musl/patches/301-ppc-add-header-guards-user-h.patch
new file mode 100644
index 000..2712d19
--- /dev/null
+++ b/toolchain/musl/patches/301-ppc-add-header-guards-user-h.patch
@@ -0,0 +1,17 @@
+diff --git a/arch/powerpc/bits/errno.h b/arch/powerpc/bits/errno.h
+index 36ad2f9..1011bf7 100644
+--- a/arch/powerpc/bits/errno.h
 b/arch/powerpc/bits/errno.h
+@@ -55,7 +55,10 @@
+ #define ENOANO  55
+ #define EBADRQC 56
+ #define EBADSLT 57
++#ifndef _ASM_POWERPC_ERRNO_H
++#define _ASM_POWERPC_ERRNO_H
+ #define EDEADLOCK   58 
++#endif
+ #define EBFONT  59
+ #define ENOSTR  60
+ #define ENODATA 61
+diff --git a/arch/powerpc/bits/user.h b/arch/powerpc/bits/user.h
+index 6cc8aaf..e1d06f6 100644
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] [firewall3] defaults.c: remove toplevel_rule struct

[Alexandru Ardelean]

From: Alexandru Ardelean <ardeleana...@gmail.com>

Since commit 60f1444 , this struct is no longer used.

Signed-off-by: Alexandru Ardelean <ardeleana...@gmail.com>
---
 defaults.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/defaults.c b/defaults.c
index e246949..3d210f9 100644
--- a/defaults.c
+++ b/defaults.c
@@ -164,13 +164,6 @@ fw3_print_default_chains(struct fw3_ipt_handle *handle, 
struct fw3_state *state,
set(defs->flags, handle->family, handle->table);
 }
 
-
-struct toplevel_rule {
-   enum fw3_table table;
-   const char *chain;
-   const char *target;
-};
-
 void
 fw3_print_default_head_rules(struct fw3_ipt_handle *handle,
  struct fw3_state *state, bool reload)
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] defaults.c: remove toplevel_rule struct

[Alexandru Ardelean]

From: Alexandru Ardelean <ardeleana...@gmail.com>

Since commit 60f1444 , this struct is no longer used.

Signed-off-by: Alexandru Ardelean <ardeleana...@gmail.com>
---
 defaults.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/defaults.c b/defaults.c
index e246949..3d210f9 100644
--- a/defaults.c
+++ b/defaults.c
@@ -164,13 +164,6 @@ fw3_print_default_chains(struct fw3_ipt_handle *handle, 
struct fw3_state *state,
set(defs->flags, handle->family, handle->table);
 }
 
-
-struct toplevel_rule {
-   enum fw3_table table;
-   const char *chain;
-   const char *target;
-};
-
 void
 fw3_print_default_head_rules(struct fw3_ipt_handle *handle,
  struct fw3_state *state, bool reload)
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] target/linux/mpc85xx: fix EDEADLOCK define collisions with musl

[Alexandru Ardelean]

libbpf fails to build.
perf just emits a warning and carries on.

This is a collision between linux's  and musl's 
when building for powerpc.

For powerpc, EDEADLOCK has value 58.
The initial definition in the kernel
  include/uapi/asm-generic/errno.h : #define EDEADLOCK EDEADLK
Then this gets overriden:
  arch/powerpc/include/uapi/asm/errno.h : #define EDEADLOCK  58

And in musl:
  arch/powerpc/bits/errno.h : #define EDEADLOCK   58

There would be 2 ways to solve this:
 1. Patch perf, libbpf and other tools to change the inclusion order of 

 2. Patch the kernel just for the powerpc arch to not re-define EDEADLOCK if 
defined

I chose 2.

===
Build failure is:
  CC   libbpf.o
In file included from 
/home/sandu/work/Wrt1/openwrt/build_dir/target-powerpc_8540_musl-1.1.14_ewok/linux-mpc85xx_ewok/linux-4.4.6/arch/powerpc/include/uapi/asm/errno.h:4:0,
 from 
/home/sandu/work/Wrt1/openwrt/build_dir/target-powerpc_8540_musl-1.1.14_ewok/linux-mpc85xx_ewok/linux-4.4.6/tools/include/linux/err.h:7,
 from libbpf.h:13,
 from libbpf.c:24:
/home/sandu/work/Wrt1/openwrt/build_dir/target-powerpc_8540_musl-1.1.14_ewok/linux-mpc85xx_ewok/linux-4.4.6/include/uapi/asm-generic/errno.h:39:0:
 error: "EDEADLOCK" redefined [-Werror]
#define EDEADLOCK EDEADLK
^
In file included from 
/home/sandu/work/Wrt1/openwrt/staging_dir/toolchain-powerpc_8540_gcc-5.3.0_musl-1.1.14/include/errno.h:10:0,
 from libbpf.c:16:
/home/sandu/work/Wrt1/openwrt/staging_dir/toolchain-powerpc_8540_gcc-5.3.0_musl-1.1.14/include/bits/errno.h:58:0:
 note: this is the location of the previous definition
#define EDEADLOCK   58
^
cc1: all warnings being treated as errors
  CC   bpf.o
  LD   libbpf-in.o
powerpc-openwrt-linux-musl-ld: cannot find libbpf.o: No such file or directory

Signed-off-by: Alexandru Ardelean <ardeleana...@gmail.com>
---
 .../301-fix-edeadlock-define-collisions-with-musl.patch   | 15 +++
 1 file changed, 15 insertions(+)
 create mode 100644 
target/linux/mpc85xx/patches-4.4/301-fix-edeadlock-define-collisions-with-musl.patch

diff --git 
a/target/linux/mpc85xx/patches-4.4/301-fix-edeadlock-define-collisions-with-musl.patch
 
b/target/linux/mpc85xx/patches-4.4/301-fix-edeadlock-define-collisions-with-musl.patch
new file mode 100644
index 000..57a35f6
--- /dev/null
+++ 
b/target/linux/mpc85xx/patches-4.4/301-fix-edeadlock-define-collisions-with-musl.patch
@@ -0,0 +1,15 @@
+diff --git a/include/uapi/asm-generic/errno.h 
b/include/uapi/asm-generic/errno.h
+index 88e0914..7549bec 100644
+--- a/include/uapi/asm-generic/errno.h
 b/include/uapi/asm-generic/errno.h
+@@ -36,7 +36,9 @@
+ #define   EBADRQC 56  /* Invalid request code */
+ #define   EBADSLT 57  /* Invalid slot */
+ 
+-#define   EDEADLOCK   EDEADLK
++#ifndef EDEADLOCK
++#define   EDEADLOCK   58
++#endif
+ 
+ #define   EBFONT  59  /* Bad font file format */
+ #define   ENOSTR  60  /* Device not a stream */
-- 
2.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] libnl-tiny: backport 'gnet_stats_rate_est64' support

[Alexandru Ardelean]

This has been added to the kernel uapi for a while, and makes
sense to have it here too.
At the moment we're using it for query-ing qdisc via netlink
using libnl-tiny.

Signed-off-by: Alexandru Ardelean <ardeleana...@gmail.com>
---
 package/libs/libnl-tiny/src/include/linux/gen_stats.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/package/libs/libnl-tiny/src/include/linux/gen_stats.h 
b/package/libs/libnl-tiny/src/include/linux/gen_stats.h
index 13f4e74..8b6f3fc 100644
--- a/package/libs/libnl-tiny/src/include/linux/gen_stats.h
+++ b/package/libs/libnl-tiny/src/include/linux/gen_stats.h
@@ -9,6 +9,7 @@ enum {
TCA_STATS_RATE_EST,
TCA_STATS_QUEUE,
TCA_STATS_APP,
+   TCA_STATS_RATE_EST64,
__TCA_STATS_MAX,
 };
 #define TCA_STATS_MAX (__TCA_STATS_MAX - 1)
@@ -36,6 +37,17 @@ struct gnet_stats_rate_est
 };
 
 /**
+ * struct gnet_stats_rate_est64 - rate estimator
+ * @bps: current byte rate
+ * @pps: current packet rate
+ */
+struct gnet_stats_rate_est64
+{
+   __u64   bps;
+   __u64   pps;
+};
+
+/**
  * struct gnet_stats_queue - queuing statistics
  * @qlen: queue length
  * @backlog: backlog size of queue
-- 
2.7.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Question regarding call python script

[Alexandru Ardelean]

On Thu, Mar 10, 2016 at 6:38 PM, Jo-Philipp Wich  wrote:

> Hi Jason,
>
> no reason against it per se but it would introduce a new build prereq I
> suppose. If possible we'd like to stick to things we already require
> (perl, awk, shell).
>
>
> Regards, Jo
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>

As far as I know, python is already required by the OpenWRT build system.
The build stops if there is no /usr/bin/python (not 100% sure about this
anymore)

And in rules.mk there's
PYTHON:=python
(and this is not related in any way to the Python package in the feeds)

So, I guess Python is fine.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] target/mpc85xx: check for 'generic' subtarget for initramfs image file

[Alexandru Ardelean]

From: Alexandru Ardelean <ardeleana...@gmail.com>

Copy 'cuImage.tl-wdr4900-v1-initramfs' only for the 'generic' subtarget.
This is a follow-up to:
 
http://git.openwrt.org/?p=openwrt.git;a=commitdiff;h=b889fe55c1844aec2c03da28fecb03e958c21f18

We build our initramfs images more rarely, so it took a while
to catch this too.

Signed-off-by: Alexandru Ardelean <ardeleana...@gmail.com>
---
 target/linux/mpc85xx/image/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target/linux/mpc85xx/image/Makefile 
b/target/linux/mpc85xx/image/Makefile
index 3c3f100..25a9b07 100644
--- a/target/linux/mpc85xx/image/Makefile
+++ b/target/linux/mpc85xx/image/Makefile
@@ -32,7 +32,9 @@ endef
 
 define Image/BuildKernel/Initramfs
cp $(KDIR)/zImage-initramfs $(BIN_DIR)/$(IMG_PREFIX)-initramfs-zImage
+ifeq ($(SUBTARGET),generic)
cp $(KDIR)/cuImage.tl-wdr4900-v1-initramfs 
$(BIN_DIR)/$(IMG_PREFIX)-tl-wdr4900-v1-initramfs.uImage
+endif
 endef
 
 define Image/Build/TPLINK
-- 
2.7.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] b53: reset vlans data when setting 'enable_vlan'

[Alexandru Ardelean]

From: Alexandru Ardelean <ardeleana...@gmail.com>

In our case we don't call reset (to reset the chip and the driver)
on each reconfigure.
So, we can re-use the 'enable_vlan' call, because this gets called
once on each switch re-configure and we can reset all previously
set VLANs.

Signed-off-by: Alexandru Ardelean <ardeleana...@gmail.com>
---
 target/linux/generic/files/drivers/net/phy/b53/b53_common.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c 
b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
index 676e301..a6bde8f 100644
--- a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
+++ b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
@@ -590,6 +590,8 @@ static int b53_global_set_vlan_enable(struct switch_dev 
*dev,
struct b53_device *priv = sw_to_b53(dev);
 
priv->enable_vlan = val->value.i;
+   /* Reset VLANs whenever calling this ; this would set the system to a 
deterministic state */
+   memset(priv->vlans, 0, sizeof(*priv->vlans) * dev->vlans);
 
return 0;
 }
-- 
2.7.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] dnsmasq: add dhcp relay option

[Alexandru Ardelean]

On Tue, Jan 19, 2016 at 11:38 AM, Dan Bugnar  wrote:

> Should I remove this part? Maybe comment it (to have a sample) or replace
> with something else.
>
> Dan Bugnar
>
> On Tue, Jan 19, 2016 at 11:20 AM, Dan Bugnar  wrote:
>
>> Should I remove this part? Maybe comment it (to have a sample) or replace
>> with something else.
>>
>> Dan Bugnar
>>
>> On Tue, Jan 19, 2016 at 11:11 AM, John Crispin  wrote:
>>
>>>
>>>
>>> On 08/01/2016 16:24, dbugnar wrote:
>>> > Signed-off-by: dbugnar 
>>> > ---
>>> >  package/network/services/dnsmasq/files/dhcp.conf|  6 ++
>>> >  package/network/services/dnsmasq/files/dnsmasq.init | 19
>>> +++
>>> >  2 files changed, 25 insertions(+)
>>> >
>>> > diff --git a/package/network/services/dnsmasq/files/dhcp.conf
>>> b/package/network/services/dnsmasq/files/dhcp.conf
>>> > index 362b90a..7a66b44 100644
>>> > --- a/package/network/services/dnsmasq/files/dhcp.conf
>>> > +++ b/package/network/services/dnsmasq/files/dhcp.conf
>>> > @@ -30,3 +30,9 @@ config dhcp lan
>>> >  config dhcp wan
>>> >   option interfacewan
>>> >   option ignore   1
>>> > +
>>> > +config relay
>>> > + option local_addr   '192.168.1.1'
>>> > + option server_addr  '0.0.0.0'
>>> > + option interface'eth0'
>>>
>>>
>>> NAK on this part. you cannot add a static config for eth0/192.168.1.1 as
>>> that is specific to your board and not generic.
>>>
>>> JOhn
>>>
>>> > +
>>> > diff --git a/package/network/services/dnsmasq/files/dnsmasq.init
>>> b/package/network/services/dnsmasq/files/dnsmasq.init
>>> > index 3ef2b3d..ac45d1b 100644
>>> > --- a/package/network/services/dnsmasq/files/dnsmasq.init
>>> > +++ b/package/network/services/dnsmasq/files/dnsmasq.init
>>> > @@ -538,6 +538,24 @@ dhcp_hostrecord_add() {
>>> >   xappend "--host-record=$record"
>>> >  }
>>> >
>>> > +dhcp_relay_add() {
>>> > + local cfg="$1"
>>> > + local local_addr server_addr interface
>>> > +
>>> > + config_get local_addr "$cfg" local_addr
>>> > + [ -n "$local_addr" ] || return 0
>>> > +
>>> > + config_get server_addr "$cfg" server_addr
>>> > + [ -n "$server_addr" ] || return 0
>>> > +
>>> > + config_get interface "$cfg" interface
>>> > + if [ -z "$interface" ]; then
>>> > + xappend "--dhcp-relay=$local_addr,$server_addr"
>>> > + else
>>> > + xappend
>>> "--dhcp-relay=$local_addr,$server_addr,$interface"
>>> > + fi
>>> > +}
>>> > +
>>> >  service_triggers()
>>> >  {
>>> >   procd_add_reload_trigger "dhcp"
>>> > @@ -597,6 +615,7 @@ start_service() {
>>> >   config_foreach dhcp_subscrid_add subscrid
>>> >   config_foreach dhcp_domain_add domain
>>> >   config_foreach dhcp_hostrecord_add hostrecord
>>> > + config_foreach dhcp_relay_add relay
>>> >
>>> >   # add own hostname
>>> >   local lanaddr
>>> >
>>>
>>
>>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
>
Is there a follow-up to this discussion ?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/2] lldpd: fix reload function for when interfaces change

[Alexandru Ardelean]

From: Alexandru Ardelean <a...@ocedo.com>

The problem is that interfaces are specified at start as
command line arguments, making them unchange-able via reload.

That means, we have to move (since lldpd allows this) the
interfaces-match-pattern option to be in a config file and reload
the configuration.
It's either that, or do a 'restart'.

Since we're generating the lldpd.conf file, we'll have to
move the 'sysconfdir' of lldpd to /tmp, where the files will
get written ; this will prevent any unncessary flash writes.

Signed-off-by: Alexandru Ardelean <ardeleana...@gmail.com>
---
 package/network/services/lldpd/Makefile |  1 +
 package/network/services/lldpd/files/lldpd.init | 53 +
 2 files changed, 37 insertions(+), 17 deletions(-)

diff --git a/package/network/services/lldpd/Makefile 
b/package/network/services/lldpd/Makefile
index 81e4a8f..5f413cf 100644
--- a/package/network/services/lldpd/Makefile
+++ b/package/network/services/lldpd/Makefile
@@ -94,6 +94,7 @@ CONFIGURE_ARGS += \
--with-embedded-libevent=no \
--disable-hardening \
--without-xml \
+   --sysconfdir=/tmp \
$(if $(CONFIG_LLDPD_WITH_CDP),,--disable-cdp) \
$(if $(CONFIG_LLDPD_WITH_FDP),,--disable-fdp) \
$(if $(CONFIG_LLDPD_WITH_EDP),,--disable-edp) \
diff --git a/package/network/services/lldpd/files/lldpd.init 
b/package/network/services/lldpd/files/lldpd.init
index 6965189..064bac1 100644
--- a/package/network/services/lldpd/files/lldpd.init
+++ b/package/network/services/lldpd/files/lldpd.init
@@ -7,6 +7,8 @@ STOP=01
 USE_PROCD=1
 LLDPCLI=/usr/sbin/lldpcli
 LLDPSOCKET=/var/run/lldpd.socket
+LLDPD_CONF=/tmp/lldpd.conf
+LLDPD_CONFS_DIR=/tmp/lldpd.d
 
 find_release_info()
 {
@@ -17,16 +19,43 @@ find_release_info()
echo "${DISTRIB_DESCRIPTION:-Unknown OpenWrt release} @ $(cat 
/proc/sys/kernel/hostname)"
 }
 
-start_service() {
+write_lldpd_conf()
+{
. /lib/functions/network.sh
 
+   local lldp_description
+
+   config_load 'lldpd'
+   config_get lldp_description 'config' 'lldp_description' 
"$(find_release_info)"
+
+   local ifaces
+   config_get ifaces 'config' 'interface'
+
+   local iface ifnames=""
+   for iface in $ifaces; do
+   local ifname=""
+   if network_get_device ifname "$iface" || [ -e 
"/sys/class/net/$iface" ]; then
+   append ifnames "${ifname:-$iface}" ","
+   fi
+   done
+
+   # Clear out the config file first
+   echo -n > "$LLDPD_CONF"
+   [ -n "$ifnames" ] && echo "configure system interface pattern" 
"$ifnames" >> "$LLDPD_CONF"
+   [ -n "$lldp_description" ] && echo "configure system description" 
"\"$lldp_description\"" >> "$LLDPD_CONF"
+
+   # Since lldpd's sysconfdir is /tmp, we'll symlink /etc/lldpd.d to 
/tmp/$LLDPD_CONFS_DIR
+   [ -e $LLDPD_CONFS_DIR ] || ln -s /etc/lldpd.d $LLDPD_CONFS_DIR
+}
+
+start_service() {
+
local enable_cdp
local enable_fdp
local enable_sonmp
local enable_edp
local lldp_class
local lldp_location
-   local lldp_description
local readonly_mode
 
config_load 'lldpd'
@@ -36,35 +65,24 @@ start_service() {
config_get_bool enable_edp 'config' 'enable_edp' 0
config_get lldp_class 'config' 'lldp_class'
config_get lldp_location 'config' 'lldp_location'
-   config_get lldp_description 'config' 'lldp_description' 
"$(find_release_info)"
config_get_bool readonly_mode 'config' 'readonly_mode' 0
 
-   local ifaces
-   config_get ifaces 'config' 'interface'
-
-   local iface ifnames=""
-   for iface in $ifaces; do
-   local ifname=""
-   if network_get_device ifname "$iface" || [ -e 
"/sys/class/net/$iface" ]; then
-   append ifnames "${ifname:-$iface}" ","
-   fi
-   done
-
mkdir -p /var/run/lldp
chown lldp:lldp /var/run/lldp
 
+   # When lldpd starts, it also loads up what we write in this config file
+   write_lldpd_conf
+
procd_open_instance
procd_set_param command /usr/sbin/lldpd
procd_append_param command -d # don't daemonize, procd will handle that 
for us
 
-   [ -n "$ifnames" ] && procd_append_param command -I "$ifnames"
[ $enable_cdp -gt 0 ] && procd_append_param command '-c'
[ $enable_fdp -gt 0 ] && procd_append_param command '-f'
[ $enable_sonmp -gt 0 ] && procd_append_param command '-s'
[ $enable_edp -gt 0 ] && procd_append_param command '-e'
[ $readonly_mode -gt 0 ]

[OpenWrt-Devel] [PATCH 2/2] lldpd: add /lib/lldpd.unconf file for reload

[Alexandru Ardelean]

Looks like we need to call 'unconfigure' options lldpd has to offer
to do a proper (more complete) reload.

And while we're doing reload, we need to pause lldpd's execution
to prevent it sending unconfigured data/TLVs to the other side
( which could confuse the other side ).

Signed-off-by: Alexandru Ardelean <ardeleana...@gmail.com>
---
 package/network/services/lldpd/Makefile   |  9 -
 package/network/services/lldpd/files/lldpd.init   | 12 +++-
 package/network/services/lldpd/files/lldpd.unconf |  9 +
 3 files changed, 24 insertions(+), 6 deletions(-)
 create mode 100644 package/network/services/lldpd/files/lldpd.unconf

diff --git a/package/network/services/lldpd/Makefile 
b/package/network/services/lldpd/Makefile
index 5f413cf..4445867 100644
--- a/package/network/services/lldpd/Makefile
+++ b/package/network/services/lldpd/Makefile
@@ -61,11 +61,12 @@ define Package/lldpd/install
$(INSTALL_DIR) $(1)/etc/init.d
$(INSTALL_DIR) $(1)/etc/lldpd.d
$(INSTALL_DIR) $(1)/etc/config
-   $(INSTALL_DIR) $(1)/usr/lib $(1)/usr/sbin
+   $(INSTALL_DIR) $(1)/lib $(1)/usr/lib $(1)/usr/sbin
$(CP) $(PKG_INSTALL_DIR)/usr/sbin/lldp{cli,ctl,d} $(1)/usr/sbin/
$(CP) $(PKG_INSTALL_DIR)/usr/lib/liblldpctl.so* $(1)/usr/lib/
$(INSTALL_BIN) ./files/lldpd.init $(1)/etc/init.d/lldpd
$(INSTALL_DATA) ./files/lldpd.config $(1)/etc/config/lldpd
+   $(INSTALL_CONF) ./files/lldpd.unconf $(1)/lib
 ifneq ($(CONFIG_LLDPD_WITH_CDP),y)
sed -i -e '/cdp/d' $(1)/etc/init.d/lldpd $(1)/etc/config/lldpd
 endif
@@ -78,6 +79,12 @@ endif
 ifneq ($(CONFIG_LLDPD_WITH_SONMP),y)
sed -i -e '/sonmp/d' $(1)/etc/init.d/lldpd $(1)/etc/config/lldpd
 endif
+ifneq ($(CONFIG_LLDPD_WITH_LLDPMED),y)
+   sed -i -e '/med/d' $(1)/lib/lldpd.unconf
+endif
+ifneq ($(CONFIG_LLDPD_WITH_CUSTOM),y)
+   sed -i -e '/custom-tlv/d' $(1)/lib/lldpd.unconf
+endif
 endef
 
 define Package/lldpd/conffiles
diff --git a/package/network/services/lldpd/files/lldpd.init 
b/package/network/services/lldpd/files/lldpd.init
index 064bac1..1cf3ce7 100644
--- a/package/network/services/lldpd/files/lldpd.init
+++ b/package/network/services/lldpd/files/lldpd.init
@@ -98,13 +98,15 @@ service_running() {
 
 reload_service() {
running || return 1
-   # Custom TLVs are special and should be
-   # reloaded from config during lldpd reload
-   $LLDPCLI -u $LLDPSOCKET unconfigure lldp custom-tlv &> /dev/null
+   # Pause lldpd execution so that it won't send out info during reconfig
+   $LLDPCLI -u $LLDPSOCKET pause &> /dev/null
+   $LLDPCLI -u $LLDPSOCKET -c /lib/lldpd.unconf &> /dev/null
write_lldpd_conf
$LLDPCLI -u $LLDPSOCKET -c $LLDPD_CONF -c $LLDPD_CONFS_DIR &> /dev/null
-   # Broadcast update over the wire
-   $LLDPCLI -u $LLDPSOCKET update &> /dev/null
+   $LLDPCLI -u $LLDPSOCKET &> /dev/null << EOF
+   resume
+   update
+EOF
return 0
 }
 
diff --git a/package/network/services/lldpd/files/lldpd.unconf 
b/package/network/services/lldpd/files/lldpd.unconf
new file mode 100644
index 000..b7bdafc
--- /dev/null
+++ b/package/network/services/lldpd/files/lldpd.unconf
@@ -0,0 +1,9 @@
+unconfigure system hostname
+unconfigure system description
+unconfigure system platform
+unconfigure system interface pattern
+unconfigure system interface description
+unconfigure system interface promiscuous
+unconfigure system ip management pattern
+unconfigure lldp custom-tlv
+unconfigure med fast-start
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Fwd: OpenVSwitch 2.5.0 for Linux kernel 4.3

[Alexandru Ardelean]

@Ronaldo: there was a patch submission to add OVS support to netifd.
http://comments.gmane.org/gmane.comp.embedded.openwrt.devel/21591

I was not accepted from the looks of it.

Regarding the discussion about the upgrade to 2.5.0.
Let's move it here:
https://github.com/openwrt/packages/issues/2201



On Tue, Dec 29, 2015 at 1:35 PM, Ronaldo Afonso <
rona...@ronaldoafonso.com.br> wrote:

>   Hi all,
>
>   I'd like to take advantage of that thread and ask you guys if there is
> someone working on porting "netifd package" to support Open vSwitch.
>
>   Jeroen,
>
>   How are you planning to configure your /etc/config/network file in order
> for it to work with Open vSwitch?
>
>   Thanks in advance ...
>
>
> 2015-12-29 0:34 GMT-02:00 Yousong Zhou :
>
>> On 29 December 2015 at 04:33, Jeroen van Bemmel  wrote:
>> > All,
>> >
>> > For a Xiaomi Mini WiFi router I wanted to try OpenVSwitch, but the
>> > 2.4.0 version available in the feeds only supports Linux kernels up to
>> > 4.1. The ramips target uses kernel 4.3, and downgrading to 4.1 didn't
>> work
>> > for me.
>> >
>> > OpenVSwitch 2.5.0 does support kernel 4.3, so I made some
>> > modifications to the package Makefile to build the newer version. Most
>> > of the patches are no longer needed, and with some minor patch the
>> > code builds now
>> > ( though I haven't tested it on the target )
>> >
>> > Is anyone else interested in these changes, and if so what would be
>> > the proper way to add a second version of the existing package ( with
>> > its own source code URL + patches )? Would it be a delta on the
>> > existing package, or a new "openvswitch-2.5.0" package?
>> >
>>
>> I think we can just move to 2.5.0.  Use the newest version or the LTS
>> version (2.3.2).
>>
>> Open vSwitch is provided through the packages feed, so opening
>> issue/pr there should be better.
>>
>> yousong
>>
>> > Thanks,
>> > Jeroen van Bemmel
>> > ___
>> > openwrt-devel mailing list
>> > openwrt-devel@lists.openwrt.org
>> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>
>
>
>
> --
> Ronaldo Afonso
> 11 9 5252 0484
> www.ronaldoafonso.com.br
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] libubus: add null for ubus_context object in ubus_shutdown()

[Alexandru Ardelean]

At the moment, we do our own null checks before calling ubus_free().
The likely-hood of 'ctx' being null (in ubus_free()) is low, 
but since free() handles null, might make sense for ubus_free() to do so as 
well.

Signed-off-by: Alexandru Ardelean <ardeleana...@gmail.com>
---
 libubus.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libubus.c b/libubus.c
index ccaa069..88a6ad3 100644
--- a/libubus.c
+++ b/libubus.c
@@ -354,6 +354,8 @@ struct ubus_context *ubus_connect(const char *path)
 void ubus_shutdown(struct ubus_context *ctx)
 {
blob_buf_free();
+   if (!ctx)
+   return;
close(ctx->sock.fd);
free(ctx->msgbuf.data);
 }
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] binutils: upgrade to version 2.25

[Alexandru Ardelean]

Fixes build:
config/tc-i386.c: In function 'build_modrm_byte':
config/tc-i386.c:6143:31: error: logical not is only applied to the left hand 
side of comparison [-Werror=logical-not-parentheses]
 && !op.bitfield.reg64 != 1

Contains this fix:
   https://sourceware.org/ml/binutils/2014-09/msg00095.html

Signed-off-by: Alexandru Ardelean <ardeleana...@gmail.com>
---
 package/devel/binutils/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/package/devel/binutils/Makefile b/package/devel/binutils/Makefile
index f8549ad..8e25a1e 100644
--- a/package/devel/binutils/Makefile
+++ b/package/devel/binutils/Makefile
@@ -8,13 +8,13 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=binutils
-PKG_VERSION:=2.24
-PKG_RELEASE:=3
+PKG_VERSION:=2.25
+PKG_RELEASE:=1
 
 PKG_SOURCE_URL:=@GNU/binutils
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
 PKG_VERSION:=$(PKG_VERSION)
-PKG_MD5SUM:=e0f71a7b2ddab0f8612336ac81d9636b
+PKG_MD5SUM:=d9f3303f802a5b6b0bb73a335ab89d66
 
 PKG_FIXUP:=autoreconf
 PKG_LIBTOOL_PATHS:=. gas bfd opcodes gprof binutils ld libiberty gold intl
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] b53: add 'flush_arl' command per port

[Alexandru Ardelean]

This would in essence re-use the current b53_flush_arl() function
with the added part that we can select a single port to flush ARL for.

Signed-off-by: Alexandru Ardelean <ardeleana...@gmail.com>

---
 .../generic/files/drivers/net/phy/b53/b53_common.c | 29 ++
 .../generic/files/drivers/net/phy/b53/b53_regs.h   |  4 +++
 2 files changed, 28 insertions(+), 5 deletions(-)

diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c 
b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
index 859d8d1..8c8d217 100644
--- a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
+++ b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
@@ -336,12 +336,17 @@ static int b53_set_jumbo(struct b53_device *dev, int 
enable, int allow_10_100)
return b53_write16(dev, B53_JUMBO_PAGE, dev->jumbo_size_reg, max_size);
 }
 
-static int b53_flush_arl(struct b53_device *dev)
+static int b53_flush_arl(struct b53_device *dev, int port)
 {
unsigned int i;
+   u8 age_ctrl = FAST_AGE_DONE | FAST_AGE_DYNAMIC | FAST_AGE_STATIC;
 
-   b53_write8(dev, B53_CTRL_PAGE, B53_FAST_AGE_CTRL,
-  FAST_AGE_DONE | FAST_AGE_DYNAMIC | FAST_AGE_STATIC);
+   if (port > -1 && port < B53_N_PORTS) {
+   b53_write8(dev, B53_CTRL_PAGE, B53_FAST_AGE_PORT_CTRL, 
FAST_AGE_SINGLE_PORT(port));
+   age_ctrl |= FAST_AGE_PORT;
+   }
+
+   b53_write8(dev, B53_CTRL_PAGE, B53_FAST_AGE_CTRL, age_ctrl);
 
for (i = 0; i < 10; i++) {
u8 fast_age_ctrl;
@@ -355,7 +360,7 @@ static int b53_flush_arl(struct b53_device *dev)
mdelay(1);
}
 
-   pr_warn("time out while flushing ARL\n");
+   pr_warn("time out while flushing ARL, port %d\n", port);
 
return -EINVAL;
 }
@@ -565,7 +570,7 @@ static int b53_switch_reset(struct b53_device *dev)
 
b53_enable_mib(dev);
 
-   return b53_flush_arl(dev);
+   return b53_flush_arl(dev, -1);
 }
 
 /*
@@ -890,6 +895,14 @@ static int b53_port_get_mib(struct switch_dev *sw_dev,
return 0;
 }
 
+static int b53_port_flush_arl(struct switch_dev *sw_dev,
+   const struct switch_attr *attr,
+   struct switch_val *val)
+{
+   struct b53_device *dev = sw_to_b53(sw_dev);
+   return b53_flush_arl(dev, val->port_vlan);
+}
+
 static struct switch_attr b53_global_ops_25[] = {
{
.type = SWITCH_TYPE_INT,
@@ -976,6 +989,12 @@ static struct switch_attr b53_port_ops[] = {
.description = "Get port's MIB counters",
.get = b53_port_get_mib,
},
+   {
+   .type = SWITCH_TYPE_NOVAL,
+   .name = "flush_arl",
+   .description = "Flush ARL",
+   .set = b53_port_flush_arl,
+   },
 };
 
 static struct switch_attr b53_no_ops[] = {
diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h 
b/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h
index 144e1c8..138d26b 100644
--- a/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h
+++ b/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h
@@ -135,6 +135,10 @@
 #define   FAST_AGE_MC  BIT(5)
 #define   FAST_AGE_DONEBIT(7)
 
+/* Fast Aging Port Control register (8 bit) */
+#define B53_FAST_AGE_PORT_CTRL 0x89
+#define   FAST_AGE_SINGLE_PORT(p)  ((u8)(0xf & p))
+
 /*
  * Status Page registers
  */
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] lldpd: add STOP=01 param in init script

[Alexandru Ardelean]

From: Alexandru Ardelean <a...@ocedo.com>

This should ensure that lldpd is among the first processes to stop,
so that it has time to send the shutdown LLDPU to the other side,
before the network goes down.

Signed-off-by: Alexandru Ardelean <ardeleana...@gmail.com>
---
 package/network/services/lldpd/files/lldpd.init | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/package/network/services/lldpd/files/lldpd.init 
b/package/network/services/lldpd/files/lldpd.init
index 04e5b8c..6965189 100644
--- a/package/network/services/lldpd/files/lldpd.init
+++ b/package/network/services/lldpd/files/lldpd.init
@@ -1,7 +1,8 @@
 #!/bin/sh /etc/rc.common
-# Copyright (C) 2008-2012 OpenWrt.org
+# Copyright (C) 2008-2015 OpenWrt.org
 
 START=90
+STOP=01
 
 USE_PROCD=1
 LLDPCLI=/usr/sbin/lldpcli
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] package/devel/perf: fix build for kernel 4.1

[Alexandru Ardelean]

Ah, sorry about this.
I forgot about it ; completely swamped.

Will add it in my desktop notes that I keep and come back with an answer
asap (hopefully today/tomorrow).


On Mon, Oct 26, 2015 at 12:13 PM, John Crispin <blo...@openwrt.org> wrote:

>
>
> On 21/10/2015 20:03, John Crispin wrote:
> >
> >
> > On 15/10/2015 15:01, Alexandru Ardelean wrote:
> >> This fix contains 2 parts:
> >>  - kernel 4.1: backport upstream patch "perf build: Do not fail on
> missing Build file"
> >>  - add +liblzma dependency
> >>
> >
> > did you find out why there is suddenly a dependency on lzma ?
> >
> >   John
>
>
> ping ...
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] package/devel/perf: fix build for kernel 4.1

[Alexandru Ardelean]

Looks like it did not take much to actually come back with an answer.
So,

In file:
https://github.com/torvalds/linux/blob/v4.1/tools/perf/Makefile.perf
Line 75:   # Define NO_LZMA if you do not want to support compressed (xz)
kernel modules

Then file:
https://github.com/torvalds/linux/blob/v4.1/tools/perf/config/Makefile
Lines 544-553:

ifndef NO_LZMA
  ifeq ($(feature-lzma), 1)
CFLAGS += -DHAVE_LZMA_SUPPORT
EXTLIBS += -llzma
$(call detected,CONFIG_LZMA)
  else
msg := $(warning No liblzma found, disables xz kernel module
decompression, please install xz-devel/liblzma-dev);
NO_LZMA := 1
  endif
endif

In my case it seems to enable by default.

Looking at the same files in 3.18:
https://github.com/torvalds/linux/blob/v3.18/tools/perf/config/Makefile
https://github.com/torvalds/linux/blob/v3.18/tools/perf/Makefile.perf

No mention of these.

Going a bit deeper, I found this commit:
https://github.com/torvalds/linux/commit/80a32e5b498a7547073e5e4b2b804edc7219979d
where LZMA compression gets added to perf.

Looks like it was enabled default in upstream.

So, I guess, we could build perf with NO_LZMA:=1 defined and we could
disable it.
No strong preferences from me.

Your call :)

On Mon, Oct 26, 2015 at 12:58 PM, John Crispin <blo...@openwrt.org> wrote:

> thanks ! the patch looks good but i am failing to understand why the
> lzma needs to be added :)
>
> On 26/10/2015 11:52, Alexandru Ardelean wrote:
> > Ah, sorry about this.
> > I forgot about it ; completely swamped.
> >
> > Will add it in my desktop notes that I keep and come back with an answer
> > asap (hopefully today/tomorrow).
> >
> >
> > On Mon, Oct 26, 2015 at 12:13 PM, John Crispin <blo...@openwrt.org
> > <mailto:blo...@openwrt.org>> wrote:
> >
> >
> >
> > On 21/10/2015 20:03, John Crispin wrote:
> > >
> > >
> > > On 15/10/2015 15:01, Alexandru Ardelean wrote:
> > >> This fix contains 2 parts:
> > >>  - kernel 4.1: backport upstream patch "perf build: Do not fail
> on missing Build file"
> > >>  - add +liblzma dependency
> > >>
> > >
> > > did you find out why there is suddenly a dependency on lzma ?
> > >
> > >   John
> >
> >
> > ping ...
> >
> >
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] package/devel/perf: fix build for kernel 4.1

[Alexandru Ardelean]

This fix contains 2 parts:
 - kernel 4.1: backport upstream patch "perf build: Do not fail on missing 
Build file"
 - add NO_LZMA=1 to perf MAKE_FLAGS to disable LZMA support

Signed-off-by: Alexandru Ardelean <ardeleana...@gmail.com>
---
 package/devel/perf/Makefile|  1 +
 ...f-build-Do-not-fail-on-missing-Build-file.patch | 67 ++
 2 files changed, 68 insertions(+)
 create mode 100644 
target/linux/generic/patches-4.1/222-perf-build-Do-not-fail-on-missing-Build-file.patch

diff --git a/package/devel/perf/Makefile b/package/devel/perf/Makefile
index b77e29a..5e3d63f 100644
--- a/package/devel/perf/Makefile
+++ b/package/devel/perf/Makefile
@@ -50,6 +50,7 @@ MAKE_FLAGS = \
NO_LIBPERL=1 \
NO_LIBPYTHON=1 \
NO_NEWT=1 \
+   NO_LZMA=1 \
CROSS_COMPILE="$(TARGET_CROSS)" \
CC="$(TARGET_CC)" \
LD="$(TARGET_CROSS)ld" \
diff --git 
a/target/linux/generic/patches-4.1/222-perf-build-Do-not-fail-on-missing-Build-file.patch
 
b/target/linux/generic/patches-4.1/222-perf-build-Do-not-fail-on-missing-Build-file.patch
new file mode 100644
index 000..3fb2df6
--- /dev/null
+++ 
b/target/linux/generic/patches-4.1/222-perf-build-Do-not-fail-on-missing-Build-file.patch
@@ -0,0 +1,67 @@
+From d7a3d85e08477a979933a2bb3b525a8de99543c2 Mon Sep 17 00:00:00 2001
+From: Jiri Olsa <jo...@kernel.org>
+Date: Fri, 29 May 2015 17:42:58 +0200
+Subject: [PATCH] perf build: Do not fail on missing Build file
+
+Allow nesting into directories without Build file. Currently we force
+include of the Build file, which fails the build when the Build file is
+missing.
+
+We already support empty *-in.o' objects if there's nothing in the
+directory to be compiled, so we can just use it for missing Build file
+cases.
+
+Also adding this case under tests.
+
+Reported-by: Rabin Vincent <rabin.vinc...@axis.com>
+Signed-off-by: Jiri Olsa <jo...@kernel.org>
+Cc: David Ahern <dsah...@gmail.com>
+Cc: Namhyung Kim <namhy...@kernel.org>
+Cc: Paul Mackerras <pau...@samba.org>
+Cc: Peter Zijlstra <a.p.zijls...@chello.nl>
+Cc: Rabin Vincent <rabin.vinc...@axis.com>
+Link: 
http://lkml.kernel.org/r/1432914178-24086-1-git-send-email-jo...@kernel.org
+Signed-off-by: Arnaldo Carvalho de Melo <a...@redhat.com>
+---
+ tools/build/Makefile.build | 2 +-
+ tools/build/tests/ex/Build | 1 +
+ tools/build/tests/ex/empty2/README | 2 ++
+ 3 files changed, 4 insertions(+), 1 deletion(-)
+ create mode 100644 tools/build/tests/ex/empty2/README
+
+diff --git a/tools/build/Makefile.build b/tools/build/Makefile.build
+index 10df572..69c35cf 100644
+--- a/tools/build/Makefile.build
 b/tools/build/Makefile.build
+@@ -37,7 +37,7 @@ subdir-obj-y :=
+ 
+ # Build definitions
+ build-file := $(dir)/Build
+-include $(build-file)
++-include $(build-file)
+ 
+ quiet_cmd_flex  = FLEX $@
+ quiet_cmd_bison = BISON$@
+diff --git a/tools/build/tests/ex/Build b/tools/build/tests/ex/Build
+index 0e6c3e6..70d8762 100644
+--- a/tools/build/tests/ex/Build
 b/tools/build/tests/ex/Build
+@@ -2,6 +2,7 @@ ex-y += ex.o
+ ex-y += a.o
+ ex-y += b.o
+ ex-y += empty/
++ex-y += empty2/
+ 
+ libex-y += c.o
+ libex-y += d.o
+diff --git a/tools/build/tests/ex/empty2/README 
b/tools/build/tests/ex/empty2/README
+new file mode 100644
+index 000..2107cc5
+--- /dev/null
 b/tools/build/tests/ex/empty2/README
+@@ -0,0 +1,2 @@
++This directory is left intentionally without Build file
++to test proper nesting into Build-less directories.
+-- 
+2.1.4
+
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Package compile which requires Python.h

[Alexandru Ardelean]

Yep, seen this a couple of times.

You're building for an x86 target, but you're including the host Python's
Python.h file.
Any idea why this happens ? Or if you're include paths are ok ?

It could also [very likely] be a regression with the Python package.
If you want, you could show me your Makefile and I can try to figure out
what's wrong.

An example of a Python package that builds as  C extension is this:
https://github.com/wlanslovenija/firmware-packages-opkg/blob/master/lang/python-greenlet/Makefile

Here's a similar issue [a Github link] which is closed:
https://github.com/openwrt/packages/issues/518

Cheers
Alex

On Sun, Oct 18, 2015 at 2:08 AM, W. Michael Petullo  wrote:

> I am trying to create a new gobject-introspection package for
> OpenWrt. This package builds some code using Python.h. However, the
> configuration of gobject-introspection fails with the following appearing
> in config.log:
>
> configure:14641: i486-openwrt-linux-musl-gcc -E
> -I/home/mike/Source/openwrt/openwrt/staging_dir/target-i386_pentium4_musl-1.1.11/usr/include
> -I/home/mike/Source/openwrt/openwrt/staging_dir/target-i386_pentium4_musl-1.1.11/include
> -I/home/mike/Source/openwrt/openwrt/staging_dir/toolchain-i386_pentium4_gcc-4.8-linaro_musl-1.1.11/usr/include
> -I/home/mike/Source/openwrt/openwrt/staging_dir/toolchain-i386_pentium4_gcc-4.8-linaro_musl-1.1.11/include/fortify
> -I/home/mike/Source/openwrt/openwrt/staging_dir/toolchain-i386_pentium4_gcc-4.8-linaro_musl-1.1.11/include
> -I/home/mike/Source/openwrt/openwrt/staging_dir/target-i386_pentium4_musl-1.1.11/usr/lib/libiconv-stub/include
> -I/home/mike/Source/openwrt/openwrt/staging_dir/target-i386_pentium4_musl-1.1.11/usr/lib/libintl-stub/include
> -I/home/mike/Source/openwrt/openwrt/staging_dir/host/include/python2.7
> -I/home/mike/Source/openwrt/openwrt/staging_dir/host/include/python2.7
> conftest.c
> In file included from
> /home/mike/Source/openwrt/openwrt/staging_dir/host/include/python2.7/Python.h:8:0,
>  from conftest.c:42:
> /home/mike/Source/openwrt/openwrt/staging_dir/host/include/python2.7/pyconfig.h:1019:0:
> warning: "SIZEOF_LONG" redefined [enabled by default]
>  #define SIZEOF_LONG 8
>  ^
> conftest.c:30:0: note: this is the location of the previous definition
>  #define SIZEOF_LONG 4
>  ^
> In file included from
> /home/mike/Source/openwrt/openwrt/staging_dir/host/include/python2.7/Python.h:58:0,
>  from conftest.c:42:
> /home/mike/Source/openwrt/openwrt/staging_dir/host/include/python2.7/pyport.h:886:2:
> error: #error "LONG_BIT definition appears wrong for platform (bad
> gcc/glibc config?)."
>  #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc
> config?)."
>   ^
>
> Has anyone else seen this LONG_BIT check causing a problem when building
> a Python-related package?
>
> --
> Mike
>
> :wq
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] package/devel/perf: fix build for kernel 4.1

[Alexandru Ardelean]

This fix contains 2 parts:
 - kernel 4.1: backport upstream patch "perf build: Do not fail on missing 
Build file"
 - add +liblzma dependency

Signed-off-by: Alexandru Ardelean <ardeleana...@gmail.com>
---
 package/devel/perf/Makefile|  2 +-
 ...f-build-Do-not-fail-on-missing-Build-file.patch | 67 ++
 2 files changed, 68 insertions(+), 1 deletion(-)
 create mode 100644 
target/linux/generic/patches-4.1/222-perf-build-Do-not-fail-on-missing-Build-file.patch

diff --git a/package/devel/perf/Makefile b/package/devel/perf/Makefile
index b77e29a..5eba8f1 100644
--- a/package/devel/perf/Makefile
+++ b/package/devel/perf/Makefile
@@ -19,7 +19,7 @@ include $(INCLUDE_DIR)/package.mk
 define Package/perf
   SECTION:=devel
   CATEGORY:=Development
-  DEPENDS:= @USE_GLIBC +libelf1 +libdw +libpthread +librt +binutils
+  DEPENDS:= @USE_GLIBC +libelf1 +libdw +libpthread +librt +binutils +liblzma
   TITLE:=Linux performance monitoring tool
   VERSION:=$(LINUX_VERSION)-$(PKG_RELEASE)
   URL:=http://www.kernel.org
diff --git 
a/target/linux/generic/patches-4.1/222-perf-build-Do-not-fail-on-missing-Build-file.patch
 
b/target/linux/generic/patches-4.1/222-perf-build-Do-not-fail-on-missing-Build-file.patch
new file mode 100644
index 000..3fb2df6
--- /dev/null
+++ 
b/target/linux/generic/patches-4.1/222-perf-build-Do-not-fail-on-missing-Build-file.patch
@@ -0,0 +1,67 @@
+From d7a3d85e08477a979933a2bb3b525a8de99543c2 Mon Sep 17 00:00:00 2001
+From: Jiri Olsa <jo...@kernel.org>
+Date: Fri, 29 May 2015 17:42:58 +0200
+Subject: [PATCH] perf build: Do not fail on missing Build file
+
+Allow nesting into directories without Build file. Currently we force
+include of the Build file, which fails the build when the Build file is
+missing.
+
+We already support empty *-in.o' objects if there's nothing in the
+directory to be compiled, so we can just use it for missing Build file
+cases.
+
+Also adding this case under tests.
+
+Reported-by: Rabin Vincent <rabin.vinc...@axis.com>
+Signed-off-by: Jiri Olsa <jo...@kernel.org>
+Cc: David Ahern <dsah...@gmail.com>
+Cc: Namhyung Kim <namhy...@kernel.org>
+Cc: Paul Mackerras <pau...@samba.org>
+Cc: Peter Zijlstra <a.p.zijls...@chello.nl>
+Cc: Rabin Vincent <rabin.vinc...@axis.com>
+Link: 
http://lkml.kernel.org/r/1432914178-24086-1-git-send-email-jo...@kernel.org
+Signed-off-by: Arnaldo Carvalho de Melo <a...@redhat.com>
+---
+ tools/build/Makefile.build | 2 +-
+ tools/build/tests/ex/Build | 1 +
+ tools/build/tests/ex/empty2/README | 2 ++
+ 3 files changed, 4 insertions(+), 1 deletion(-)
+ create mode 100644 tools/build/tests/ex/empty2/README
+
+diff --git a/tools/build/Makefile.build b/tools/build/Makefile.build
+index 10df572..69c35cf 100644
+--- a/tools/build/Makefile.build
 b/tools/build/Makefile.build
+@@ -37,7 +37,7 @@ subdir-obj-y :=
+ 
+ # Build definitions
+ build-file := $(dir)/Build
+-include $(build-file)
++-include $(build-file)
+ 
+ quiet_cmd_flex  = FLEX $@
+ quiet_cmd_bison = BISON$@
+diff --git a/tools/build/tests/ex/Build b/tools/build/tests/ex/Build
+index 0e6c3e6..70d8762 100644
+--- a/tools/build/tests/ex/Build
 b/tools/build/tests/ex/Build
+@@ -2,6 +2,7 @@ ex-y += ex.o
+ ex-y += a.o
+ ex-y += b.o
+ ex-y += empty/
++ex-y += empty2/
+ 
+ libex-y += c.o
+ libex-y += d.o
+diff --git a/tools/build/tests/ex/empty2/README 
b/tools/build/tests/ex/empty2/README
+new file mode 100644
+index 000..2107cc5
+--- /dev/null
 b/tools/build/tests/ex/empty2/README
+@@ -0,0 +1,2 @@
++This directory is left intentionally without Build file
++to test proper nesting into Build-less directories.
+-- 
+2.1.4
+
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] lldpd: implement a reload hook

[Alexandru Ardelean]

From: Alexandru Ardelean <a...@ocedo.com>

Seems the default one is not working as expected.
The way that reload should work is that the 'start' service
call should return 1 (if lldpd is running) and then a normal
restart would be called.

However, for lldpd a reload would mean just clearing all custom TLVs
(if they're configured) and reloading the configuration.

So, this patch adds a reload hook, which would:
 - 'start' lldpd if it's not running (because we return 1 if not running)
 - reload configuration if it is running (also previously 
clearing custom TLVs if present)

Signed-off-by: Alexandru Ardelean <ardeleana...@gmail.com>
---
 package/network/services/lldpd/files/lldpd.init | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/package/network/services/lldpd/files/lldpd.init 
b/package/network/services/lldpd/files/lldpd.init
index 3d7d8b9..04e5b8c 100644
--- a/package/network/services/lldpd/files/lldpd.init
+++ b/package/network/services/lldpd/files/lldpd.init
@@ -4,6 +4,8 @@
 START=90
 
 USE_PROCD=1
+LLDPCLI=/usr/sbin/lldpcli
+LLDPSOCKET=/var/run/lldpd.socket
 
 find_release_info()
 {
@@ -71,6 +73,21 @@ start_service() {
procd_close_instance
 }
 
+service_running() {
+   pgrep -x /usr/sbin/lldpd &> /dev/null
+}
+
+reload_service() {
+   running || return 1
+   # Custom TLVs are special and should be
+   # reloaded from config during lldpd reload
+   $LLDPCLI -u $LLDPSOCKET unconfigure lldp custom-tlv &> /dev/null
+   $LLDPCLI -u $LLDPSOCKET -c /etc/lldpd.conf -c /etc/lldpd.d &> /dev/null
+   # Broadcast update over the wire
+   $LLDPCLI -u $LLDPSOCKET update &> /dev/null
+   return 0
+}
+
 stop_service() {
-   rm -f /var/run/lldpd.socket /var/run/lldpd.pid
+   rm -rf /var/run/lldp $LLDPSOCKET
 }
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH][RESEND] libnl: split libnl into smaller libraries

[Alexandru Ardelean]

Sure, will do.
Was going to open up some suggestions in that directions.

I also want to look into the part where other modules can build against
libnl (instead of libnl-tiny), when libnl selected.
Not sure how elegant that would become, but I'll look into it.


On Thu, Oct 1, 2015 at 7:33 PM, Rick Farina <sidh...@gmail.com> wrote:

> At least aircrack-ng wants genl as well as core.  Please feel free to
> fix aircrack-ng to dep properly when you make this change.
>
> Thanks,
> Zero_Chaos (openwrt maintainer of aircrack-ng)
>
> On 09/23/2015 04:17 AM, Alexandru Ardelean wrote:
> > From: Alexandru Ardelean <a...@ocedo.com>
> >
> > Some modules may require only libnl-genl, some
> > libnl-route and fewer would require libnl-nf.
> >
> > This patch splits the entire libnl package into smaller
> > more granular libs that can be installed individually as required.
> >
> > Also added libnl*.so symlinks for convenience.
> >
> > Signed-off-by: Alexandru Ardelean <ardeleana...@gmail.com>
> > ---
> >  package/libs/libnl/Makefile | 101
> ++--
> >  1 file changed, 88 insertions(+), 13 deletions(-)
> >
> > diff --git a/package/libs/libnl/Makefile b/package/libs/libnl/Makefile
> > index 995fda2..857bbe2 100644
> > --- a/package/libs/libnl/Makefile
> > +++ b/package/libs/libnl/Makefile
> > @@ -18,16 +18,61 @@ PKG_LICENSE:=LGPL-2.1
> >
> >  include $(INCLUDE_DIR)/package.mk
> >
> > -define Package/libnl
> > +define Package/libnl/default
> >SECTION:=libs
> >CATEGORY:=Libraries
> > -  TITLE:=netlink socket library
> > -  DEPENDS:=+libpthread
> >URL:=http://people.suug.ch/~tgr/libnl/
> >  endef
> >
> > +define Package/libnl-core
> > +$(call Package/libnl/default)
> > +  TITLE:=Core Netlink Library
> > +  DEPENDS:=+libpthread
> > +endef
> > +
> > +define Package/libnl-genl
> > +$(call Package/libnl/default)
> > +  TITLE:=Generic Netlink Library
> > +  DEPENDS:=+libnl-core
> > +endef
> > +
> > +define Package/libnl-route
> > +$(call Package/libnl/default)
> > +  TITLE:=Routing Netlink Library
> > +  DEPENDS:=+libnl-core
> > +endef
> > +
> > +define Package/libnl-nf
> > +$(call Package/libnl/default)
> > +  TITLE:=Netfilter Netlink Library
> > +  DEPENDS:=+libnl-route
> > +endef
> > +
> > +define Package/libnl
> > +$(call Package/libnl/default)
> > +  TITLE:=Full Netlink Library
> > +  DEPENDS:=+libnl-genl +libnl-route +libnl-nf
> > +endef
> > +
> > +define Package/libnl-core/description
> > + Common code for all netlink libraries
> > +endef
> > +
> > +define Package/libnl-genl/description
> > + Generic Netlink Library Functions
> > +endef
> > +
> > +define Package/libnl-route/description
> > + Routing Netlink Library Functions
> > +endef
> > +
> > +define Package/libnl-nf/description
> > + Netfilter Netlink Library Functions
> > +endef
> > +
> >  define Package/libnl/description
> > - This package contains a library for applications dealing with netlink
> sockets
> > + Socket handling, connection management, sending and receiving of data,
> > + message construction and parsing, object caching system, etc.
> >  endef
> >
> >  TARGET_CFLAGS += -ffunction-sections $(FPIC)
> > @@ -40,18 +85,48 @@ define Build/Compile
> >  endef
> >
> >  define Build/InstallDev
> > - $(INSTALL_DIR) $(1)
> > - $(CP) $(PKG_INSTALL_DIR)/* $(1)/
> > - mkdir -p $(1)/usr/include/libnl
> > - $(CP) $(PKG_BUILD_DIR)/include/linux $(1)/usr/include/libnl/
> > + $(INSTALL_DIR) $(1)/usr/include/libnl $(1)/usr/lib/pkgconfig
> > + $(CP) $(PKG_INSTALL_DIR)/usr/include/libnl3/*
> $(1)/usr/include/libnl/
> > + $(CP) $(PKG_INSTALL_DIR)/usr/lib/* $(1)/usr/lib
> > + $(CP) $(PKG_INSTALL_DIR)/usr/lib/pkgconfig/*.pc
> $(1)/usr/lib/pkgconfig
> > +
> > + # Copy symlinks
> > + $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-3.so $(1)/usr/lib/libnl.so
> > + $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-genl-3.so
> $(1)/usr/lib/libnl-genl.so
> > + $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-nf-3.so
> $(1)/usr/lib/libnl-nf.so
> > + $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-route-3.so
> $(1)/usr/lib/libnl-route.so
> >  endef
> >
> > -define Package/libnl/install
> > +define Package/libnl-core/install
> > + $(INSTALL_DIR) $(1)/usr/lib
> > + $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-3.so* $(1)/u

[OpenWrt-Devel] [PATCH] lldpd: wrap procd command args in separate quotes

[Alexandru Ardelean]

From: Alexandru Ardelean <a...@ocedo.com>

Seems the match pattern was being adapted from 'eth0' to ' eth0'
because of the way I added the procd command args.

This did not seem to be a problem when there were multiple interfaces,
just on devices with single interfaces for lldpd to listen on.

Signed-off-by: Alexandru Ardelean <ardeleana...@gmail.com>
---
 package/network/services/lldpd/files/lldpd.init | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/package/network/services/lldpd/files/lldpd.init 
b/package/network/services/lldpd/files/lldpd.init
index 278dbaf..3d7d8b9 100644
--- a/package/network/services/lldpd/files/lldpd.init
+++ b/package/network/services/lldpd/files/lldpd.init
@@ -54,14 +54,14 @@ start_service() {
procd_set_param command /usr/sbin/lldpd
procd_append_param command -d # don't daemonize, procd will handle that 
for us
 
-   [ -n "$ifnames" ] && procd_append_param command "-I $ifnames"
+   [ -n "$ifnames" ] && procd_append_param command -I "$ifnames"
[ $enable_cdp -gt 0 ] && procd_append_param command '-c'
[ $enable_fdp -gt 0 ] && procd_append_param command '-f'
[ $enable_sonmp -gt 0 ] && procd_append_param command '-s'
[ $enable_edp -gt 0 ] && procd_append_param command '-e'
[ $readonly_mode -gt 0 ] && procd_append_param command '-r'
-   [ -n "$lldp_class" ] && procd_append_param command "-M $lldp_class"
-   [ -n "$lldp_description" ] && procd_append_param command "-S 
$lldp_description"
+   [ -n "$lldp_class" ] && procd_append_param command -M "$lldp_class"
+   [ -n "$lldp_description" ] && procd_append_param command -S 
"$lldp_description"
 
# set auto respawn behavior
procd_set_param respawn
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH][RESEND] libnl: split libnl into smaller libraries

[Alexandru Ardelean]

From: Alexandru Ardelean <a...@ocedo.com>

Some modules may require only libnl-genl, some
libnl-route and fewer would require libnl-nf.

This patch splits the entire libnl package into smaller
more granular libs that can be installed individually as required.

Also added libnl*.so symlinks for convenience.

Signed-off-by: Alexandru Ardelean <ardeleana...@gmail.com>
---
 package/libs/libnl/Makefile | 101 ++--
 1 file changed, 88 insertions(+), 13 deletions(-)

diff --git a/package/libs/libnl/Makefile b/package/libs/libnl/Makefile
index 995fda2..857bbe2 100644
--- a/package/libs/libnl/Makefile
+++ b/package/libs/libnl/Makefile
@@ -18,16 +18,61 @@ PKG_LICENSE:=LGPL-2.1
 
 include $(INCLUDE_DIR)/package.mk
 
-define Package/libnl
+define Package/libnl/default
   SECTION:=libs
   CATEGORY:=Libraries
-  TITLE:=netlink socket library
-  DEPENDS:=+libpthread
   URL:=http://people.suug.ch/~tgr/libnl/
 endef
 
+define Package/libnl-core
+$(call Package/libnl/default)
+  TITLE:=Core Netlink Library
+  DEPENDS:=+libpthread
+endef
+
+define Package/libnl-genl
+$(call Package/libnl/default)
+  TITLE:=Generic Netlink Library
+  DEPENDS:=+libnl-core
+endef
+
+define Package/libnl-route
+$(call Package/libnl/default)
+  TITLE:=Routing Netlink Library
+  DEPENDS:=+libnl-core
+endef
+
+define Package/libnl-nf
+$(call Package/libnl/default)
+  TITLE:=Netfilter Netlink Library
+  DEPENDS:=+libnl-route
+endef
+
+define Package/libnl
+$(call Package/libnl/default)
+  TITLE:=Full Netlink Library
+  DEPENDS:=+libnl-genl +libnl-route +libnl-nf
+endef
+
+define Package/libnl-core/description
+ Common code for all netlink libraries
+endef
+
+define Package/libnl-genl/description
+ Generic Netlink Library Functions
+endef
+
+define Package/libnl-route/description
+ Routing Netlink Library Functions
+endef
+
+define Package/libnl-nf/description
+ Netfilter Netlink Library Functions
+endef
+
 define Package/libnl/description
- This package contains a library for applications dealing with netlink sockets
+ Socket handling, connection management, sending and receiving of data,
+ message construction and parsing, object caching system, etc.
 endef
 
 TARGET_CFLAGS += -ffunction-sections $(FPIC)
@@ -40,18 +85,48 @@ define Build/Compile
 endef
 
 define Build/InstallDev
-   $(INSTALL_DIR) $(1)
-   $(CP) $(PKG_INSTALL_DIR)/* $(1)/
-   mkdir -p $(1)/usr/include/libnl
-   $(CP) $(PKG_BUILD_DIR)/include/linux $(1)/usr/include/libnl/
+   $(INSTALL_DIR) $(1)/usr/include/libnl $(1)/usr/lib/pkgconfig
+   $(CP) $(PKG_INSTALL_DIR)/usr/include/libnl3/* $(1)/usr/include/libnl/
+   $(CP) $(PKG_INSTALL_DIR)/usr/lib/* $(1)/usr/lib
+   $(CP) $(PKG_INSTALL_DIR)/usr/lib/pkgconfig/*.pc $(1)/usr/lib/pkgconfig
+
+   # Copy symlinks
+   $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-3.so $(1)/usr/lib/libnl.so
+   $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-genl-3.so 
$(1)/usr/lib/libnl-genl.so
+   $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-nf-3.so $(1)/usr/lib/libnl-nf.so
+   $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-route-3.so 
$(1)/usr/lib/libnl-route.so
 endef
 
-define Package/libnl/install
+define Package/libnl-core/install
+   $(INSTALL_DIR) $(1)/usr/lib
+   $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-3.so* $(1)/usr/lib/
+   $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-3.so $(1)/usr/lib/libnl.so
+endef
+
+define Package/libnl-genl/install
$(INSTALL_DIR) $(1)/usr/lib
-   $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-route-3.so.* $(1)/usr/lib/
-   $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-genl-3.so.* $(1)/usr/lib/
-   $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-nf-3.so.* $(1)/usr/lib/
-   $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-3.so.* $(1)/usr/lib/
+   $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-genl-3.so* $(1)/usr/lib/
+   $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-genl-3.so 
$(1)/usr/lib/libnl-genl.so
+endef
+
+define Package/libnl-route/install
+   $(INSTALL_DIR) $(1)/usr/lib
+   $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-route-3.so* $(1)/usr/lib/
+   $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-route-3.so 
$(1)/usr/lib/libnl-route.so
+endef
+
+define Package/libnl-nf/install
+   $(INSTALL_DIR) $(1)/usr/lib
+   $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-nf-3.so* $(1)/usr/lib/
+   $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-nf-3.so $(1)/usr/lib/libnl-nf.so
+endef
+
+define Package/libnl/install
+   :
 endef
 
+$(eval $(call BuildPackage,libnl-core))
+$(eval $(call BuildPackage,libnl-genl))
+$(eval $(call BuildPackage,libnl-route))
+$(eval $(call BuildPackage,libnl-nf))
 $(eval $(call BuildPackage,libnl))
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] target/mpc85xx: add cuImage.tl-wdr4900-v1 kernel image if CONFIG_TL_WDR4900_V1=y

[Alexandru Ardelean]

From: Alexandru Ardelean <a...@ocedo.com>

Signed-off-by: Alexandru Ardelean <ardeleana...@gmail.com>
---
 target/linux/mpc85xx/Makefile | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/target/linux/mpc85xx/Makefile b/target/linux/mpc85xx/Makefile
index e43327a..bfc2c8d 100644
--- a/target/linux/mpc85xx/Makefile
+++ b/target/linux/mpc85xx/Makefile
@@ -16,7 +16,10 @@ SUBTARGETS=generic p1020
 
 KERNEL_PATCHVER:=3.18
 
-KERNEL_IMAGES := zImage cuImage.tl-wdr4900-v1
+KERNEL_IMAGES := zImage
+ifeq ($(CONFIG_TL_WDR4900_V1),y)
+KERNEL_IMAGES += cuImage.tl-wdr4900-v1
+endif
 
 include $(INCLUDE_DIR)/target.mk
 
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] target/mpc85xx: add cuImage.tl-wdr4900-v1 kernel image if CONFIG_TL_WDR4900_V1=y

[Alexandru Ardelean]

On Tue, Sep 22, 2015 at 4:45 PM, Felix Fietkau <n...@openwrt.org> wrote:

> On 2015-09-22 15:11, Alexandru Ardelean wrote:
> >
> >
> > On Tue, Sep 22, 2015 at 4:05 PM, Matthias Schiffer
> > <mschif...@universe-factory.net <mailto:mschif...@universe-factory.net>>
> > wrote:
> >
> > On 09/22/2015 06:25 PM, Alexandru Ardelean wrote:
> > > From: Alexandru Ardelean <a...@ocedo.com <mailto:a...@ocedo.com>>
> > >
> > > Signed-off-by: Alexandru Ardelean <ardeleana...@gmail.com
> > <mailto:ardeleana...@gmail.com>>
> > > ---
> > >  target/linux/mpc85xx/Makefile | 5 -
> > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/target/linux/mpc85xx/Makefile
> > b/target/linux/mpc85xx/Makefile
> > > index e43327a..bfc2c8d 100644
> > > --- a/target/linux/mpc85xx/Makefile
> > > +++ b/target/linux/mpc85xx/Makefile
> > > @@ -16,7 +16,10 @@ SUBTARGETS=generic p1020
> > >
> > >  KERNEL_PATCHVER:=3.18
> > >
> > > -KERNEL_IMAGES := zImage cuImage.tl-wdr4900-v1
> > > +KERNEL_IMAGES := zImage
> > > +ifeq ($(CONFIG_TL_WDR4900_V1),y)
> > > +KERNEL_IMAGES += cuImage.tl-wdr4900-v1
> > > +endif
> > >
> > >  include $(INCLUDE_DIR)/target.mk <http://target.mk>
> > >
> > >
> >
> > This doesn't work, CONFIG_TL_WDR4900_V1 is a kernel .config option,
> not
> > a OpenWrt .config option, and thus isn't available in OpenWrt
> Makefiles.
> > What is this supposed to fix?
> >
> >
> > Seems I'm confused here with the makefiles.
> >
> > For our case, removing that kernel image file is needed, because we
> > build our own mpc85xx image that is different from wdr4900-v1 ; so no
> > file named cuImage.tl-wdr4900-v1.
> > Ideally, I'd like to put it under a config option that disables/enables
> > this ; I will admit that I haven't tried the case where this is on.
> >
> > I'll try to find another option that disables this, that can also enable
> it.
> > Any suggestions ?
> Is this about non-upstream changes to the mpc85xx target? Or are you
> using a different subtarget?
> Either way, we should probably make the check for the 'generic'
> subtarget...
>
> - Felix
>

We use a different subtarget, and we're trying to find a solution for this
that is also upstream-able, in the idea that it makes sync-ing with
upstream easier.
Checking for the Generic subtarget sounds good.

Should I send a patch for that ?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] target/mpc85xx: add cuImage.tl-wdr4900-v1 kernel image if CONFIG_TL_WDR4900_V1=y

[Alexandru Ardelean]

On Tue, Sep 22, 2015 at 4:05 PM, Matthias Schiffer <
mschif...@universe-factory.net> wrote:

> On 09/22/2015 06:25 PM, Alexandru Ardelean wrote:
> > From: Alexandru Ardelean <a...@ocedo.com>
> >
> > Signed-off-by: Alexandru Ardelean <ardeleana...@gmail.com>
> > ---
> >  target/linux/mpc85xx/Makefile | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/target/linux/mpc85xx/Makefile
> b/target/linux/mpc85xx/Makefile
> > index e43327a..bfc2c8d 100644
> > --- a/target/linux/mpc85xx/Makefile
> > +++ b/target/linux/mpc85xx/Makefile
> > @@ -16,7 +16,10 @@ SUBTARGETS=generic p1020
> >
> >  KERNEL_PATCHVER:=3.18
> >
> > -KERNEL_IMAGES := zImage cuImage.tl-wdr4900-v1
> > +KERNEL_IMAGES := zImage
> > +ifeq ($(CONFIG_TL_WDR4900_V1),y)
> > +KERNEL_IMAGES += cuImage.tl-wdr4900-v1
> > +endif
> >
> >  include $(INCLUDE_DIR)/target.mk
> >
> >
>
> This doesn't work, CONFIG_TL_WDR4900_V1 is a kernel .config option, not
> a OpenWrt .config option, and thus isn't available in OpenWrt Makefiles.
> What is this supposed to fix?
>

Seems I'm confused here with the makefiles.

For our case, removing that kernel image file is needed, because we build
our own mpc85xx image that is different from wdr4900-v1 ; so no file named
cuImage.tl-wdr4900-v1.
Ideally, I'd like to put it under a config option that disables/enables
this ; I will admit that I haven't tried the case where this is on.

I'll try to find another option that disables this, that can also enable it.
Any suggestions ?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] libnl: split into smaller libraries

[Alexandru Ardelean]

On Thu, Sep 17, 2015 at 5:13 PM, Alexandru Ardelean <ardeleana...@gmail.com>
wrote:

>
>
> On Thu, Sep 17, 2015 at 4:50 PM, Felix Fietkau <n...@openwrt.org> wrote:
>
>> On 2015-09-17 15:05, Alexandru Ardelean wrote:
>> > From: Alexandru Ardelean <a...@ocedo.com>
>> >
>> > The idea is that we may only need the libnl core,
>> > or libnl-route or libnl-nf libs, but maybe not all of them.
>> >
>> > This way we can select which ones we need without bloating the
>> > firmware image too much.
>> >
>> > Signed-off-by: Alexandru Ardelean <ardeleana...@gmail.com>
>> Maybe it would be better to have libnl as a metapackage selecting
>> libnl-core + the other ones. The way you split the package, you might be
>> breaking some packages that depend on it.
>>
>> Or did you review all of the packages to ensure that they only need the
>> core?
>>
>> - Felix
>>
>
> Good point.
> I only took a look at base packages.
>
> Looking through the packages feed, there's keepalived , ibrcommon, kismet,
> bmon and aircrack-ng that depend on libnl.
> Other feeds don't have libnl deps.
>
> I'll check if libnl is sufficient and if not, implement your suggestion.
>
> Thanks
>
>
Seems I'll have to re-spin this patch.
There are a few things that need updating on it. They came up once I did a
full clean + rebuild.
I forgot about the staging dir stuff that piles up and causes
false-successes.

So,
- bmon requires libnl-route
- aircrack-ng requires libnl-genl
- kismet i am not sure 100% ; maybe libnl-genl ; I did not want to
investigate much deeper
- ibrcommon requires libnl-genl and libnl-route
- keepalived requires libnl-genl

Hopefully I got most of this right.

Now, here's the bloat for libnl:
- 86856 Sep 22 14:00 libnl-3.so.200.16.1
- 244304 Sep 22 14:00 libnl-route-3.so.200.16.1
- 16096 Sep 22 14:00 libnl-genl-3.so.200.16.1
- Seems libnl-nf is not needed. That's around 80k.
- libnl-tiny is 30k

Maybe aircrack-ng and keepalived could also work with [just] libnl-tiny,
but that's another discussion.

I need libnl-route for an upcoming new lldpd version, which will require
libnl-route.

The main reason I started this split, is because I need libnl-route, and I
am trying to minimise the bloat wherever I can.
I'll also see about pulling libnl-tiny out [in my case], since I'll be
stuck with needing libnl anyway.

Anyway, moving forward with the split:
1) Do I rename the libnl package to libnl-core and make libnl a metapackage
that pulls in everything ? or
2) Do I leave this structure as is (with the fixes/updates I'll add later)
and update those packages to pull only the libfiles that are needed ?
For 2), I'd of-course need the approval/blessing of the package maintainers
above.

>From my point of view any of these 2 approaches is fine, because I can just
pull whichever libnl-xxx package I need.

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

[OpenWrt-Devel] [PATCH] dropbear: add respawn param in case dropbear crashes

[Alexandru Ardelean]

Signed-off-by: Alexandru Ardelean <ardeleana...@gmail.com>
---
 package/network/services/dropbear/files/dropbear.init | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/network/services/dropbear/files/dropbear.init 
b/package/network/services/dropbear/files/dropbear.init
index 01d88af..03745c9 100755
--- a/package/network/services/dropbear/files/dropbear.init
+++ b/package/network/services/dropbear/files/dropbear.init
@@ -79,6 +79,7 @@ dropbear_instance()
[ "${IdleTimeout}" -ne 0 ] && procd_append_param command -I 
"${IdleTimeout}"
[ "${SSHKeepAlive}" -ne 0 ] && procd_append_param command -K 
"${SSHKeepAlive}"
[ "${mdns}" -ne 0 ] && procd_add_mdns "ssh" "tcp" "$Port" 
"daemon=dropbear"
+   procd_set_param respawn
procd_close_instance
 }
 
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] libnl: split into smaller libraries

[Alexandru Ardelean]

On Thu, Sep 17, 2015 at 4:50 PM, Felix Fietkau <n...@openwrt.org> wrote:

> On 2015-09-17 15:05, Alexandru Ardelean wrote:
> > From: Alexandru Ardelean <a...@ocedo.com>
> >
> > The idea is that we may only need the libnl core,
> > or libnl-route or libnl-nf libs, but maybe not all of them.
> >
> > This way we can select which ones we need without bloating the
> > firmware image too much.
> >
> > Signed-off-by: Alexandru Ardelean <ardeleana...@gmail.com>
> Maybe it would be better to have libnl as a metapackage selecting
> libnl-core + the other ones. The way you split the package, you might be
> breaking some packages that depend on it.
>
> Or did you review all of the packages to ensure that they only need the
> core?
>
> - Felix
>

Good point.
I only took a look at base packages.

Looking through the packages feed, there's keepalived , ibrcommon, kismet,
bmon and aircrack-ng that depend on libnl.
Other feeds don't have libnl deps.

I'll check if libnl is sufficient and if not, implement your suggestion.

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

[OpenWrt-Devel] [PATCH] libnl: split into smaller libraries

[Alexandru Ardelean]

From: Alexandru Ardelean <a...@ocedo.com>

The idea is that we may only need the libnl core, 
or libnl-route or libnl-nf libs, but maybe not all of them.

This way we can select which ones we need without bloating the
firmware image too much.

Signed-off-by: Alexandru Ardelean <ardeleana...@gmail.com>
---
 package/libs/libnl/Makefile | 62 -
 1 file changed, 56 insertions(+), 6 deletions(-)

diff --git a/package/libs/libnl/Makefile b/package/libs/libnl/Makefile
index 995fda2..4cdcfba 100644
--- a/package/libs/libnl/Makefile
+++ b/package/libs/libnl/Makefile
@@ -18,16 +18,51 @@ PKG_LICENSE:=LGPL-2.1
 
 include $(INCLUDE_DIR)/package.mk
 
-define Package/libnl
+define Package/libnl/default
   SECTION:=libs
   CATEGORY:=Libraries
-  TITLE:=netlink socket library
-  DEPENDS:=+libpthread
   URL:=http://people.suug.ch/~tgr/libnl/
 endef
 
+define Package/libnl
+$(call Package/libnl/default)
+  TITLE:=Core Netlink Library
+  DEPENDS:=+libpthread
+endef
+
+define Package/libnl-genl
+$(call Package/libnl/default)
+  TITLE:=Generic Netlink Library
+  DEPENDS:=+libnl
+endef
+
+define Package/libnl-nf
+$(call Package/libnl/default)
+  TITLE:=Netfilter Netlink Library
+  DEPENDS:=+libnl
+endef
+
+define Package/libnl-route
+$(call Package/libnl/default)
+  TITLE:=Routing Netlink Library
+  DEPENDS:=+libnl
+endef
+
 define Package/libnl/description
- This package contains a library for applications dealing with netlink sockets
+ Socket handling, connection management, sending and receiving of data,
+ message construction and parsing, object caching system, etc.
+endef
+
+define Package/libnl-genl/description
+ Generic Netlink Library Functions
+endef
+
+define Package/libnl-nf/description
+ Netfilter Netlink Library Functions
+endef
+
+define Package/libnl-route/description
+ Routing Netlink Library Functions
 endef
 
 TARGET_CFLAGS += -ffunction-sections $(FPIC)
@@ -48,10 +83,25 @@ endef
 
 define Package/libnl/install
$(INSTALL_DIR) $(1)/usr/lib
-   $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-route-3.so.* $(1)/usr/lib/
+   $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-3.so.* $(1)/usr/lib/
+endef
+
+define Package/libnl-genl/install
+   $(INSTALL_DIR) $(1)/usr/lib
$(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-genl-3.so.* $(1)/usr/lib/
+endef
+
+define Package/libnl-nf/install
+   $(INSTALL_DIR) $(1)/usr/lib
$(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-nf-3.so.* $(1)/usr/lib/
-   $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-3.so.* $(1)/usr/lib/
+endef
+
+define Package/libnl-route/install
+   $(INSTALL_DIR) $(1)/usr/lib
+   $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-route-3.so.* $(1)/usr/lib/
 endef
 
 $(eval $(call BuildPackage,libnl))
+$(eval $(call BuildPackage,libnl-genl))
+$(eval $(call BuildPackage,libnl-nf))
+$(eval $(call BuildPackage,libnl-route))
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Using procd for USB hotplug detection

[Alexandru Ardelean]

procd is for service handling mostly; so, start/stop/etc
basically you'd need to have another service that does usb-device handling
(of that device).

what i'd do, is to write a hotplug script, add it under /etc/hotplug.d and
then call whatever needs to be called from that script
it can be a ubus call to procd, or to some other service (ubus or not ubus)


On Sat, Aug 29, 2015 at 9:20 PM, Lazar Demin la...@onion.io wrote:

 Hi,

 I am trying to figure out how I can use procd to detect when a new usb
 device comes up.

 The wiki (http://wiki.openwrt.org/doc/techref/procd) was pretty vague
 on the proper usage of procd.
 The procd init script wiki
 (http://wiki.openwrt.org/inbox/procd-init-scripts) wasn't particularly
 illuminating either and looks like its mostly geared towards whether
 or not to restart the daemon based on if a configuration file (or
 network interface) has changed.

 Is there a way to use procd to detect a new usb device in a similar
 way to the hotplug deamon? Can somebody point me in the right
 direction?

 I'm currently using fstab to automatically mount any usb-storage, but
 ideally I would like to know the device name and type.


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

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

Re: [OpenWrt-Devel] Openvswitch package not available in trunk

[Alexandru Ardelean]

OVS seems to work fine if I compile it with uClibc instead of musl
On x86 (kernel 4.1 added manually) + uClibc + OVS 2.4 it works fine
On x86 (kernel 4.1 added manually) + musl + OVS 2.4 it seems to segfault

Will keep looking.


On Tue, Aug 11, 2015 at 12:05 PM, Alexandru Ardelean ardeleana...@gmail.com
 wrote:

 Will make some more time to try this.

 Thanks for testing

 On Mon, Aug 10, 2015 at 5:50 PM, Florian Siebertz 
 florian.siebe...@inf.h-brs.de wrote:

 Today I compiled with your fork and everything seemed fine at first.
 After flashing to a TP-Link WDR3600 Router I can see the ovsdb-server
 running
 and ovs-vsctl show reveals the usual String ID.

 When I try to add a bridge with ovs-vsctl add-br br0 the command does
 not return
 to the input prompt. After pressing ctrl+c and checking ovs-vsctl show
 it seems like
 the bridge was created. The same happens when adding ports or changing any
 settings on the bridge.

 Additionally, the switch does not connect to the controller. I'm not sure
 how to debug
 this further, but if you have an idea I will test it on the device.


 Am 07.08.2015 um 16:14 schrieb Alexandru Ardelean:
  @Florian
  So, I took some time today to patch a bit of support for OVS to compile
 on
  OpenWRT with kernel 4.1
 
  Can you pull this from my fork and test it out a bit ?
  Branch is here: https://github.com/commodo/packages/tree/ovs-kernel-4.1
  Commit is this one:
 
 https://github.com/commodo/packages/commit/de519aac8c751cd8744d839efd071cdf02891db1
 
  If you need a tarball, send me a message and I can prepare one, or maybe
  Github has a download zip/tar button per branches somewhere not sure.
 
  Anyway, I'd appreciate if you took the time to test it out a bit.
  I'm a bit swamped and don't have time to do proper testing ; to be
 honest I
  just made it build, and I haven't managed to get hold of a device with
  which to actually test it.
  If all is good I'll add a PR into the official OpenWRT packages.
 
  Thanks
 
  On Wed, Aug 5, 2015 at 5:18 PM, Alexandru Ardelean 
 ardeleana...@gmail.com
  wrote:
 
  I will admit I only tested with x86.
  I ASSumed that it's on kernel 4.1.
 
  Will check again and try to spin up a patch for kernel 4.1.
 
  On Wed, Aug 5, 2015 at 3:53 PM, Florian Siebertz 
  florian.siebe...@inf.h-brs.de wrote:
 
  Thank you for your work, i really appreciate it.
  Now the package is back, but at compilation it fails when
  checking against the kernel version:
 
  (cd
 
 /home/administrator/openwrt/build_dir/target-mips_34kc_musl-1.1.10/openvswitch-2.4.0/./;
  if [ -x ./configure ]; then find
 
 /home/administrator/openwrt/build_dir/target-mips_34kc_musl-1.1.10/openvswitch-2.4.0/
  -name config.guess | xargs -r chmod u+w; find
 
 /home/administrator/openwrt/build_dir/target-mips_34kc_musl-1.1.10/openvswitch-2.4.0/
  -name config.guess | xargs -r -n1 cp --remove-destination
  /home/administrator/openwrt/scripts/config.guess; find
 
 /home/administrator/openwrt/build_dir/target-mips_34kc_musl-1.1.10/openvswitch-2.4.0/
  -name config.sub | xargs -r chmod u+w; find
 
 /home/administrator/openwrt/build_dir/target-mips_34kc_musl-1.1.10/openvswitch-2.4.0/
  -name config.sub | xargs -r -n1 cp --remove-destination
  /home/administrator/openwrt/scripts/config.sub;
  AR=mips-openwrt-linux-musl-gcc-ar AS=mips-openwrt-linux-musl-gcc
 -c -Os
  -pipe -mno-branch-likely -mips32r2 -mtune=34kc -fno-caller-saves
  -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float
 -Wformat !
   -Werror=fo
  rmat-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now
  -Wl,-z,relro -mno-mips16 -mno-interlink-mips16 -flto -std=gnu99
  LD=mips-openwrt-linux-musl-ld NM=mips-openwrt-linux-musl-gcc-nm
  CC=mips-openwrt-linux-musl-gcc GCC=mips-openwrt-linux-musl-gcc
  CXX=mips-openwrt-linux-musl-g++
  RANLIB=mips-openwrt-linux-musl-gcc-ranlib
  STRIP=mips-openwrt-linux-musl-strip
 OBJCOPY=mips-openwrt-linux-musl-objcopy
  OBJDUMP=mips-openwrt-linux-musl-objdump
 SIZE=mips-openwrt-linux-musl-size
  CFLAGS=-Os -pipe -mno-branch-likely -mips32r2 -mtune=34kc
  -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable
  -msoft-float -Wformat -Werror=format-security -fstack-protector
  -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -mno-mips16
  -mno-interlink-mips16 -flto -std=gnu99  CXXFLAGS=-Os -pipe
  -mno-branch-likely -mips32r2 -mtune=34kc -fno-caller-saves
 -fhonour-copts
  -Wno-error=unused-but-set-variable -msoft-float -Wformat
  -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1!
-Wl,-z,no
  w -Wl,-z,relro -mno-mips16 -mno-interlink-mips16 -flto -std=gnu99 
 
 CPPFLAGS=-I/home/administrator/openwrt/staging_dir/target-mips_34kc_musl-1.1.10/usr/include
 
 -I/home/administrator/openwrt/staging_dir/target-mips_34kc_musl-1.1.10/include
 
 -I/home/administrator/openwrt/staging_dir/toolchain-mips_34kc_gcc-4.8-linaro_musl-1.1.10/usr/include
 
 -I/home/administrator/openwrt/staging_dir/toolchain-mips_34kc_gcc-4.8-linaro_musl-1.1.10/include/fortify
 
 -I

[OpenWrt-Devel] [PATCH 2/4] lldpd: move /var/run creation + chmod earlier

[Alexandru Ardelean]

Signed-off-by: Alexandru Ardelean a...@ocedo.com
---
 package/network/services/lldpd/files/lldpd.init | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/package/network/services/lldpd/files/lldpd.init 
b/package/network/services/lldpd/files/lldpd.init
index 4b49cbd..bd957b6 100644
--- a/package/network/services/lldpd/files/lldpd.init
+++ b/package/network/services/lldpd/files/lldpd.init
@@ -47,6 +47,9 @@ start() {
fi
done
 
+   mkdir -p /var/run/lldp
+   chown lldp:lldp /var/run/lldp
+
[ -n $ifnames ]  append args -I $ifnames
[ $enable_cdp -gt 0 ]  append args '-c'
[ $enable_fdp -gt 0 ]  append args '-f'
@@ -54,9 +57,6 @@ start() {
[ $enable_edp -gt 0 ]  append args '-e'
[ $readonly_mode -gt 0 ]  append args '-r'
 
-   mkdir -p /var/run/lldp
-   chown lldp:lldp /var/run/lldp
-
service_start /usr/sbin/lldpd $args \
${lldp_class:+ -M $lldp_class} \
${lldp_description:+ -S $lldp_description}
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/4] lldpd: remove obsolete/unsupported lldpctl call

[Alexandru Ardelean]

This call is no longer supported.
Maybe a come-back for it would be to use a config /etc/lldpd.conf
or /etc/lldpd.d/some-file.conf

Signed-off-by: Alexandru Ardelean a...@ocedo.com
---
 package/network/services/lldpd/files/lldpd.init | 5 -
 1 file changed, 5 deletions(-)

diff --git a/package/network/services/lldpd/files/lldpd.init 
b/package/network/services/lldpd/files/lldpd.init
index 40f2611..4b49cbd 100644
--- a/package/network/services/lldpd/files/lldpd.init
+++ b/package/network/services/lldpd/files/lldpd.init
@@ -60,11 +60,6 @@ start() {
service_start /usr/sbin/lldpd $args \
${lldp_class:+ -M $lldp_class} \
${lldp_description:+ -S $lldp_description}
-
-   [ -n $lldp_location ]  {
-   sleep 1
-   /usr/sbin/lldpctl -L $lldp_location  /dev/null 21
-   }
 }
 
 stop() {
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 3/4] lldpd: conversion of init script to procd format

[Alexandru Ardelean]

And add respawn param (the main reason for this conversion).

Signed-off-by: Alexandru Ardelean a...@ocedo.com
---
 package/network/services/lldpd/files/lldpd.init | 31 ++---
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/package/network/services/lldpd/files/lldpd.init 
b/package/network/services/lldpd/files/lldpd.init
index bd957b6..fca0ebf 100644
--- a/package/network/services/lldpd/files/lldpd.init
+++ b/package/network/services/lldpd/files/lldpd.init
@@ -3,7 +3,7 @@
 
 START=90
 
-SERVICE_USE_PID=1
+USE_PROCD=1
 
 find_release_info()
 {
@@ -14,7 +14,7 @@ find_release_info()
echo ${DISTRIB_DESCRIPTION:-Unknown OpenWrt release} @ $(cat 
/proc/sys/kernel/hostname)
 }
 
-start() {
+start_service() {
. /lib/functions/network.sh
 
local enable_cdp
@@ -50,19 +50,24 @@ start() {
mkdir -p /var/run/lldp
chown lldp:lldp /var/run/lldp
 
-   [ -n $ifnames ]  append args -I $ifnames
-   [ $enable_cdp -gt 0 ]  append args '-c'
-   [ $enable_fdp -gt 0 ]  append args '-f'
-   [ $enable_sonmp -gt 0 ]  append args '-s'
-   [ $enable_edp -gt 0 ]  append args '-e'
-   [ $readonly_mode -gt 0 ]  append args '-r'
+   procd_open_instance
+   procd_set_param command /usr/sbin/lldpd
+   procd_append_param command -d # don't daemonize, procd will handle that 
for us
 
-   service_start /usr/sbin/lldpd $args \
-   ${lldp_class:+ -M $lldp_class} \
-   ${lldp_description:+ -S $lldp_description}
+   [ -n $ifnames ]  procd_append_param command -I $ifnames
+   [ $enable_cdp -gt 0 ]  procd_append_param command '-c'
+   [ $enable_fdp -gt 0 ]  procd_append_param command '-f'
+   [ $enable_sonmp -gt 0 ]  procd_append_param command '-s'
+   [ $enable_edp -gt 0 ]  procd_append_param command '-e'
+   [ $readonly_mode -gt 0 ]  procd_append_param command '-r'
+   [ -n $lldp_class ]  procd_append_param command -M $lldp_class
+   [ -n $lldp_description ]  procd_append_param command -S 
$lldp_description
+
+   # set auto respawn behavior
+   procd_set_param respawn
+   procd_close_instance
 }
 
-stop() {
-   service_stop /usr/sbin/lldpd
+stop_service() {
rm -f /var/run/lldpd.socket /var/run/lldpd.pid
 }
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Openvswitch package not available in trunk

[Alexandru Ardelean]

Will make some more time to try this.

Thanks for testing

On Mon, Aug 10, 2015 at 5:50 PM, Florian Siebertz 
florian.siebe...@inf.h-brs.de wrote:

 Today I compiled with your fork and everything seemed fine at first.
 After flashing to a TP-Link WDR3600 Router I can see the ovsdb-server
 running
 and ovs-vsctl show reveals the usual String ID.

 When I try to add a bridge with ovs-vsctl add-br br0 the command does
 not return
 to the input prompt. After pressing ctrl+c and checking ovs-vsctl show
 it seems like
 the bridge was created. The same happens when adding ports or changing any
 settings on the bridge.

 Additionally, the switch does not connect to the controller. I'm not sure
 how to debug
 this further, but if you have an idea I will test it on the device.


 Am 07.08.2015 um 16:14 schrieb Alexandru Ardelean:
  @Florian
  So, I took some time today to patch a bit of support for OVS to compile
 on
  OpenWRT with kernel 4.1
 
  Can you pull this from my fork and test it out a bit ?
  Branch is here: https://github.com/commodo/packages/tree/ovs-kernel-4.1
  Commit is this one:
 
 https://github.com/commodo/packages/commit/de519aac8c751cd8744d839efd071cdf02891db1
 
  If you need a tarball, send me a message and I can prepare one, or maybe
  Github has a download zip/tar button per branches somewhere not sure.
 
  Anyway, I'd appreciate if you took the time to test it out a bit.
  I'm a bit swamped and don't have time to do proper testing ; to be
 honest I
  just made it build, and I haven't managed to get hold of a device with
  which to actually test it.
  If all is good I'll add a PR into the official OpenWRT packages.
 
  Thanks
 
  On Wed, Aug 5, 2015 at 5:18 PM, Alexandru Ardelean 
 ardeleana...@gmail.com
  wrote:
 
  I will admit I only tested with x86.
  I ASSumed that it's on kernel 4.1.
 
  Will check again and try to spin up a patch for kernel 4.1.
 
  On Wed, Aug 5, 2015 at 3:53 PM, Florian Siebertz 
  florian.siebe...@inf.h-brs.de wrote:
 
  Thank you for your work, i really appreciate it.
  Now the package is back, but at compilation it fails when
  checking against the kernel version:
 
  (cd
 
 /home/administrator/openwrt/build_dir/target-mips_34kc_musl-1.1.10/openvswitch-2.4.0/./;
  if [ -x ./configure ]; then find
 
 /home/administrator/openwrt/build_dir/target-mips_34kc_musl-1.1.10/openvswitch-2.4.0/
  -name config.guess | xargs -r chmod u+w; find
 
 /home/administrator/openwrt/build_dir/target-mips_34kc_musl-1.1.10/openvswitch-2.4.0/
  -name config.guess | xargs -r -n1 cp --remove-destination
  /home/administrator/openwrt/scripts/config.guess; find
 
 /home/administrator/openwrt/build_dir/target-mips_34kc_musl-1.1.10/openvswitch-2.4.0/
  -name config.sub | xargs -r chmod u+w; find
 
 /home/administrator/openwrt/build_dir/target-mips_34kc_musl-1.1.10/openvswitch-2.4.0/
  -name config.sub | xargs -r -n1 cp --remove-destination
  /home/administrator/openwrt/scripts/config.sub;
  AR=mips-openwrt-linux-musl-gcc-ar AS=mips-openwrt-linux-musl-gcc -c
 -Os
  -pipe -mno-branch-likely -mips32r2 -mtune=34kc -fno-caller-saves
  -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float
 -Wformat !
   -Werror=fo
  rmat-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now
  -Wl,-z,relro -mno-mips16 -mno-interlink-mips16 -flto -std=gnu99
  LD=mips-openwrt-linux-musl-ld NM=mips-openwrt-linux-musl-gcc-nm
  CC=mips-openwrt-linux-musl-gcc GCC=mips-openwrt-linux-musl-gcc
  CXX=mips-openwrt-linux-musl-g++
  RANLIB=mips-openwrt-linux-musl-gcc-ranlib
  STRIP=mips-openwrt-linux-musl-strip
 OBJCOPY=mips-openwrt-linux-musl-objcopy
  OBJDUMP=mips-openwrt-linux-musl-objdump
 SIZE=mips-openwrt-linux-musl-size
  CFLAGS=-Os -pipe -mno-branch-likely -mips32r2 -mtune=34kc
  -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable
  -msoft-float -Wformat -Werror=format-security -fstack-protector
  -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -mno-mips16
  -mno-interlink-mips16 -flto -std=gnu99  CXXFLAGS=-Os -pipe
  -mno-branch-likely -mips32r2 -mtune=34kc -fno-caller-saves
 -fhonour-copts
  -Wno-error=unused-but-set-variable -msoft-float -Wformat
  -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1!
-Wl,-z,no
  w -Wl,-z,relro -mno-mips16 -mno-interlink-mips16 -flto -std=gnu99 
 
 CPPFLAGS=-I/home/administrator/openwrt/staging_dir/target-mips_34kc_musl-1.1.10/usr/include
 
 -I/home/administrator/openwrt/staging_dir/target-mips_34kc_musl-1.1.10/include
 
 -I/home/administrator/openwrt/staging_dir/toolchain-mips_34kc_gcc-4.8-linaro_musl-1.1.10/usr/include
 
 -I/home/administrator/openwrt/staging_dir/toolchain-mips_34kc_gcc-4.8-linaro_musl-1.1.10/include/fortify
 
 -I/home/administrator/openwrt/staging_dir/toolchain-mips_34kc_gcc-4.8-linaro_musl-1.1.10/include
  
 
 LDFLAGS=-L/home/administrator/openwrt/staging_dir/target-mips_34kc_musl-1.1.10/usr/lib
 
 -L/home/administrator/openwrt/staging_dir/target-mips_34kc_musl-1.1.10/lib
 
 -L/home/administrator/openwrt/staging_dir/toolchain

Re: [OpenWrt-Devel] Openvswitch package not available in trunk

[Alexandru Ardelean]

@Florian
So, I took some time today to patch a bit of support for OVS to compile on
OpenWRT with kernel 4.1

Can you pull this from my fork and test it out a bit ?
Branch is here: https://github.com/commodo/packages/tree/ovs-kernel-4.1
Commit is this one:
https://github.com/commodo/packages/commit/de519aac8c751cd8744d839efd071cdf02891db1

If you need a tarball, send me a message and I can prepare one, or maybe
Github has a download zip/tar button per branches somewhere not sure.

Anyway, I'd appreciate if you took the time to test it out a bit.
I'm a bit swamped and don't have time to do proper testing ; to be honest I
just made it build, and I haven't managed to get hold of a device with
which to actually test it.
If all is good I'll add a PR into the official OpenWRT packages.

Thanks

On Wed, Aug 5, 2015 at 5:18 PM, Alexandru Ardelean ardeleana...@gmail.com
wrote:

 I will admit I only tested with x86.
 I ASSumed that it's on kernel 4.1.

 Will check again and try to spin up a patch for kernel 4.1.

 On Wed, Aug 5, 2015 at 3:53 PM, Florian Siebertz 
 florian.siebe...@inf.h-brs.de wrote:

 Thank you for your work, i really appreciate it.
 Now the package is back, but at compilation it fails when
 checking against the kernel version:

 (cd
 /home/administrator/openwrt/build_dir/target-mips_34kc_musl-1.1.10/openvswitch-2.4.0/./;
 if [ -x ./configure ]; then find
 /home/administrator/openwrt/build_dir/target-mips_34kc_musl-1.1.10/openvswitch-2.4.0/
 -name config.guess | xargs -r chmod u+w; find
 /home/administrator/openwrt/build_dir/target-mips_34kc_musl-1.1.10/openvswitch-2.4.0/
 -name config.guess | xargs -r -n1 cp --remove-destination
 /home/administrator/openwrt/scripts/config.guess; find
 /home/administrator/openwrt/build_dir/target-mips_34kc_musl-1.1.10/openvswitch-2.4.0/
 -name config.sub | xargs -r chmod u+w; find
 /home/administrator/openwrt/build_dir/target-mips_34kc_musl-1.1.10/openvswitch-2.4.0/
 -name config.sub | xargs -r -n1 cp --remove-destination
 /home/administrator/openwrt/scripts/config.sub;
 AR=mips-openwrt-linux-musl-gcc-ar AS=mips-openwrt-linux-musl-gcc -c -Os
 -pipe -mno-branch-likely -mips32r2 -mtune=34kc -fno-caller-saves
 -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -Wformat !
  -Werror=fo
 rmat-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now
 -Wl,-z,relro -mno-mips16 -mno-interlink-mips16 -flto -std=gnu99
 LD=mips-openwrt-linux-musl-ld NM=mips-openwrt-linux-musl-gcc-nm
 CC=mips-openwrt-linux-musl-gcc GCC=mips-openwrt-linux-musl-gcc
 CXX=mips-openwrt-linux-musl-g++
 RANLIB=mips-openwrt-linux-musl-gcc-ranlib
 STRIP=mips-openwrt-linux-musl-strip OBJCOPY=mips-openwrt-linux-musl-objcopy
 OBJDUMP=mips-openwrt-linux-musl-objdump SIZE=mips-openwrt-linux-musl-size
 CFLAGS=-Os -pipe -mno-branch-likely -mips32r2 -mtune=34kc
 -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable
 -msoft-float -Wformat -Werror=format-security -fstack-protector
 -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -mno-mips16
 -mno-interlink-mips16 -flto -std=gnu99  CXXFLAGS=-Os -pipe
 -mno-branch-likely -mips32r2 -mtune=34kc -fno-caller-saves -fhonour-copts
 -Wno-error=unused-but-set-variable -msoft-float -Wformat
 -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1!
   -Wl,-z,no
 w -Wl,-z,relro -mno-mips16 -mno-interlink-mips16 -flto -std=gnu99 
 CPPFLAGS=-I/home/administrator/openwrt/staging_dir/target-mips_34kc_musl-1.1.10/usr/include
 -I/home/administrator/openwrt/staging_dir/target-mips_34kc_musl-1.1.10/include
 -I/home/administrator/openwrt/staging_dir/toolchain-mips_34kc_gcc-4.8-linaro_musl-1.1.10/usr/include
 -I/home/administrator/openwrt/staging_dir/toolchain-mips_34kc_gcc-4.8-linaro_musl-1.1.10/include/fortify
 -I/home/administrator/openwrt/staging_dir/toolchain-mips_34kc_gcc-4.8-linaro_musl-1.1.10/include
 
 LDFLAGS=-L/home/administrator/openwrt/staging_dir/target-mips_34kc_musl-1.1.10/usr/lib
 -L/home/administrator/openwrt/staging_dir/target-mips_34kc_musl-1.1.10/lib
 -L/home/administrator/openwrt/staging_dir/toolchain-mips_34kc_gcc-4.8-linaro_musl-1.1.10/usr/lib
 -L/home/administrator/openwrt/staging_dir/toolchain-mips_34kc_gcc-4.8-linaro_musl-1.1.10/lib
 -znow -zrelro./configure --target=mips-openwrt-linux
 --host=mips-openwrt-linux --build!
  =x86_64-li
 nux-gnu --program-prefix= --program-suffix= --prefix=/usr
 --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
 --libexecdir=/usr/lib --sysconfdir=/etc --datadir=/usr/share
 --localstatedir=/var --mandir=/usr/man --infodir=/usr/info --disable-nls
  
 _python_sysroot=/home/administrator/openwrt/staging_dir/target-mips_34kc_musl-1.1.10
 _python_prefix=/usr _python_exec_prefix=/usr
 --with-linux=/home/administrator/openwrt/build_dir/target-mips_34kc_musl-1.1.10/linux-ar71xx_generic/linux-4.1.3
 --with-rundir=/var/run --enable-ndebug --disable-ssl --enable-shared ; fi; )

 [...] (a bunch of checks)

 checking for kernel version... 4.1.3
 configure: error: Linux kernel in
 /home/administrator

Re: [OpenWrt-Devel] Openvswitch package not available in trunk

[Alexandru Ardelean]

I will admit I only tested with x86.
I ASSumed that it's on kernel 4.1.

Will check again and try to spin up a patch for kernel 4.1.

On Wed, Aug 5, 2015 at 3:53 PM, Florian Siebertz 
florian.siebe...@inf.h-brs.de wrote:

 Thank you for your work, i really appreciate it.
 Now the package is back, but at compilation it fails when
 checking against the kernel version:

 (cd
 /home/administrator/openwrt/build_dir/target-mips_34kc_musl-1.1.10/openvswitch-2.4.0/./;
 if [ -x ./configure ]; then find
 /home/administrator/openwrt/build_dir/target-mips_34kc_musl-1.1.10/openvswitch-2.4.0/
 -name config.guess | xargs -r chmod u+w; find
 /home/administrator/openwrt/build_dir/target-mips_34kc_musl-1.1.10/openvswitch-2.4.0/
 -name config.guess | xargs -r -n1 cp --remove-destination
 /home/administrator/openwrt/scripts/config.guess; find
 /home/administrator/openwrt/build_dir/target-mips_34kc_musl-1.1.10/openvswitch-2.4.0/
 -name config.sub | xargs -r chmod u+w; find
 /home/administrator/openwrt/build_dir/target-mips_34kc_musl-1.1.10/openvswitch-2.4.0/
 -name config.sub | xargs -r -n1 cp --remove-destination
 /home/administrator/openwrt/scripts/config.sub;
 AR=mips-openwrt-linux-musl-gcc-ar AS=mips-openwrt-linux-musl-gcc -c -Os
 -pipe -mno-branch-likely -mips32r2 -mtune=34kc -fno-caller-saves
 -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -Wformat !
  -Werror=fo
 rmat-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now
 -Wl,-z,relro -mno-mips16 -mno-interlink-mips16 -flto -std=gnu99
 LD=mips-openwrt-linux-musl-ld NM=mips-openwrt-linux-musl-gcc-nm
 CC=mips-openwrt-linux-musl-gcc GCC=mips-openwrt-linux-musl-gcc
 CXX=mips-openwrt-linux-musl-g++
 RANLIB=mips-openwrt-linux-musl-gcc-ranlib
 STRIP=mips-openwrt-linux-musl-strip OBJCOPY=mips-openwrt-linux-musl-objcopy
 OBJDUMP=mips-openwrt-linux-musl-objdump SIZE=mips-openwrt-linux-musl-size
 CFLAGS=-Os -pipe -mno-branch-likely -mips32r2 -mtune=34kc
 -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable
 -msoft-float -Wformat -Werror=format-security -fstack-protector
 -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -mno-mips16
 -mno-interlink-mips16 -flto -std=gnu99  CXXFLAGS=-Os -pipe
 -mno-branch-likely -mips32r2 -mtune=34kc -fno-caller-saves -fhonour-copts
 -Wno-error=unused-but-set-variable -msoft-float -Wformat
 -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1!
   -Wl,-z,no
 w -Wl,-z,relro -mno-mips16 -mno-interlink-mips16 -flto -std=gnu99 
 CPPFLAGS=-I/home/administrator/openwrt/staging_dir/target-mips_34kc_musl-1.1.10/usr/include
 -I/home/administrator/openwrt/staging_dir/target-mips_34kc_musl-1.1.10/include
 -I/home/administrator/openwrt/staging_dir/toolchain-mips_34kc_gcc-4.8-linaro_musl-1.1.10/usr/include
 -I/home/administrator/openwrt/staging_dir/toolchain-mips_34kc_gcc-4.8-linaro_musl-1.1.10/include/fortify
 -I/home/administrator/openwrt/staging_dir/toolchain-mips_34kc_gcc-4.8-linaro_musl-1.1.10/include
 
 LDFLAGS=-L/home/administrator/openwrt/staging_dir/target-mips_34kc_musl-1.1.10/usr/lib
 -L/home/administrator/openwrt/staging_dir/target-mips_34kc_musl-1.1.10/lib
 -L/home/administrator/openwrt/staging_dir/toolchain-mips_34kc_gcc-4.8-linaro_musl-1.1.10/usr/lib
 -L/home/administrator/openwrt/staging_dir/toolchain-mips_34kc_gcc-4.8-linaro_musl-1.1.10/lib
 -znow -zrelro./configure --target=mips-openwrt-linux
 --host=mips-openwrt-linux --build!
  =x86_64-li
 nux-gnu --program-prefix= --program-suffix= --prefix=/usr
 --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
 --libexecdir=/usr/lib --sysconfdir=/etc --datadir=/usr/share
 --localstatedir=/var --mandir=/usr/man --infodir=/usr/info --disable-nls
  
 _python_sysroot=/home/administrator/openwrt/staging_dir/target-mips_34kc_musl-1.1.10
 _python_prefix=/usr _python_exec_prefix=/usr
 --with-linux=/home/administrator/openwrt/build_dir/target-mips_34kc_musl-1.1.10/linux-ar71xx_generic/linux-4.1.3
 --with-rundir=/var/run --enable-ndebug --disable-ssl --enable-shared ; fi; )

 [...] (a bunch of checks)

 checking for kernel version... 4.1.3
 configure: error: Linux kernel in
 /home/administrator/openwrt/build_dir/target-mips_34kc_musl-1.1.10/linux-ar71xx_generic/linux-4.1.3
 is version 4.1.3, but version newer than 4.0.x is not supported (please
 refer to the FAQ for advice)
 make[3]: ***
 [/home/administrator/openwrt/build_dir/target-mips_34kc_musl-1.1.10/openvswitch-2.4.0/.configured_]
 Error 1
 make[3]: Leaving directory
 `/home/administrator/openwrt/feeds/packages/net/openvswitch'
 make[2]: *** [package/feeds/packages/openvswitch/compile] Error 2
 make[2]: Leaving directory `/home/administrator/openwrt'
 make[1]: ***
 [/home/administrator/openwrt/staging_dir/target-mips_34kc_musl-1.1.10/stamp/.package_compile]
 Error 2
 make[1]: Leaving directory `/home/administrator/openwrt'
 make: *** [world] Error 2



 Am 04.08.2015 um 16:08 schrieb Alexandru Ardelean:
  Took some 20-30 minutes to upgrade OVS and test it (with kernel 4.1).
  Seems to work fine so far

Re: [OpenWrt-Devel] Openvswitch package not available in trunk

[Alexandru Ardelean]

Well, OpenVSwitch is a bit behind on kernel support.
It's at 3.18 currently.
OpenWRT is at 4.1

We'd need to do an upgrade of OVS to get it up to speed.




On Tue, Aug 4, 2015 at 12:43 PM, Florian Siebertz 
florian.siebe...@inf.h-brs.de wrote:

 Hi,

 i noticed that the openvswitch package is not available in trunk at the
 moment. It is not in the precompiled snapshots, neither can it be
 choosen in 'make menuconfig'. (Yes, i did ./scripts/feeds
 [update|install] -a).

 Does anyone know why and when it will be back?

 Thanks!

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

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

Re: [OpenWrt-Devel] Openvswitch package not available in trunk

[Alexandru Ardelean]

Took some 20-30 minutes to upgrade OVS and test it (with kernel 4.1).
Seems to work fine so far.

Please monitor this PR; after it's merged it should appear.

On Tue, Aug 4, 2015 at 1:37 PM, Alexandru Ardelean ardeleana...@gmail.com
wrote:

 Well, OpenVSwitch is a bit behind on kernel support.
 It's at 3.18 currently.
 OpenWRT is at 4.1

 We'd need to do an upgrade of OVS to get it up to speed.




 On Tue, Aug 4, 2015 at 12:43 PM, Florian Siebertz 
 florian.siebe...@inf.h-brs.de wrote:

 Hi,

 i noticed that the openvswitch package is not available in trunk at the
 moment. It is not in the precompiled snapshots, neither can it be
 choosen in 'make menuconfig'. (Yes, i did ./scripts/feeds
 [update|install] -a).

 Does anyone know why and when it will be back?

 Thanks!

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



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

Re: [OpenWrt-Devel] alternative for pyserial+python-mini

[Alexandru Ardelean]

It's still turned off.
But it was turned off again, once it was moved to Github.
There was a more recent discussion here:
https://github.com/openwrt/packages/issues/474

[ Quick answer here: yes we can precompile bytecodes at build-time and ship
those instead ]

So, .py  vs  .pyc  vs  .pyo  is a recurring question.

.py - python source file
.pyc - compiled bytecodes (from .py file)
.pyo - compiled optimized bytecodes (not sure yet what optimized means)

Which of these 3 formats should the Python libraries use to be packaged ?
Opinions differ here.

At the time I packaged python, it seemed logical that .py files should be
it; that's how most how distros get Python packaged.
But then, .py files automatically generate .pyc files that fill up RAM or
Flash, so that was disabled [ for the OpenWRT case ].

But now that I re-think about it [for the OpenWRT case] maybe changing to
.pyo would be better, since it would optimize performance (size  speed).
And then the source files could be re-packaged to python-sources [ or
something ] .
One proposal was a bit backwards in logic: i.e. package Python libs as are
now, and package Python bytecodes in additional+installable packages.
My main preference here, is that I wouldn't want to give up the convenience
of having Python source files, which is why I prefer[ed] to sacrifice
performance in the first place.
[ And then, nobody complained yet loud enough to change this ].

So, this python packages to bytecode conversion + python sources packages
would be an interesting idea to do.


On Tue, Jul 21, 2015 at 11:48 PM, valent.turko...@gmail.com 
valent.turko...@gmail.com wrote:

 Just found this --

 https://dev.openwrt.org/browser/packages/lang/python/files/python-package.mk?rev=13921
 -- which suggests that 7 years ago .pyc file creation was turned OFF
 for Python.

 I can only assume that it was because of the SquashFS issue, so my
 question is: Can we precompile Python files at image creation time so
 that they can be included in the SquashFS from the beginning. Maybe a
 cross-compiling guru can enlighten us?

 On 2 July 2015 at 11:25, Alexandru Ardelean ardeleana...@gmail.com
 wrote:
  Will make time to update Python :)
 
 
  On Thu, Jul 2, 2015 at 11:51 AM, valent.turko...@gmail.com
  valent.turko...@gmail.com wrote:
 
  Come on guys help me out with Python wiki page, it looks like I know
  much less about python that you and I'm the only one documenting this
  which is bad :)
 
  Take a look at latest version:
  http://wiki.openwrt.org/doc/software/python
 
  On 27 June 2015 at 22:42, Christian Mehlis christ...@m3hlis.de wrote:
   Am 26.06.2015 um 14:57 schrieb valent.turko...@gmail.com:
  
   Does micro-python have some alternative or replacement for pyserial?
  
  
   you can use stty[1] from busybox to configure the tty.
   After that every program can use regular read/write calls...
  
   [1] http://unixhelp.ed.ac.uk/CGI/man-cgi?stty
  
   Best
   Christian
  
   ___
   openwrt-devel mailing list
   openwrt-devel@lists.openwrt.org
   https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
 
 

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

[OpenWrt-Devel] [PATCH] swconfig: swlib.c: Fix another memleak

[Alexandru Ardelean]

From: Helmut Schaa h...@ocedo.com

---
 openwrt/package/network/config/swconfig/src/swlib.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/package/network/config/swconfig/src/swlib.c 
b/package/network/config/swconfig/src/swlib.c
index dae603c..f79b826 100644
--- a/package/network/config/swconfig/src/swlib.c
+++ b/package/network/config/swconfig/src/swlib.c
@@ -529,10 +529,13 @@ struct switch_attr *swlib_lookup_attr(struct switch_dev 
*dev,
 static void
 swlib_priv_free(void)
 {
+   if (family)
+   nl_object_put((struct nl_object*)family);
if (cache)
nl_cache_free(cache);
if (handle)
nl_socket_free(handle);
+   family = NULL;
handle = NULL;
cache = NULL;
 }
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] [RFC] [RESEND] swconfig: Split libsw out of swconfig for reuse in other packages

[Alexandru Ardelean]

From: Helmut Schaa h...@ocedo.com

Signed-off-by: Helmut Schaa helmut.sc...@googlemail.com

---
 package/network/config/swconfig/Makefile | 9 +
 package/network/config/swconfig/src/Makefile | 9 ++---
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/package/network/config/swconfig/Makefile 
b/package/network/config/swconfig/Makefile
index 50d395c..5af31f7 100644
--- a/package/network/config/swconfig/Makefile
+++ b/package/network/config/swconfig/Makefile
@@ -41,9 +41,18 @@ define Build/Compile
LIBS=$(TARGET_LDFLAGS) -lnl-tiny -lm -luci
 endef
 
+define Build/InstallDev
+   $(INSTALL_DIR) $(1)/usr/include
+   $(CP) $(PKG_BUILD_DIR)/swlib.h $(1)/usr/include/
+
+   $(INSTALL_DIR) $(1)/lib
+   $(CP) $(PKG_BUILD_DIR)/libsw.so $(1)/lib/
+endef
+
 define Package/swconfig/install
$(INSTALL_DIR) $(1)/sbin $(1)/lib/network
$(INSTALL_BIN) $(PKG_BUILD_DIR)/swconfig $(1)/sbin/swconfig
+   $(INSTALL_BIN) $(PKG_BUILD_DIR)/libsw.so $(1)/lib
$(INSTALL_DATA) ./files/switch.sh $(1)/lib/network/
 endef
 
diff --git a/package/network/config/swconfig/src/Makefile 
b/package/network/config/swconfig/src/Makefile
index 0d56f43..1176bf0 100644
--- a/package/network/config/swconfig/src/Makefile
+++ b/package/network/config/swconfig/src/Makefile
@@ -6,7 +6,10 @@ LIBS=-lnl -lnl-genl
 all: swconfig
 
 %.o: %.c
-   $(CC) $(CFLAGS) -c -o $@ $^
+   $(CC) $(CFLAGS) -fPIC -c -o $@ $^
 
-swconfig: cli.o swlib.o uci.o
-   $(CC) $(LDFLAGS) -o $@ $^ $(LIBS)
+libsw.so: swlib.o
+   $(CC) $(CFLAGS) -fPIC -shared -o $@ swlib.o
+
+swconfig: libsw.so cli.o uci.o
+   $(CC) $(LDFLAGS) -o $@ $^ $(LIBS) -L./ -lsw
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel