Re: [LEDE-DEV] Routing two interfaces on same subnet

[Baptiste Jonglez]

On Mon, Jul 04, 2016 at 10:54:27PM +0200, Baptiste Clenet wrote:
> Hi Wang,
> Thank for your answer. May you explain how to do that?
> I think this should work.

The general idea would be:

  default via 192.168.0.1 dev wlan0  src 192.168.0.12  metric 300
  default via 192.168.1.1 dev eth0   src 192.168.1.42  metric 200

where the route with the lowest metric is used.  If it disappears, the
remaining route is used instead.

You should be able to do that on LEDE/OpenWRT, see the metric option here:

  https://wiki.openwrt.org/doc/uci/network#ipv4_routes

The problem is that, in your case, it probably won't work, because:

1) you mentioned that the route doesn't go away when the interface goes
   down (which might or might not be a bug)

2) if both gateways are in the same subnet, chances are you're screwed up
   anyway, because the kernel will only do ARP on one of your interface,
   for both routes.  I'd be interested to know if this is not the case.

What is your use-case?  You are possibly applying the wrong solution to a
problem that can be solved in a cleaner way (VRRP? bonding? multipath
forwarding?)  It depends on what problem you are really trying to solve.

> 2016-07-04 12:16 GMT+02:00 Wang Linetkux :
> > Hi,
> >   I think you can setup two default route with different/proper metric
> > value. Which means you use one of them as the backup line, and the
> > other as the main line.
> >
> >
> >
> > Thanks,
> > Rujun
> >
> > 2016-07-04 16:14 GMT+08:00 Baptiste Clenet :
> >> Hi,
> >>
> >> On my board, I've got a wifi and an ethernet interfaces on the same
> >> subnet (192.168.0.0/24). Problem is if ethernet cable is unplugged I
> >> can't use wifi anymore, see
> >>
> >> root@eisox:/# ip route
> >> default via 192.168.0.50 dev eth0  proto static
> >> 192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.85
> >> 192.168.0.0/24 dev apcli0  proto kernel  scope link  src 192.168.0.80
> >> Here, ethernet is unplugged and wifi connected to other router so I
> >> can't use the wifi (ping failed in both direction).
> >>
> >> If I delete eth route, it works.
> >> root@eisox:/# ip route del 192.168.0.0/24 dev eth0
> >> root@eisox:/# ip route
> >> default via 192.168.0.50 dev eth0  proto static
> >> 192.168.0.0/24 dev apcli0  proto kernel  scope link  src 192.168.0.80
> >> root@eisox:/#
> >>
> >> How can I can solve the problem?
> >> I won't know the status of Wifi and Ethernet so I would like that both
> >> can work if they are plugged.
> >>
> >> Or how to disable one interface is the other one is connected (like if
> >> ethernet is plugged, allow only ethernet to work, if it is unplugged,
> >> allow only wifi)
> >>
> >> Cheers,
> >>
> >> --
> >> Baptiste
> >>
> >> ___
> >> Lede-dev mailing list
> >> Lede-dev@lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/lede-dev


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

Re: [LEDE-DEV] Target Profile removed from image name?

[Baptiste Jonglez]

Hi,

On Fri, Jul 08, 2016 at 11:11:25AM -0600, Donald Chisholm wrote:
> Hi all,
> 
> I have several hundred nodes running Openwrt CC with batman-adv and
> thought I would start testing LEDE.  However, after the build I
> noticed you have removed the target profile (i.e. tl-841v11) from the
> image file name.  For me this is a huge headache.  I also noticed you
> have uncoupled the build option for different hardware versions of
> device models.  This is an inconvenience but not a huge problem.

I'm not sure what you mean?  The images still have the profile name in
them, for instance look at the images for tl-841v11 here:

  https://downloads.lede-project.org/snapshots/targets/ar71xx/generic/

> I build and distribute firmware updates for multiple device models.
> With Openwrt I build for several different models (and versions) and
> use a script that distributes the new firmware based on the firmware
> file name matches against a table of appropriate nodes.   Of course
> this is not possible if the firmware file names are all the same.  As
> it is now, I need to build and rename for each device model and
> version.

Note that it you want to build multiple profiles at the same time, you can
now do that directly in menuconfig.

> Can you clarify why this information was removed from the image file
> name?  Is it reasonable to put it back or include it in the directory
> structure so consecutive builds do not clobber previous images in the
> bin directory?
> 
> Thanks for reading,
> Donald
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


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

Re: [LEDE-DEV] LEDE & IPv6

[Baptiste Jonglez]

On Fri, Jul 08, 2016 at 10:11:16AM +0200, Baptiste Jonglez wrote:
> On Thu, Jul 07, 2016 at 08:01:10PM -0700, Craig Miller wrote:
> > Dear Devs,
> > 
> > Congratulations on the fork of OpenWRT. I look forward to the new LEDE
> > releases.
> > 
> > I am writing here because I am not a committer, but would like to
> > communicate with the Devs. I am a professional software tester, with
> > extensive IPv6 experience. I have been working with IPv6 and OpenWRT
> > specifically for the past year, and have found a few things lacking.
> > 
> > I see in the TODO list, review IPv6 changes. I too would like to see what
> > you have on the horizon for IPv6. I _can_ tell you that systemd is _not_
> > ready for IPv6, and have raised a few issues with the systemd team.
> > 
> > Here are some of the investigations I have done with OpenWRT, systemd and
> > IPv6.
> > http://ipv6-net.blogspot.ca/2016/02/nat-tiness-and-v6brouter.html
> > http://ipv6-net.blogspot.ca/2016/03/v6brouter-part-2-v6bridge-firewall.html
> 
> Instead of this horrible hack, please have a look at the excellent work
> done by the Homenet people from the IETF, in particular HNCP and hnetd.
> Some random links:
> 
>   https://www.irif.univ-paris-diderot.fr/~jch/software/homenet/howto.html
>   https://wiki.openwrt.org/doc/howto/hncp
>   https://github.com/sbyx/hnetd/
>   https://tools.ietf.org/html/rfc7368.html

Just to be certain that my message was not misinterpreted: this is not
intended as a personal attack or a devaluation of your work on IPv6.
I just think that having separate layer-2 domains for IPv4 and IPv6 is a
terrible idea and is prone to subtle bugs.

> > http://ipv6-net.blogspot.ca/2016/04/systemd-oh-you-wanted-to-run-ipv6.html
> > 
> > Although I am not a c-coder, I have been writing software for the past 30
> > years. And would be happy to contribute, especially in the area of IPv6.
> > 
> > thanks,
> > 
> > Craig...



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



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

Re: [LEDE-DEV] LEDE & IPv6

[Baptiste Jonglez]

On Thu, Jul 07, 2016 at 08:01:10PM -0700, Craig Miller wrote:
> Dear Devs,
> 
> Congratulations on the fork of OpenWRT. I look forward to the new LEDE
> releases.
> 
> I am writing here because I am not a committer, but would like to
> communicate with the Devs. I am a professional software tester, with
> extensive IPv6 experience. I have been working with IPv6 and OpenWRT
> specifically for the past year, and have found a few things lacking.
> 
> I see in the TODO list, review IPv6 changes. I too would like to see what
> you have on the horizon for IPv6. I _can_ tell you that systemd is _not_
> ready for IPv6, and have raised a few issues with the systemd team.
> 
> Here are some of the investigations I have done with OpenWRT, systemd and
> IPv6.
> http://ipv6-net.blogspot.ca/2016/02/nat-tiness-and-v6brouter.html
> http://ipv6-net.blogspot.ca/2016/03/v6brouter-part-2-v6bridge-firewall.html

Instead of this horrible hack, please have a look at the excellent work
done by the Homenet people from the IETF, in particular HNCP and hnetd.
Some random links:

  https://www.irif.univ-paris-diderot.fr/~jch/software/homenet/howto.html
  https://wiki.openwrt.org/doc/howto/hncp
  https://github.com/sbyx/hnetd/
  https://tools.ietf.org/html/rfc7368.html

> http://ipv6-net.blogspot.ca/2016/04/systemd-oh-you-wanted-to-run-ipv6.html
> 
> Although I am not a c-coder, I have been writing software for the past 30
> years. And would be happy to contribute, especially in the area of IPv6.
> 
> thanks,
> 
> Craig...


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

[LEDE-DEV] Kernel symbol dependencies and KCONFIG usage for kernel packages

[Baptiste Jonglez]

Hi,

I am packaging a new kernel module (wireguard), the package is currently here 
[1].

However, I have some trouble understanding what KCONFIG does.  Wireguard
needs a few kernel options, so I thought that KCONFIG was the place to
declare such dependencies:

  https://github.com/zorun/packages-1/blob/wireguard/net/wireguard/Makefile#L90

However, it does not seem to enable these options.  The module compiles
fine, it installs fine [2], but then it fails to load at runtime:

Sat Jul  2 10:04:50 2016 kern.warn kernel: [   95.015838] wireguard: Unknown 
symbol udp_sock_create4 (err 0)
Sat Jul  2 10:04:50 2016 kern.warn kernel: [   95.022021] wireguard: Unknown 
symbol udp_tunnel6_xmit_skb (err 0)
Sat Jul  2 10:04:50 2016 kern.warn kernel: [   95.028767] wireguard: Unknown 
symbol udp_tunnel_sock_release (err 0)
Sat Jul  2 10:04:50 2016 kern.warn kernel: [   95.035570] wireguard: Unknown 
symbol setup_udp_tunnel_sock (err 0)
Sat Jul  2 10:04:50 2016 kern.warn kernel: [   95.042136] wireguard: Unknown 
symbol udp_sock_create6 (err 0)
Sat Jul  2 10:04:50 2016 kern.warn kernel: [   95.048297] wireguard: Unknown 
symbol udp_tunnel_xmit_skb (err 0)

It works when selecting the needed options manually in kernel_menuconfig,
but it's a huge pain.

Is there a way to get the needed kernel options automatically?  Maybe this
only happens for packages that are part of the core Lede distribution?

Thanks,
Baptiste

[1] https://github.com/zorun/packages-1/blob/wireguard/net/wireguard/Makefile
[2] http://paste.aliens-lyon.fr/CBI


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

Re: [LEDE-DEV] Kernel symbol dependencies and KCONFIG usage for kernel packages

[Baptiste Jonglez]

On Sat, Jul 02, 2016 at 03:48:36PM +0200, Hauke Mehrtens wrote:
> > However, I have some trouble understanding what KCONFIG does.  Wireguard
> > needs a few kernel options, so I thought that KCONFIG was the place to
> > declare such dependencies:
> > 
> >   
> > https://github.com/zorun/packages-1/blob/wireguard/net/wireguard/Makefile#L90
> 
> > KCONFIG:=CONFIG_NET_UDP_TUNNEL CONFIG_IPV6 \
> >  CONFIG_NETFILTER_XT_MATCH_HASHLIMIT
> 
> Instead of activating the kernel symbols you should add a dependency to
> the packages which are building these models:
> 
> DEPENDS:=+kmod-udptunnel4 +kmod-udptunnel6 +kmod-ipt-hashlimit

Well, actually, this is already there, on the next line :)

  https://github.com/zorun/packages-1/blob/wireguard/net/wireguard/Makefile#L91

So, I can remove the KCONFIG line altogether?  I thought the kernel
symbols activated some necessary machinery in the kernel, in addition to
producing the .ko module.

I think I found the cause of the issue: the packages kmod-udptunnel4.ipk
and kmod-udptunnel6.ipk are generated, but are empty (no .ko file).  When
I activate the kernel symbol in kernel_menuconfig, these packages do
provide the .ko files as expected.

I have attached the empty packages to this email, just in case.

Thanks,
Baptiste


kmod-udptunnel4_4.4.14-1_mips_34kc.ipk
Description: application/vnd.shana.informed.package


kmod-udptunnel6_4.4.14-1_mips_34kc.ipk
Description: application/vnd.shana.informed.package


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

Re: [LEDE-DEV] kmod-udptunnel{4, 6} packages are empty (Was: Kernel symbol dependencies and KCONFIG usage for kernel packages)

[Baptiste Jonglez]

On Sat, Jul 02, 2016 at 04:55:28PM +0200, Baptiste Jonglez wrote:
> I think I found the cause of the issue: the packages kmod-udptunnel4.ipk
> and kmod-udptunnel6.ipk are generated, but are empty (no .ko file).  When
> I activate the kernel symbol in kernel_menuconfig, these packages do
> provide the .ko files as expected.

Moving to a different subject, since this is unrelated to wireguard.

Here is how to reproduce the issue (tried with 2a8bb46294):

- start with a fresh config
- activate kmod-udptunnel4 and kmod-udptunnel6 as modules (in Kernel modules → 
Network Support)
- select a target profile (I tried with TP-LINK TL-WR841N/ND v8)
- build

The resulting packages for kmod-udptunnel{4,6} are only 800 octets and do
not contain any .ko module:

$ find bin/ -name "*.ipk" -size '-1000c' -exec ls -lh {} \;
-rw-r--r-- 1 bjonglez users 805 juil.  2 17:14 
bin/targets/ar71xx/generic/packages/kmod-udptunnel6_4.4.14-1_mips_34kc.ipk
-rw-r--r-- 1 bjonglez users 802 juil.  2 17:14 
bin/targets/ar71xx/generic/packages/kmod-udptunnel4_4.4.14-1_mips_34kc.ipk
-rw-r--r-- 1 bjonglez users 781 juil.  2 17:14 
bin/targets/ar71xx/generic/packages/kernel_4.4.14-1-43373ff95800a35b632ff21cb43a1ef1_mips_34kc.ipk
-rw-r--r-- 1 bjonglez users 900 juil.  2 17:15 
bin/packages/mips_34kc/base/ip6tables_1.4.21-2_mips_34kc.ipk

The .ko are actually not built:

$ find 
build_dir/target-mips_34kc_musl-1.1.14/linux-ar71xx_generic/packages/ipkg-mips_34kc/udptunnel4
 -name "*.ko"

$ find 
build_dir/target-mips_34kc_musl-1.1.14/linux-ar71xx_generic/linux-4.4.14/ -name 
"*udp*.ko"
build_dir/target-mips_34kc_musl-1.1.14/linux-ar71xx_generic/linux-4.4.14/net/netfilter/xt_tcpudp.ko


The packages in the snapshots are somehow correct:

  https://downloads.lede-project.org/snapshots/targets/ar71xx/generic/packages/

So, this may actually be a local issue...

Baptiste


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

Re: [LEDE-DEV] Routing two interfaces on same subnet

[Baptiste Jonglez]

On Mon, Jul 04, 2016 at 10:14:26AM +0200, Baptiste Clenet wrote:
> Hi,
> 
> On my board, I've got a wifi and an ethernet interfaces on the same
> subnet (192.168.0.0/24). Problem is if ethernet cable is unplugged I
> can't use wifi anymore, see
> 
> root@eisox:/# ip route
> default via 192.168.0.50 dev eth0  proto static
> 192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.85
> 192.168.0.0/24 dev apcli0  proto kernel  scope link  src 192.168.0.80
> Here, ethernet is unplugged and wifi connected to other router so I
> can't use the wifi (ping failed in both direction).
> 
> If I delete eth route, it works.
> root@eisox:/# ip route del 192.168.0.0/24 dev eth0
> root@eisox:/# ip route
> default via 192.168.0.50 dev eth0  proto static
> 192.168.0.0/24 dev apcli0  proto kernel  scope link  src 192.168.0.80
> root@eisox:/#

Does it?  Your default route still points at eth0.

> How can I can solve the problem?

It's very simple: don't use the same subnet on two different interfaces...

This is not even specific to OpenWRT/LEDE, this is just generally asking
for trouble.

> I won't know the status of Wifi and Ethernet so I would like that both
> can work if they are plugged.
> 
> Or how to disable one interface is the other one is connected (like if
> ethernet is plugged, allow only ethernet to work, if it is unplugged,
> allow only wifi)
> 
> Cheers,


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

Re: [LEDE-DEV] Build error Arcadyan VGV7510KW22(NOR) / o2 6431 - asterisk13

[Baptiste Jonglez]

Hi Dennis,

Please report this bug to the specific package feed: 
https://github.com/openwrt/telephony

It simply looks like a missing dependency (libxml), but bug reports like
this should go there, so that maintainers can do something.

Baptiste

On Tue, Jan 31, 2017 at 10:10:13AM +0100, Dennis Schneck wrote:
> Hello,
> i downloaded the source with: git clone https://github.com/lede-project/source
> 
> Select for VGV7510KW22 ( see attach please!  .config as _config )
> 
> Target System (Lantiq)
> Subtarget (XRX200)
> Target Profile (o2 Box 6431 / Arcadyan VGV7510KW22 (NOR)
> 
> 
> Base system -> block-mount
> Base system -> sqm-scripts
> 
> Kernel modules -> Filesystems -> kmod-fs-ext4
> Kernel modules -> USB Support -> kmod-usb-storage
> 
> LuCI -> Collections -> luci
> LuCI -> Applications -> luci-app-sqm
> 
> Firmware -> dsl-vrx200-firmware-xdsl-b
> 
> Network -> Telephony -> asterisk13
> Network -> Telephony -> asterisk13 ->asterisk13-app-directed_pickup
> Network -> Telephony -> asterisk13 ->asterisk13-app-read
> Network -> Telephony -> asterisk13 ->asterisk13-app-stack
> Network -> Telephony -> asterisk13 ->asterisk13-app-system
> Network -> Telephony -> asterisk13 ->asterisk13-cdr
> Network -> Telephony -> asterisk13 ->asterisk13-cdr-csv
> Network -> Telephony -> asterisk13 ->asterisk13-chan-sip
> Network -> Telephony -> asterisk13 ->asterisk13-codec-a-mu
> Network -> Telephony -> asterisk13 ->asterisk13-codec-alaw
> Network -> Telephony -> asterisk13 ->asterisk13-codec-g722
> Network -> Telephony -> asterisk13 ->asterisk13-codec-g726
> Network -> Telephony -> asterisk13 ->asterisk13-codec-gsm
> Network -> Telephony -> asterisk13 ->asterisk13-codec-ilbc
> Network -> Telephony -> asterisk13 ->asterisk13-codec-resample
> Network -> Telephony -> asterisk13 ->asterisk13-codec-ulaw
> Network -> Telephony -> asterisk13 ->asterisk13-format-gsm
> Network -> Telephony -> asterisk13 ->asterisk13-format-sln
> Network -> Telephony -> asterisk13 ->asterisk13-func-blacklist
> Network -> Telephony -> asterisk13 ->asterisk13-func-groupcount
> Network -> Telephony -> asterisk13 ->asterisk13-pbx-spool
> Network -> Telephony -> asterisk13 ->asterisk13-res-rtp-asterisk
> 
> Languages -> perl
> Languages -> perl -> perl-html-tree
> Languages -> perl -> perl-http-message
> 
> Mail -> mailsend
> 
> 
> 
> But asterisk13 build fail.
> 
> checking for strcasestr... yes
> checking for strndup... yes
> checking for strnlen... yes
> checking for strsep... yes
> checking for unsetenv... yes
> checking for vasprintf... yes
> checking for initscr in -lncurses... yes
> checking curses.h usability... yes
> checking curses.h presence... yes
> checking for curses.h... yes
> checking for a sed that does not truncate output... 
> /home/dennis/Downloads/o26431-vmmc_v3/source/staging_dir/host/bin/sed
> checking for xml2-config... 
> /home/dennis/Downloads/o26431-vmmc_v3/source/staging_dir/target-mips_24kc_musl-1.1.16/host/bin/xml2-config
> configure: error: Could not find required 'Libxml2' development package
> make[3]: *** [Makefile:291: 
> /home/dennis/Downloads/o26431-vmmc_v3/source/build_dir/target-mips_24kc_musl-1.1.16/asterisk-13.9.1/.configured_yyy]
>  Error 1
> make[3]: Leaving directory 
> '/home/dennis/Downloads/o26431-vmmc_v3/source/feeds/telephony/net/asterisk-13.x'
> make[2]: *** [package/Makefile:108: 
> package/feeds/telephony/asterisk-13.x/compile] Error 2
> make[2]: Leaving directory '/home/dennis/Downloads/o26431-vmmc_v3/source'
> make[1]: *** [package/Makefile:102: 
> /home/dennis/Downloads/o26431-vmmc_v3/source/staging_dir/target-mips_24kc_musl-1.1.16/stamp/.package_compile]
>  Error 2
> make[1]: Leaving directory '/home/dennis/Downloads/o26431-vmmc_v3/source'
> make: *** 
> [/home/dennis/Downloads/o26431-vmmc_v3/source/include/toplevel.mk:199: world] 
> Error 2
> 
> 
> 
> How to fix this ?
> 
> Many thanks to Stefan Koch for his helping hand!
> 
> 
> Using Manjaro Linux to build the Image
> have installed this packages: 
> 
> pacman -S --needed subversion asciidoc bash bc binutils bzip2 fastjar flex 
> git gcc util-linux gawk intltool zlib make cdrkit ncurses openssl patch 
> perl-extutils-makemaker rsync sdcc unzip wget gettext libxslt boost libusb 
> bin86 sharutils b43-fwcutter findutils
> 
> https://wiki.openwrt.org/doc/howto/buildroot.exigence
> 
> Thanks
> 
> Dennis


> 
> $ make
> Checking 'rsync'... ok.
>  make[1] world
>  make[2] target/compile
>  make[3] -C target/linux compile
>  make[2] package/cleanup
>  make[2] package/compile
>  make[3] -C package/libs/toolchain compile
>  make[3] -C package/libs/libnl-tiny compile
>  make[3] -C package/libs/libjson-c compile
>  make[3] -C package/utils/lua compile
>  make[3] -C package/libs/libubox compile
>  make[3] -C package/system/ubus compile
>  make[3] -C package/system/uci compile
>  make[3] -C package/network/config/netifd compile
>  make[3] -C package/system/ubox compile
>  make[3] -C package/libs/ncurses host-compile
>  make[3] -C package/libs/ncurses 

Re: [LEDE-DEV] ath9k stability in LEDE master branch - kernel panic every ~5 minutes

[Baptiste Jonglez]

Hi,

On Sun, Feb 05, 2017 at 04:50:29PM +, Nick Lowe wrote:
> I have an apu2c4 (quad core AMD GX-412TC) with two AR9390 cards, one
> offering service at 2.4 GHz and one offering service at 5 GHz with the
> same SSID.
> 
> I decided to test out the latest x86-64 LEDE snapshot, as of this
> Saturday morning:
> 
> lede-x86-64-combined-ext4.img.gz 5582.0 KB Sat Feb 4 21:37:05 2017
> 
> LEDE Reboot SNAPSHOT r3293-f791fb4 / LuCI Master (git-17.034.72963-f1820de)
> 
> With this, service comes up as expected but I observe regular kernel
> panics and reboots, roughly every 5 minutes, usually within the ath9k
> driver.

Have you tried the rc1 image for 17.01?  
https://downloads.lede-project.org/releases/17.01.0-rc1/targets/x86/64/

In any case, you should open a bug report here: https://bugs.lede-project.org/

Thanks,
Baptiste

> The hardware tests out fine so this looks to be a software issue in
> the ath9k driver.
> 
> First example:
> 
> root@LEDE:/# [  345.531745] general protection fault:  [#1] SMP
> [  345.536800] Modules linked in: ath9k ath9k_common pppoe ppp_async
> ath9k_hw ath pppox ppp_generic nf_conntrack_ipv6 mac80211 iptable_nat
> ipt_REJECT ipt_MASQUERADE cfg80211 xt_ti
> me xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit
> xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_CT slhc r8169
> nf_reject_ipv4 nf_nat_redirect nf_nat_masqu
> erade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4
> nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack
> iptable_mangle iptable_filter ip_tables e1000e crc_ccit
> t compat i2c_dev ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common
> ip6table_mangle ip6table_filter ip6_tables x_tables igb i2c_algo_bit
> i2c_core e1000 button_hotplug ptp pps_co
> re mii
> [  345.601401] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.4.46 #0
> [  345.607344] Hardware name: PC Engines apu2/apu2, BIOS 6f1e98a-dirty
> 05/15/2016
> [  345.614605] task: 88011a0e8000 ti: 88011a0f task.ti:
> 88011a0f
> [  345.622124] RIP: 0010:[]  []
> native_queued_spin_lock_slowpath+0xf4/0x160
> [  345.632039] RSP: 0018:88011ed83d38  EFLAGS: 00010202
> [  345.637374] RAX: 36e6 RBX: 8800da9173f8 RCX: 
> 88011ed945c0
> [  345.644523] RDX: 0010 RSI: 0022ad3800376879 RDI: 
> 8800da88b4b0
> [  345.651682] RBP: 88011ed83e38 R08: 0101 R09: 
> 
> [  345.658841] R10: 00561eb7d9aa R11: 0246 R12: 
> 8800da88b4b0
> [  345.665992] R13: 0030 R14: 88011a3afe00 R15: 
> 8800da889c00
> [  345.673161] FS:  7fc45bd40b48() GS:88011ed8()
> knlGS:
> [  345.681302] CS:  0010 DS:  ES:  CR0: 80050033
> [  345.687079] CR2: 0060c430 CR3: db98b000 CR4: 
> 000406e0
> [  345.694236] Stack:
> [  345.696270]  8149f403 a02ba330 
> 
> [  345.703801]    
> 0400
> [  345.711329]  0001 0001 8800dafa4820
> 
> [  345.718855] Call Trace:
> [  345.721327]  
> [  345.723284]  [] ? _raw_spin_lock_bh+0x23/0x30
> [  345.729460]  [] ? ath_tx_aggr_wakeup+0x610/0xe90 [ath9k]
> [  345.736381]  [] ? ath_tx_edma_tasklet+0x188/0x340 [ath9k]
> [  345.743371]  [] ? ath9k_tasklet+0xef/0x230 [ath9k]
> [  345.749757]  [] ? tasklet_action+0xa2/0xb0
> [  345.755438]  [] ? __do_softirq+0xc6/0x1d0
> [  345.761035]  [] ? irq_exit+0x6f/0x80
> [  345.766205]  [] ? do_IRQ+0x4a/0xc0
> [  345.771205]  [] ? common_interrupt+0x7f/0x7f
> [  345.777056]  
> [  345.779005]  [] ? cpuidle_enter_state+0x12d/0x1e0
> [  345.785529]  [] ? cpuidle_enter_state+0x126/0x1e0
> [  345.791822]  [] ? cpu_startup_entry+0x1f4/0x250
> [  345.797945]  [] ? start_secondary+0x12d/0x140
> [  345.803891] Code: 87 47 02 c1 e0 10 85 c0 74 33 48 89 c6 c1 e8 12
> 48 c1 ee 0c 83 e8 01 83 e6 30 48 98 48 81 c6 c0 45 01 00 48 03 34 c5
> 20 dc 6c 81 <48> 89 0e eb 02 f3 90 8b 41
> 08 85 c0 74 f7 eb 02 f3 90 8b 07 66
> [  345.824448] RIP  []
> native_queued_spin_lock_slowpath+0xf4/0x160
> [  345.832016]  RSP 
> [  345.835563] ---[ end trace b85322db3e31494d ]---
> [  345.840213] Kernel panic - not syncing: Fatal exception in interrupt
> [  345.846616] Kernel Offset: disabled
> [  345.850127] Rebooting in 3 seconds..
> 
> Second example:
> 
> [  243.130690] general protection fault:  [#1] SMP
> [  243.135744] Modules linked in: ath9k ath9k_common pppoe ppp_async
> ath9k_hw ath pppox ppp_generic nf_conntrack_ipv6 mac80211 iptable_nat
> ipt_REJECT ipt_MASQUERADE cfg80211 xt_ti
> me xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit
> xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_CT slhc r8169
> nf_reject_ipv4 nf_nat_redirect nf_nat_masqu
> erade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4
> nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack
> iptable_mangle 

Re: [LEDE-DEV] LEDE-17.01 Final Release Notes available

[Baptiste Jonglez]

On Tue, Jan 31, 2017 at 10:14:04AM +, David Woodhouse wrote:
> On Tue, 2017-01-31 at 10:54 +0100, Baptiste Jonglez wrote:
> > 
> > - IPv6 support: since that was the focus of CC, at least mention that
> >   nothing was intentionally broken (and maybe there were some
> >   improvement?)]
> 
> What was the IPv6 problem?

Nothing, hopefully :) What I meant is that LEDE should work as well as
OpenWRT CC with respect to IPv6 support.  This is currently implicit,
because the release notes do not mention IPv6 at all.  I was wondering if
it would make sense to mention that IPv6 support remains very good.

Baptiste


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

[LEDE-DEV] [PATCH] dnsmasq: Add upstream patch fixing SERVFAIL issues with multiple servers

[Baptiste Jonglez]

From: Baptiste Jonglez <g...@bitsofnetworks.org>

This fixes FS#391 for lede-17.01

Signed-off-by: Baptiste Jonglez <g...@bitsofnetworks.org>
---
 .../patches/000-fix-servfail-handling.patch| 130 +
 1 file changed, 130 insertions(+)
 create mode 100644 
package/network/services/dnsmasq/patches/000-fix-servfail-handling.patch

diff --git 
a/package/network/services/dnsmasq/patches/000-fix-servfail-handling.patch 
b/package/network/services/dnsmasq/patches/000-fix-servfail-handling.patch
new file mode 100644
index 00..e311c34729
--- /dev/null
+++ b/package/network/services/dnsmasq/patches/000-fix-servfail-handling.patch
@@ -0,0 +1,130 @@
+From 68f6312d4bae30b78daafcd6f51dc441b8685b1e Mon Sep 17 00:00:00 2001
+From: Baptiste Jonglez <g...@bitsofnetworks.org>
+Date: Mon, 6 Feb 2017 21:09:11 +
+Subject: [PATCH] Stop treating SERVFAIL as a successful response from upstream
+ servers.
+
+This effectively reverts most of 51967f9807 ("SERVFAIL is an expected
+error return, don't try all servers.") and 4ace25c5d6 ("Treat REFUSED (not
+SERVFAIL) as an unsuccessful upstream response").
+
+With the current behaviour, as soon as dnsmasq receives a SERVFAIL from an
+upstream server, it stops trying to resolve the query and simply returns
+SERVFAIL to the client.  With this commit, dnsmasq will instead try to
+query other upstream servers upon receiving a SERVFAIL response.
+
+According to RFC 1034 and 1035, the semantic of SERVFAIL is that of a
+temporary error condition.  Recursive resolvers are expected to encounter
+network or resources issues from time to time, and will respond with
+SERVFAIL in this case.  Similarly, if a validating DNSSEC resolver [RFC
+4033] encounters issues when checking signatures (unknown signing
+algorithm, missing signatures, expired signatures because of a wrong
+system clock, etc), it will respond with SERVFAIL.
+
+Note that all those behaviours are entirely different from a negative
+response, which would provide a definite indication that the requested
+name does not exist.  In our case, if an upstream server responds with
+SERVFAIL, another upstream server may well provide a positive answer for
+the same query.
+
+Thus, this commit will increase robustness whenever some upstream servers
+encounter temporary issues or are misconfigured.
+
+Quoting RFC 1034, Section 4.3.1. "Queries and responses":
+
+If recursive service is requested and available, the recursive response
+to a query will be one of the following:
+
+   - The answer to the query, possibly preface by one or more CNAME
+ RRs that specify aliases encountered on the way to an answer.
+
+   - A name error indicating that the name does not exist.  This
+ may include CNAME RRs that indicate that the original query
+ name was an alias for a name which does not exist.
+
+   - A temporary error indication.
+
+Here is Section 5.2.3. of RFC 1034, "Temporary failures":
+
+In a less than perfect world, all resolvers will occasionally be unable
+to resolve a particular request.  This condition can be caused by a
+resolver which becomes separated from the rest of the network due to a
+link failure or gateway problem, or less often by coincident failure or
+unavailability of all servers for a particular domain.
+
+And finally, RFC 1035 specifies RRCODE 2 for this usage, which is now more
+widely known as SERVFAIL (RFC 1035, Section 4.1.1. "Header section format"):
+
+RCODE   Response code - this 4 bit field is set as part of
+responses.  The values have the following
+interpretation:
+(...)
+
+2   Server failure - The name server was
+unable to process this query due to a
+problem with the name server.
+
+For the DNSSEC-related usage of SERVFAIL, here is RFC 4033
+Section 5. "Scope of the DNSSEC Document Set and Last Hop Issues":
+
+A validating resolver can determine the following 4 states:
+(...)
+
+Insecure: The validating resolver has a trust anchor, a chain of
+   trust, and, at some delegation point, signed proof of the
+   non-existence of a DS record.  This indicates that subsequent
+   branches in the tree are provably insecure.  A validating resolver
+   may have a local policy to mark parts of the domain space as
+   insecure.
+
+Bogus: The validating resolver has a trust anchor and a secure
+   delegation indicating that subsidiary data is signed, but the
+   response fails to validate for some reason: missing signatures,
+   expired signatures, signatures with unsupported algorithms, data
+   missing that the relevant NSEC RR says should be present, and so
+   forth.
+(...)
+
+This specification only defines

Re: [LEDE-DEV] [PATCH] dnsmasq: Add upstream patch fixing SERVFAIL issues with multiple servers

[Baptiste Jonglez]

Sorry, I forgot to add the 17.01 tag.  I am resending it with the proper tag.

On Mon, Feb 20, 2017 at 04:48:49PM +0100, Baptiste Jonglez wrote:
> From: Baptiste Jonglez <g...@bitsofnetworks.org>
> 
> This fixes FS#391 for lede-17.01
> 
> Signed-off-by: Baptiste Jonglez <g...@bitsofnetworks.org>
> ---
>  .../patches/000-fix-servfail-handling.patch| 130 
> +
>  1 file changed, 130 insertions(+)
>  create mode 100644 
> package/network/services/dnsmasq/patches/000-fix-servfail-handling.patch
> 
> diff --git 
> a/package/network/services/dnsmasq/patches/000-fix-servfail-handling.patch 
> b/package/network/services/dnsmasq/patches/000-fix-servfail-handling.patch
> new file mode 100644
> index 00..e311c34729
> --- /dev/null
> +++ b/package/network/services/dnsmasq/patches/000-fix-servfail-handling.patch
> @@ -0,0 +1,130 @@
> +From 68f6312d4bae30b78daafcd6f51dc441b8685b1e Mon Sep 17 00:00:00 2001
> +From: Baptiste Jonglez <g...@bitsofnetworks.org>
> +Date: Mon, 6 Feb 2017 21:09:11 +
> +Subject: [PATCH] Stop treating SERVFAIL as a successful response from 
> upstream
> + servers.
> +
> +This effectively reverts most of 51967f9807 ("SERVFAIL is an expected
> +error return, don't try all servers.") and 4ace25c5d6 ("Treat REFUSED (not
> +SERVFAIL) as an unsuccessful upstream response").
> +
> +With the current behaviour, as soon as dnsmasq receives a SERVFAIL from an
> +upstream server, it stops trying to resolve the query and simply returns
> +SERVFAIL to the client.  With this commit, dnsmasq will instead try to
> +query other upstream servers upon receiving a SERVFAIL response.
> +
> +According to RFC 1034 and 1035, the semantic of SERVFAIL is that of a
> +temporary error condition.  Recursive resolvers are expected to encounter
> +network or resources issues from time to time, and will respond with
> +SERVFAIL in this case.  Similarly, if a validating DNSSEC resolver [RFC
> +4033] encounters issues when checking signatures (unknown signing
> +algorithm, missing signatures, expired signatures because of a wrong
> +system clock, etc), it will respond with SERVFAIL.
> +
> +Note that all those behaviours are entirely different from a negative
> +response, which would provide a definite indication that the requested
> +name does not exist.  In our case, if an upstream server responds with
> +SERVFAIL, another upstream server may well provide a positive answer for
> +the same query.
> +
> +Thus, this commit will increase robustness whenever some upstream servers
> +encounter temporary issues or are misconfigured.
> +
> +Quoting RFC 1034, Section 4.3.1. "Queries and responses":
> +
> +If recursive service is requested and available, the recursive response
> +to a query will be one of the following:
> +
> +   - The answer to the query, possibly preface by one or more CNAME
> + RRs that specify aliases encountered on the way to an answer.
> +
> +   - A name error indicating that the name does not exist.  This
> + may include CNAME RRs that indicate that the original query
> +   name was an alias for a name which does not exist.
> +
> +   - A temporary error indication.
> +
> +Here is Section 5.2.3. of RFC 1034, "Temporary failures":
> +
> +In a less than perfect world, all resolvers will occasionally be unable
> +to resolve a particular request.  This condition can be caused by a
> +resolver which becomes separated from the rest of the network due to a
> +link failure or gateway problem, or less often by coincident failure or
> +unavailability of all servers for a particular domain.
> +
> +And finally, RFC 1035 specifies RRCODE 2 for this usage, which is now more
> +widely known as SERVFAIL (RFC 1035, Section 4.1.1. "Header section format"):
> +
> +RCODE   Response code - this 4 bit field is set as part of
> +responses.  The values have the following
> +interpretation:
> +(...)
> +
> +2   Server failure - The name server was
> +unable to process this query due to a
> +problem with the name server.
> +
> +For the DNSSEC-related usage of SERVFAIL, here is RFC 4033
> +Section 5. "Scope of the DNSSEC Document Set and Last Hop Issues":
> +
> +A validating resolver can determine the following 4 states:
> +(...)
> +
> +Insecure: The validating resolver has a trust anchor, a chain of
> +   trust, and, at some delegation point, signed proof of the
> +   

[LEDE-DEV] [PATCH] [17.01] dnsmasq: Add upstream patch fixing SERVFAIL issues with multiple servers

[Baptiste Jonglez]

From: Baptiste Jonglez <g...@bitsofnetworks.org>

This fixes FS#391 for lede-17.01

Signed-off-by: Baptiste Jonglez <g...@bitsofnetworks.org>
---
 .../patches/000-fix-servfail-handling.patch| 130 +
 1 file changed, 130 insertions(+)
 create mode 100644 
package/network/services/dnsmasq/patches/000-fix-servfail-handling.patch

diff --git 
a/package/network/services/dnsmasq/patches/000-fix-servfail-handling.patch 
b/package/network/services/dnsmasq/patches/000-fix-servfail-handling.patch
new file mode 100644
index 00..e311c34729
--- /dev/null
+++ b/package/network/services/dnsmasq/patches/000-fix-servfail-handling.patch
@@ -0,0 +1,130 @@
+From 68f6312d4bae30b78daafcd6f51dc441b8685b1e Mon Sep 17 00:00:00 2001
+From: Baptiste Jonglez <g...@bitsofnetworks.org>
+Date: Mon, 6 Feb 2017 21:09:11 +
+Subject: [PATCH] Stop treating SERVFAIL as a successful response from upstream
+ servers.
+
+This effectively reverts most of 51967f9807 ("SERVFAIL is an expected
+error return, don't try all servers.") and 4ace25c5d6 ("Treat REFUSED (not
+SERVFAIL) as an unsuccessful upstream response").
+
+With the current behaviour, as soon as dnsmasq receives a SERVFAIL from an
+upstream server, it stops trying to resolve the query and simply returns
+SERVFAIL to the client.  With this commit, dnsmasq will instead try to
+query other upstream servers upon receiving a SERVFAIL response.
+
+According to RFC 1034 and 1035, the semantic of SERVFAIL is that of a
+temporary error condition.  Recursive resolvers are expected to encounter
+network or resources issues from time to time, and will respond with
+SERVFAIL in this case.  Similarly, if a validating DNSSEC resolver [RFC
+4033] encounters issues when checking signatures (unknown signing
+algorithm, missing signatures, expired signatures because of a wrong
+system clock, etc), it will respond with SERVFAIL.
+
+Note that all those behaviours are entirely different from a negative
+response, which would provide a definite indication that the requested
+name does not exist.  In our case, if an upstream server responds with
+SERVFAIL, another upstream server may well provide a positive answer for
+the same query.
+
+Thus, this commit will increase robustness whenever some upstream servers
+encounter temporary issues or are misconfigured.
+
+Quoting RFC 1034, Section 4.3.1. "Queries and responses":
+
+If recursive service is requested and available, the recursive response
+to a query will be one of the following:
+
+   - The answer to the query, possibly preface by one or more CNAME
+ RRs that specify aliases encountered on the way to an answer.
+
+   - A name error indicating that the name does not exist.  This
+ may include CNAME RRs that indicate that the original query
+ name was an alias for a name which does not exist.
+
+   - A temporary error indication.
+
+Here is Section 5.2.3. of RFC 1034, "Temporary failures":
+
+In a less than perfect world, all resolvers will occasionally be unable
+to resolve a particular request.  This condition can be caused by a
+resolver which becomes separated from the rest of the network due to a
+link failure or gateway problem, or less often by coincident failure or
+unavailability of all servers for a particular domain.
+
+And finally, RFC 1035 specifies RRCODE 2 for this usage, which is now more
+widely known as SERVFAIL (RFC 1035, Section 4.1.1. "Header section format"):
+
+RCODE   Response code - this 4 bit field is set as part of
+responses.  The values have the following
+interpretation:
+(...)
+
+2   Server failure - The name server was
+unable to process this query due to a
+problem with the name server.
+
+For the DNSSEC-related usage of SERVFAIL, here is RFC 4033
+Section 5. "Scope of the DNSSEC Document Set and Last Hop Issues":
+
+A validating resolver can determine the following 4 states:
+(...)
+
+Insecure: The validating resolver has a trust anchor, a chain of
+   trust, and, at some delegation point, signed proof of the
+   non-existence of a DS record.  This indicates that subsequent
+   branches in the tree are provably insecure.  A validating resolver
+   may have a local policy to mark parts of the domain space as
+   insecure.
+
+Bogus: The validating resolver has a trust anchor and a secure
+   delegation indicating that subsidiary data is signed, but the
+   response fails to validate for some reason: missing signatures,
+   expired signatures, signatures with unsupported algorithms, data
+   missing that the relevant NSEC RR says should be present, and so
+   forth.
+(...)
+
+This specification only defines

Re: [LEDE-DEV] [LEDE DEV][wiki] Login with github

[Baptiste Jonglez]

Hi Thomas,

Is the github login integration supposed to work?  There is a bug reported
about a 404 error when trying to login:

  https://bugs.lede-project.org/index.php?do=details_id=531

Thanks!
Baptiste

On Sat, Oct 01, 2016 at 05:25:54PM +0200, Thomas Endt wrote:
> IIRC it was Martin who proposed to use oAuth to log in to the wiki with
> github credentials.
> 
> I installed the oAuth plugin (https://www.dokuwiki.org/plugin:oauth) for
> this purpose and created an oAuth application with my github account for
> testing purposes.
> 
> Since the owner of the application is shown under
> https://github.com/settings/applications and to avoid a SPOF, the owner of
> the LEDE-Wiki login application should probably be someone other than me.
> I'm not sure if github organizations (i.e. lede-project) can create oAuth
> applications. Can someone of the devs please try?
> 
>  Things to enter in https://github.com/settings/applications/new
> 
> Application name  : LEDE wiki login
> Homepage URL  : https://wiki.lede-project.org/doku.php
> Application description   : Log in to the LEDE wiki with your github 
> account.
> Authorization callback URL: https://wiki.lede-project.org/doku.php
> 
> After successful creation of the application, the "Client ID" and "Client
> Secret" need to be entered in the oAuth config of the wiki (-> admin ->
> config -> oAuth). You can either do this yourself or let me know.
> 
> To use the login via github, the user needs to update his wiki profile
> accordingly:
> -> Update profile -> Login with other Services -> check Github -> save
> 
> Please let me know your thoughts.
> 
> Regards,
> Thomas


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



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

Re: [LEDE-DEV] kmod-ebtables: install fails

[Baptiste Jonglez]

On Sun, Feb 19, 2017 at 01:48:04PM +0100, yanosz wrote:
> Hello,
> 
> I've some trouble installing kmod-ebtables on lede 17.01 rc2.
> 
> root@Node-2:/etc/config# opkg install kmod-ebtables
> Package kmod-ebtables (4.4.47-1) installed in root is up to date.

It looks like kmod-ebtables is already installed in your system?

> Configuring kmod-ebtables.
> ebtable_broute is already loaded
> ebtable_filter is already loaded
> ebtable_nat is already loaded
> ebt_802_3 is already loaded
> ebt_among is already loaded
> ebt_limit is already loaded
> ebt_mark_m is already loaded
> ebt_pkttype is already loaded
> ebt_stp is already loaded
> ebt_vlan is already loaded
> ebt_mark is already loaded
> ebt_redirect is already loaded
> Collected errors:
>  * pkg_run_script: package "kmod-ebtables" postinst script returned
> status 255.
>  * opkg_configure: kmod-ebtables.postinst returned 255.
> 
> uname -a
> root@Node-2:/etc/config# uname -a
> Linux Node-2 4.4.47 #0 Mon Feb 6 21:34:28 2017 mips GNU/Linux
> 
> I don't know what went wrong .. ebtables looks usable ... It seems like
> kmod-ebtables is suprised by its modules already been loaded ...
> 
> Greetz, yanosz




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



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

Re: [LEDE-DEV] [wiki]Table of packages is officially live!

[Baptiste Jonglez]

On Mon, Feb 20, 2017 at 06:52:15PM +, Alberto Bursi wrote:
> The wiki feature showing what packages are in LEDE (and some information 
> about them) is now complete! Hooray! :)
> 
> https://lede-project.org/packages/start

Great, thanks Alberto!

Here are a few questions and comments:

- what is the difference between /packages/$pkg and /packages/pkgdata/$pkg?
  e.g. https://lede-project.org/packages/tinc vs. 
https://lede-project.org/packages/pkgdata/tinc
  It seems that the first one is supposed to be created manually?

- what would you think of moving the "category" column more to the right
  in the tables, for instance after "source code"?  This way, the first
  two columns are "name" and "version", which are for me the most important
  information.

- the description field is often quite large (look for instance at the
  "network---vpn" category), so the table looks ugly.  I'm not sure how to
  fix this though, maybe show just the beginning of the text, and show the
  rest in a popup when hovering/clicking on the field?

- still with the description: it seems that line breaks are removed.  On
  the other hand, word-wrapped text is ugly in HTML.  What do you think of
  removing single line breaks, but treating two consecutive line breaks as
  a  or even a new  block?

- your script does not seem to handle multiple maintainers? (e.g. net/wireguard)

- just a cosmetic note: why not use "/" instead of "---" to separate
  between category and submenu?

Thanks again, other than these minor points it's a great tool :)

Baptiste


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

[LEDE-DEV] Broken emails and SPF (Was: [PATCH] This patch adds support for the Actiontec R1000H gateway to the brcm63xx targets.)

[Baptiste Jonglez]

On Thu, Feb 23, 2017 at 09:48:10PM +0100, David Woodhouse wrote:
> On Thu, 2017-02-23 at 21:35 +0100, Rafał Miłecki wrote:
> > On 12 February 2017 at 14:48, Anthony Sepa via Lede-dev
> >  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.
> > You don't need this and I think you were already instructed on other
> > ML not to do so.
> > 
> > Just include proper From: as the first e-mail of your e-mail body.
> > Actually git format-patch can even do that for you.
> 
> He didn't do that bit. That's the stupid list configuration. Anthony's
> problem was that he was posting from a mail domain with stupid
> settings. The list's stupidity is a reaction to that.
> 
> Personally, I think we're better off just *rejecting* posts from people
> with such broken domains.

Well, it may be stupid, but not really "broken", because it's done
intentionally by Yahoo:

$ dig +short yahoo.ca TXT
"v=spf1 redirect=_spf.mail.yahoo.com"
$ dig +short _spf.mail.yahoo.com TXT
"v=spf1 ptr:yahoo.com ptr:yahoo.net ?all"
$ dig +short _dmarc.yahoo.ca TXT
"v=DMARC1; p=reject; pct=100; rua=mailto:dmarc_y_...@yahoo.com;;

Long story short, Yahoo uses SPF to only allow yahoo mail servers to send
emails with a "From:" field in a @yahoo.whatever domain.
Google does the same thing for gmail, but they are just more permissive (for 
now?).

See also https://www.ietf.org/mail-archive/web/ietf/current/msg87153.html


David, you could configure the mailing list to avoid the annoying wrapping
of the original message, and just change the From field.  This may be less
confusing (but maybe this already got discussed elsewhere?)

Baptiste


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

[LEDE-DEV] [PATCH] build: fix dependency of kernel_menuconfig target

[Baptiste Jonglez]

From: Baptiste Jonglez <g...@bitsofnetworks.org>

When running "make kernel_menuconfig" in a clean tree, it fails with:

make[1]: *** No rule to make target 'tools/quilt/install'.  Stop.

Replacing the dependency with 'tools/quilt/compile' fixes the issue (quilt
and all its prerequisites will be built, and quilt will be installed in
staging_dir).

Signed-off-by: Baptiste Jonglez <g...@bitsofnetworks.org>
---
 include/toplevel.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/toplevel.mk b/include/toplevel.mk
index 24e4ebf823..a9ea21bbef 100644
--- a/include/toplevel.mk
+++ b/include/toplevel.mk
@@ -132,7 +132,7 @@ prepare_kernel_conf: .config FORCE
 
 ifeq ($(wildcard staging_dir/host/bin/quilt),)
   prepare_kernel_conf:
-   @+$(SUBMAKE) -r tools/quilt/install
+   @+$(SUBMAKE) -r tools/quilt/compile
 else
   prepare_kernel_conf: ;
 endif
-- 
2.11.1


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

[LEDE-DEV] [PATCH] sdk: Fix src-git URL for the base feed when on a detached commit (FS#501)

[Baptiste Jonglez]

From: Baptiste Jonglez <g...@bitsofnetworks.org>

When the source repository is on a detached commit (such as when building
a release tag), the git URL for the "base" feed is incorrect in the SDK.

Before this commit:

  On branch "master":  src-git base git://git.lede-project.org/source
  On branch "lede-17.01":  src-git base 
git://git.lede-project.org/source;lede-17.01
  On tag "v17.01.0-rc2":   src-git base git://git.lede-project.org/source;HEAD  
<-- incorrect

After this commit:

  On branch "master":  src-git base git://git.lede-project.org/source;master
  On branch "lede-17.01":  src-git base 
git://git.lede-project.org/source;lede-17.01
  On tag "v17.01.0-rc2":   src-git base 
git://git.lede-project.org/source^28b7d7f1dac725157c19236b8899e1c97f19cee9

Notice that the "master" branch is now explicitly expanded: this is just
to simplify the new code.

Signed-off-by: Baptiste Jonglez <g...@bitsofnetworks.org>
---
 target/sdk/Makefile | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/target/sdk/Makefile b/target/sdk/Makefile
index 719b659d25..34755b2096 100644
--- a/target/sdk/Makefile
+++ b/target/sdk/Makefile
@@ -38,9 +38,10 @@ SDK_DIRS = \
$(STAGING_SUBDIR_TOOLCHAIN)
 
 GIT_URL:=$(filter git://% http://% https://%,$(shell git config --get 
remote.origin.url 2>/dev/null))
-GIT_BRANCH:=$(filter-out master,$(shell git rev-parse --abbrev-ref HEAD 
2>/dev/null))
+GIT_BRANCH:=$(filter-out HEAD,$(shell git rev-parse --abbrev-ref HEAD 
2>/dev/null))
+GIT_DETACHED_COMMIT:=$(shell git rev-parse HEAD 2>/dev/null)
 
-BASE_FEED:=$(if $(GIT_URL),src-git base $(GIT_URL)$(if 
$(GIT_BRANCH),;$(GIT_BRANCH)))
+BASE_FEED:=$(if $(GIT_URL),src-git base $(GIT_URL)$(if 
$(GIT_BRANCH),;$(GIT_BRANCH),^$(GIT_DETACHED_COMMIT)))
 BASE_FEED:=$(if $(BASE_FEED),$(BASE_FEED),$(shell cd $(TOPDIR); LC_ALL=C git 
svn info 2>/dev/null | sed -ne 's/^URL: /src-gitsvn base /p'))
 BASE_FEED:=$(if $(BASE_FEED),$(BASE_FEED),$(shell cd $(TOPDIR); LC_ALL=C svn 
info 2>/dev/null | sed -ne 's/^URL: /src-svn base /p'))
 BASE_FEED:=$(if $(BASE_FEED),$(BASE_FEED),src-git base 
https://git.lede-project.org/source.git$(if $(GIT_BRANCH),;$(GIT_BRANCH)))
-- 
2.11.1


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

[LEDE-DEV] Cherry-pick "kernel: remove kmod packages for bridge, stp, llc and 8021q" to 17.01

[Baptiste Jonglez]

Hi Felix,

Could you cherry-pick the following commit to lede-17.01?
It should fix FS#433.

7096ed58: kernel: remove kmod packages for bridge, stp, llc and 8021q

As far as I can tell, these packages were dummy packages since quite some
time anyway, so it will just avoid the annoying error messages when
installing e.g. kmod-ebtables.

Thanks!
Baptiste


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

Re: [LEDE-DEV] [wiki]Wiki structure

[Baptiste Jonglez]

On Thu, Oct 06, 2016 at 08:38:35PM +, Alberto Bursi wrote:
> 
> 
> On 10/06/2016 02:14 PM, Rich Brown wrote:
> > The "experimental" section of the Wiki now substantially clones the entire 
> > web presence of www.lede-project.org. See the update info at: 
> > https://wiki.lede-project.org/talk:to_do_list
> 
> the wiki's "full version" (the desktop version) lacks the navigation 
> panel on the left side.
> To get anywhere I need to switch to "mobile version".

I see the same issue: with the default template, I only get a "Log in"
link on the left side, nothing else.

By the way, the mobile template looks usable enough on a regular computer,
is there a need to have two different templates?

Also, I find it a bit annoying that the menu on the left changes whenever
visiting different pages.  For instance, the links provided by the left
sidebar (with the mobile template) are very practical on the main page,
but when visiting e.g. https://wiki.lede-project.org/docs:start , an
entirely different set of links is displayed.  I find this somewhat
confusing.

All in all, the wiki looks nice and useful already, thanks for making it
happen!

Baptiste


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

Re: [LEDE-DEV] How do you develop (compile) LEDE efficiently?

[Baptiste Jonglez]

On Mon, Nov 07, 2016 at 06:23:49AM +0100, Rafał Miłecki wrote:
> On 7 November 2016 at 00:40, Russell Senior  wrote:
> > I have a 16-core build box which I connect to over ssh.  I use scp to
> > move images to devices.  I have a testbed with ethernet connections to
> > the build box and serial consoles on most if not all of them.
> 
> But what about development with modifying files in build_dir? That's
> the most tricky part for me.

What do you mean exactly?

I use the GCC compile farm to develop/compile, since the hardware there is
much faster than my laptop (and has more disk space).  I generally mount
the remote server locally using sshfs to get access to the generated
images and packages.  When I need to edit things in the development tree,
I do it directly on the server.


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

Re: [LEDE-DEV] [PATCH] wireguard: select parallel encryption engine

[Baptiste Jonglez]

Hi Jason,

Thanks for the patch.  Wireguard is not part of the core OpenWRT/LEDE
systems, it is managed on https://github.com/openwrt/packages , so you
should have sent a pull request there.

Nevertheless, I will try to test and apply your patch within a few days.

Baptiste

On Thu, Nov 10, 2016 at 04:08:15AM +0100, Jason A. Donenfeld wrote:
> On non SMP systems, this doesn't wind up doing anything or adding any
> code at all. On SMP systems, this adds a little bit of code, and makes
> encryption use all cores.
> 
> Signed-off-by: Jason A. Donenfeld 
> ---
>  net/wireguard/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/wireguard/Makefile b/net/wireguard/Makefile
> index 7387673..c5c014c 100644
> --- a/net/wireguard/Makefile
> +++ b/net/wireguard/Makefile
> @@ -89,7 +89,7 @@ define KernelPackage/wireguard
>CATEGORY:=Kernel modules
>SUBMENU:=Network Support
>TITLE:=Wireguard kernel module
> -  DEPENDS:=@IPV6 +kmod-udptunnel4 +kmod-udptunnel6 +kmod-ipt-hashlimit
> +  DEPENDS:=@IPV6 +@KERNEL_CRYPTO_PCRYPT +kmod-udptunnel4 +kmod-udptunnel6 
> +kmod-ipt-hashlimit
>FILES:= $(PKG_BUILD_DIR)/src/wireguard.$(LINUX_KMOD_SUFFIX)
>AUTOLOAD:=$(call AutoLoad,33,wireguard)
>  endef


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

Re: [LEDE-DEV] How do you develop (compile) LEDE efficiently?

[Baptiste Jonglez]

On Mon, Nov 07, 2016 at 09:51:31AM +0100, Rafał Miłecki wrote:
> >> But what about development with modifying files in build_dir? That's
> >> the most tricky part for me.
> >
> > What do you mean exactly?
> 
> Like working with quilt to modify software (kernel/packages) in the build_dir.

I see, I think I would do that directly on the server then.

> > I use the GCC compile farm to develop/compile, since the hardware there is
> > much faster than my laptop (and has more disk space).  I generally mount
> > the remote server locally using sshfs to get access to the generated
> > images and packages.  When I need to edit things in the development tree,
> > I do it directly on the server.
> 
> It sounds like sshfs being too slow for you? That's what bothers me. I
> think I'll just need to experiment with nfs and sshfs a bit and see if
> that will be fast enough for me or not.

It's not so much a matter of sshfs being slow than being unreliable.  If
you (or the server) lose network connectivity or change IP address while
you're working over sshfs, it's a bit inconvenient.  Sshfs uses fuse, so
initially it will just block I/O if the server is not reachable.  But if
the issue lasts for too long, from my experience the mountpoint will
either block I/O forever, return I/O errors or get unmounted.

Of course, on a local network, you're less likely to encounter issues.

Baptiste


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

Re: [LEDE-DEV] [PATCH] kernel: expose configuration for padata

[Baptiste Jonglez]

On Thu, Nov 10, 2016 at 04:07:44AM +0100, Jason A. Donenfeld wrote:
> The padata API is a powerful framework for doing parallel jobs inside
> the kernel, on which various modules in the package feed can depend,
> such as WireGuard. There is no item text, so that it does not show up
> in menuconfig, as this is only supposed to be an option selected as a
> dependency. There as already precedent for this behavior, with
> CONFIG_KERNEL_RELAY, on which several packages depend.

Looks good to me, I didn't see an increase in kernel size when selecting
this option on ar71xx (I looked at the size of
"build_dir/target-mips_24kc_musl-1.1.15/linux-ar71xx_generic/linux-4.4.30/vmlinuz")

However, I had to do a "make clean", because selecting
KERNEL_CRYPTO_PCRYPT does not cause all kmod packages to be rebuilt for
the new kernel config:

Collected errors:
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for  
kmod-lib-crc-ccitt:
 *  kernel (= 4.4.30-1-288c1d58c9e4426041f1cf660ee89665) *
 * opkg_install_cmd: Cannot install package kmod-lib-crc-ccitt.
…
make[2]: *** [package/install] Error 255
make[2]: Leaving directory `/home/bjonglez/lede'
make[1]: *** 
[/home/bjonglez/lede/staging_dir/target-mips_24kc_musl-1.1.15/stamp/.package_install]
 Error 2
make[1]: Leaving directory `/home/bjonglez/lede'
make: *** [world] Error 2 

Jow, does this have the potential to break the buildbot setup?

Baptiste


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

Re: [LEDE-DEV] [PATCH] scripts/getver.sh: treat all commits as local if can't find upstream

[Baptiste Jonglez]

Hi,

On Thu, Nov 17, 2016 at 07:25:21AM +0100, Rafał Miłecki wrote:
> If something goes wrong and script can't find upstream revision it will
> return something like:
> r2220
> which looks like a valid upstream revision 2220. We cant' distinguish it
> from e.g. 2200 upstream commits and 20 local ones.
> 
> The new format still provides revision number but also points clearly
> that is may be not the upstream one:
> r0+2220

I tried a LEDE snapshot yesterday, and the version number in the banner
had this format (r0+22XX, can't remember which version exactly).  So it
seems that there is an issue either with the buildbots or with your patch.

The exact snapshot I used is this one, for WR841 v11.0: 
https://downloads.lede-project.org/snapshots/targets/ar71xx/generic/lede-ar71xx-generic-tl-wr841-v11-squashfs-factory-eu.bin

Baptiste


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

[LEDE-DEV] [wiki] Permalinks to page sections

[Baptiste Jonglez]

Hi,

There is a small usability issue with the wiki: there is no easy way to
get a permalink to a page section (i.e. a link that includes an anchor).

First, it would be nice to have a small clickable permalink just beside a
section title.

Also, there is a bug in the table of contents of a page.  The table of
contents provides correct links to sections, but after clicking on the
link, the URL (with the anchor to the section) is not updated in the
address bar of the browser.

For instance:

1) https://wiki.lede-project.org/docs/user-guide/tunneling_interface_protocols
   has a table of contents, with links to sections, for instance
   
https://wiki.lede-project.org/docs/user-guide/tunneling_interface_protocols#protocol_wireguard_wireguard_vpn

2) When clicking on the link to a section, the page scrolls down to the
   section, this is good.

3) However, the URL in the address bar of the browser is still
   https://wiki.lede-project.org/docs/user-guide/tunneling_interface_protocols
   (there is no anchor at the end)

Thanks,
Baptiste


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

[LEDE-DEV] Package data on the wiki

[Baptiste Jonglez]

Hi,

I discovered that tons of packages now have their own page in the wiki,
which is nice.  It looks automated, what is the source of the data?

Here are a few observations:

- I'm not sure the list of architectures is very relevant, and it clutters
  the page a lot.  See for instance 
https://wiki.lede-project.org/pkgdata/htop-snapshot

- Regarding https://wiki.lede-project.org/pkgdata/wireguard-tools-snapshot
  the link to the "Source code" is wrong, it points to utils/openocd instead
  of net/wireguard.  Also, a lot of metadata have not been imported, like
  version or dependencies.

- There is no page for the kmod-wireguard package, which is built
  alongside wireguard-tools.  In fact, there seems to be no kmod-*
  packages at all.

Baptiste


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

[LEDE-DEV] Babeld now has procd support on OpenWRT/LEDE

[Baptiste Jonglez]

Hi,

Here is yet another OpenWRT-related change for babeld: I just merged procd
support for babeld [2], after more than two years of lingering [1].

The only user-visible changes should be:

- babeld now logs to the system log (visible with "logread") instead of a
  file in /var/log.  This is nice for embedded devices, where you don't
  want to write too much to the filesystem.  It is still possible to
  explicitly configure babeld to use a log file;

- babeld is now restarted automatically whenever it crashes;

- the usual procd niceties: calling "/etc/init.d/babeld reload" will
  restart babeld only if the configuration has changed.


Please test babeld 1.8.0-2 and report any resulting breakage.  I would
like this change (and the other compatibility change) to make it into the
upcoming LEDE release, which is due to happen quite soon.

Baptiste

[1] https://github.com/openwrt-routing/packages/pull/55
[2] https://github.com/openwrt-routing/packages/pull/250


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

Re: [LEDE-DEV] Difference between AutoLoad vs. AutoProbe for kernel modules?

[Baptiste Jonglez]

On Tue, Jan 10, 2017 at 07:56:36AM +0100, John Crispin wrote:
> >> While investigating an issue with module loading order¹, I discovered
> >> that
> >> some kernel packages use AutoProbe, like this:
> >>
> >>  AUTOLOAD:=$(call AutoProbe,xt_hashlimit)
> >>
> >> while some kernel packages use the AutoLoad helper I was used to, with a
> >> priority:
> >>
> >>  AUTOLOAD:=$(call AutoLoad,28,raid0)
> >>
> >> Judging from this commit² and `include/kernel.mk`, it seems the only
> >> difference is that AutoProbe does not include a priority.
> >>
> >> Is the loading order determined automatically for AutoProbe?  If so,
> >> where
> >> is the magic, and why is AutoLoad still needed in some cases?
> > 
> > I opened the issue, so using autoload the modules will get a priority
> > specified by the number, for wireguard above 90 would issue only one
> > warning and using autoprobe the module would be loaded by the order of
> > the name ? so setting the xt_hashlimit with a lower number (autoload)
> > will start wireguard without complaining
> > 
> 
> autoload is like insmod while autoproe is more liek modprobe. kmodloader
> will first load all numbered modules in the given order and then probe
> the remaining ones.

So, with AutoProbe, there is dependency resolution, similarly to modprobe?
But without using depmod?


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

Re: [LEDE-DEV] [RFC] build: adjust version number handling

[Baptiste Jonglez]

Hi jow,

On Thu, Dec 01, 2016 at 06:34:42PM +0100, Jo-Philipp Wich wrote:
> After this commit, the relevent files will look like the examples given below:
> # cat /usr/lib/os-release
> NAME="LEDE"
> VERSION="CURRENT, Reboot"
> ID="lede"
> ID_LIKE="lede openwrt"
> PRETTY_NAME="LEDE Reboot CURRENT"
> VERSION_ID="current"
> HOME_URL="http://www.lede-project.org/;
> BUG_URL="https://www.lede-project.org/development.html;

While you're at it, maybe you can update this variable to point to the
bugtracker?

Baptiste


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

Re: [LEDE-DEV] procd question, something causing high cpu usage

[Baptiste Jonglez]

Hi Sebastian,

On Mon, Dec 19, 2016 at 11:58:26PM +0100, Sebastian Kemper wrote:
> Hi all,
> 
> I'm running LEDE git from yesterday (but also observed this on an older
> git revision from a few weeks back) on a small mips router. When I start
> freeswitch compiled without libedit via procd, CPU usage goes up to a
> 100% percent. When freeswitch is compiled with libedit on the other
> hand, everything seems fine.
> 
> Also, when I start the libedit-less freeswitch from the command
> line/shell, all is fine, too.
> 
> When I set the logging to syslog (procd_set_param stdout 1), then
> logread shows this all the time:
> 
> Mon Dec 19 23:17:12 2016 daemon.info freeswitch[3495]: freeswitch@hank2> 
> Mon Dec 19 23:17:12 2016 daemon.info freeswitch[3495]: freeswitch@hank2> 
> Mon Dec 19 23:17:12 2016 daemon.info freeswitch[3495]: freeswitch@hank2> 
> Mon Dec 19 23:17:12 2016 daemon.info freeswitch[3495]: freeswitch@hank2> 

What is the behaviour of freeswitch when you launch it directly from the
command-line?  Does it give you a prompt, or does it just run in the
foreground without printing anything?

If freeswitch expects an interactive terminal to accept user commands,
it's most likely the cause of the issue, because procd does not provide
this.  If that is the case, maybe disabling the interactive prompt in
freeswitch could help?

> These messages keep flashing by, only the time stamp is changing. After
> a while the router hangs up and reboots. So it seems that freeswitch is
> blasting its command prompt to procd all the time. top suggests the
> same:
> 
>   PID  PPID USER STAT   VSZ %VSZ %CPU COMMAND
>  3629  3628 freeswit R23208  19%  46% freeswitch -c -cache 
> /tmp/freeswitch/
> 1 0 root R 1524   1%  26% /sbin/procd
>   723 1 root S 6288   5%  26% /sbin/logd -S 64
>  1472 1 root S 1664   1%   1% /usr/sbin/hostapd -P 
> /var/run/wifi-ph
> 
> Has anybody an idea what could cause this? Maybe the same experience
> with another program? Any idea what I could try to get around this?
> 
> I've put the procd part of the init script below. But I think it's
> pretty standard.
> 
> Kind regards,
> Sebastian
> 
>   procd_open_instance
>   procd_set_param command freeswitch
>   procd_append_param command -c -cache "$fs_dir_cache" \
> -conf "$fs_dir_etc" -db "$fs_dir_db" -log "$fs_dir_log" \
> -recordings "$fs_dir_recordings" -run "$fs_dir_run" \
> -storage "$fs_dir_storage" -temp "$fs_dir_temp" $OPTIONS
>   procd_set_param user "$fs_user"
>   # forward stdout of the command to logd
>   #procd_set_param stdout 1
>   # same for stderr
>   procd_set_param stderr 1
>   procd_close_instance
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


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

Re: [LEDE-DEV] [procd] Using "procd_set_param file" on a directory

[Baptiste Jonglez]

On Mon, Jan 09, 2017 at 04:58:23PM +0100, Baptiste Jonglez wrote:
> On Mon, Jan 09, 2017 at 04:36:25PM +0100, Felix Fietkau wrote:
> > It does not support passing a directory. You should do:
> > procd_set_param file /tmp/babeld.d/*.conf (without quotes)
> 
> I wanted to avoid this solution if possible, because it does not handle
> file creation.  However, that is not a major issue in my case, so I will
> use this solution.  Thanks!

Actually, it seems that this method *does* support file creation: when
creating a new file /tmp/babeld.d/foo.conf and calling "/etc/init.d/babeld
reload", the process is restarted.

I don't understand how this is possible, is start_service() called each
time a reload is requested?

Baptiste


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

[LEDE-DEV] [procd] Using "procd_set_param file" on a directory

[Baptiste Jonglez]

Hi,

I am using the "procd_set_param file" feature of procd, so that calling
"/etc/init.d/myscript reload" only restarts the process if one of the
config file has changed.

I was wondering if I can do the same thing on a directory?  Basically, my
daemon can now take configuration from all files in a given directory,
"/tmp/babeld.d/*.conf".  So, I would like to pass "/tmp/babeld.d" like this:

procd_set_param file "/tmp/babeld.d/"

In this case, will procd look for changes in any files in this directory?
Will it also detect file creation/deletion?

Thanks,
Baptiste

PS: the complete procd block is the following:

procd_open_instance  
procd_set_param command /usr/sbin/babeld -I "" -c "/etc/babeld.conf" -c 
"/var/etc/babeld.conf"
procd_set_param stdout 1
procd_set_param stderr 1   
# Last argument is a directory
procd_set_param file "/var/etc/babeld.conf" "/etc/babeld.conf" 
"/tmp/babeld.d"
procd_set_param respawn   
procd_close_instance


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

Re: [LEDE-DEV] [procd] Using "procd_set_param file" on a directory

[Baptiste Jonglez]

On Mon, Jan 09, 2017 at 04:36:25PM +0100, Felix Fietkau wrote:
> It does not support passing a directory. You should do:
> procd_set_param file /tmp/babeld.d/*.conf (without quotes)

I wanted to avoid this solution if possible, because it does not handle
file creation.  However, that is not a major issue in my case, so I will
use this solution.  Thanks!

On Mon, Jan 09, 2017 at 04:36:49PM +0100, Jo-Philipp Wich wrote:
> unfortunately it can't atm. Internally it calculates hashes over the
> contents of the given files and it has no handling for directory listing
> at all.
> 
> You could consider creating a dummy configuration only containing a
> commented-out directory listing and register that with procd - would
> that work in your case?

This seems quite complicated, the shell globbing approach looks much
simpler.

Thanks for your answers,
Baptiste


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

[LEDE-DEV] Breaking compatibility with pre-1.5.1 babeld on OpenWRT/LEDE

[Baptiste Jonglez]

Dear babeld users on OpenWRT/LEDE,

Starting from babeld 1.5.1, the UCI format for configuring babeld on
OpenWRT had changed to be more consistent with upstream babeld (use the
same option names, and a few other changes).

At the time, I had ensured backward compatibility, see:

  https://wiki.openwrt.org/doc/uci/babeld#backward_compatibility
  
https://github.com/openwrt-routing/packages/blob/master/babeld/files/babeld.init#L65

Since we are now at babeld 1.8 and a stable release of LEDE is nearing,
I would like to remove this compatibility code.  It would make the babeld
init script more readable and less confusing.  Quoting the Zen of Python:

« There should be one-- and preferably only one --obvious way to do it. »


If I hear no objection by the beginning of next week, I will go ahead with
the cleanup.  Please yell if you still need the old syntax.

Baptiste


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

[LEDE-DEV] Difference between AutoLoad vs. AutoProbe for kernel modules?

[Baptiste Jonglez]

Hi,

While investigating an issue with module loading order¹, I discovered that
some kernel packages use AutoProbe, like this:

AUTOLOAD:=$(call AutoProbe,xt_hashlimit)

while some kernel packages use the AutoLoad helper I was used to, with a
priority:

AUTOLOAD:=$(call AutoLoad,28,raid0)

Judging from this commit² and `include/kernel.mk`, it seems the only
difference is that AutoProbe does not include a priority.

Is the loading order determined automatically for AutoProbe?  If so, where
is the magic, and why is AutoLoad still needed in some cases?

Thanks,
Baptiste

¹ https://github.com/openwrt/packages/issues/3790
² 
https://git.lede-project.org/?p=source.git;a=commitdiff;h=022cadd64e8a24818d15b22bc28f3460e0b2519c


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

[LEDE-DEV] lantiq: cannot access flash on Netgear DM200 while porting LEDE

[Baptiste Jonglez]

Hi,

I am currently adding LEDE support for the Netgear DM200 VDSL modem
[https://wiki.openwrt.org/toh/netgear/dm200], which uses a Lantiq VR9 SoC.

I was able to boot LEDE from RAM, and got the LEDs working, but I cannot
get the flash to work with LEDE :(

The bootloader (u-boot) has access to the flash and says this after
initialisation:

8192 KiB W25Q64 at 0:3 is now current device

I assumed that it's a NOR flash chip given the size, connected via SPI.
The stock firmware only calls it "ltq_sflash" without being more specific.
For instance, here is the kernel cmdline from the stock firmware:

root=/dev/mtdblock4 ro rootfstype=squashfs 
ip=192.168.1.1:192.168.1.10eth0:on console=ttyLTQ0,115200 
ethaddr=00:E0:92:00:01:40 mem=62M panic=1 
mtdparts=ltq_sflash:128k(uboot),64k(gphyfirmware),1600k(kernel),512k(firmware),5120k(rootfs),7232k@0x3(image),64k(dniconfig),64k(log),512k(language),64k(sysconfig),8k(ubootconfig),4k(ART),4k(pot),-(ret)
 init=/etc/preinit vpe1_load_addr=0x83f0 vpe1_mem=1M 
ubootver=U-Boot-2010.06-LANTIQ-v-2.3.16.1


So, assuming it's similar to other VR9 devices, I used this DTS:

   fpi@1000 {
localbus@0 {
nor-boot@0 {
compatible = "lantiq,nor";
bank-width = <2>;
reg = <0 0x0 0x080>;
#address-cells = <1>;
#size-cells = <1>;

partitions {
// etc


But with this DTS, LEDE fails to initialize the flash chip ("probing
failed" and nothing in /proc/mtd):

[1.936821] lantiq nor flash device: 0080 at 1000
[1.941431] ltq-nor 1000.nor-boot: probing failed
[2.054037] libphy: lantiq,xrx200-mdio: probed
[2.078013] net-xrx200: invalid MAC, using random

I tried setting the CS (Chip Select) in the DTS, because the bootloader
uses bus 0 and CS 3 to access the flash.  I added this line to the
nor-boot@0 tree:

lantiq,cs = <3>;

but it didn't change anything, LEDE still cannot access the flash.

How can I find the right parameters for the flash and set them in the DTS?
Any guidance would be appreciated!

Thanks,
Baptiste


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

Re: [LEDE-DEV] Cake SQM killing my DIR-860L - was: [17.01] Kernel: bump to 4.4.51

[Baptiste Jonglez]

On Wed, Mar 01, 2017 at 08:23:13AM +0100, Stijn Segers wrote:
> OK... So I tried to disable offloading on the WAN interface (eth0.2 for the
> DIR-860L), but that throws the following error:
> 
> # ethtool -K tso off gso off gro off eth0
> Cannot get device feature names: No such device
> 
> Same for any other devices I try... Is there a way to disable offloading
> without ethtool?

I'm not sure the NIC of most embedded devices actually support
offloading...


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

Re: [LEDE-DEV] lantiq: cannot access flash on Netgear DM200 while porting LEDE

[Baptiste Jonglez]

On Sun, Apr 02, 2017 at 06:16:10PM +0200, Hauke Mehrtens wrote:
> The Vendor SDK is based on UGW 6.1.1, based on OpenWrt 12.09 with kernel
> 3.10 and device tree support. Probably even the vendor image uses a
> device tree compiled into the kernel image.
> According to the configuration file in
> /DM200-V1.0.0.44_gpl_src/config/defconfig_dm200
> it would include this dts file:
> /DM200-V1.0.0.44_gpl_src/target/linux/lantiq/image/dts/EASY220.dts
> In this dts file the flash is connected to the SPI controller.

I had already looked hard at the GPL archive (it was useful to find how to
get ethernet working), but I didn't find the DTS.  Thanks a lot!

I will use this DTS to get the SPI-attached flash working, and then there
are still a few things to fix before submitting.

Baptiste


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

Re: [LEDE-DEV] libressl fails to build on debian-x32

[Baptiste Jonglez]

Hi,

On Sat, Jul 29, 2017 at 06:20:00AM +, txt.file wrote:
> Hey folks,
> 
> I tried to build lede 17.01.2 which is using libressl 2.5.0 bug got an
> build error. The problem looks similar to the error described at
> https://wiki.debian.org/X32Port#amd64_assembly.
> 
> bn/bn_div.c:279: Error: incorrect register `%r14d' used with `q' suffix
> 
> A build log is attached. The file is gziped cause it is ~400 kB
> uncompressed.

Please try trunk, which has libressl 2.5.4 instead of 2.5.0.

If the issue is still there, you should open a bug upstream as it looks
like an upstream issue.


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

Re: [LEDE-DEV] [RFC] kernel patches cleanup

[Baptiste Jonglez]

On Mon, Jul 31, 2017 at 06:11:49PM +0200, John Crispin wrote:
> I rebased my ages old kernel patch cleanup series. It can be found here [1].
> 
> the series annotates all patches and splits them up into 3 folders
> backports/pending/hacks.
> 
> I'd like to push this asap if there are no mayor issues as it will be a pain
> to rebase once again

Just a minor note on your first patch 18f24f2ea2a28d04942db9d192496faf9f5f4cbc:

> diff --git a/include/quilt.mk b/include/quilt.mk
> index 7f525e2e93..61dcc7964c 100644
> --- a/include/quilt.mk
> +++ b/include/quilt.mk
> @@ -124,7 +130,9 @@ define Quilt/Refresh/Kernel
> echo "All kernel patches must start with either generic/ or 
> platform/"; \
> false; \
> }
> +   $(call 
> Quilt/RefreshDir,$(PKG_BUILD_DIR),$(GENERIC_BACKPORT_DIR),generic-backport/)
> $(call 
> Quilt/RefreshDir,$(PKG_BUILD_DIR),$(GENERIC_PATCH_DIR),generic/)
> +   $(call 
> Quilt/RefreshDir,$(PKG_BUILD_DIR),$(GENERIC_HACK_DIR),generic-hack/)
> $(call Quilt/RefreshDir,$(PKG_BUILD_DIR),$(PATCH_DIR),platform/)
>  endef

I think you can get rid of the check just above ("All kernel patches must
start with either generic/ or platform/"), because it is now incorrect.

Anyway, this is mostly cosmetic, because the check seems to be broken (it
does not trigger even after your changes).

Baptiste


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

Re: [LEDE-DEV] ECDSA support in dropbear (Was: Planning v17.01.2)

[Baptiste Jonglez]

Hi,

On Thu, Jun 15, 2017 at 04:41:50PM +0200, Jo-Philipp Wich wrote:
> > ... and, if I may throw my EUR 0.02 in, why not recompile dropbear
> > with "elliptic curve" support?
> 
> whats the size impact?

There is already an option DROPBEAR_ECC to enable ECDSA, disabled by
default, and it adds 23 KB to the MIPS binary.

See https://bugs.lede-project.org/index.php?do=details_id=786 for the
same request.

Baptiste


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

[LEDE-DEV] [PATCH 2/4] x86: Refresh subtargets kernel config

[Baptiste Jonglez]

From: Baptiste Jonglez <g...@bitsofnetworks.org>

This was done by simply running `make kernel_menuconfig CONFIG_TARGET=subtarget`
and then saving without changing any option.

Most of the removed options can be explained because they are already
present in the target config or in the generic 4.9 config:

- PAE-related options, enabled by default on x86 by 961c0eac
- LZO-related options, enabled by default since 4.9

As far as I understand the build system, this shouldn't have any
user-visible impact, because the build system already merges the
various kernel configs during build.

Signed-off-by: Baptiste Jonglez <g...@bitsofnetworks.org>
---
 target/linux/x86/64/config-default  | 16 ++--
 target/linux/x86/generic/config-default | 33 -
 target/linux/x86/geode/config-default   |  9 +
 target/linux/x86/legacy/config-default  | 24 +++-
 4 files changed, 10 insertions(+), 72 deletions(-)

diff --git a/target/linux/x86/64/config-default 
b/target/linux/x86/64/config-default
index 1950213b16..8288c1ade2 100644
--- a/target/linux/x86/64/config-default
+++ b/target/linux/x86/64/config-default
@@ -26,12 +26,8 @@ CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y
 # CONFIG_ACPI_SBS is not set
 CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT=y
 CONFIG_ACPI_THERMAL=y
-# CONFIG_ACPI_VIDEO is not set
 # CONFIG_ACPI_WMI is not set
 CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
-CONFIG_ARCH_DMA_ADDR_T_64BIT=y
-CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
-CONFIG_ARCH_ENABLE_SPLIT_PMD_PTLOCK=y
 CONFIG_ARCH_HAS_ACPI_TABLE_UPGRADE=y
 CONFIG_ARCH_HAS_GIGANTIC_PAGE=y
 CONFIG_ARCH_HAS_KCOV=y
@@ -40,14 +36,12 @@ CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC=y
 CONFIG_ARCH_MMAP_RND_BITS=28
 CONFIG_ARCH_MMAP_RND_BITS_MAX=32
 CONFIG_ARCH_MMAP_RND_BITS_MIN=28
-CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
 CONFIG_ARCH_SPARSEMEM_DEFAULT=y
 CONFIG_ARCH_SUPPORTS_INT128=y
 CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
 CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y
 CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
 CONFIG_AUDIT_ARCH=y
-# CONFIG_BACKLIGHT_APPLE is not set
 CONFIG_BACKLIGHT_CLASS_DEVICE=y
 CONFIG_BACKLIGHT_GENERIC=y
 CONFIG_BACKLIGHT_LCD_SUPPORT=y
@@ -133,6 +127,7 @@ CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
 CONFIG_GENERIC_CPU=y
 CONFIG_GENERIC_PENDING_IRQ=y
 CONFIG_GPIOLIB=y
+CONFIG_GPIOLIB_IRQCHIP=y
 CONFIG_GPIO_ACPI=y
 # CONFIG_GPIO_AMDPT is not set
 # CONFIG_GPIO_F7188X is not set
@@ -144,7 +139,6 @@ CONFIG_GPIO_SYSFS=y
 CONFIG_HAVE_ACPI_APEI=y
 CONFIG_HAVE_ACPI_APEI_NMI=y
 # CONFIG_HAVE_AOUT is not set
-CONFIG_HAVE_ARCH_HUGE_VMAP=y
 CONFIG_HAVE_ARCH_SOFT_DIRTY=y
 CONFIG_HAVE_ARCH_VMAP_STACK=y
 CONFIG_HAVE_CONTEXT_TRACKING=y
@@ -190,7 +184,6 @@ CONFIG_INTEL_IDLE=y
 # CONFIG_INTEL_MIC_BUS is not set
 # CONFIG_INTEL_PMC_IPC is not set
 # CONFIG_IOMMU_DEBUG is not set
-CONFIG_IOMMU_HELPER=y
 # CONFIG_ISCSI_IBFT_FIND is not set
 # CONFIG_ITCO_VENDOR_SUPPORT is not set
 CONFIG_ITCO_WDT=y
@@ -205,6 +198,7 @@ CONFIG_LEGACY_VSYSCALL_NONE=y
 # CONFIG_LIQUIDIO is not set
 CONFIG_LOCK_SPIN_ON_OWNER=y
 CONFIG_LPC_ICH=y
+CONFIG_LPC_SCH=y
 # CONFIG_MAXSMP is not set
 CONFIG_MEMORY_BALLOON=y
 # CONFIG_MEMORY_HOTPLUG is not set
@@ -221,7 +215,6 @@ CONFIG_MMC_SDHCI_PCI=y
 CONFIG_MODULES_USE_ELF_RELA=y
 # CONFIG_MPSC is not set
 CONFIG_MUTEX_SPIN_ON_OWNER=y
-CONFIG_NEED_DMA_MAP_STATE=y
 CONFIG_NET_FLOW_LIMIT=y
 CONFIG_NR_CPUS=8
 # CONFIG_NUMA is not set
@@ -240,12 +233,10 @@ CONFIG_PATA_PLATFORM=y
 CONFIG_PATA_VIA=y
 CONFIG_PCIEAER=y
 CONFIG_PCIEPORTBUS=y
-CONFIG_PCI_BUS_ADDR_T_64BIT=y
 # CONFIG_PCI_HYPERV is not set
 # CONFIG_PCI_MMCONFIG is not set
 CONFIG_PGTABLE_LEVELS=4
 CONFIG_PHYSICAL_ALIGN=0x100
-CONFIG_PHYS_ADDR_T_64BIT=y
 # CONFIG_PMIC_OPREGION is not set
 CONFIG_PNP=y
 CONFIG_PNPACPI=y
@@ -278,7 +269,6 @@ CONFIG_SPARSEMEM_MANUAL=y
 # CONFIG_SPARSEMEM_VMEMMAP is not set
 CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
 # CONFIG_SURFACE_PRO3_BUTTON is not set
-CONFIG_SWIOTLB=y
 # CONFIG_THUNDER_NIC_BGX is not set
 # CONFIG_THUNDER_NIC_PF is not set
 # CONFIG_THUNDER_NIC_RGX is not set
@@ -330,7 +320,6 @@ CONFIG_X86_ACPI_CPUFREQ=y
 CONFIG_X86_AMD_FREQ_SENSITIVITY=y
 # CONFIG_X86_AMD_PLATFORM_DEVICE is not set
 CONFIG_X86_CMOV=y
-CONFIG_X86_CMPXCHG64=y
 CONFIG_X86_DEBUGCTLMSR=y
 CONFIG_X86_DEV_DMA_OPS=y
 CONFIG_X86_DIRECT_GBPAGES=y
@@ -342,7 +331,6 @@ CONFIG_X86_MINIMUM_CPU_FAMILY=64
 # CONFIG_X86_PMEM_LEGACY is not set
 CONFIG_X86_PM_TIMER=y
 # CONFIG_X86_POWERNOW_K8 is not set
-CONFIG_X86_TSC=y
 # CONFIG_X86_VSYSCALL_EMULATION is not set
 CONFIG_X86_X2APIC=y
 # CONFIG_X86_X32 is not set
diff --git a/target/linux/x86/generic/config-default 
b/target/linux/x86/generic/config-default
index a2c8db33c9..cef35fd157 100644
--- a/target/linux/x86/generic/config-default
+++ b/target/linux/x86/generic/config-default
@@ -42,13 +42,9 @@ CONFIG_AGP_INTEL=y
 # CONFIG_AGP_SWORKS is not set
 # CONFIG_AGP_VIA is not set
 # CONFIG_APM is not set
-CONFIG_ARCH_ENABLE_SPLIT_PMD_PTLOCK=y
 CONFIG_ARCH_HAS_ACPI_TABLE_UPGRADE=y
 CONFIG_AR

[LEDE-DEV] [PATCH] x86: Fix xen serial console by removing conflicting PATA driver

[Baptiste Jonglez]

From: Baptiste Jonglez <g...@bitsofnetworks.org>

The Xen serial console has been broken since the xen_domu subtarget
was merged in the generic x86 subtarget (commits 1d6879ee and 371b382a).

The reason for the broken serial console seems to be an IRQ conflict
between the serial console driver and the PATA_LEGACY driver:

[1.330125] genirq: Flags mismatch irq 8.  (hvc_console) vs. 
 (platform[pata_legacy.4])
[1.330134] hvc_open: request_irq failed with rc -16.
[1.330148] Warning: unable to open an initial console.

Just drop the PATA_LEGACY driver from the x86/generic and x86_64
subtargets, since this driver is marked experimental and only supports
very old ISA devices anyway.  It is still included in the x86/legacy
subtarget where it rightfully belongs.

Fixes: FS#787

Signed-off-by: Baptiste Jonglez <g...@bitsofnetworks.org>
---
 target/linux/x86/64/config-default  | 1 -
 target/linux/x86/generic/config-default | 1 -
 2 files changed, 2 deletions(-)

diff --git a/target/linux/x86/64/config-default 
b/target/linux/x86/64/config-default
index 1950213b16..79607efd34 100644
--- a/target/linux/x86/64/config-default
+++ b/target/linux/x86/64/config-default
@@ -233,7 +233,6 @@ CONFIG_PARAVIRT_CLOCK=y
 CONFIG_PARAVIRT_SPINLOCKS=y
 CONFIG_PATA_AMD=y
 CONFIG_PATA_ATIIXP=y
-CONFIG_PATA_LEGACY=y
 CONFIG_PATA_MPIIX=y
 CONFIG_PATA_OLDPIIX=y
 CONFIG_PATA_PLATFORM=y
diff --git a/target/linux/x86/generic/config-default 
b/target/linux/x86/generic/config-default
index a2c8db33c9..7f10310638 100644
--- a/target/linux/x86/generic/config-default
+++ b/target/linux/x86/generic/config-default
@@ -274,7 +274,6 @@ CONFIG_PARAVIRT_SPINLOCKS=y
 # CONFIG_PARAVIRT_TIME_ACCOUNTING is not set
 CONFIG_PATA_AMD=y
 CONFIG_PATA_ATIIXP=y
-CONFIG_PATA_LEGACY=y
 CONFIG_PATA_MPIIX=y
 CONFIG_PATA_OLDPIIX=y
 CONFIG_PATA_PLATFORM=y
-- 
2.13.3


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

Re: [LEDE-DEV] [PATCH ubox v2] Add template support to logread

[Baptiste Jonglez]

Hi,

On Thu, Apr 27, 2017 at 04:33:31PM -0700, Henry Chang wrote:
> Hi,
> 
> I would like to integrate logd with a cloud logging service.
> The service only accepts certain format of log, so I decided to make logread 
> support an output template.

Can't this service use standard syslog messages?

E.g. by using something like:

  config system
  option log_remote '1'
  option log_ip '42.42.42.42'

> Here's the usage:
> 
> logread -T "%priority% %source% %message% %timestamp%"
> 
> Currently supports 4 keywords: priority, source, message, timestamp.
> The keywords should be surrounded by percent signs as showed above.
> 
> Regards,
> 
> Henry Chang
> 
> Henry Chang (1):
>   logread: Add support for output template
> 
>  log/logread.c | 153 
> --
>  1 file changed, 127 insertions(+), 26 deletions(-)


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

Re: [LEDE-DEV] [PATCH] mbedtls: Re-allow SHA1-signed certificates

[Baptiste Jonglez]

On Sun, Jul 30, 2017 at 06:00:48PM +0200, Baptiste Jonglez wrote:
> On Sun, Jul 30, 2017 at 05:57:37PM +0200, Baptiste Jonglez wrote:
> > Since mbedtls 2.5.1, SHA1 has been disallowed in TLS certificates.
> > This breaks openvpn clients that try to connect to servers that
> > present a TLS certificate signed with SHA1, which is fairly common.
> > 
> > Run-tested with openvpn-mbedtls 2.4.3, LEDE 17.01.2, on ar71xx.
> > 
> > Fixes: FS#942
> 
> This can be cherry-picked cleanly on the lede-17.01 branch.  I think it
> should be done, because the update to 2.5.1 broke a working use-case.

See the discussion on Flyspray: 
https://bugs.lede-project.org/index.php?do=details_id=942

As a compromise between security and stability, it makes sense to merge
this to lede-17.01 only, and keep SHA1 disabled in master.

> > Signed-off-by: Baptiste Jonglez <g...@bitsofnetworks.org>
> > ---
> >  package/libs/mbedtls/Makefile | 2 +-
> >  package/libs/mbedtls/patches/200-config.patch | 9 +
> >  2 files changed, 10 insertions(+), 1 deletion(-)
> > 
> > diff --git a/package/libs/mbedtls/Makefile b/package/libs/mbedtls/Makefile
> > index 4cceb743d5..101324de07 100644
> > --- a/package/libs/mbedtls/Makefile
> > +++ b/package/libs/mbedtls/Makefile
> > @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
> >  
> >  PKG_NAME:=mbedtls
> >  PKG_VERSION:=2.5.1
> > -PKG_RELEASE:=1
> > +PKG_RELEASE:=2
> >  PKG_USE_MIPS16:=0
> >  
> >  PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-gpl.tgz
> > diff --git a/package/libs/mbedtls/patches/200-config.patch 
> > b/package/libs/mbedtls/patches/200-config.patch
> > index 39de3cc1ec..fb5a74fc65 100644
> > --- a/package/libs/mbedtls/patches/200-config.patch
> > +++ b/package/libs/mbedtls/patches/200-config.patch
> > @@ -269,3 +269,12 @@
> >   
> >   /* \} name SECTION: mbed TLS modules */
> >   
> > +@@ -2646,7 +2646,7 @@
> > +  * recommended because of it is possible to generte SHA-1 collisions, 
> > however
> > +  * this may be safe for legacy infrastructure where additional controls 
> > apply.
> > +  */
> > +-// #define MBEDTLS_TLS_DEFAULT_ALLOW_SHA1_IN_CERTIFICATES
> > ++#define MBEDTLS_TLS_DEFAULT_ALLOW_SHA1_IN_CERTIFICATES
> > + 
> > + /**
> > +  * Allow SHA-1 in the default TLS configuration for TLS 1.2 handshake



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



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

Re: [LEDE-DEV] [PATCH] mbedtls: Re-allow SHA1-signed certificates

[Baptiste Jonglez]

On Sun, Jul 30, 2017 at 05:57:37PM +0200, Baptiste Jonglez wrote:
> Since mbedtls 2.5.1, SHA1 has been disallowed in TLS certificates.
> This breaks openvpn clients that try to connect to servers that
> present a TLS certificate signed with SHA1, which is fairly common.
> 
> Run-tested with openvpn-mbedtls 2.4.3, LEDE 17.01.2, on ar71xx.
> 
> Fixes: FS#942

This can be cherry-picked cleanly on the lede-17.01 branch.  I think it
should be done, because the update to 2.5.1 broke a working use-case.

> Signed-off-by: Baptiste Jonglez <g...@bitsofnetworks.org>
> ---
>  package/libs/mbedtls/Makefile | 2 +-
>  package/libs/mbedtls/patches/200-config.patch | 9 +
>  2 files changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/package/libs/mbedtls/Makefile b/package/libs/mbedtls/Makefile
> index 4cceb743d5..101324de07 100644
> --- a/package/libs/mbedtls/Makefile
> +++ b/package/libs/mbedtls/Makefile
> @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
>  
>  PKG_NAME:=mbedtls
>  PKG_VERSION:=2.5.1
> -PKG_RELEASE:=1
> +PKG_RELEASE:=2
>  PKG_USE_MIPS16:=0
>  
>  PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-gpl.tgz
> diff --git a/package/libs/mbedtls/patches/200-config.patch 
> b/package/libs/mbedtls/patches/200-config.patch
> index 39de3cc1ec..fb5a74fc65 100644
> --- a/package/libs/mbedtls/patches/200-config.patch
> +++ b/package/libs/mbedtls/patches/200-config.patch
> @@ -269,3 +269,12 @@
>   
>   /* \} name SECTION: mbed TLS modules */
>   
> +@@ -2646,7 +2646,7 @@
> +  * recommended because of it is possible to generte SHA-1 collisions, 
> however
> +  * this may be safe for legacy infrastructure where additional controls 
> apply.
> +  */
> +-// #define MBEDTLS_TLS_DEFAULT_ALLOW_SHA1_IN_CERTIFICATES
> ++#define MBEDTLS_TLS_DEFAULT_ALLOW_SHA1_IN_CERTIFICATES
> + 
> + /**
> +  * Allow SHA-1 in the default TLS configuration for TLS 1.2 handshake


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

[LEDE-DEV] [PATCH] mbedtls: Re-allow SHA1-signed certificates

[Baptiste Jonglez]

From: Baptiste Jonglez <g...@bitsofnetworks.org>

Since mbedtls 2.5.1, SHA1 has been disallowed in TLS certificates.
This breaks openvpn clients that try to connect to servers that
present a TLS certificate signed with SHA1, which is fairly common.

Run-tested with openvpn-mbedtls 2.4.3, LEDE 17.01.2, on ar71xx.

Fixes: FS#942

Signed-off-by: Baptiste Jonglez <g...@bitsofnetworks.org>
---
 package/libs/mbedtls/Makefile | 2 +-
 package/libs/mbedtls/patches/200-config.patch | 9 +
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/package/libs/mbedtls/Makefile b/package/libs/mbedtls/Makefile
index 4cceb743d5..101324de07 100644
--- a/package/libs/mbedtls/Makefile
+++ b/package/libs/mbedtls/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=mbedtls
 PKG_VERSION:=2.5.1
-PKG_RELEASE:=1
+PKG_RELEASE:=2
 PKG_USE_MIPS16:=0
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-gpl.tgz
diff --git a/package/libs/mbedtls/patches/200-config.patch 
b/package/libs/mbedtls/patches/200-config.patch
index 39de3cc1ec..fb5a74fc65 100644
--- a/package/libs/mbedtls/patches/200-config.patch
+++ b/package/libs/mbedtls/patches/200-config.patch
@@ -269,3 +269,12 @@
  
  /* \} name SECTION: mbed TLS modules */
  
+@@ -2646,7 +2646,7 @@
+  * recommended because of it is possible to generte SHA-1 collisions, however
+  * this may be safe for legacy infrastructure where additional controls apply.
+  */
+-// #define MBEDTLS_TLS_DEFAULT_ALLOW_SHA1_IN_CERTIFICATES
++#define MBEDTLS_TLS_DEFAULT_ALLOW_SHA1_IN_CERTIFICATES
+ 
+ /**
+  * Allow SHA-1 in the default TLS configuration for TLS 1.2 handshake
-- 
2.13.3


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

Re: [LEDE-DEV] WiFi speed on MT7620A

[Baptiste Jonglez]

On Wed, Aug 09, 2017 at 02:35:13AM -0700, Amir Sabbaghi wrote:
> Hi everyone,
> 
> I have a MT7620A based router which is supposed to handle 300Mbps of
> bandwidth over WiFi. But during my tests I could only get around
> 50Mbps which is very unstable and changes between 20Mbps to to 70Mbps.
> What is the problem? Is it a hardware limitation or the software is
> unable to take advantage of its full capacity? Are there any other
> drivers available for it's wireless chip?

See https://bugs.lede-project.org/index.php?do=details_id=929


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

[LEDE-DEV] b43 support for AC chipsets like BCM4360 and BCM4352?

[Baptiste Jonglez]

Hi,

As far as I can tell, the b43 driver does not support AC chipsets like
BCM4352, BCM4360, BCM4366.  Support for these is marked BROKEN upstream.

This means that a few devices supported by LEDE actually have no wireless,
for instance Archer C9 v1, ASUS RT-AC68U, maybe others.  Also, quite a lot
of dual-band devices lack 5 GHz support, because BCM4360 seems to be quite
popular as a second wireless chipset.

Is there any news regarding AC support in b43, and more generally
b43-related activity, or should we just avoid these devices?

Thanks,
Baptiste


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

Re: [LEDE-DEV] [PATCH] kernel: try to remove TCP_RENO from the kernel.

[Baptiste Jonglez]

Hi,

On Sat, Aug 05, 2017 at 06:15:46PM -0700, Rosen Penev wrote:
> LEDE currently uses CUBIC and not RENO by default. In theory, this
> change should remove RENO from the kernel, but it doesn't. Might
> as well keep it like this in case something changes.

As far as I can tell, Reno is hard-wired in the kernel TCP implementation.
So, it's just not possible to disable support for it.  I doubt it would
significantly reduce the size of the kernel anyway.

Baptiste

> Signed-off by: Rosen Penev 
> ---
>  target/linux/generic/config-3.18 | 2 +-
>  target/linux/generic/config-4.4  | 2 +-
>  target/linux/generic/config-4.9  | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/target/linux/generic/config-3.18 
> b/target/linux/generic/config-3.18
> index 1e3f0b5abe..de479a79a8 100644
> --- a/target/linux/generic/config-3.18
> +++ b/target/linux/generic/config-3.18
> @@ -867,7 +867,6 @@ CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
>  # CONFIG_DEFAULT_RENO is not set
>  CONFIG_DEFAULT_SECURITY=""
>  CONFIG_DEFAULT_SECURITY_DAC=y
> -CONFIG_DEFAULT_TCP_CONG="cubic"
>  CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
>  # CONFIG_DELL_SMO8800 is not set
>  # CONFIG_DEPRECATED_PARAM_STRUCT is not set
> @@ -3904,6 +3903,7 @@ CONFIG_TCP_CONG_CUBIC=y
>  # CONFIG_TCP_CONG_HYBLA is not set
>  # CONFIG_TCP_CONG_ILLINOIS is not set
>  # CONFIG_TCP_CONG_LP is not set
> +# CONFIG_TCP_RENO is not set
>  # CONFIG_TCP_CONG_SCALABLE is not set
>  # CONFIG_TCP_CONG_VEGAS is not set
>  # CONFIG_TCP_CONG_VENO is not set
> diff --git a/target/linux/generic/config-4.4 b/target/linux/generic/config-4.4
> index 1c0af9597f..1c13b89912 100644
> --- a/target/linux/generic/config-4.4
> +++ b/target/linux/generic/config-4.4
> @@ -911,7 +911,6 @@ CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
>  # CONFIG_DEFAULT_RENO is not set
>  CONFIG_DEFAULT_SECURITY=""
>  CONFIG_DEFAULT_SECURITY_DAC=y
> -CONFIG_DEFAULT_TCP_CONG="cubic"
>  CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
>  # CONFIG_DELL_RBTN is not set
>  # CONFIG_DELL_SMO8800 is not set
> @@ -4112,6 +4111,7 @@ CONFIG_TCP_CONG_CUBIC=y
>  # CONFIG_TCP_CONG_HYBLA is not set
>  # CONFIG_TCP_CONG_ILLINOIS is not set
>  # CONFIG_TCP_CONG_LP is not set
> +# CONFIG_TCP_RENO is not set
>  # CONFIG_TCP_CONG_SCALABLE is not set
>  # CONFIG_TCP_CONG_VEGAS is not set
>  # CONFIG_TCP_CONG_VENO is not set
> diff --git a/target/linux/generic/config-4.9 b/target/linux/generic/config-4.9
> index 24bbbc0587..06e2c4da4b 100644
> --- a/target/linux/generic/config-4.9
> +++ b/target/linux/generic/config-4.9
> @@ -1008,7 +1008,6 @@ CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
>  # CONFIG_DEFAULT_RENO is not set
>  CONFIG_DEFAULT_SECURITY=""
>  CONFIG_DEFAULT_SECURITY_DAC=y
> -CONFIG_DEFAULT_TCP_CONG="cubic"
>  CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
>  # CONFIG_DELL_RBTN is not set
>  # CONFIG_DELL_SMO8800 is not set
> @@ -4488,6 +4487,7 @@ CONFIG_TCP_CONG_CUBIC=y
>  # CONFIG_TCP_CONG_ILLINOIS is not set
>  # CONFIG_TCP_CONG_LP is not set
>  # CONFIG_TCP_CONG_NV is not set
> +# CONFIG_TCP_CONG_RENO is not set
>  # CONFIG_TCP_CONG_SCALABLE is not set
>  # CONFIG_TCP_CONG_VEGAS is not set
>  # CONFIG_TCP_CONG_VENO is not set


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

Re: [LEDE-DEV] b43 support for AC chipsets like BCM4360 and BCM4352?

[Baptiste Jonglez]

On Mon, Jul 31, 2017 at 06:31:43PM -0700, ros...@gmail.com wrote:
> Based on kernel activity, this driver is not under active development.
> 
> And yes, avoid.

Ok, I was hoping to get an answer from Rafał or Hauke.

But you seem to be right about the development activity!

Thanks,
Baptiste

> On Tue, 2017-08-01 at 00:42 +0200, Baptiste Jonglez wrote:
> > Hi,
> > 
> > As far as I can tell, the b43 driver does not support AC chipsets
> > like
> > BCM4352, BCM4360, BCM4366.  Support for these is marked BROKEN
> > upstream.
> > 
> > This means that a few devices supported by LEDE actually have no
> > wireless,
> > for instance Archer C9 v1, ASUS RT-AC68U, maybe others.  Also, quite
> > a lot
> > of dual-band devices lack 5 GHz support, because BCM4360 seems to be
> > quite
> > popular as a second wireless chipset.
> > 
> > Is there any news regarding AC support in b43, and more generally
> > b43-related activity, or should we just avoid these devices?
> > 
> > Thanks,
> > Baptiste


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

Re: [LEDE-DEV] Issues with ncurses (Was: Issues with xtables-addons after rebasing today)

[Baptiste Jonglez]

On 23-08-17, Koen Vandeputte wrote:
> Now this one pops up again (reported by Mauro Mozzarelli yesterday):
> 
> 
> find 
> /mnt/ramdisk/test/firmware/builds/generic_imx6/build_dir/target-arm_cortex-a9+neon_musl_eabi/util-linux-2.30.1/ipkg-arm_cortex-a9_neon/dmesg
> -name 'CVS' -o -name '.svn' -o -name '.#*' -o -name '*~'| xargs -r rm -rf
> Package dmesg is missing dependencies for the following libraries:
> libncursesw.so.6

This is probably related to the util-linux bump from a few days ago, it
added a dependency to libncursesw for fdisk but possibly missed dmesg.

Also, it's a bit of a mess, some util-linux packages depend on libncurses
and some depend on libncursesw (it's the same package in the end so it's
not such a big deal).

Baptiste

> Makefile:673: recipe for target 
> '/mnt/ramdisk/test/firmware/builds/generic_imx6/bin/packages/arm_cortex-a9_neon/base/dmesg_2.30.1-1_arm_cortex-a9_neon.ipk'
> failed
> make[3]: *** 
> [/mnt/ramdisk/test/firmware/builds/generic_imx6/bin/packages/arm_cortex-a9_neon/base/dmesg_2.30.1-1_arm_cortex-a9_neon.ipk]
> Error 1
> make[3]: Leaving directory
> '/mnt/ramdisk/test/firmware/builds/generic_imx6/package/utils/util-linux'
> package/Makefile:109: recipe for target 'package/utils/util-linux/compile'
> failed
> make[2]: *** [package/utils/util-linux/compile] Error 2
> make[2]: Leaving directory '/mnt/ramdisk/test/firmware/builds/generic_imx6'
> package/Makefile:105: recipe for target 
> '/mnt/ramdisk/test/firmware/builds/generic_imx6/staging_dir/target-arm_cortex-a9+neon_musl_eabi/stamp/.package_compile'
> failed
> make[1]: *** 
> [/mnt/ramdisk/test/firmware/builds/generic_imx6/staging_dir/target-arm_cortex-a9+neon_musl_eabi/stamp/.package_compile]
> Error 2
> make[1]: Leaving directory '/mnt/ramdisk/test/firmware/builds/generic_imx6'
> /mnt/ramdisk/test/firmware/builds/generic_imx6/include/toplevel.mk:207:
> recipe for target 'world' failed
> make: *** [world] Error 2
> 
> 
> 
> Remark: I'm using the full dmesg package, not the one provided in busybox
> 
> I'll leave the build in it's current state here.
> If you want details from a certain file, please let me know.
> 
> 
> Koen
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


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

Re: [LEDE-DEV] [PATCH 2/3] ramips-mt7621: add GPIO-config for Ubiquiti-EdgeRouterX(-SFP)

[Baptiste Jonglez]

On Sat, May 06, 2017 at 08:08:54PM +0200, Mathias Kresin wrote:
> 06.05.2017 14:31, Sven Roederer:
> >On Freitag, 5. Mai 2017 14:32:12 CEST Mathias Kresin wrote:
> >>Is it necessary to control the GPIOs from userspace/via config files?
> >>If not, add a gpio_export node to the dts and set the output value
> >>this way [0].
> >>
> > Or is there something better?
> 
> Yes there is. Please add a gpio-export node to the dts (see
> target/linux/ramips/dts/A5-V11.dts). It does basically the same but allows
> to set the polarity and uses the gpio-export,name for the actual export. And
> it doesn't add userspace stuff to the image which is included for all
> images.
> 
> >
> >To have it in userspace is the best (only?) option to enable / disable or
> >power-cycle the attached PoE-equipment.
> 
> The question is more or less whether it is necessary to disable PoE for the
> ports. The gpio-export node for example, is used in most cases for enabling
> something like usb power.

Just an opinion: being able to disable/enable PoE for each port is really
useful when you want to remotely reboot a device plugged into your PoE
switch/router.  Most PoE-capable devices expose this option with the stock
firmware.

Does your approach with the gpio-export node allow to change the state of
the GPIO at runtime? (i.e. probably from userspace)

> I have no strong opinion on this and I'll leave it up to you to add what you
> are the opinion is the best.
> 
> Mathias
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


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

Re: [LEDE-DEV] [PATCH] scripts/download.pl: fail loudly if provided hash is unsupported

[Baptiste Jonglez]

Thanks for merging, can this be merged to lede-17.01 as well?

On 03-09-17, Baptiste Jonglez wrote:
> Currently, if the provided hash is unsupported (length different from 32
> or 64 bytes), we happily download the requested file without any kind of
> checksum verification.
> 
> This is quite dangerous and may provide a false sense of security, because
> a single typo in the hash (e.g. one character deleted by mistake) may skip
> checksum verification entirely.
> 
> Instead, fail immediately if we don't support the provided hash.
> In particular, if an external package repository decides to change the
> hash algorithm one day, we will now fail loudly instead of skipping
> checksum verification without complaints.
> 
> Note: if some users of scripts/download.pl knowingly provide an empty hash
> because they don't need checksum verification, this change will break
> them.  This does not seem to be the case currently, but if this feature is
> ever needed, an option should be added to download.pl instead of relying
> on the hash being empty.
> 
> Fixes: eaa4eba10a89 ("scripts/download.pl: add SHA-256 support")
> 
> Signed-off-by: Baptiste Jonglez <g...@bitsofnetworks.org>
> ---
>  scripts/download.pl | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/scripts/download.pl b/scripts/download.pl
> index bf9fe8c761..775408934a 100755
> --- a/scripts/download.pl
> +++ b/scripts/download.pl
> @@ -88,6 +88,7 @@ sub download_cmd($) {
>  }
>  
>  my $hash_cmd = hash_cmd();
> +$hash_cmd or die "Cannot find appropriate hash command, ensure the provided 
> hash is either a MD5 or SHA256 checksum.\n";
>  
>  sub download
>  {


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

Re: [LEDE-DEV] [PATCH] ipq806x: Archer C2600: fix switch ports numbering

[Baptiste Jonglez]

Can this be merged to lede-17.01?  As I mentioned in the commit, it
applies cleanly.

Thanks,
Baptiste

On 23-08-17, Baptiste Jonglez wrote:
> The order of LAN ports shown in Luci is reversed compared to what is
> written on the case of the device.  Fix the order so that they match.
> 
> Signed-off-by: Baptiste Jonglez <g...@bitsofnetworks.org>
> ---
> This patch applies cleanly to the lede-17.01 branch and should
> be backported there too.
> 
>  target/linux/ipq806x/base-files/etc/board.d/02_network | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/target/linux/ipq806x/base-files/etc/board.d/02_network 
> b/target/linux/ipq806x/base-files/etc/board.d/02_network
> index 28e42dcaf8..28dc405c8a 100755
> --- a/target/linux/ipq806x/base-files/etc/board.d/02_network
> +++ b/target/linux/ipq806x/base-files/etc/board.d/02_network
> @@ -13,7 +13,6 @@ board=$(board_name)
>  
>  case "$board" in
>  ap148 |\
> -c2600 |\
>  d7800 |\
>  r7500 |\
>  r7500v2 |\
> @@ -22,6 +21,10 @@ vr2600v)
>   ucidef_add_switch "switch0" \
>   "1:lan" "2:lan" "3:lan" "4:lan" "6@eth1" "5:wan" "0@eth0"
>   ;;
> +c2600)
> + ucidef_add_switch "switch0" \
> + "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "6@eth1" "5:wan" 
> "0@eth0"
> + ;;
>  db149)
>   ucidef_set_interface_lan "eth1 eth2 eth3"
>   ucidef_add_switch "switch0" \


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

Re: [LEDE-DEV] [PATCH] ath10k: Re-enable intermediate softqueues for all devices

[Baptiste Jonglez]

On 19-09-17, Toke Høiland-Jørgensen wrote:
> Baptiste Jonglez <bapti...@bitsofnetworks.org> writes:
> 
> > Hi,
> >
> > On 14-09-17, Toke Høiland-Jørgensen wrote:
> >> Toke Høiland-Jørgensen <t...@toke.dk> writes:
> >> 
> >> > The upstream ath10k driver disables the intermediate softqueues for some
> >> > devices. This patch reverts that behaviour and always enables the
> >> > softqueues (and associated bufferbloat fixes). We have had reports of 
> >> > people
> >> > running this with good results:
> >> > https://lists.bufferbloat.net/pipermail/make-wifi-fast/2017-September/001497.html
> >> 
> >> So there seems to be some issues with QCA9980 with this patch. See
> >> https://lists.bufferbloat.net/pipermail/make-wifi-fast/2017-September/001505.html
> >
> > I have updated my Archer C2600 to 53839da46e a few days ago (your patch
> > was just merged) and did not notice any particular performance issue.  The
> > Archer C2600 also has a QCA9980.
> 
> Cool, thanks for testing! The other performance problems that were
> reported also seem to be fixed, so no need to revert the patch after all :)

OK, good news :)

I did stress the Archer C2600 but forgot to report about it, everything
looked normal (up to ~450 Mbps on 5 GHz).


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

Re: [LEDE-DEV] [PATCH] ath10k: Re-enable intermediate softqueues for all devices

[Baptiste Jonglez]

Hi,

On 14-09-17, Toke Høiland-Jørgensen wrote:
> Toke Høiland-Jørgensen  writes:
> 
> > The upstream ath10k driver disables the intermediate softqueues for some
> > devices. This patch reverts that behaviour and always enables the
> > softqueues (and associated bufferbloat fixes). We have had reports of people
> > running this with good results:
> > https://lists.bufferbloat.net/pipermail/make-wifi-fast/2017-September/001497.html
> 
> So there seems to be some issues with QCA9980 with this patch. See
> https://lists.bufferbloat.net/pipermail/make-wifi-fast/2017-September/001505.html

I have updated my Archer C2600 to 53839da46e a few days ago (your patch
was just merged) and did not notice any particular performance issue.  The
Archer C2600 also has a QCA9980.

I will stress it a bit more tomorrow to see if there is a performance
problem.

Baptiste


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

Re: [LEDE-DEV] [PATCH lede-17.01 1/4] x86/generic: use HIGHMEM64G instead of HIGHMEM4G to fix PAE and Xen

[Baptiste Jonglez]

Hi,

Any chance to get this patch serie merged to the lede-17.01 branch?
As far as I can tell:

- Xen support is still broken in 17.01
- this patch serie still applies cleanly

Thanks,
Baptiste

On 15-07-17, Baptiste Jonglez wrote:
> From: Baptiste Jonglez <g...@bitsofnetworks.org>
> 
> This is a backport of 641a65fd062987a456216cc4fa91ff2910528261 in master.
> 
> This change re-enables PAE for the 32-bit x86 subtarget, which is
> interesting in its own right but also necessary for Xen support.
> 
> Commit af1d1ebd ("x86: enable 4G high memory support for generic (32bit)
> subtarget") inadvertently disabled both PAE and Xen support.
> 
> Fixes: FS#908
> 
> Cc: Daniel Golle <dan...@makrotopia.org>
> Cc: Jo-Philipp Wich <j...@mein.io>
> Signed-off-by: Baptiste Jonglez <g...@bitsofnetworks.org>
> ---
>  target/linux/x86/generic/config-default | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/target/linux/x86/generic/config-default 
> b/target/linux/x86/generic/config-default
> index 1a14c270bc..c4ca4fd396 100644
> --- a/target/linux/x86/generic/config-default
> +++ b/target/linux/x86/generic/config-default
> @@ -42,6 +42,7 @@ CONFIG_AGP_INTEL=y
>  # CONFIG_AGP_SWORKS is not set
>  # CONFIG_AGP_VIA is not set
>  # CONFIG_APM is not set
> +CONFIG_ARCH_DMA_ADDR_T_64BIT=y
>  CONFIG_ARCH_ENABLE_SPLIT_PMD_PTLOCK=y
>  CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC=y
>  CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
> @@ -165,7 +166,8 @@ CONFIG_HDMI=y
>  CONFIG_HIBERNATE_CALLBACKS=y
>  CONFIG_HID=y
>  CONFIG_HID_BATTERY_STRENGTH=y
> -# CONFIG_HIGHMEM64G is not set
> +# CONFIG_HIGHMEM4G is not set
> +CONFIG_HIGHMEM64G=y
>  CONFIG_HOTPLUG_CPU=y
>  CONFIG_HPET=y
>  CONFIG_HPET_MMAP=y
> @@ -267,6 +269,7 @@ CONFIG_PATA_VIA=y
>  CONFIG_PCIEAER=y
>  CONFIG_PCIEPORTBUS=y
>  CONFIG_PCIE_PME=y
> +CONFIG_PCI_BUS_ADDR_T_64BIT=y
>  CONFIG_PCI_MMCONFIG=y
>  CONFIG_PCI_XEN=y
>  # CONFIG_PCWATCHDOG is not set


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

Re: [LEDE-DEV] [PATCH] scripts/download.pl: fail loudly if provided hash is unsupported

[Baptiste Jonglez]

On 08-10-17, Stijn Tintel wrote:
> On 25-09-17 18:43, Stijn Tintel wrote:
> > On 25-09-17 00:20, Baptiste Jonglez wrote:
> >> On 24-09-17, Stijn Tintel wrote:
> >>> My bad. When we update a package, we bump the version in the Makefile
> >>> and remove the current hash, then run "make package/foo/dowload; make
> >>> package/foo/check FIXUP=1". This downloads the tarbal for the new
> >>> version, and FIXUP writes its hash to the Makefile. This is what's
> >>> broken since the change.
> >> Ok, I see the issue now.
> >>
> >> As mentioned in the commit message, we definitely should add an explicit
> >> option to download.pl to skip hash verification, and then implement
> >> something like this:
> >>
> >> $ make package/foo/download SKIPHASH=1
> >>
> >> What do you think?
> > We were thinking in that direction on #lede-dev, not sure why we
> > couldn't agree. Let's wait a bit if anybody else chimes in?

> Maybe just send an RFC patch with the suggested change, as nobodoy seems
> to be responding.

Yes, sorry for the delay, I will submit a patch in the coming days/weeks.

Baptiste


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

Re: [LEDE-DEV] [PATCH lede-17.01 1/4] x86/generic: use HIGHMEM64G instead of HIGHMEM4G to fix PAE and Xen + revert

[Baptiste Jonglez]

On 16-10-17, Felix Fietkau wrote:
> On 2017-10-16 09:43, Baptiste Jonglez wrote:
> > Hi,
> > 
> > Any chance to get this patch serie merged to the lede-17.01 branch?
> > As far as I can tell:
> > 
> > - Xen support is still broken in 17.01
> > - this patch serie still applies cleanly
> Done. Sorry for the delay.

Thanks!

Jow, I noticed your subsequent revert in 46e29bd0788, can you explain a
bit more about the rationale?  Isn't it safe to refresh kernel config this
way?

As far as I can tell, all symbols removed by the refresh were redundant
with either the generic config or the x86 target config (except for
CONFIG_X86_X2APIC and CONFIG_ACPI_VIDEO which are not defined anywhere).

Thanks,
Baptiste


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

Re: [LEDE-DEV] [PATCH] netifd-proto.sh: add ip4table & ip6table to `proto_add_dynamic_defaults()`

[Baptiste Jonglez]

On 09-09-17, Baptiste Jonglez wrote:
> On 05-09-17, Alexandru Ardelean wrote:
> > The `proto_add_dynamic_defaults()` seems to be called mostly
> > in the context of LTE/3G modems (via wwan, qmi, etc) setup.
> > 
> > When they get setup, these devices override default routes.
> > 
> > However, depending on setup, we want these modems to
> > be part of a another routing table.
> > This change allows that.
> > 
> > ip4table/ip6table are of string type in netifd to allow
> > for `default`, `local` routing table names to be specified.
> 
> Just a remark on the names: "ip4table" and "ip6table" make it looks like
> it's related to firewall.  But this has nothing to do with firewalls.
> 
> Maybe use "routingtable" and "routingtablev6" instead?  Or just
> "table"/"tablev6"?

It seems that "ip4table" and "ip6table" is already understood by other
protocols, so you can disregard my remark:

https://wiki.openwrt.org/doc/uci/network#options_valid_for_all_protocol_types


> > Signed-off-by: Alexandru Ardelean <ardeleana...@gmail.com>
> > ---
> >  scripts/netifd-proto.sh | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/scripts/netifd-proto.sh b/scripts/netifd-proto.sh
> > index cc7031a..fd7b596 100644
> > --- a/scripts/netifd-proto.sh
> > +++ b/scripts/netifd-proto.sh
> > @@ -26,6 +26,8 @@ proto_add_dynamic_defaults() {
> > [ -n "$defaultroute" ] && json_add_boolean defaultroute "$defaultroute"
> > [ -n "$peerdns" ] && json_add_boolean peerdns "$peerdns"
> > [ -n "$metric" ] && json_add_int metric "$metric"
> > +   [ -n "$ip4table" ] && json_add_string ip4table "$ip4table"
> > +   [ -n "$ip6table" ] && json_add_string ip6table "$ip6table"
> >  }
> >  
> >  _proto_do_teardown() {




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

Re: [LEDE-DEV] [PATCH] netifd-proto.sh: add ip4table & ip6table to `proto_add_dynamic_defaults()`

[Baptiste Jonglez]

Hi,

On 05-09-17, Alexandru Ardelean wrote:
> The `proto_add_dynamic_defaults()` seems to be called mostly
> in the context of LTE/3G modems (via wwan, qmi, etc) setup.
> 
> When they get setup, these devices override default routes.
> 
> However, depending on setup, we want these modems to
> be part of a another routing table.
> This change allows that.
> 
> ip4table/ip6table are of string type in netifd to allow
> for `default`, `local` routing table names to be specified.

Just a remark on the names: "ip4table" and "ip6table" make it looks like
it's related to firewall.  But this has nothing to do with firewalls.

Maybe use "routingtable" and "routingtablev6" instead?  Or just
"table"/"tablev6"?

> Signed-off-by: Alexandru Ardelean 
> ---
>  scripts/netifd-proto.sh | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/scripts/netifd-proto.sh b/scripts/netifd-proto.sh
> index cc7031a..fd7b596 100644
> --- a/scripts/netifd-proto.sh
> +++ b/scripts/netifd-proto.sh
> @@ -26,6 +26,8 @@ proto_add_dynamic_defaults() {
>   [ -n "$defaultroute" ] && json_add_boolean defaultroute "$defaultroute"
>   [ -n "$peerdns" ] && json_add_boolean peerdns "$peerdns"
>   [ -n "$metric" ] && json_add_int metric "$metric"
> + [ -n "$ip4table" ] && json_add_string ip4table "$ip4table"
> + [ -n "$ip6table" ] && json_add_string ip6table "$ip6table"
>  }
>  
>  _proto_do_teardown() {


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

Re: [LEDE-DEV] [PATCH] scripts/download.pl: fail loudly if provided hash is unsupported

[Baptiste Jonglez]

Hi,

On 24-09-17, Stijn Tintel wrote:
> On 03-09-17 15:01, Baptiste Jonglez wrote:
> > Note: if some users of scripts/download.pl knowingly provide an empty hash
> > because they don't need checksum verification, this change will break
> > them.  This does not seem to be the case currently, but if this feature is
> > ever needed, an option should be added to download.pl instead of relying
> > on the hash being empty.
>
> Unfortunately this change breaks the make/foo/download feature,

Can you elaborate on this?  It seems to work fine here:

$ make package/dnsmasq/download V=s
make[1]: Entering directory '/lede/tmp/lede-project'
make[2]: Entering directory 
'/lede/tmp/lede-project/package/network/services/dnsmasq'
mkdir -p /lede/tmp/lede-project/dl
SHELL= flock /lede/tmp/lede-project/tmp/.dnsmasq-2.77.tar.xz.flock -c ' 
/lede/tmp/lede-project/scripts/download.pl "/lede/tmp/lede-project/dl" 
"dnsmasq-2.77.tar.xz" 
"6eac3b1c50ae25170e3ff8c96ddb55236cf45007633fdb8a35b1f3e02f5f8b8a" "" 
"http://thekelleys.org.uk/dnsmasq/;'
+ curl -f --connect-timeout 20 --retry 5 --location --insecure 
http://thekelleys.org.uk/dnsmasq/dnsmasq-2.77.tar.xz
  % Total% Received % Xferd  Average Speed   TimeTime Time  
Current
 Dload  Upload   Total   SpentLeft  
Speed
100  475k  100  475k0 0   237k  0  0:00:02  0:00:02 --:--:--  
232k
make[2]: Leaving directory 
'/lede/tmp/lede-project/package/network/services/dnsmasq'
make[1]: Leaving directory '/lede/tmp/lede-project'

> and because of this also the script we use to update kernel versions and
> refresh patches for all targets. This has been discussed in #lede-dev a
> few times, but we never agreed on a solution. Today, this is biting me
> once again, and therefore I suggest to revert this change until we can
> agree on a solution that is both secure and doesn't break something some
> of use rather frequently.


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

Re: [LEDE-DEV] [PATCH] scripts/download.pl: fail loudly if provided hash is unsupported

[Baptiste Jonglez]

On 24-09-17, Stijn Tintel wrote:
> My bad. When we update a package, we bump the version in the Makefile
> and remove the current hash, then run "make package/foo/dowload; make
> package/foo/check FIXUP=1". This downloads the tarbal for the new
> version, and FIXUP writes its hash to the Makefile. This is what's
> broken since the change.

Ok, I see the issue now.

As mentioned in the commit message, we definitely should add an explicit
option to download.pl to skip hash verification, and then implement
something like this:

$ make package/foo/download SKIPHASH=1

What do you think?


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

Re: [LEDE-DEV] [PATCH] minidlna: update to 1.2.1

[Baptiste Jonglez]

Hi,

minidlna belongs to the package feed: this patch (and the follow-up ones)
should be submitted to https://github.com/openwrt/packages/ and
https://github.com/openwrt/luci

Baptiste

On 23-09-17, James Christopher Adduono wrote:
> 1.2.1 - Released 24-Aug-2017
> 
> - Added Movian client detection and subtitle support.
> - Fixed an issue with discovery on non-Linux systems.
> - Fixed Bonjour discovery compatibility with TiVo Bolt.
> - Fixed NFO file parsing, and added change monitoring support for them.
> - Added a workaround for video thumbnails on some Samsung clients.
> - Added DoS protection for event subscriptions.
> - Fixed content browsing issues with some Samsung TVs.
> - Improved non-destructive update scan support.
> 
> Signed-off-by: James Christopher Adduono 
> ---
>  multimedia/minidlna/Makefile | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/multimedia/minidlna/Makefile b/multimedia/minidlna/Makefile
> index e2c79e84..92439193 100644
> --- a/multimedia/minidlna/Makefile
> +++ b/multimedia/minidlna/Makefile
> @@ -8,12 +8,12 @@
>  include $(TOPDIR)/rules.mk
>  
>  PKG_NAME:=minidlna
> -PKG_VERSION:=1.2.0
> +PKG_VERSION:=1.2.1
>  PKG_RELEASE:=1
>  
>  PKG_SOURCE_URL:=@SF/minidlna
>  PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
> -PKG_HASH:=8d34436580c4c44be25976d5e46bc5b71af69bf441c4492774eac001164c4433
> +PKG_HASH:=67388ba23ab0c7033557a32084804f796aa2a796db7bb2b770fb76ac2a742eec
>  
>  PKG_LICENSE:=GPL-2.0 BSD-3-Clause
>  PKG_LICENSE_FILES:=COPYING LICENCE.miniupnpd


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

[LEDE-DEV] [PATCH] ipq806x: Archer C2600: fix switch ports numbering

[Baptiste Jonglez]

From: Baptiste Jonglez <g...@bitsofnetworks.org>

The order of LAN ports shown in Luci is reversed compared to what is
written on the case of the device.  Fix the order so that they match.

Signed-off-by: Baptiste Jonglez <g...@bitsofnetworks.org>
---
This patch applies cleanly to the lede-17.01 branch and should
be backported there too.

 target/linux/ipq806x/base-files/etc/board.d/02_network | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/target/linux/ipq806x/base-files/etc/board.d/02_network 
b/target/linux/ipq806x/base-files/etc/board.d/02_network
index 28e42dcaf8..28dc405c8a 100755
--- a/target/linux/ipq806x/base-files/etc/board.d/02_network
+++ b/target/linux/ipq806x/base-files/etc/board.d/02_network
@@ -13,7 +13,6 @@ board=$(board_name)
 
 case "$board" in
 ap148 |\
-c2600 |\
 d7800 |\
 r7500 |\
 r7500v2 |\
@@ -22,6 +21,10 @@ vr2600v)
ucidef_add_switch "switch0" \
"1:lan" "2:lan" "3:lan" "4:lan" "6@eth1" "5:wan" "0@eth0"
;;
+c2600)
+   ucidef_add_switch "switch0" \
+   "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "6@eth1" "5:wan" 
"0@eth0"
+   ;;
 db149)
ucidef_set_interface_lan "eth1 eth2 eth3"
ucidef_add_switch "switch0" \
-- 
2.14.1


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

Re: [LEDE-DEV] [PATCH lede-17.01 1/4] x86/generic: use HIGHMEM64G instead of HIGHMEM4G to fix PAE and Xen

[Baptiste Jonglez]

Hi,

On 25-07-17, Sven Roederer wrote:
> On Samstag, 15. Juli 2017 22:57:53 CEST Baptiste Jonglez wrote:
> > From: Baptiste Jonglez <g...@bitsofnetworks.org>
> > 
> > This is a backport of 641a65fd062987a456216cc4fa91ff2910528261 in master.
> > 
> > This change re-enables PAE for the 32-bit x86 subtarget, which is
> > interesting in its own right but also necessary for Xen support.
> > 
> 
> Baptiste,
> 
> thanks for fixing the Xen and Xen-serial-console support.
> i added these patches to out Freifunk-builds and can happily run this images 
> on my vm-host again.

Glad to hear that it also works for you!

> Hope they will find their way into the repo soon.

This patch series was merged in master but not yet in lede-17.01.  I don't
know if another 17.01 point release is expected, but I think it should be
merged in any case.

Baptiste


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

Re: [LEDE-DEV] [PATCH 13/13] sunxi: Add A64 support with cortex53 subtarget

[Baptiste Jonglez]

Hi,

On 03-08-17, Hauke Mehrtens wrote:
> This adds initial support for the A64 Allwinner SoC to LEDE.
> It will be build in the new cortexa53 subtarget.
> 
> Currently it only supports the pine64 and the image is able to boot on
> this SoC.

Thanks for the patches!

I tested them on a pine64+ 1GB but it does not seem to work: the green NIC
LED keeps blinking on and off and the device stays unreachable from the
network.  If I force the other end to use 100baseTx-FD, the green NIC LED
stays on instead of blinking, but the device is still unreachable.

I will soon look at it more closely with a serial cable.

> Signed-off-by: Hauke Mehrtens 
> ---
>  target/linux/sunxi/Makefile |   2 +-
>  target/linux/sunxi/cortexa53/config-default | 100 
> 
>  target/linux/sunxi/cortexa53/target.mk  |  13 
>  target/linux/sunxi/image/Makefile   |   1 +
>  target/linux/sunxi/image/cortex-a53.mk  |  20 ++
>  5 files changed, 135 insertions(+), 1 deletion(-)
>  create mode 100644 target/linux/sunxi/cortexa53/config-default
>  create mode 100644 target/linux/sunxi/cortexa53/target.mk
>  create mode 100644 target/linux/sunxi/image/cortex-a53.mk
> 
> diff --git a/target/linux/sunxi/Makefile b/target/linux/sunxi/Makefile
> index 65d43358c9..982eecbcbd 100644
> --- a/target/linux/sunxi/Makefile
> +++ b/target/linux/sunxi/Makefile
> @@ -11,7 +11,7 @@ ARCH:=arm
>  BOARD:=sunxi
>  BOARDNAME:=Allwinner A1x/A20/A3x
>  FEATURES:=fpu usb ext4 display rtc squashfs
> -SUBTARGETS:=cortexa8 cortexa7
> +SUBTARGETS:=cortexa8 cortexa7 cortexa53
>  MAINTAINER:=Zoltan HERPAI 
>  
>  KERNEL_PATCHVER:=4.9
> diff --git a/target/linux/sunxi/cortexa53/config-default 
> b/target/linux/sunxi/cortexa53/config-default
> new file mode 100644
> index 00..58ac214695
> --- /dev/null
> +++ b/target/linux/sunxi/cortexa53/config-default
> @@ -0,0 +1,100 @@
> +CONFIG_64BIT=y
> +CONFIG_ARCH_DMA_ADDR_T_64BIT=y
> +CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
> +CONFIG_ARCH_HAS_GIGANTIC_PAGE=y
> +CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y
> +CONFIG_ARCH_HAS_KCOV=y
> +CONFIG_ARCH_MMAP_RND_BITS=18
> +CONFIG_ARCH_MMAP_RND_BITS_MAX=24
> +CONFIG_ARCH_MMAP_RND_BITS_MIN=18
> +CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=11
> +CONFIG_ARCH_SELECT_MEMORY_MODEL=y
> +CONFIG_ARCH_SPARSEMEM_DEFAULT=y
> +CONFIG_ARCH_SPARSEMEM_ENABLE=y
> +CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
> +CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
> +CONFIG_ARCH_WANT_COMPAT_IPC_PARSE_VERSION=y
> +CONFIG_ARCH_WANT_FRAME_POINTERS=y
> +CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
> +CONFIG_ARM64=y
> +# CONFIG_ARM64_16K_PAGES is not set
> +CONFIG_ARM64_4K_PAGES=y
> +# CONFIG_ARM64_64K_PAGES is not set
> +CONFIG_ARM64_CONT_SHIFT=4
> +# CONFIG_ARM64_CRYPTO is not set
> +# CONFIG_ARM64_HW_AFDBM is not set
> +# CONFIG_ARM64_LSE_ATOMICS is not set
> +CONFIG_ARM64_PAGE_SHIFT=12
> +# CONFIG_ARM64_PAN is not set
> +# CONFIG_ARM64_PTDUMP is not set
> +# CONFIG_ARM64_RANDOMIZE_TEXT_OFFSET is not set
> +# CONFIG_ARM64_UAO is not set
> +CONFIG_ARM64_VA_BITS=39
> +CONFIG_ARM64_VA_BITS_39=y
> +# CONFIG_ARM64_VA_BITS_48 is not set
> +# CONFIG_ARM64_VHE is not set
> +CONFIG_ARM_AMBA=y
> +CONFIG_ARM_GIC_V3=y
> +# CONFIG_ARM_SBSA_WATCHDOG is not set
> +# CONFIG_ARM_SP805_WATCHDOG is not set
> +CONFIG_AUDIT_ARCH_COMPAT_GENERIC=y
> +# CONFIG_COMMON_CLK_VERSATILE is not set
> +CONFIG_COMMON_CLK_XGENE=y
> +# CONFIG_COMPAT is not set
> +# CONFIG_DEBUG_ALIGN_RODATA is not set
> +CONFIG_DEBUG_RODATA=y
> +CONFIG_FRAME_POINTER=y
> +# CONFIG_FSL_ERRATUM_A008585 is not set
> +CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
> +CONFIG_GENERIC_CPU_AUTOPROBE=y
> +CONFIG_GENERIC_CSUM=y
> +CONFIG_GENERIC_IRQ_MIGRATION=y
> +CONFIG_HAVE_ALIGNED_STRUCT_PAGE=y
> +CONFIG_HAVE_ARCH_HUGE_VMAP=y
> +CONFIG_HAVE_ARCH_KASAN=y
> +CONFIG_HAVE_CMPXCHG_DOUBLE=y
> +CONFIG_HAVE_CMPXCHG_LOCAL=y
> +CONFIG_HAVE_DEBUG_BUGVERBOSE=y
> +CONFIG_HAVE_EBPF_JIT=y
> +CONFIG_HAVE_KVM_MSI=y
> +CONFIG_HAVE_MEMORY_PRESENT=y
> +CONFIG_HAVE_PATA_PLATFORM=y
> +CONFIG_ILLEGAL_POINTER_VALUE=0xdead
> +# CONFIG_KASAN is not set
> +CONFIG_KERNEL_MODE_NEON=y
> +CONFIG_KVM_ARM_PMU=y
> +CONFIG_KVM_ARM_VGIC_V3_ITS=y
> +CONFIG_MODULES_USE_ELF_RELA=y
> +CONFIG_NEED_SG_DMA_LENGTH=y
> +CONFIG_NO_IOPORT_MAP=y
> +# CONFIG_NUMA is not set
> +CONFIG_PARTITION_PERCPU=y
> +# CONFIG_PCI_DOMAINS is not set
> +# CONFIG_PHY_XGENE is not set
> +# CONFIG_PINCTRL_GR8 is not set
> +# CONFIG_PINCTRL_SUN4I_A10 is not set
> +CONFIG_PINCTRL_SUN50I_A64=y
> +# CONFIG_PINCTRL_SUN5I_A10S is not set
> +# CONFIG_PINCTRL_SUN5I_A13 is not set
> +# CONFIG_PINCTRL_SUN6I_A31 is not set
> +# CONFIG_PINCTRL_SUN6I_A31S is not set
> +# CONFIG_PINCTRL_SUN6I_A31_R is not set
> +# CONFIG_PINCTRL_SUN7I_A20 is not set
> +# CONFIG_PINCTRL_SUN8I_A23 is not set
> +# CONFIG_PINCTRL_SUN8I_A23_R is not set
> +# CONFIG_PINCTRL_SUN8I_A33 is not set
> +# CONFIG_PINCTRL_SUN8I_A83T is not set
> +# CONFIG_PINCTRL_SUN8I_H3 is not set
> +# CONFIG_PINCTRL_SUN8I_H3_R is not 

Re: [LEDE-DEV] IPv6 link locals, vlans and bridging

[Baptiste Jonglez]

On 25-08-17, Kevin Darbyshire-Bryant wrote:
> I have dnsmasq listening on the bridge interfaces - it's happy doing so and
> says it's listening on the link local address (effectively the same address
> many times) all ok.  It also listens on the global address.  If I configure
> dns clients to use the link local address for DNS service I get no
> responses.  If I configure dns clients to use the global address relevant
> for each bridge then dns responses are fine.

Are you sure it's related to your complex bridging setup?  Maybe dnsmasq
just fails to answer on link-local IPv6 addresses in all cases?

This was already reported before: 
https://bugs.lede-project.org/index.php?do=details_id=677

Baptiste


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

Re: [LEDE-DEV] [PATCH 13/13] sunxi: Add A64 support with cortex53 subtarget

[Baptiste Jonglez]

On 29-08-17, Baptiste Jonglez wrote:
> Hi,
> 
> On 03-08-17, Hauke Mehrtens wrote:
> > This adds initial support for the A64 Allwinner SoC to LEDE.
> > It will be build in the new cortexa53 subtarget.
> > 
> > Currently it only supports the pine64 and the image is able to boot on
> > this SoC.
> 
> Thanks for the patches!
> 
> I tested them on a pine64+ 1GB but it does not seem to work: the green NIC
> LED keeps blinking on and off and the device stays unreachable from the
> network.  If I force the other end to use 100baseTx-FD, the green NIC LED
> stays on instead of blinking, but the device is still unreachable.

I just found this comment in the DTS:

  /* TODO: Camera, Ethernet PHY, touchscreen, etc. */

So, the non-working NIC seems to be expected: this should be more apparent
in the patch descriptions to avoid surprises :)

(I totally understand that this patch series is about preliminary support
for the board)

> I will soon look at it more closely with a serial cable.
> 
> > Signed-off-by: Hauke Mehrtens <ha...@hauke-m.de>
> > ---
> >  target/linux/sunxi/Makefile |   2 +-
> >  target/linux/sunxi/cortexa53/config-default | 100 
> > 
> >  target/linux/sunxi/cortexa53/target.mk  |  13 
> >  target/linux/sunxi/image/Makefile   |   1 +
> >  target/linux/sunxi/image/cortex-a53.mk  |  20 ++
> >  5 files changed, 135 insertions(+), 1 deletion(-)
> >  create mode 100644 target/linux/sunxi/cortexa53/config-default
> >  create mode 100644 target/linux/sunxi/cortexa53/target.mk
> >  create mode 100644 target/linux/sunxi/image/cortex-a53.mk
> > 
> > diff --git a/target/linux/sunxi/Makefile b/target/linux/sunxi/Makefile
> > index 65d43358c9..982eecbcbd 100644
> > --- a/target/linux/sunxi/Makefile
> > +++ b/target/linux/sunxi/Makefile
> > @@ -11,7 +11,7 @@ ARCH:=arm
> >  BOARD:=sunxi
> >  BOARDNAME:=Allwinner A1x/A20/A3x
> >  FEATURES:=fpu usb ext4 display rtc squashfs
> > -SUBTARGETS:=cortexa8 cortexa7
> > +SUBTARGETS:=cortexa8 cortexa7 cortexa53
> >  MAINTAINER:=Zoltan HERPAI <wigy...@uid0.hu>
> >  
> >  KERNEL_PATCHVER:=4.9
> > diff --git a/target/linux/sunxi/cortexa53/config-default 
> > b/target/linux/sunxi/cortexa53/config-default
> > new file mode 100644
> > index 00..58ac214695
> > --- /dev/null
> > +++ b/target/linux/sunxi/cortexa53/config-default
> > @@ -0,0 +1,100 @@
> > +CONFIG_64BIT=y
> > +CONFIG_ARCH_DMA_ADDR_T_64BIT=y
> > +CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
> > +CONFIG_ARCH_HAS_GIGANTIC_PAGE=y
> > +CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y
> > +CONFIG_ARCH_HAS_KCOV=y
> > +CONFIG_ARCH_MMAP_RND_BITS=18
> > +CONFIG_ARCH_MMAP_RND_BITS_MAX=24
> > +CONFIG_ARCH_MMAP_RND_BITS_MIN=18
> > +CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=11
> > +CONFIG_ARCH_SELECT_MEMORY_MODEL=y
> > +CONFIG_ARCH_SPARSEMEM_DEFAULT=y
> > +CONFIG_ARCH_SPARSEMEM_ENABLE=y
> > +CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
> > +CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
> > +CONFIG_ARCH_WANT_COMPAT_IPC_PARSE_VERSION=y
> > +CONFIG_ARCH_WANT_FRAME_POINTERS=y
> > +CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
> > +CONFIG_ARM64=y
> > +# CONFIG_ARM64_16K_PAGES is not set
> > +CONFIG_ARM64_4K_PAGES=y
> > +# CONFIG_ARM64_64K_PAGES is not set
> > +CONFIG_ARM64_CONT_SHIFT=4
> > +# CONFIG_ARM64_CRYPTO is not set
> > +# CONFIG_ARM64_HW_AFDBM is not set
> > +# CONFIG_ARM64_LSE_ATOMICS is not set
> > +CONFIG_ARM64_PAGE_SHIFT=12
> > +# CONFIG_ARM64_PAN is not set
> > +# CONFIG_ARM64_PTDUMP is not set
> > +# CONFIG_ARM64_RANDOMIZE_TEXT_OFFSET is not set
> > +# CONFIG_ARM64_UAO is not set
> > +CONFIG_ARM64_VA_BITS=39
> > +CONFIG_ARM64_VA_BITS_39=y
> > +# CONFIG_ARM64_VA_BITS_48 is not set
> > +# CONFIG_ARM64_VHE is not set
> > +CONFIG_ARM_AMBA=y
> > +CONFIG_ARM_GIC_V3=y
> > +# CONFIG_ARM_SBSA_WATCHDOG is not set
> > +# CONFIG_ARM_SP805_WATCHDOG is not set
> > +CONFIG_AUDIT_ARCH_COMPAT_GENERIC=y
> > +# CONFIG_COMMON_CLK_VERSATILE is not set
> > +CONFIG_COMMON_CLK_XGENE=y
> > +# CONFIG_COMPAT is not set
> > +# CONFIG_DEBUG_ALIGN_RODATA is not set
> > +CONFIG_DEBUG_RODATA=y
> > +CONFIG_FRAME_POINTER=y
> > +# CONFIG_FSL_ERRATUM_A008585 is not set
> > +CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
> > +CONFIG_GENERIC_CPU_AUTOPROBE=y
> > +CONFIG_GENERIC_CSUM=y
> > +CONFIG_GENERIC_IRQ_MIGRATION=y
> > +CONFIG_HAVE_ALIGNED_STRUCT_PAGE=y
> > +CONFIG_HAVE_ARCH_HUGE_VMAP=y
> > +CONFIG_HAVE_ARCH_KASAN=y
> > +CONFIG_HAVE_CMPXC

Re: [LEDE-DEV] [PATCH] dropbear: Link ssh and scp command to /bin instead of /usr/bin

[Baptiste Jonglez]

On 01-09-17, Rosen Penev wrote:
> ssh and scp commands interfere with OpenSSH when installed in /usr/bin .
> 
> One use case is when installing dropbear to get root access when only OpenSSH 
> is available (OpenSSH disallows root password logins). Once dropbear 
> installs, it replaces OpenSSH's executables, even when removed with opkg. 
> OpenSSH must be reinstalled to get them back.

Wouldn't it be better to use Yousong's alternatives support in opkg?
Instead of moving paths around with no guarantee that they will stay
unique in the future...

> v2: Fix paths.
> 
> Signed-off-by: Rosen Penev 
> ---
>  package/network/services/dropbear/Makefile | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/package/network/services/dropbear/Makefile 
> b/package/network/services/dropbear/Makefile
> index 7302db273c..2568b830a6 100644
> --- a/package/network/services/dropbear/Makefile
> +++ b/package/network/services/dropbear/Makefile
> @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
>  
>  PKG_NAME:=dropbear
>  PKG_VERSION:=2017.75
> -PKG_RELEASE:=3
> +PKG_RELEASE:=4
>  
>  PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
>  PKG_SOURCE_URL:= \
> @@ -126,10 +126,11 @@ define Package/dropbear/install
>   $(INSTALL_DIR) $(1)/usr/sbin
>   $(INSTALL_BIN) $(PKG_BUILD_DIR)/dropbearmulti $(1)/usr/sbin/dropbear
>   $(INSTALL_DIR) $(1)/usr/bin
> - $(LN) ../sbin/dropbear $(1)/usr/bin/scp
> - $(LN) ../sbin/dropbear $(1)/usr/bin/ssh
>   $(LN) ../sbin/dropbear $(1)/usr/bin/dbclient
>   $(LN) ../sbin/dropbear $(1)/usr/bin/dropbearkey
> + $(INSTALL_DIR) $(1)/bin
> + $(LN) ../sbin/dropbear $(1)/bin/scp
> + $(LN) ../sbin/dropbear $(1)/bin/ssh
>   $(INSTALL_DIR) $(1)/etc/config
>   $(INSTALL_DATA) ./files/dropbear.config $(1)/etc/config/dropbear
>   $(INSTALL_DIR) $(1)/etc/init.d


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

[LEDE-DEV] [PATCH] scripts/download.pl: fail loudly if provided hash is unsupported

[Baptiste Jonglez]

From: Baptiste Jonglez <g...@bitsofnetworks.org>

Currently, if the provided hash is unsupported (length different from 32
or 64 bytes), we happily download the requested file without any kind of
checksum verification.

This is quite dangerous and may provide a false sense of security, because
a single typo in the hash (e.g. one character deleted by mistake) may skip
checksum verification entirely.

Instead, fail immediately if we don't support the provided hash.
In particular, if an external package repository decides to change the
hash algorithm one day, we will now fail loudly instead of skipping
checksum verification without complaints.

Note: if some users of scripts/download.pl knowingly provide an empty hash
because they don't need checksum verification, this change will break
them.  This does not seem to be the case currently, but if this feature is
ever needed, an option should be added to download.pl instead of relying
on the hash being empty.

Fixes: eaa4eba10a89 ("scripts/download.pl: add SHA-256 support")

Signed-off-by: Baptiste Jonglez <g...@bitsofnetworks.org>
---
 scripts/download.pl | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/download.pl b/scripts/download.pl
index bf9fe8c761..775408934a 100755
--- a/scripts/download.pl
+++ b/scripts/download.pl
@@ -88,6 +88,7 @@ sub download_cmd($) {
 }
 
 my $hash_cmd = hash_cmd();
+$hash_cmd or die "Cannot find appropriate hash command, ensure the provided 
hash is either a MD5 or SHA256 checksum.\n";
 
 sub download
 {
-- 
2.14.1


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

Re: [LEDE-DEV] [PATCH 13/13] sunxi: Add A64 support with cortex53 subtarget

[Baptiste Jonglez]

On 23-10-17, Hauke Mehrtens wrote:
> Could you try an image build the sunxi branch of my staging tree please:
> https://git.lede-project.org/?p=lede/hauke/staging.git;a=shortlog;h=refs/heads/sunxi
> 
> I backproted the MMC driver in there as it got some patches which are
> probably needed for the A64 SoC. For me it also boots up without these
> changes, but sometimes I also see some error messages.

Thanks, it worked on the first try with your branch!

> I never looked at the 3.10 kernel or booted it up, I only looked at what
> is in mainline.

I agree, I tested the non-mainline 3.10 kernel to make sure there was no
hardware issue.

Baptiste


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

Re: [LEDE-DEV] [PATCH 13/13] sunxi: Add A64 support with cortex53 subtarget

[Baptiste Jonglez]

Hi Hauke,

On 03-08-17, Hauke Mehrtens wrote:
> This adds initial support for the A64 Allwinner SoC to LEDE.
> It will be build in the new cortexa53 subtarget.
> 
> Currently it only supports the pine64 and the image is able to boot on
> this SoC.

This was merged a while ago, but I gave it another try on my Pine64+ and
still couldn't boot a LEDE image.  But this time I have a serial console
adapter :)

I tried to boot the latest LEDE snapshot from several different µSD card.
The kernel always starts to boot, complains about errors reading from the
mmc, and then gets stuck.  The device is a pine64+ with 1 GB of RAM.

Sometimes it fails before mounting the root:

[1.273249] Waiting for root device /dev/mmcblk0p2...
[1.281238] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 55, RE RCE !!
[1.317715] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 3, RCE !!
[1.323864] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 3, RCE !!
[1.344409] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 55, RCE !!
[1.350097] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 6, RE RCE !!
[1.355941] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 55, RCE !!
[1.361651] mmc0: new high speed SDHC card at address cda0
[1.367559] mmcblk0: mmc0:cda0 0 7.51 GiB
[1.372415] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 18, RD RE RCE !!
[1.378609] sunxi-mmc 1c0f000.mmc: data error, sending stop command
[2.374894] sunxi-mmc 1c0f000.mmc: send stop command failed

Sometimes it fails just after:

[1.273185] Waiting for root device /dev/mmcblk0p2...
[1.342876] mmc0: new high speed SDHC card at address 0007
[1.348790] mmcblk0: mmc0:0007 SD8GB 7.42 GiB
[1.354623]  mmcblk0: p1 p2
[1.401534] VFS: Mounted root (squashfs filesystem) readonly on device 179:2.
[1.408891] Freeing unused kernel memory: 320K
[1.418724] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 18, RD DCE !!
[1.424659] sunxi-mmc 1c0f000.mmc: data error, sending stop command
[1.430953] sunxi-mmc 1c0f000.mmc: send stop command failed
[1.436564] mmcblk0: timed out sending r/w cmd command, card status 0x400900
[1.443601] mmcblk0: command error, retrying timeout
[1.449386] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 18, RD DCE !!
[1.455309] sunxi-mmc 1c0f000.mmc: data error, sending stop command
[1.461581] sunxi-mmc 1c0f000.mmc: send stop command failed
[1.467185] mmcblk0: timed out sending r/w cmd command, card status 0x400900
[1.474221] mmcblk0: command error, retrying timeout
[1.484737] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 18, RD DCE !!
[1.490670] sunxi-mmc 1c0f000.mmc: data error, sending stop command
[1.496956] sunxi-mmc 1c0f000.mmc: send stop command failed
[1.502550] mmcblk0: timed out sending r/w cmd command, card status 0x400900
[1.509598] mmcblk0: command error, retrying timeout
[1.516026] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 18, RD DCE !!
[1.521959] sunxi-mmc 1c0f000.mmc: data error, sending stop command
[2.524849] sunxi-mmc 1c0f000.mmc: send stop command failed

Do you have any idea of what could be wrong?

I also tried an Armbian image (based on Debian jessie, with a non-mainline
3.10 kernel) and it worked fine out-of-the-box.

Attached are full bootlogs for both LEDE and Armbian.

Thanks,
Baptiste
U-Boot SPL 2017.07 (Oct 19 2017 - 19:48:49)
DRAM: 1024 MiB
Trying to boot from MMC1
NOTICE:  BL3-1: Running on A64/H64 (1689) in SRAM A2 (@0x44000)
NOTICE:  Configuring SPC Controller
NOTICE:  BL3-1: v1.0(debug):fbde9ac
NOTICE:  BL3-1: Built : 23:50:51, Oct 19 2017
NOTICE:  Configuring AXP PMIC
NOTICE:  PMIC: fixing DRAM voltage from 1.24V to 1.36V
NOTICE:  PMIC: setup successful
NOTICE:  SCPI: dummy stub handler, implementation level: 00
INFO:BL3-1: Initializing runtime services
INFO:BL3-1: Preparing for EL3 exit to normal world
INFO:BL3-1: Next image address: 0x4a00, SPSR: 0x3c9


U-Boot 2017.07 (Oct 19 2017 - 19:48:49 +) Allwinner Technology

CPU:   Allwinner A64 (SUN50I)
Model: Pine64+
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   No ethernet found.
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
reading /boot.scr
384 bytes read in 16 ms (23.4 KiB/s)
## Executing script at 4fc0
reading uImage
7090184 bytes read in 690 ms (9.8 MiB/s)
reading dtb
8592 bytes read in 27 ms (310.5 KiB/s)
## Flattened Device Tree blob at 4fa0
   Booting using the fdt blob at 0x4fa0
   Loading Device Tree to 49ffa000, end 49fff18f ... OK

Starting kernel ...

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.9.57 (buildbot@crazyhorse) (gcc version 5.5.0 
(LEDE GCC 5.5.0 r5117-fbde9ac) ) #0 SMP PREEMPT Thu Oct 19 

Re: [LEDE-DEV] [PATCH] [RFC] openssl: update to version 1.1.0f

[Baptiste Jonglez]

Hi,

Thanks for feedback!

On 31-10-17, Philip Prindeville wrote:
> I’d also note that some of the compatibility stuff has been deprecated, 
> hasn’t it?

What do you mean?

> > define Package/openssl/Default/description
> > -The OpenSSL Project is a collaborative effort to develop a robust,
> > -commercial-grade, full-featured, and Open Source toolkit implementing the 
> > Secure
> > -Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols 
> > as well
> > -as a full-strength general purpose cryptography library.
> > +OpenSSL is a robust, commercial-grade, and full-featured toolkit for the
> > +Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols.
> > +It is also a general-purpose cryptography library.
> 
> 
> Don’t know where this text is coming from, but it’s important to also note 
> that OpenSSL provides a full suite of crypto and digest primitives (MD5, 
> SHA*, AES, RSA, 3DES, Blowfish, etc), as well as PKI support (X.509, etc), 
> which is useful for non-networking applications as well (file security, code 
> signing, etc).

I took the text from https://www.openssl.org/

I changed the description because the old one was mentioning SSLv2, which
is no longer supported.

> Nice getting rid of all those patches!  How many are we down to after this 
> round of changes?

Basically just one, which defines custom compilation flags for the
different architectures supported by OpenWrt.

In this RFC I had added a second patch to fix build on aarch64, but it
already made it upstream (in 1.1.0g, while this RFC is based 1.1.0f).

By the way, did you have a look at dependent packages that fail to build?
I remember there was at least wget.

Baptiste


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

Re: [LEDE-DEV] [PATCH 2/2] download.mk: introduce a new variable SKIPHASH

[Baptiste Jonglez]

Hi Stijn,

What is your opinion on this patch?  There has been a bit of feedback, but
you were the one requesting the change in the first place :)

Thanks,
Baptiste

On 26-10-17, Baptiste Jonglez wrote:
> When calling a download target, hash verification is now completely
> skipped if the SKIPHASH variable is set.
> 
> This allows to easily bump package version:
> 
> # Update PKG_VERSION in the package Makefile
> $ make package//download SKIPHASH=1 V=s
> $ make package//check FIXUP=1 V=s
> 
> This will download the new version of the package, and then automatically
> update PKG_HASH with the hash of the new version.  Of course, it is still
> the responsibility of the packager to ensure that the new tarball is
> legitimate, because it is downloaded from a possibly untrusted source.
> 
> Fixes: b30ba14e ("scripts/download.pl: fail loudly if provided hash is 
> unsupported")
> Signed-off-by: Baptiste Jonglez <g...@bitsofnetworks.org>
> ---
>  include/download.mk | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/include/download.mk b/include/download.mk
> index 0a25641738..a6821b5304 100644
> --- a/include/download.mk
> +++ b/include/download.mk
> @@ -102,12 +102,18 @@ check_md5 = \
>  hash_var = $(if $(filter-out x,$(1)),MD5SUM,HASH)
>  endif
>  
> +ifdef SKIPHASH
> +DOWNLOAD_CMD = $(SCRIPT_DIR)/download.pl --skip-hash
> +else
> +DOWNLOAD_CMD = $(SCRIPT_DIR)/download.pl
> +endif
> +
>  define DownloadMethod/unknown
>   echo "ERROR: No download method available"; false
>  endef
>  
>  define DownloadMethod/default
> - $(SCRIPT_DIR)/download.pl "$(DL_DIR)" "$(FILE)" "$(HASH)" "$(URL_FILE)" 
> $(foreach url,$(URL),"$(url)") \
> + $(DOWNLOAD_CMD) "$(DL_DIR)" "$(FILE)" "$(HASH)" "$(URL_FILE)" $(foreach 
> url,$(URL),"$(url)") \
>   $(if $(filter check,$(1)), \
>   $(call check_hash,$(FILE),$(HASH),$(2)$(call 
> hash_var,$(MD5SUM))) \
>   $(call check_md5,$(MD5SUM),$(2)MD5SUM,$(2)HASH) \


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

[LEDE-DEV] [RFC] A new developper documentation for OpenWrt/LEDE

[Baptiste Jonglez]

Hi,

As an occasional contributor to OpenWrt/LEDE, I am often frustrated by the
lack of good technical documentation.  By "technical documentation", I
mean a detailed, reasonably complete and up-to-date documentation on "How
things work under the hood" and "How to do advanced stuff with the build
system".  That is, documentation targeted at hackers, contributors, and
would-be developers.

So, here is a RFC proposal of a new developer documentation based on git
and Sphinx:

  https://files.polyno.me/openwrt/doc/index.html
  git clone git://git.polyno.me/openwrt-doc

This is really early work in progress, because it's good to have early
feedback before I spend too much time on this :)

The idea (which of course needs to be discussed) would be to keep this
documentation in the same git repository as the main project.  The main
advantages compared with the wiki ("developer guide" [1] and associated
pages [2,3]) would be:

- ensuring the doc is reasonably up-to-date, because of fate sharing:
  whenever a patch modifies something substantial in the code base, it can
  update the documentation at the same time;

- more focused scope: the scope is explicitly limited to developer
  documentation.  This makes it easier to produce good, complete and
  consistent documentation.  Also, as a contributor, searching for a
  particular topic would become easier than in the wiki;

- allow release branches for the documentation.  For instance, if a
  feature is changed in trunk, the documentation in the 17.01 branch would
  still be correct for LEDE 17.01.  Likewise, when backporting a feature
  from trunk to a stable release, the associated documentation would be
  backported as well.  This is exactly what Django does with its
  documentation [4].

On the downside, it would become harder to contribute to the
documentation: this is likely a reason for the failure of the LEDE "web
presence".  But I think another important reason for this failure was the
scope, which was too broad (both user + developer documentation).

Of course, this proposal is not meant to *replace* the existing
documentation on the wiki, but rather to *complement* it.  In my opinion,
this new doc would serve as a detailed and up-to-date reference for
OpenWrt internals, while the wiki would still be extremely useful for
user-oriented documentation (which hopefully would become even more
relevant and accurate thanks to this new reference documentation).


I can commit to setting it up, and help keeping it alive over the next
few months/years.  But of course it is not possible nor desirable to do
this alone!  Help would be required in the following areas:

1) define the general structure of the doc: what should go in, what shouldn't, 
and how to organize the content;
2) initial effort: importing/refreshing relevant bits from the wiki, and 
writing the rest;
3) define some consensual rules on how to keep the doc up-to-date with the 
codebase.

Now for the questions:

- does this seem to go in the right direction?

- would all developers be willing to spend a reasonable amount of time and
  effort to keep this documentation project alive and up-to-date over time?

- what should be the general structure of this documentation?  It would
  have been nice to brainstorm on this at the OpenWrt summit, but
  unfortunately I cannot attend.

Thanks,
Baptiste

PS: for the record, here is a set of questions that (I hope) would be
answered by this new documentation:

- how can I build an image for my device?
- how do I add UCI/netifd support for a new tunneling protocol?
- how do I enable a kernel option for my target/subtarget?
- how can I package my favourite software for LEDE?
- what is the difference between target, subtarget and profile?
- how do I work with kernel patches?
- how do I listen to particular ubus events from a shell script?
- how do I parse UCI config from C? shell? lua?
- how do all these ubox/netifd/ubus/procd things work together anyway?
- what is the format of /etc/board.json?
- how do I add a new target?
- how do I write a procd init script?
- (probably tons more...)

This kind of questions can currently be answered somewhat by reading the
devel doc on the wiki [1,2,3], but information is scattered around,
incomplete, and very often outdated (though it has improved with LEDE).
Quite often, technical questions are asked (and answered!) directly on the
mailing list, which makes it even harder to find in the future.

For reference, some questions that I think this documentation effort
SHOULD NOT address, at least not initially:

- does OpenWrt run on device X?
- how do I add a port redirection in the firewall?
- how do I configure package X from the external feed?

The wiki is currently fine for this, and such broad documentation
requires a tremendous amount of work.  Let's stay reasonable and not
reinvent all wheels at the same time :)



[1] https://wiki.openwrt.org/doc/guide-developer and 
https://lede-project.org/docs/guide-developer/start
[2] 

[LEDE-DEV] [PATCH 2/2] download.mk: introduce a new variable SKIPHASH

[Baptiste Jonglez]

When calling a download target, hash verification is now completely
skipped if the SKIPHASH variable is set.

This allows to easily bump package version:

# Update PKG_VERSION in the package Makefile
$ make package//download SKIPHASH=1 V=s
$ make package//check FIXUP=1 V=s

This will download the new version of the package, and then automatically
update PKG_HASH with the hash of the new version.  Of course, it is still
the responsibility of the packager to ensure that the new tarball is
legitimate, because it is downloaded from a possibly untrusted source.

Fixes: b30ba14e ("scripts/download.pl: fail loudly if provided hash is 
unsupported")
Signed-off-by: Baptiste Jonglez <g...@bitsofnetworks.org>
---
 include/download.mk | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/include/download.mk b/include/download.mk
index 0a25641738..a6821b5304 100644
--- a/include/download.mk
+++ b/include/download.mk
@@ -102,12 +102,18 @@ check_md5 = \
 hash_var = $(if $(filter-out x,$(1)),MD5SUM,HASH)
 endif
 
+ifdef SKIPHASH
+DOWNLOAD_CMD = $(SCRIPT_DIR)/download.pl --skip-hash
+else
+DOWNLOAD_CMD = $(SCRIPT_DIR)/download.pl
+endif
+
 define DownloadMethod/unknown
echo "ERROR: No download method available"; false
 endef
 
 define DownloadMethod/default
-   $(SCRIPT_DIR)/download.pl "$(DL_DIR)" "$(FILE)" "$(HASH)" "$(URL_FILE)" 
$(foreach url,$(URL),"$(url)") \
+   $(DOWNLOAD_CMD) "$(DL_DIR)" "$(FILE)" "$(HASH)" "$(URL_FILE)" $(foreach 
url,$(URL),"$(url)") \
$(if $(filter check,$(1)), \
$(call check_hash,$(FILE),$(HASH),$(2)$(call 
hash_var,$(MD5SUM))) \
$(call check_md5,$(MD5SUM),$(2)MD5SUM,$(2)HASH) \
-- 
2.11.0


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

[LEDE-DEV] [PATCH 1/2] scripts/download.pl: Add a --skip-hash option

[Baptiste Jonglez]

When the new "--skip-hash" option is passed to scripts/download.pl, hash
verification of the downloaded files is completely skipped.  This can be
useful when bumping package version, since the hash may not be known in
advance.

Signed-off-by: Baptiste Jonglez <g...@bitsofnetworks.org>
---
 scripts/download.pl | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/scripts/download.pl b/scripts/download.pl
index 775408934a..e0bf187559 100755
--- a/scripts/download.pl
+++ b/scripts/download.pl
@@ -13,9 +13,11 @@ use File::Basename;
 use File::Copy;
 use Text::ParseWords;
 
-@ARGV > 2 or die "Syntax: $0 
[ ...]\n";
+@ARGV > 2 or die "Syntax: $0 [--skip-hash] [ ...]\n";
 
 my $url_filename;
+my $skip_hash = 0;
+$skip_hash = shift @ARGV if $ARGV[0] eq "--skip-hash";
 my $target = glob(shift @ARGV);
 my $filename = shift @ARGV;
 my $file_hash = shift @ARGV;
@@ -87,8 +89,13 @@ sub download_cmd($) {
;
 }
 
-my $hash_cmd = hash_cmd();
-$hash_cmd or die "Cannot find appropriate hash command, ensure the provided 
hash is either a MD5 or SHA256 checksum.\n";
+my $hash_cmd;
+if ($skip_hash) {
+   print("Warning: skipping hash verification as requested.\n");
+} else {
+   $hash_cmd = hash_cmd();
+   $hash_cmd or die "Cannot find appropriate hash command, ensure the 
provided hash is either a MD5 or SHA256 checksum.\n";
+}
 
 sub download
 {
-- 
2.11.0


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

[LEDE-DEV] [PATCH] [RFC] openssl: update to version 1.1.0f

[Baptiste Jonglez]

From: Baptiste Jonglez <g...@bitsofnetworks.org>

This patch is marked [RFC] because this is such a huge change, and some
dependent packages now fail to build because of API changes.  Also, there
is no parallel build for now, but this was already the case with 1.0.2l.
Feedback is welcome!

Here is a summary of the changes:

1) complete overhaul of the upstream build system, which allowed to remove
   most local patches;

2) upstream removal of KRB5, SSL2, JPAKE;

3) upstream addition of BLAKE2, CHACHA20, POLY1305, OCB (disabled by
   default in the package but configurable);

4) clean-up configuration of optional features: in OpenSSL, some options
   are enabled by default, while some are disabled by default.  As a
   result, the package now explicitely enables or disables each optional
   feature;

5) new upstream async mode, primarily used for crypto engines.  It is
   disabled in the package because musl does not seem to implement
   getcontext/setcontext (see 52739e40ccc1b16cd966ea204bcfea3cc874fec8
   upstream);

6) a patch fixing build on Aarch64 has been added and sent upstream
   https://github.com/openssl/openssl/pull/4617

Here is the size increase for libopenssl.ipk compared to 1.0.2l, first
1.1.0f with default options and then 1.1.0f with all new options¹:

| Architecture  | 1.0.2l  | 1.1.0f  | 1.1.0f   |
|   | Default | Default | All new options¹ |
|---+-+-+--|
| aarch64_cortex-a53| 634K| 831K| 844K |
| aarch64_generic   | 628K| 662K| 672K |
| arc_arc700| 573K| 610K| 621K |
| arc_archs | 570K| 605K| 613K |
| arm_arm1176jzf-s_vfp  | 631K| 823K| 833K |
| arm_arm926ej-s| 631K| 824K| 835K |
| arm_cortex-a15_neon-vfpv4 | 638K| 831K| 843K |
| arm_cortex-a5 | 639K| 832K| 843K |
| arm_cortex-a7_neon-vfpv4  | 638K| 830K| 843K |
| arm_cortex-a8_vfpv3   | 639K| 831K| 843K |
| armeb_xscale  | 639K| 834K| 844K |
| arm_fa526 | 638K| 831K| 841K |
| i386_pentium4 | 784K| 822K| 834K |
| i386_pentium  | 795K| 832K| 842K |
| mips_24kc | 701K| 742K| 755K |
| mips64el_mips64   | 674K| 710K| 719K |
| mips64_mips64 | 689K| 725K| 734K |
| mipsel_24kc   | 688K| 728K| 740K |
| mipsel_74kc   | 693K| 735K| 747K |
| mipsel_mips32 | 691K| 731K| 744K |
| mips_mips32   | 701K| 744K| 757K |
| powerpc_464fp | 664K| 703K| 714K |
| powerpc_8540  | 672K| 712K| 723K |
| x86_64| 949K| 986K| 1002K|

¹ All new options:
CONFIG_OPENSSL_WITH_BLAKE2=y
CONFIG_OPENSSL_WITH_CHACHA20=y
CONFIG_OPENSSL_WITH_POLY1305=y
CONFIG_OPENSSL_WITH_OCB=y
---
 package/libs/openssl/Config.in |  20 +++
 package/libs/openssl/Makefile  | 110 +++-
 ...g-Use-eventfd2-syscall-instead-of-eventfd.patch |  48 ++
 .../openssl/patches/110-optimize-for-size.patch|  43 +++--
 package/libs/openssl/patches/130-perl-path.patch   |  64 ---
 .../libs/openssl/patches/140-makefile-dirs.patch   |  11 --
 package/libs/openssl/patches/150-no_engines.patch  |  81 -
 .../openssl/patches/160-disable_doc_tests.patch|  58 ---
 package/libs/openssl/patches/170-bash_path.patch   |   8 -
 .../openssl/patches/180-fix_link_segfault.patch|  18 --
 .../patches/190-remove_timestamp_check.patch   |  23 ---
 .../libs/openssl/patches/200-parallel_build.patch  | 184 -
 12 files changed, 168 insertions(+), 500 deletions(-)
 create mode 100644 
package/libs/openssl/patches/0001-afalg-Use-eventfd2-syscall-instead-of-eventfd.patch
 delete mode 100644 package/libs/openssl/patches/130-perl-path.patch
 delete mode 100644 package/libs/openssl/patches/140-makefile-dirs.patch
 delete mode 100644 package/libs/openssl/patches/150-no_engines.patch
 delete mode 100644 package/libs/openssl/patches/160-disable_doc_tests.patch
 delete mode 100644 package/libs/openssl/patches/170-bash_path.patch
 delete mode 100644 package/libs/openssl/patches/180-fix_link_segfault.patch
 delete mode 100644 
package/libs/openssl/patches/190-remove_timestamp_check.patch
 delete mode 100644 package/libs/openssl/patches/200-parallel_build.patch

diff --git a/package/libs/openssl/Config.in b/package/libs/openssl/Config.in
index dbcd11abfc..4b395281a7 100644
--- a/package/libs/openssl/Config.in
+++ b/p

Re: [LEDE-DEV] [PATCH] openssl: Enable assembler optimizations for aarch64

[Baptiste Jonglez]

On 28-10-17, Baptiste Jonglez wrote:
> The awesome AES performance was too good to be true: it seems to produce
> incorrect results when encrypting on the pine64 and decrypting on a x86_64
> machine :(
> Possibly some assembler is optimized away by the compiler, which would
> explain why it's so fast.  Please don't merge for now until I investigate.

After investigating, there is actually no issue, so this is good to merge!

For the details:

- I was using openssl 1.1 for encrypting and openssl 1.0 for decrypting,
  so I was bitten by https://www.openssl.org/docs/faq.html#USER3 .
  Using the same digest algorithm on both sides yields correct results.

- AES performance is so good because openssl exploits the dedicated
  hardware instructions for AES found in most Aarch64 CPUs.  Support for
  this was introduced 3 years ago:
  
https://github.com/openssl/openssl/commit/9af4cb3d3beaaed8af33ee0bbc547cfef49c88a6

Baptiste

> On 27-10-17, Baptiste Jonglez wrote:
> > OpenSSL is built with the generic linux settings for most targets,
> > including aarch64.  These generic settings are designed for 32-bit CPU and
> > provide no assembler optmization: this is widely suboptimal for aarch64.
> > 
> > This patch simply switches to the aarch64 settings that are already
> > available in OpenSSL.
> > 
> > Here is the output of "openssl speed" before the optimization, with
> > "(...)" representing build flags that didn't change:
> > 
> > OpenSSL 1.0.2l  25 May 2017
> > options:bn(64,32) rc4(ptr,char) des(idx,cisc,2,int) aes(partial) 
> > blowfish(ptr)
> > compiler: aarch64-openwrt-linux-musl-gcc  (...)
> > 
> > And after this patch, OpenSSL uses 64 bit mode and assembler optimizations:
> > 
> > OpenSSL 1.0.2l  25 May 2017
> > options:bn(64,64) rc4(ptr,char) des(idx,cisc,2,int) aes(partial) 
> > blowfish(ptr)
> > compiler: aarch64-openwrt-linux-musl-gcc  (...)  -DSHA1_ASM 
> > -DSHA256_ASM -DSHA512_ASM
> > 
> > Here are some benchmarks on a pine64+ running latest LEDE master 
> > r5142-20d363aed3:
> > 
> > before# openssl speed sha aes blowfish
> > The 'numbers' are in 1000s of bytes per second processed.
> > type 16 bytes 64 bytes256 bytes   1024 bytes   8192 
> > bytes
> > sha1  3918.89k 9982.43k19148.03k24933.03k
> > 27325.78k
> > sha2564604.51k10240.64k17472.51k21355.18k
> > 22801.07k
> > sha5123662.19k14539.41k21443.16k29544.11k
> > 33177.60k
> > blowfish cbc 16266.63k16940.86k17176.92k17237.33k
> > 17252.35k
> > aes-128 cbc  19712.95k21447.40k22091.09k22258.35k
> > 22304.09k
> > aes-192 cbc  17680.12k19064.47k19572.14k19703.13k
> > 19737.26k
> > aes-256 cbc  15986.67k17132.48k17537.28k17657.17k
> > 17689.26k
> > 
> > after# openssl speed sha aes blowfish
> > type 16 bytes 64 bytes256 bytes   1024 bytes   8192 
> > bytes
> > sha1  6770.87k26172.80k86878.38k   205649.58k   
> > 345978.20k
> > sha256   20913.93k74663.85k   184658.18k   290891.09k   
> > 351032.66k
> > sha5127633.10k30110.14k50083.24k71883.43k
> > 82485.25k
> > blowfish cbc 16224.93k16933.55k17173.76k17234.94k
> > 17252.35k
> > aes-128 cbc  19425.74k21193.31k22065.74k22304.77k
> > 22380.54k
> > aes-192 cbc  17452.29k18883.84k19536.90k19741.70k
> > 19800.06k
> > aes-256 cbc  15815.89k17003.01k17530.03k17695.40k
> > 17746.60k
> > 
> > For some reason AES and blowfish do not benefit, but SHA performance
> > improves between 1.7x and 15x.  SHA256 clearly benefits the most from the
> > optimization (4.5x on small blocks, 15x on large blocks!).
> > 
> > When using EVP (with "openssl speed -evp "):
> > 
> > # Before, EVP mode
> > type 16 bytes 64 bytes256 bytes   1024 bytes   8192 
> > bytes
> > sha1  3824.46k10049.66k19170.56k24947.03k
> > 27325.78k
> > sha2563368.33k 8511.15k16061.44k20772.52k
> > 22721.88k
> > sha5122845.23k11381.57k19467.69k28512.26k
> > 33008.30k
> > bf-cbc   15146.74k16623.83k17092.01k17211.39k
> > 17249.62k
> > aes-128-

Re: [LEDE-DEV] Lede/Openwrt documentation

[Baptiste Jonglez]

Hi,

On 24-10-17, John Norton wrote:
> On 24/10/2017 18:02, Javier Domingo Cansino wrote:
> Imho (what I would do) is just migrate current LEDE wiki content in OpenWRT
> wiki,
> while current OpenWRT stuff is either obsoleted (where it is replaced by the
> LEDE wiki articles) or moved to suit the same general structure of LEDE
> wiki.

Don't underestimate the amount of contributions made to the OpenWrt wiki
during the LEDE/OpenWrt split.  Old habits are hard to break :)

Just diff'ing the dokuwiki files on the two servers would not be very
useful, because there is no way to know if a chunk has been removed on one
side (e.g. LEDE) or added on the other side (e.g. OpenWrt).

This problem is well-known [1,2] and can be solved by having access to a
common ancestor between the two versions.  A possible way to do this would
be to convert each wiki to a git repository [3], merge the two histories
using git, and then convert back the git repository to a dokuwiki
structure.  It sounds tedious but feasible.

Baptiste

[1] 
http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#merge
[2] https://en.wikipedia.org/wiki/Merge_(version_control)#Three-way_merge
[3] https://github.com/hoxu/dokuwiki2git


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

Re: [LEDE-DEV] [PATCH 2/2] download.mk: introduce a new variable SKIPHASH

[Baptiste Jonglez]

On 26-10-17, Karl Palsson wrote:
> Until/if your new documentation project takes off, please
> consider adding this to the "how to package" doc pages. none of
> these extra magical parameters are discoverable in any way right
> now.

Fully agreed, all this is magical enough :)  While writing this patch, I even
discovered some features of download.pl I didn't know about and are not
documented anywhere...

By the way, FIXUP=1 is already documented here: 
https://wiki.openwrt.org/doc/devel/packages#use_source_repository

Baptiste


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

Re: [LEDE-DEV] [PATCH 2/2] download.mk: introduce a new variable SKIPHASH

[Baptiste Jonglez]

On 27-10-17, Yousong Zhou wrote:
> On 26 October 2017 at 17:50, Baptiste Jonglez <g...@bitsofnetworks.org> wrote:
> > When calling a download target, hash verification is now completely
> > skipped if the SKIPHASH variable is set.
> >
> > This allows to easily bump package version:
> >
> > # Update PKG_VERSION in the package Makefile
> > $ make package//download SKIPHASH=1 V=s
> > $ make package//check FIXUP=1 V=s
> >
> > This will download the new version of the package, and then automatically
> > update PKG_HASH with the hash of the new version.  Of course, it is still
> > the responsibility of the packager to ensure that the new tarball is
> > legitimate, because it is downloaded from a possibly untrusted source.
> 
> Introducing another knob to the build system seems cubersome.  I
> remembered that hash checking would be skipped if PKG_MD5SUM var was
> empty and the behaviour is very likely the same with PKG_HASH.  The
> workflow can be simply emptying PKG_HASH var while bumping the
> versions, then do the download and hash fixup on the second command.
> This should eliminate the need for SKIPHASH var.

In my opinion, it's bad practice to implicitly skip hash verification in
some special cases.  Before my first patch [1], any typo in the hash would
result in verification being silently skipped.  You can also imagine a
typo in the variable name (e.g. "PKGHASH" instead of "PKG_HASH") and this
would inadvertently result in an empty hash.

When we're talking about bypassing security features, it's much better to
have an explicit knob to avoid mistakes.

[1] http://patchwork.ozlabs.org/patch/809259/

Baptiste


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

Re: [LEDE-DEV] Support for TP-Link Archer C7 1750 v4.0

[Baptiste Jonglez]

Hi,

On 23-10-17, Emmanuel Grumbach wrote:
> I just bought a TP-Link Archer C7 AC1750 and got the v4.0 version. I
> haven't found any image in
> https://lede-project.org/toh/views/toh_fwdownload that claims it
> features that version. I can see v1 and v2, but not v4.

Support for this board has just been merged: 
https://git.lede-project.org/9887afb1afcf387f6892315413e610a6816df463

So, there is no support in 17.01 but snapshot images should work, and the
ToH at actually links to downloadable images :)

  https://lede-project.org/toh/hwdata/tp-link/tp-link_archer_c7_v

Baptiste


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

Re: [LEDE-DEV] Lede/Openwrt documentation

[Baptiste Jonglez]

Hi Thomas,

On 27-10-17, Thomas Endt wrote:
> That's contrary to your statements in the start posting:
> 
> > [...] documentation targeted at hackers, contributors, and would-be 
> > developers.
> > [...] RFC proposal of a new developer documentation
> > Links [1] [2] [3]
> > [...] more focused scope: the scope is explicitly limited to developer 
> > documentation.
> > [...] this new doc would serve as a detailed and up-to-date reference for 
> > OpenWrt internals, while the wiki would still be extremely useful for 
> > user-oriented documentation

It seems that there was a bit of confusion.  What you quote here is from
me, not from Javier.  Also, it's from a different thread [1], in which I
indeed proposed a new system from the developer documentation (only).

The current thread is about how to merge the LEDE wiki and the OpenWrt wiki.
Or at least, that was the initial discussion.

Baptiste

[1] http://lists.infradead.org/pipermail/lede-dev/2017-October/009530.html


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

Re: [LEDE-DEV] Lede/Openwrt documentation

[Baptiste Jonglez]

Hi Alberto,

On 27-10-17, John Norton wrote:
> On 27/10/2017 10:46, Baptiste Jonglez wrote:
> >On 24-10-17, John Norton wrote:
> >>On 24/10/2017 18:02, Javier Domingo Cansino wrote:
> >>Imho (what I would do) is just migrate current LEDE wiki content in OpenWRT
> >>wiki,
> >>while current OpenWRT stuff is either obsoleted (where it is replaced by the
> >>LEDE wiki articles) or moved to suit the same general structure of LEDE
> >>wiki.
> >Don't underestimate the amount of contributions made to the OpenWrt wiki
> >during the LEDE/OpenWrt split.  Old habits are hard to break :)
> >
> 
> Don't overestimate the amount of content in LEDE wiki. It's mostly core
> documentation.

Don't get me wrong: there is no question that the LEDE wiki has improved
quite a lot during the split, both in content and organisation.  And given
the amount of effort that went into it (especially the ToH), it only makes
sense to use it as the "authoritative" source when merging the two wikis.

What I was saying is simply this: out of habit, some people (including
myself) have contributed content to the OpenWrt wiki instead of the LEDE
wiki.  Just look at this for example:

  https://wiki.openwrt.org/start?do=recent
  https://wiki.openwrt.org/doc/uci/wireless?do=revisions
  https://wiki.openwrt.org/doc/devel/packages?do=revisions

> LEDE wiki can be moved over as-is, its articles more or less directly
> obsoleting their analogue in the OpenWRT wiki after a quick read and source
> modification check after the merge.
> 
> Bulk of content in OpenWRT wiki does not have an analogue in LEDE wiki, so
> that can just be re-arranged without modification (for now).

Your proposed method looks good, I am just afraid that the "quick read"
may not be that quick given the above considerations (to ensure that no
relevant content is lost).

Baptiste


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

Re: [LEDE-DEV] Lede/Openwrt documentation

[Baptiste Jonglez]

Hi,

On 27-10-17, Javier Domingo Cansino wrote:
> > This problem is well-known [1,2] and can be solved by having access to a
> > common ancestor between the two versions.  A possible way to do this would
> > be to convert each wiki to a git repository [3], merge the two histories
> > using git, and then convert back the git repository to a dokuwiki
> > structure.  It sounds tedious but feasible.
> 
> As it looks like there are no clear decisions, I would like to propose
> the following changes.

To clarify: the "convert dokuwiki to git" thing I was talking about is
just a technical possibility for merging the OpenWrt wiki and the LEDE
wiki.  I was certainly not suggesting to switch to a completely new system
for the wiki: I think it's fine as it is for most of the documentation.

> Git backed documentation:
>  * It's easier to have all the content at a glance sorted in folders
> to help structure the documentation
>  * You can move content between pages easier
> 
> Use github as a place to host the document repository:
>  * There are buildhooks from services integrated, such as github pages
> or readthedocs that make it transparent to collaborate
>  * Users can provide feedback through issues on missing docs, giving
> tips to contributors to see what areas can be improved
>  * Discussions about documental structure happen openly, easing burden
> on people maintaining documentation by having an specific pipe
> everything goes through
>  * Contributions can be reviewed or automatically contributed if diff
> < 100 lines (I can do a simple bot for that)
> 
> Integrate existing openwrt docs inside lede structure.
>  * Having an structured documentation helps user know where to look
> for the content
>  * Makes easier to spot a place to write your contribution at
>  * It is more user / dev-newbie friendly
> 
> Switch to sphinx
>  * Most of the times there is no clue on where to place the
> documentation, so you create a new wiki page, this leads to duplicate
> information
>  * Can generate HTML Single page, pdf, epub, etc. Although the usual
> one is the multipage HTML
>  * Can be hosted in readthedocs and integrated with github so that
> every deployment is automatic
>  * Can tag versions, so in the event we finally reach a good
> documentation, users can browse different docs for each version
>  * It's industry standard for project documentation. Not only about
> documenting python
>  * It has good to go skins that are proven to be easy to read
>  * More complete syntax (if something like that would be required
> 
> Drawbacks I see:
>  * Contributions in the wiki are instant, here they would have a
> proper process to review.
>  * There is a migration effort to be done, greater than just merging
> docs in the same place
> 
> I volunteer however to setup today an example with the current lede
> docs in sphinx, so that you can see the look and feel I am speaking
> about.
> 
> Also, openwrt.readthedocs.org is taken but if we were to make official
> this proposal, I would contact the current owner or rtd people to get
> it transferred.
> 
> Cheers,


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

Re: [LEDE-DEV] [PATCH] openssl: Enable assembler optimizations for aarch64

[Baptiste Jonglez]

The awesome AES performance was too good to be true: it seems to produce
incorrect results when encrypting on the pine64 and decrypting on a x86_64
machine :(
Possibly some assembler is optimized away by the compiler, which would
explain why it's so fast.  Please don't merge for now until I investigate.

SHA does seem to give correct results though (and is really fast).

On 27-10-17, Baptiste Jonglez wrote:
> OpenSSL is built with the generic linux settings for most targets,
> including aarch64.  These generic settings are designed for 32-bit CPU and
> provide no assembler optmization: this is widely suboptimal for aarch64.
> 
> This patch simply switches to the aarch64 settings that are already
> available in OpenSSL.
> 
> Here is the output of "openssl speed" before the optimization, with
> "(...)" representing build flags that didn't change:
> 
> OpenSSL 1.0.2l  25 May 2017
> options:bn(64,32) rc4(ptr,char) des(idx,cisc,2,int) aes(partial) 
> blowfish(ptr)
> compiler: aarch64-openwrt-linux-musl-gcc  (...)
> 
> And after this patch, OpenSSL uses 64 bit mode and assembler optimizations:
> 
> OpenSSL 1.0.2l  25 May 2017
> options:bn(64,64) rc4(ptr,char) des(idx,cisc,2,int) aes(partial) 
> blowfish(ptr)
> compiler: aarch64-openwrt-linux-musl-gcc  (...)  -DSHA1_ASM -DSHA256_ASM 
> -DSHA512_ASM
> 
> Here are some benchmarks on a pine64+ running latest LEDE master 
> r5142-20d363aed3:
> 
> before# openssl speed sha aes blowfish
> The 'numbers' are in 1000s of bytes per second processed.
> type 16 bytes 64 bytes256 bytes   1024 bytes   8192 
> bytes
> sha1  3918.89k 9982.43k19148.03k24933.03k
> 27325.78k
> sha2564604.51k10240.64k17472.51k21355.18k
> 22801.07k
> sha5123662.19k14539.41k21443.16k29544.11k
> 33177.60k
> blowfish cbc 16266.63k16940.86k17176.92k17237.33k
> 17252.35k
> aes-128 cbc  19712.95k21447.40k22091.09k22258.35k
> 22304.09k
> aes-192 cbc  17680.12k19064.47k19572.14k19703.13k
> 19737.26k
> aes-256 cbc  15986.67k17132.48k17537.28k17657.17k
> 17689.26k
> 
> after# openssl speed sha aes blowfish
> type 16 bytes 64 bytes256 bytes   1024 bytes   8192 
> bytes
> sha1  6770.87k26172.80k86878.38k   205649.58k   
> 345978.20k
> sha256   20913.93k74663.85k   184658.18k   290891.09k   
> 351032.66k
> sha5127633.10k30110.14k50083.24k71883.43k
> 82485.25k
> blowfish cbc 16224.93k16933.55k17173.76k17234.94k
> 17252.35k
> aes-128 cbc  19425.74k21193.31k22065.74k22304.77k
> 22380.54k
> aes-192 cbc  17452.29k18883.84k19536.90k19741.70k
> 19800.06k
> aes-256 cbc  15815.89k17003.01k17530.03k17695.40k
> 17746.60k
> 
> For some reason AES and blowfish do not benefit, but SHA performance
> improves between 1.7x and 15x.  SHA256 clearly benefits the most from the
> optimization (4.5x on small blocks, 15x on large blocks!).
> 
> When using EVP (with "openssl speed -evp "):
> 
> # Before, EVP mode
> type 16 bytes 64 bytes256 bytes   1024 bytes   8192 
> bytes
> sha1  3824.46k10049.66k19170.56k24947.03k
> 27325.78k
> sha2563368.33k 8511.15k16061.44k20772.52k
> 22721.88k
> sha5122845.23k11381.57k19467.69k28512.26k
> 33008.30k
> bf-cbc   15146.74k16623.83k17092.01k17211.39k
> 17249.62k
> aes-128-cbc  17873.03k20870.61k21933.65k22216.36k
> 22301.35k
> aes-192-cbc  16184.18k18607.15k19447.13k19670.02k
> 19737.26k
> aes-256-cbc  14774.06k16757.25k17457.58k17639.42k
> 17686.53k
> 
> # After, EVP mode
> type 16 bytes 64 bytes256 bytes   1024 bytes   8192 
> bytes
> sha1  7056.97k27142.10k89515.86k   209155.41k   
> 347419.99k
> sha2567745.70k29750.06k95341.48k   211001.69k   
> 332376.75k
> sha5124550.47k18086.06k39997.10k65880.75k
> 81431.21k
> bf-cbc   15129.20k16619.03k17090.56k17212.76k
> 17246.89k
> aes-128-cbc  99619.74k   269032.34k   450214.23k   567353.00k   
> 613933.06k
> aes-192-cbc  93180.74k   231017.79k   361766.66k   433671.51k   
> 461731.16k
> aes-256-cbc  893