Re: [LEDE-DEV] jffs corruption
Hi, the patch seems useful, I suggest to send it upstream to receive wider feedback there. If the MTD guys deem it suitable, we can cherry pick it from there. ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 1/2] helpers: make the proto field as a list rather than one option
Hi Pierre, is there anything speaking against just adding a 2nd section for TCP? ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Lack of DNS robustness for openwrt.org
Hi Bjørn, the current timings of the DO zone are: ;; ANSWER SECTION: openwrt.org.1800 IN SOA ns1.digitalocean.com. hostmaster.openwrt.org. ( 1525688668 ; serial 10800 ; refresh (3 hours) 3600 ; retry (1 hour) 604800 ; expire (1 week) 1800 ; minimum (30 minutes) ) Regards, Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Lack of DNS robustness for openwrt.org
Hi Joerg, John. I created an openwrt.org zone on Digital Ocean now so you could delegate the name servers to ns1.digitalocean.com, ns2.digitalocean.com and ns3.digitalocean.com, maybe with one of the SPI machines thrown into the mix... ~ Jo signature.asc Description: OpenPGP digital signature ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [RFC PATCH 2/2] odhcpd: adjust configuration default
Move the odhcpd lease state file from /tmp/hosts/odhcpd to /var/run/hosts.d/odhcpd.leases. The motivation of this change is to align the lease state file (which essentially is a commented hosts(5) format) location with the one used by dnsmasq for the temporary hosts(5) file holding user-assigned static DHCP lease host names. Signed-off-by: Jo-Philipp Wich --- package/network/services/odhcpd/files/odhcpd.defaults | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/network/services/odhcpd/files/odhcpd.defaults b/package/network/services/odhcpd/files/odhcpd.defaults index cecbdd4a8d..4ea00a82b3 100644 --- a/package/network/services/odhcpd/files/odhcpd.defaults +++ b/package/network/services/odhcpd/files/odhcpd.defaults @@ -20,7 +20,7 @@ esac uci batch <http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [RFC PATCH 1/2] dnsmasq: adjust configuration defaults
- Change the hosts(5) files directory from /tmp/hosts/ to /var/run/hosts.d/ - Change the lease database path /tmp/dhcp.leases to /var/run/dhcp.leases - Remove "leasefile" and "resolvfile" options from default /etc/config/dhcp The motivation of this change is twofold; first to make the file and directory locations somewhat consistent with other parts of the system, second to reduce the emphasis on /etc/config/dhcp options that do not need to (and probably should not) get changed by the user for normal operation. Signed-off-by: Jo-Philipp Wich --- package/network/services/dnsmasq/files/dhcp.conf| 2 -- package/network/services/dnsmasq/files/dnsmasq.init | 6 +++--- 2 files changed, 3 insertions(+), 5 deletions(-) diff --git a/package/network/services/dnsmasq/files/dhcp.conf b/package/network/services/dnsmasq/files/dhcp.conf index 360c7d79ee..3da0dbf3e9 100644 --- a/package/network/services/dnsmasq/files/dhcp.conf +++ b/package/network/services/dnsmasq/files/dhcp.conf @@ -12,8 +12,6 @@ config dnsmasq option nonegcache 0 option authoritative1 option readethers 1 - option leasefile'/tmp/dhcp.leases' - option resolvfile '/tmp/resolv.conf.auto' #list server'/mycompany.local/1.2.3.4' option nonwildcard 1 # bind to & keep track of interfaces #list interface br-lan diff --git a/package/network/services/dnsmasq/files/dnsmasq.init b/package/network/services/dnsmasq/files/dnsmasq.init index 1881b2bcdc..121e26bc5e 100644 --- a/package/network/services/dnsmasq/files/dnsmasq.init +++ b/package/network/services/dnsmasq/files/dnsmasq.init @@ -12,7 +12,7 @@ ADD_WAN_FQDN=0 ADD_LOCAL_FQDN="" BASECONFIGFILE="/var/etc/dnsmasq.conf" -BASEHOSTFILE="/tmp/hosts/dhcp" +BASEHOSTFILE="/var/run/hosts.d/dhcp" TRUSTANCHORSFILE="/usr/share/dnsmasq/trust-anchors.conf" TIMEVALIDFILE="/var/state/dnsmasqsec" BASEDHCPSTAMPFILE="/var/run/dnsmasq" @@ -848,7 +848,7 @@ dnsmasq_start() config_list_foreach "$cfg" "notinterface" append_notinterface config_list_foreach "$cfg" "addnhosts" append_addnhosts config_list_foreach "$cfg" "bogusnxdomain" append_bogusnxdomain - append_parm "$cfg" "leasefile" "--dhcp-leasefile" "/tmp/dhcp.leases" + append_parm "$cfg" "leasefile" "--dhcp-leasefile" "/var/run/dhcp.leases" append_parm "$cfg" "serversfile" "--servers-file" append_parm "$cfg" "tftp_root" "--tftp-root" append_parm "$cfg" "dhcp_boot" "--dhcp-boot" @@ -875,7 +875,7 @@ dnsmasq_start() xappend "--dhcp-script=$DHCPSCRIPT" fi - config_get leasefile $cfg leasefile "/tmp/dhcp.leases" + config_get leasefile $cfg leasefile "/var/run/dhcp.leases" [ -n "$leasefile" -a \! -e "$leasefile" ] && touch "$leasefile" config_get_bool cachelocal "$cfg" cachelocal 1 -- 2.15.1 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [RFC PATCH 0/2] Adjust DHCP/DNS defaults for better consistency
This small patch series changes the default location of various temporary and automatically generated files used by dnsmasq and odhcpd during normal operation. The main motivation is to move the /tmp/hosts/ directory out of /tmp/ since it does not really belong there, it is a directory of dynamic runtime configuration files and not temporary applicaiton data. The other changes move the dnsmasq' lease database out of /tmp/ into the arguably better suited /var/run/ directory and remove uci options from /etc/config/dhcp that both match their default values and that should not be changed for normal operation. Jo-Philipp Wich (2): dnsmasq: adjust configuration defaults odhcpd: adjust configuration default package/network/services/dnsmasq/files/dhcp.conf | 2 -- package/network/services/dnsmasq/files/dnsmasq.init | 6 +++--- package/network/services/odhcpd/files/odhcpd.defaults | 2 +- 3 files changed, 4 insertions(+), 6 deletions(-) -- 2.15.1 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] OPKG Encryption
Hello, > Today I discovered that pulling packages from the feeds is done over > http by default instead of https. I understand it is always going to > be a trade-off between space requirements and features/security. > However, pulling in packages over an unencrypted connection will > allow for easy manipulation of the package's contents via a MITM > attack. the package integrity is verified using SHA256 check sums, the checksum file (the package index) integrity itself is verified using ed25519 based signature verification using pre-shipped public keys embedded into the firmware images. In order to perform a MITM, you'd need to either forge the Package index in transit without breaking the signature verification or manage to produce an SHA256 collision with arbitrary contents. Opkg, by default, refuses to use downloaded package indexes that cannot be verified. > For a router that is going to run these packages, that stands between > all your devices and the big bad internet that is an unacceptable > trade-off in my opinion. Hence the signature based integrity verification. > The fix itself is quite easy and involves changing the lines in > /etc/opkg/distfeeds.conf to https versions. Additionally, a package > that can download over https such as wget + ca-certicates is needed. To match the security of the current signature system you would also need to disallow all server certs except the one actually used by *.openwrt.org / *.lede-project.org. As history has shown, many pre-trusted CAs tend to have questionable security practices. > However, as you might already see, to fix this vulnerability you > need to use the vulnerable component to install these packages. Or > you need to pull in the packages via your computer, ssh it over to > your router and install it manually. Or you need to compile these > packages in. Or use the existing signature verification. > For the majority of the people they will not even be aware of this > vulnerability, let alone know how to fix this in a safe way. I'd > like to discuss whether it would be a good idea to make downloading > over https via opkg default by changing the distfeed file and > including the required packages. Given that the download integrity already is secured using checksums + signed checksum files and that a "trust any HTTPS" model would actually lower the security while requiring considerably more space, I strongly object. > We might even decide to only do this on targets that are not starved > for flash storage. Any opinions regarding this matter? Which would lead to even more confusion and a false sense of security. ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Build error since ncurses bump
Hi, > Hmm? I believe jow is talking about the toolchain. It was switched > to default to GCC7 recently. > > I use Arch Linux parts of ncurses are built on the host (mainly the tic compiler) using the host gcc. Arch linux is a bad reference for testing tools updates as it tends to use software versions not being available on various LTS distributions. ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Build error since ncurses bump
Hi Koen, please try reverting https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=4fb684a7558ea5c11580378be062f73da07f8479 and see if it fixes the issue. The change was likely not tested on systems with a gcc 5 host compiler. ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] firewall: fix logging of dropped & rejected packets
Hi Alin, thanks for the patch. Unfortunately it definitely is too big for a simple "fix logging". Will take a deeper look at it later but from a first glance it does a few unrelated changes, renames chains and has some minor style deviations. Regards, Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [LEDE-DEV, 1/3] fstools: add exfat filesystem support
Hi, fstools will use the full libblkid if it is installed on the system, this should also enable support for all filesystems supported by the full libblkid. Adding more and more exotic stuff to libblkid-tiny will bloat the default fstools install for all users, so we should avoid that - imho. Regards, Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Merged: Update to latest ath10k-ct driver,
Merged into my staging tree. Thank you! ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] new buildbot slave
Hello Daniel, > I am Daniel Müllers from Aachen. I like to setup two Buildbot Slave > to provid the LEDE OpenWRT Project with some build power. thank you for your generous offer! Can you elaborate a bit on the specifications of the machine? > Is this the way to setup an Buildbot Slave? Setting up a new slave is quite simple and can be done with a single command, although I prefer direct SSH access nowadays to be able to properly tune the machine. Given that you decide to offer resources, would it be possible to have VMs with full SSH access? > Is it possible to set a timer for the build server? I will need to look into that. It is possible to gracefully remove slaves from the cluster once a given build is finished but we cannot (or rather do not want to) hard-shutdown slaves immediately when a specific time is reached as that would lead to needlessly interrupted builds. With kind regards, Jo-Philipp ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [RFC PATCH 1/2] odhcp6c: support multiple additional user prefixes
Support configuration in the form...
list ip6prefix 2001:db8:1234::/64
list ip6prefix 2001:db8:5678::/64
... to allow specifying multiple additional IPv6 prefixes.
Implements feature request FS#1361.
Signed-off-by: Jo-Philipp Wich
---
package/network/ipv6/odhcp6c/Makefile| 2 +-
package/network/ipv6/odhcp6c/files/dhcpv6.script | 4 +++-
package/network/ipv6/odhcp6c/files/dhcpv6.sh | 13 +
3 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/package/network/ipv6/odhcp6c/Makefile
b/package/network/ipv6/odhcp6c/Makefile
index 9989f80f1a..8abb63317f 100644
--- a/package/network/ipv6/odhcp6c/Makefile
+++ b/package/network/ipv6/odhcp6c/Makefile
@@ -8,7 +8,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=odhcp6c
-PKG_RELEASE:=8
+PKG_RELEASE:=9
PKG_SOURCE_PROTO:=git
PKG_SOURCE_URL=$(PROJECT_GIT)/project/odhcp6c.git
diff --git a/package/network/ipv6/odhcp6c/files/dhcpv6.script
b/package/network/ipv6/odhcp6c/files/dhcpv6.script
index 03efaf7211..3171013966 100755
--- a/package/network/ipv6/odhcp6c/files/dhcpv6.script
+++ b/package/network/ipv6/odhcp6c/files/dhcpv6.script
@@ -48,7 +48,9 @@ setup_interface () {
fi
done
- [ -n "$USERPREFIX" ] && proto_add_ipv6_prefix "$USERPREFIX"
+ for prefix in $USERPREFIX; do
+ proto_add_ipv6_prefix "$prefix"
+ done
# Merge addresses
for entry in $RA_ADDRESSES; do
diff --git a/package/network/ipv6/odhcp6c/files/dhcpv6.sh
b/package/network/ipv6/odhcp6c/files/dhcpv6.sh
index 5c2ee6b988..54e51065f6 100755
--- a/package/network/ipv6/odhcp6c/files/dhcpv6.sh
+++ b/package/network/ipv6/odhcp6c/files/dhcpv6.sh
@@ -16,7 +16,7 @@ proto_dhcpv6_init_config() {
proto_config_add_string 'forceprefix:bool'
proto_config_add_string 'extendprefix:bool'
proto_config_add_string 'norelease:bool'
- proto_config_add_string 'ip6prefix:ip6addr'
+ proto_config_add_array 'ip6prefix:list(ip6addr)'
proto_config_add_string iface_dslite
proto_config_add_string zone_dslite
proto_config_add_string iface_map
@@ -36,12 +36,17 @@ proto_dhcpv6_init_config() {
proto_config_add_int "ra_holdoff"
}
+proto_dhcpv6_add_prefix() {
+ append "$3" "$1"
+}
+
proto_dhcpv6_setup() {
local config="$1"
local iface="$2"
- local reqaddress reqprefix clientid reqopts defaultreqopts noslaaconly
forceprefix extendprefix norelease ip6prefix iface_dslite iface_map
iface_464xlat ifaceid userclass vendorclass sendopts delegate zone_dslite
zone_map zone_464xlat zone soltimeout fakeroutes sourcefilter
keep_ra_dnslifetime ra_holdoff
- json_get_vars reqaddress reqprefix clientid reqopts defaultreqopts
noslaaconly forceprefix extendprefix norelease ip6prefix iface_dslite iface_map
iface_464xlat ifaceid userclass vendorclass delegate zone_dslite zone_map
zone_464xlat zone soltimeout fakeroutes sourcefilter keep_ra_dnslifetime
ra_holdoff
+ local reqaddress reqprefix clientid reqopts defaultreqopts noslaaconly
forceprefix extendprefix norelease ip6prefix ip6prefixes iface_dslite iface_map
iface_464xlat ifaceid userclass vendorclass sendopts delegate zone_dslite
zone_map zone_464xlat zone soltimeout fakeroutes sourcefilter
keep_ra_dnslifetime ra_holdoff
+ json_get_vars reqaddress reqprefix clientid reqopts defaultreqopts
noslaaconly forceprefix extendprefix norelease iface_dslite iface_map
iface_464xlat ifaceid userclass vendorclass delegate zone_dslite zone_map
zone_464xlat zone soltimeout fakeroutes sourcefilter keep_ra_dnslifetime
ra_holdoff
+ json_for_each_item proto_dhcpv6_add_prefix ip6prefix ip6prefixes
# Configure
local opts=""
@@ -84,7 +89,7 @@ proto_dhcpv6_setup() {
append opts "-t${soltimeout:-120}"
- [ -n "$ip6prefix" ] && proto_export "USERPREFIX=$ip6prefix"
+ [ -n "$ip6prefixes" ] && proto_export "USERPREFIX=$ip6prefixes"
[ -n "$iface_dslite" ] && proto_export "IFACE_DSLITE=$iface_dslite"
[ -n "$iface_map" ] && proto_export "IFACE_MAP=$iface_map"
[ -n "$iface_464xlat" ] && proto_export "IFACE_464XLAT=$iface_464xlat"
--
2.15.1
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [RFC PATCH 2/2] 6in4: support multiple additional user prefixes
Support configuration in the form...
list ip6prefix 2001:db8:1234::/64
list ip6prefix 2001:db8:5678::/64
... to allow specifying multiple routed IPv6 prefixes.
Implements feature request FS#1361.
Signed-off-by: Jo-Philipp Wich
---
package/network/ipv6/6in4/Makefile | 2 +-
package/network/ipv6/6in4/files/6in4.sh | 15 ++-
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/package/network/ipv6/6in4/Makefile
b/package/network/ipv6/6in4/Makefile
index 34227ce9ef..8ff4730e74 100644
--- a/package/network/ipv6/6in4/Makefile
+++ b/package/network/ipv6/6in4/Makefile
@@ -8,7 +8,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=6in4
-PKG_VERSION:=24
+PKG_VERSION:=25
PKG_RELEASE:=1
PKG_LICENSE:=GPL-2.0
diff --git a/package/network/ipv6/6in4/files/6in4.sh
b/package/network/ipv6/6in4/files/6in4.sh
index 786f37fc14..941dc43d68 100755
--- a/package/network/ipv6/6in4/files/6in4.sh
+++ b/package/network/ipv6/6in4/files/6in4.sh
@@ -22,13 +22,18 @@ proto_6in4_update() {
' "$1" "$@"
}
+proto_6in4_add_prefix() {
+ append "$3" "$1"
+}
+
proto_6in4_setup() {
local cfg="$1"
local iface="$2"
local link="6in4-$cfg"
- local mtu ttl tos ipaddr peeraddr ip6addr ip6prefix tunlink tunnelid
username password updatekey
- json_get_vars mtu ttl tos ipaddr peeraddr ip6addr ip6prefix tunlink
tunnelid username password updatekey
+ local mtu ttl tos ipaddr peeraddr ip6addr ip6prefix ip6prefixes tunlink
tunnelid username password updatekey
+ json_get_vars mtu ttl tos ipaddr peeraddr ip6addr tunlink tunnelid
username password updatekey
+ json_for_each_item proto_6in4_add_prefix ip6prefix ip6prefixes
[ -z "$peeraddr" ] && {
proto_notify_error "$cfg" "MISSING_ADDRESS"
@@ -61,10 +66,10 @@ proto_6in4_setup() {
proto_add_ipv6_route "::" 0 "" "" "" "$local6/$mask6"
}
- [ -n "$ip6prefix" ] && {
+ for ip6prefix in $ip6prefixes; do
proto_add_ipv6_prefix "$ip6prefix"
proto_add_ipv6_route "::" 0 "" "" "" "$ip6prefix"
- }
+ done
proto_add_tunnel
json_add_string mode sit
@@ -122,7 +127,7 @@ proto_6in4_init_config() {
proto_config_add_string "ipaddr"
proto_config_add_string "ip6addr"
- proto_config_add_string "ip6prefix"
+ proto_config_add_array "ip6prefix"
proto_config_add_string "peeraddr"
proto_config_add_string "tunlink"
proto_config_add_string "tunnelid"
--
2.15.1
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] Enable DCO check on Github OpenWrt organisation
Hi, ACK from me as well. > ACK to enable it for packages, not sure if it makes sense for core as we > enforce this in the project git repo already, and Github is just a mirror. It does make sense to provide immediate feedback on Github pull requests I assume. ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Merged: dnsmasq: backport validation fix in dnssec security fix
Merged into master. Thank you! ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 00/15] Metadata generator refactoring, cleanup and PROVIDES improvements
Hi Weedy, can you provide some more context lines to see which package those broken depends belong to? Thanks, Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Merged:
Merged into lede-17.01 with http://git.lede-project.org/?p=source.git;a=commitdiff;h=a9d1c0e923. Thank you! ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Merged: ar71xx: remove obsolete '< KERNEL_VERSION(4, 4, 0)' check
Merged into my staging tree with http://git.openwrt.org/?p=openwrt/staging/jow.git;a=commitdiff;h=c3e1e32d1f. Thank you! ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Merged: ar71xx: remove obsolete '< KERNEL_VERSION(4, 2, 0)' check
Merged into my staging tree with http://git.openwrt.org/?p=openwrt/staging/jow.git;a=commitdiff;h=d0ba8b42f9. Thank you! ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Merged: ar71xx: remove obsolete '< KERNEL_VERSION(3, 15, 0)' checks
Merged into my staging tree with http://git.openwrt.org/?p=openwrt/staging/jow.git;a=commitdiff;h=16849a05a4. Thank you! ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Merged: ar71xx/mikrotik: disable TP-Link TL-WR810N v2 board support
Merged into my staging tree with http://git.openwrt.org/?p=openwrt/staging/jow.git;a=commitdiff;h=bb22c988ce. Thank you! ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Merged: ar71xx/mikrotik: disable unused ethernet switch and phy drivers
Merged into my staging tree with http://git.openwrt.org/?p=openwrt/staging/jow.git;a=commitdiff;h=eed9614af2. Thank you! ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Merged: ar71xx/mikrotik: disable unused MTD partitioning and splitdrivers
Merged into my staging tree with http://git.openwrt.org/?p=openwrt/staging/jow.git;a=commitdiff;h=e7d9da323f. Thank you! ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Merged: ar71xx: sort kernel configurations
Merged into my staging tree with http://git.openwrt.org/?p=openwrt/staging/jow.git;a=commitdiff;h=f9ae253c3e. Thank you! ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Merged: ar71xx: fix Kconfig dependency of the 88E6063 switch DSAdriver
Merged into my staging tree with http://git.openwrt.org/?p=openwrt/staging/jow.git;a=commitdiff;h=b21a7e5349. Thank you! ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 13/15] metadata: always resolve dependencies through provides list
Hi,
[...]
> diff --git a/scripts/package-metadata.pl b/scripts/package-metadata.pl
> index 980ad24dc0..41e7108322 100755
> --- a/scripts/package-metadata.pl
> +++ b/scripts/package-metadata.pl
> @@ -101,14 +101,16 @@ my %dep_check;
> sub __find_package_dep($$) {
> my $pkg = shift;
> my $name = shift;
> - my $deps = ($pkg->{vdepends} or $pkg->{depends});
> + my $deps = $pkg->{depends};
>
> return 0 unless defined $deps;
> - foreach my $dep (@{$deps}) {
> - next if $dep_check{$dep};
> - $dep_check{$dep} = 1;
> - return 1 if $dep eq $name;
> - return 1 if ($package{$dep} and
> (__find_package_dep($package{$dep},$name) == 1));
> + foreach my $vpkg (@{$deps}) {
> + foreach my $dep (@{$vpackage{$vpkg}}) {
> + next if $dep_check{$dep->{name}};
> + $dep_check{$dep->{name}} = 1;
> + return 1 if $dep->{name} eq $name;
> + return 1 if (__find_package_dep($dep, $name) == 1);
> + }
> }
> return 0;
> }
> @@ -156,7 +158,6 @@ sub mconf_depends {
> my $m = "depends on";
> my $flags = "";
> $depend =~ s/^([@\+]+)// and $flags = $1;
> - my $vdep;
> my $condition = $parent_condition;
>
> next if $condition eq $depend;
> @@ -173,23 +174,21 @@ sub mconf_depends {
> }
> $depend = $2;
> }
> - next if $package{$depend} and $package{$depend}->{buildonly};
> if ($flags =~ /\+/) {
> - if ($vdep = $package{$depend}->{vdepends}) {
> + my $vdep = $vpackage{$depend};
> + if ($vdep) {
> my @vdeps;
> - $depend = undef;
>
> foreach my $v (@$vdep) {
> - if ($package{$v} &&
> $package{$v}->{variant_default}) {
> - $depend = $v;
> + next if $v->{buildonly};
> + if ($v->{variant_default}) {
> + unshift @vdeps, $v->{name};
> } else {
> - push @vdeps, $v;
> + push @vdeps, $v->{name};
> }
> }
>
> - if (!$depend) {
> - $depend = shift @vdeps;
> - }
> + $depend = shift @vdeps;
>
> if (@vdeps > 1) {
> $condition = ($condition ? "$condition
> && " : '') . '!('.join("||", map { "PACKAGE_".$_ } @vdeps).')';
> @@ -209,7 +208,8 @@ sub mconf_depends {
>
> $flags =~ /@/ or $depend = "PACKAGE_$depend";
> } else {
> - if ($vdep = $package{$depend}->{vdepends}) {
> + my $vdep = $vpackage{$depend};
> + if ($vdep) {
> $depend = join("||", map { "PACKAGE_".$_ }
> @$vdep);
Use "PACKAGE_".$_->{name} here as "$vdep" now is a reference to an array
of package structures, not package names anymore.
~ Jo
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Bug? Routes of disabled interfaces appear in routing table
Hi yanosz, "option enabled" is not defined for /etc/config/network, config interface as far as I know. Maybe you meant "option auto 0" instead? Regards, Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] owrt landing page
Hi, I've been preparing some draft for a future landing page at https://lede-project.org/openwrt. Note that some of the linked pages are obviously still LEDE branded and the links to IRC, lists, forum need to be expanded to point to both OpenWrt and LEDE forums. Maybe someone can pick up from here; the page should be editable by any registered wiki user. ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] libfstools: support file paths longer than 255 chars
Hi, > You missed call to free(globdir); at end. the buffer pointed to be globdir is supposed to stay, to be reused by later invocations of foreachdir(). It's kind of a lazily initialized global scratch buffer to construct intermediate path strings. Good catch on the globfree() though, the way it is (not) implemented right now seems to lead to some quite significant memory leaking, especially when traversing deep and large directory structures. ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [RFC 2/2] treewide: replace LEDE_GIT with PROJECT_GIT
Remove LEDE_GIT references in favor to the new name-agnostic PROJECT_GIT variable. Signed-off-by: Jo-Philipp Wich --- package/libs/librpc/Makefile | 2 +- package/libs/libubox/Makefile| 2 +- package/libs/uclient/Makefile| 2 +- package/libs/ustream-ssl/Makefile| 2 +- package/network/config/firewall/Makefile | 2 +- package/network/config/netifd/Makefile | 2 +- package/network/ipv6/odhcp6c/Makefile| 2 +- package/network/services/odhcpd/Makefile | 2 +- package/network/services/relayd/Makefile | 2 +- package/network/services/uhttpd/Makefile | 2 +- package/network/services/umdns/Makefile | 2 +- package/network/utils/iwinfo/Makefile| 2 +- package/network/utils/umbim/Makefile | 2 +- package/network/utils/uqmi/Makefile | 2 +- package/system/fstools/Makefile | 2 +- package/system/lede-keyring/Makefile | 2 +- package/system/procd/Makefile| 2 +- package/system/rpcd/Makefile | 2 +- package/system/ubox/Makefile | 2 +- package/system/ubus/Makefile | 2 +- package/system/uci/Makefile | 2 +- package/system/usign/Makefile| 2 +- package/utils/jsonfilter/Makefile| 2 +- package/utils/ugps/Makefile | 2 +- package/utils/usbmode/Makefile | 2 +- 25 files changed, 25 insertions(+), 25 deletions(-) diff --git a/package/libs/librpc/Makefile b/package/libs/librpc/Makefile index 0330614c31..e8f51a23f1 100644 --- a/package/libs/librpc/Makefile +++ b/package/libs/librpc/Makefile @@ -4,7 +4,7 @@ PKG_NAME:=librpc PKG_RELEASE=1 PKG_SOURCE_PROTO:=git -PKG_SOURCE_URL=$(LEDE_GIT)/project/librpc-uclibc.git +PKG_SOURCE_URL=$(PROJECT_GIT)/project/librpc-uclibc.git PKG_SOURCE_DATE:=2015-11-04 PKG_SOURCE_VERSION:=a921e3ded051746f9f7cd5e5a312fb6771716aac PKG_MIRROR_HASH:=22c8dc55e1c4e8e31635a37708a3ce622a6ca33ebd918a4321b0be6ffce89b21 diff --git a/package/libs/libubox/Makefile b/package/libs/libubox/Makefile index b261430e2d..6121576103 100644 --- a/package/libs/libubox/Makefile +++ b/package/libs/libubox/Makefile @@ -4,7 +4,7 @@ PKG_NAME:=libubox PKG_RELEASE=1 PKG_SOURCE_PROTO:=git -PKG_SOURCE_URL=$(LEDE_GIT)/project/libubox.git +PKG_SOURCE_URL=$(PROJECT_GIT)/project/libubox.git PKG_SOURCE_DATE:=2017-10-06 PKG_SOURCE_VERSION:=729f47fd5279f902986457682f8f166c324eafb5 PKG_MIRROR_HASH:=5ca03294498f347f437236aeb1d55747264229a46a5ddba93caeb6b3fb735e10 diff --git a/package/libs/uclient/Makefile b/package/libs/uclient/Makefile index 3eefa2e012..f0c08a3233 100644 --- a/package/libs/uclient/Makefile +++ b/package/libs/uclient/Makefile @@ -4,7 +4,7 @@ PKG_NAME:=uclient PKG_RELEASE=1 PKG_SOURCE_PROTO:=git -PKG_SOURCE_URL=$(LEDE_GIT)/project/uclient.git +PKG_SOURCE_URL=$(PROJECT_GIT)/project/uclient.git PKG_SOURCE_DATE:=2017-11-02 PKG_SOURCE_VERSION:=4b87d83160fec70d50b7fcd736a8c538c28a016c PKG_MIRROR_HASH:=4bbb4d5f295ebdcd67fec87a6794168bea2176a42cb2907c47d8566fb33dafb3 diff --git a/package/libs/ustream-ssl/Makefile b/package/libs/ustream-ssl/Makefile index 7afbeeba66..b5e773ba7f 100644 --- a/package/libs/ustream-ssl/Makefile +++ b/package/libs/ustream-ssl/Makefile @@ -4,7 +4,7 @@ PKG_NAME:=ustream-ssl PKG_RELEASE:=2 PKG_SOURCE_PROTO:=git -PKG_SOURCE_URL=$(LEDE_GIT)/project/ustream-ssl.git +PKG_SOURCE_URL=$(PROJECT_GIT)/project/ustream-ssl.git PKG_SOURCE_DATE:=2016-07-02 PKG_SOURCE_VERSION:=ec80adaa1b47f28d426fa19c692011ce60b992d6 PKG_MIRROR_HASH:=bfbad6b4e8c1e933f0bfaab43cbdd44a536c08128c3a779e6f2395a6a886aab7 diff --git a/package/network/config/firewall/Makefile b/package/network/config/firewall/Makefile index 06e67543b9..1bc2c4d1fa 100644 --- a/package/network/config/firewall/Makefile +++ b/package/network/config/firewall/Makefile @@ -12,7 +12,7 @@ PKG_NAME:=firewall PKG_RELEASE:=1 PKG_SOURCE_PROTO:=git -PKG_SOURCE_URL=$(LEDE_GIT)/project/firewall3.git +PKG_SOURCE_URL=$(PROJECT_GIT)/project/firewall3.git PKG_SOURCE_DATE:=2017-11-07 PKG_SOURCE_VERSION:=c4309372acc7e1bef8aa230269f7da1dec790e68 PKG_MIRROR_HASH:=1699884d8499d01e433959185f79ff9eb69704de47885b996123374b8015b422 diff --git a/package/network/config/netifd/Makefile b/package/network/config/netifd/Makefile index 4eb4737a3a..ade0061e7a 100644 --- a/package/network/config/netifd/Makefile +++ b/package/network/config/netifd/Makefile @@ -4,7 +4,7 @@ PKG_NAME:=netifd PKG_RELEASE:=1 PKG_SOURCE_PROTO:=git -PKG_SOURCE_URL=$(LEDE_GIT)/project/netifd.git +PKG_SOURCE_URL=$(PROJECT_GIT)/project/netifd.git PKG_SOURCE_DATE:=2018-01-04 PKG_SOURCE_VERSION:=fd5c399c01ceb1bbede3ae8b0e1daaa7652a6fa1 PKG_MIRROR_HASH:=0040f94d11d0039505328a90b2ff48968db873e9e7967307631bf40ef5679275 diff --git a/package/network/ipv6/odhcp6c/Makefile b/package/network/ipv6/odhcp6c/Makefile index 457a871efb..24cbe0b2cb 100644 --- a/package/network/ipv6/odhcp6c/Makefile +++ b/package/network/ipv6/odhcp6c/Makefile @@ -11,7 +11,7 @@ PKG_NAME:=odhcp6c PKG_RELEASE:=4 PKG_SOURCE_PROTO
[LEDE-DEV] [RFC 1/2] downloads.mk: introduce name-agnostic PROJECT_GIT variable
Introduce a name-agnostic PROJECT_GIT variable poiting to https://git.openwrt.org/ and declare LEDE_GIT and OPENWRT_GIT as aliases to it. After some transition time we can drop this alias variables. Signed-off-by: Jo-Philipp Wich --- include/download.mk | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/include/download.mk b/include/download.mk index 0a25641738..2ba8a7bdf4 100644 --- a/include/download.mk +++ b/include/download.mk @@ -6,8 +6,10 @@ # See /LICENSE for more information. # -OPENWRT_GIT = http://git.openwrt.org -LEDE_GIT = https://git.lede-project.org +PROJECT_GIT = https://git.openwrt.org + +OPENWRT_GIT = $(PROJECT_GIT) +LEDE_GIT = $(PROJECT_GIT) ifdef PKG_SOURCE_VERSION PKG_VERSION ?= $(if $(PKG_SOURCE_DATE),$(PKG_SOURCE_DATE)-)$(call version_abbrev,$(PKG_SOURCE_VERSION)) -- 2.14.2 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH netifd] proto: allow dumping protocol handlers without config_params
Hi, > I'm unable to reproduce the reported netifd crash by using a proto > shell handler having no proto_init_config function. > Looking into the code the proto_handler config_params parameter is > always assigned the proto shell handler config pointer in the function > proto_shell_add_handler; afaict the config_parameter is not altered > further in the code. > Can you describe how you triggered the crash using a proto shell > handler implementation ? That being said, I still think that the change is sensible. Even if the root cause turns out to be something else. ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] OpenWrt source replaced by former LEDE tree
Hi, following the agreed OpenWrt/LEDE re-merge procedure, we've replaced the OpenWrt Git tree with the LEDE Git tree now and archived the old repository. If you're working with older branches such as Chaos Calmer or Barrier Breaker, you do have to update your remotes in order to continue to be able to fetch from the repository. You can find the archived OpenWrt repository including all previous branches and tags at https://github.com/openwrt/archive >From now on, the https://github.com/openwrt/openwrt repository will host the contents of the former LEDE source tree at https://github.com/lede-project/source which already has been rebranded to OpenWrt in preparation for the tree swap. The synchronisation between https://github.com/openwrt/openwrt, https://github.com/lede-project/source and https://git.lede-project.org/?p=source.git will remain active until all infrastructure changes are fully settled. Kind regards, Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Merged: procd: procd_send_signal use signal names
Merged into my staging tree with http://git.lede-project.org/?p=lede/jow/staging.git;a=commitdiff;h=df5303c92a. Thank you! ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH rpcd] iwinfo: add info about frequency restrictions
Hi Rafał,
in principle fine with me - but I guess all restrictions will be in the
form { : true } so I'd rather make it an array.
Also since a restriction implies something not possible, I'd drop the
"no_" prefix too. So in the end it would look like:
{
"channel": 1,
"mhz": 2412,
"restricted": false,
"active": false,
"restrictions": [
"ht40minus",
"80mhz"
}
}
~ Jo
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] fixing of image file names
Hi Piotr, my rough idea was to somehow tie the manifest generation to the "define Device/*" macros present in the image building code because there you have all required information in a central place: - unique board identifier - image name / build steps - default package selection ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] base-files: allow skipping of hash verification
Hi John, thanks for taking care of it. I have a minor change request, can we swap "none" with "skip"? I think that makes slightly more sense in this context. ~ Jo ___ 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
Hi Baptiste,
we've been discussing this patch again on IRC today and I came up with
an alternate suggestion that does not require a new variable.
-- 8< --
diff --git a/scripts/download.pl b/scripts/download.pl
index 775408934a..ad9c480c67 100755
--- a/scripts/download.pl
+++ b/scripts/download.pl
@@ -88,7 +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";
+$hash_cmd or ($file_hash eq "none") or die "Cannot find appropriate
hash command, ensure the provided hash is either a MD5 or SHA256
checksum.\n";
sub download
{
-- >8 --
Using the change above one can issue a
"make package/mypackage/download PKG_HASH=none"
to download ignoring the Makefile checksum while preserving the error
semantics of unset PKG_HASH cases.
Ideally I'd like to push the "none" variant but wanted to share the idea
on the list first to see what others think about it.
Regards,
Jo
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] sdk: restrict base feed repo to public git for CONFIG_BUILDBOT only
Hi Rafał, > This allows people to build SDK from custom repository (git access using > ssh) and keep original URL in SDK's feeds.conf.default. > > Signed-off-by: Rafał Miłecki Acked-by: Jo-Philipp Wich ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] fixing of image file names
Hi, > I still have here some concerns/thoughts: > > 1. I don't know how to deal in above approach with region variant images > but I'm sure we should _somehow_ separate region code from boardname and > other parts of the image filename. IMHO, dash character won't work here. > > 2. We have some boards versions like "v2.1" which with my above approach > would end up as "v2-1". Maybe we should keep dot as a valid character in > version part? > > 3. Some of devices come in different RAM/flash configurations and in > case where common image can't support all of them, we include > information about RAM/flash variant sometimes only in image name and > sometimes in both the image name and boardname/compatible string. A > common and defined approach would be required for this as well. A number of these issues can also be addressed by producing a Manifest file in the same directory which allows users to map unique board identifications to an appropriate image file. This would also work for cases where multiple boards share the very same file. ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] iodine bad endianess?
Hi Gui, please test the PR at https://github.com/openwrt/packages/pull/5190. ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC] toolchain: fix GCC version check causing failure on Debian Testing with gcc-7
Hi Peter, > In Debian there were/are gcc-4.2 .. gcc-4.9, gcc-5 .. gcc-7. > And what about beauties like 'x86_64-linux-gnu-gcc-7'? > Why not ditch the 'gcc* --version' invocations and have people use > 'CC=fancy-named-gcc' on the command line if needed? That should already work (after fixing the version regex). The build system will call "$(CC) -dumpversion" and symlink that to ./staging_dir/host/bin/gcc if passing the check, so the extra "gcc-7" patch hunk should not be needed if you're fine with invoking the buildroot using "CC=gcc-7 make ...". I'm fine with removing the version checks entirely if we find an alternative to check for GCC > 4.8 - maybe a feature test of some sort? ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Merged: uqmi: fix raw-ip mode for newer lte modems
Merged into my staging tree with http://git.lede-project.org/?p=lede/jow/staging.git;a=commitdiff;h=36b31d2c49. Thank you! ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH rpcd v3] sys: fix passwd path
Merged to rpcd.git in https://git.lede-project.org/?p=project/rpcd.git;a=commitdiff;h=74a784f037867025ad1c6b8c38bfdfa548742339 - thanks. ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Merged: dnsmasq: fix dhcp-host entries with empty macs
Merged into master with http://git.lede-project.org/?p=source.git;a=commitdiff;h=fcfd5cdb59. Thank you! ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] opkg-lede not handling ar-ipks or debs anymore - bug or feature?
Hi, > Okay, fair enough. Are you accepting patches re-adding that support > or is the intention to not re-introduce support for ar-packed > archives at all? This depends on the executable size impact. > In either case, > https://git.lede-project.org/?p=source.git;a=blob;f=package/system/opkg/Makefile;h=499de217cc537c7c279fb2c126de2c2207621865;hb=HEAD#l64 > ought to be fixed for the time being, or? Yes, I'll look into it later. Thanks for the heads-up. ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] opkg-lede not handling ar-ipks or debs anymore - bug or feature?
Hi Christian, I currently have no intention to re-introduce support for .ar packed archives. Regards, Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH opkg] libopkg: fix SHA256 calculation for big endian system
On 11/18/2017 01:25 PM, Jonas Gorski wrote:
> The SHA256 implementation relied on WORDS_BIGENDIAN being defined for
> big endian systems, but this was never done. This caused it to produce
> wrong checksums on those systems.
>
> Fix this by replacing the check with a generic check for big endian byte
> order.
>
> Fixes: 84552e64fa6d ("Adding sha256.[ch] Sorry forgot adding them. Thanks for
> Graham Gower ")
Might be that the initial implementation was okay and that my
autotools->cmake refactoring broke setting WORDS_BIGENDIAN.
> Signed-off-by: Jonas Gorski
Acked-by: Jo-Philipp Wich
> ---
> libopkg/sha256.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libopkg/sha256.c b/libopkg/sha256.c
> index e0c4e3e0d423..5848799c0260 100644
> --- a/libopkg/sha256.c
> +++ b/libopkg/sha256.c
> @@ -30,7 +30,7 @@
> #include "unlocked-io.h"
> #endif
>
> -#ifdef WORDS_BIGENDIAN
> +#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
> #define SWAP(n) (n)
> #else
> #define SWAP(n) \
>
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Planned Server Maintenance
Hi, just fyi. Digital Ocean plans urgent maintenance on the host serving our wiki between Thursday, 18:00 and 19:00 UTC. Downtime is not expected but may occur. Original notice below. Regards, Jo -- FRA1 Emergency Maintenance 2017-11-16 18:00 UTC Start: 2017-11-16 18:00 UTC End: 2017-11-16 19:00 UTC Hi there, We are currently performing an urgent software upgrade impacting a subset of FRA1 physical machines. In most scenarios, this upgrade occurs seamlessly, with no impact to Droplets, however we have identified that a very small number of upgrades require manual intervention and may result in a brief Droplet downtime. Your Droplets that may be potentially impacted by this maintenance are listed below. We're extremely sorry for the short notice, and inconvenience here, but performing these upgrades are critical to significant improvements to the performance and reliability of the platform. If you have any questions, or concerns, please feel free to reply to this email or open up a support ticket on your account. Kind Regards, DigitalOcean Customer Success Affected Droplets: wiki-01.infra.lede-project.org ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Lede/Openwrt documentation
Hi, > The wiki is working for me. it's great to have the ToH. Also the > device pages are great. However the wiki is not always completely > correct and may be just wrong. It's a wiki, change it! A wiki is > always changing. I believe that a wiki is no alternative for a proper, curated documentation. I've also seen many instances where user contributed information was either incomplete or even factually wrong. Another thing I noticed is that some documentation actually seem to have devolved compared to the OpenWrt wiki. I wrote large parts of https://wiki.openwrt.org/doc/uci/network - now compare that with https://lede-project.org/docs/user-guide/network_configuration. Not even did I struggle to find that page in the first place within the LEDE wiki, I also couldn't find any trace of the missing ip rule or route action documentation. Also TOH != documentation. ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] umdns: Replace unnecessary memset calls with {}.
Hi,
comments inline.
> ---
> interface.c | 22 --
> 1 file changed, 8 insertions(+), 14 deletions(-)
>
> diff --git a/interface.c b/interface.c
> index 7f814d2..18dee52 100644
> --- a/interface.c
> +++ b/interface.c
> @@ -44,7 +44,7 @@
> static int
> interface_send_packet4(struct interface *iface, struct sockaddr_in *to,
> struct iovec *iov, int iov_len)
> {
> - static size_t cmsg_data[( CMSG_SPACE(sizeof(struct in_pktinfo)) /
> sizeof(size_t)) + 1];
> + static size_t cmsg_data[( CMSG_SPACE(sizeof(struct in_pktinfo)) /
> sizeof(size_t)) + 1] = {};
> static struct sockaddr_in a;
> static struct msghdr m = {
> .msg_name = (struct sockaddr *) &a,
> @@ -61,7 +61,6 @@ interface_send_packet4(struct interface *iface, struct
> sockaddr_in *to, struct i
> m.msg_iov = iov;
> m.msg_iovlen = iov_len;
>
> - memset(cmsg_data, 0, sizeof(cmsg_data));
The cmsg_data buffer is static, wouldn't that mean that it is never
zeroed again after the first function call?
> cmsg = CMSG_FIRSTHDR(&m);
> cmsg->cmsg_len = m.msg_controllen;
> cmsg->cmsg_level = IPPROTO_IP;
> @@ -84,7 +83,7 @@ interface_send_packet4(struct interface *iface, struct
> sockaddr_in *to, struct i
> static int
> interface_send_packet6(struct interface *iface, struct sockaddr_in6 *to,
> struct iovec *iov, int iov_len)
> {
> - static size_t cmsg_data[( CMSG_SPACE(sizeof(struct in6_pktinfo)) /
> sizeof(size_t)) + 1];
> + static size_t cmsg_data[( CMSG_SPACE(sizeof(struct in6_pktinfo)) /
> sizeof(size_t)) + 1] = {};
> static struct sockaddr_in6 a;
> static struct msghdr m = {
> .msg_name = (struct sockaddr *) &a,
> @@ -101,7 +100,6 @@ interface_send_packet6(struct interface *iface, struct
> sockaddr_in6 *to, struct
> m.msg_iov = iov;
> m.msg_iovlen = iov_len;
>
> - memset(cmsg_data, 0, sizeof(cmsg_data));
Same here, I think the buffer needs to be zeroed on each invocation.
> cmsg = CMSG_FIRSTHDR(&m);
> cmsg->cmsg_len = m.msg_controllen;
> cmsg->cmsg_level = IPPROTO_IPV6;
> @@ -186,7 +184,7 @@ read_socket4(struct uloop_fd *u, unsigned int events)
> struct iovec iov[1];
> char cmsg[CMSG_SPACE(sizeof(struct in_pktinfo)) +
> CMSG_SPACE(sizeof(int)) + 1];
> struct cmsghdr *cmsgptr;
> - struct msghdr msg;
> + struct msghdr msg = {};
> socklen_t len;
[snip]
~ Jo
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATH] uhttpd: store relative query string offset
Instead of storing a pointer to the beginning of the query string within the
request url, store the byte offset instead.
Since the URL is usually kept in the per-client blob buffer which might
change its memory location due to reallocations triggered by blobmsg_add_*,
it is not safe to point to it early in the request life cycle.
This fixes invalid memory access usually manifesting itself as corrupted
query string data in CGI scripts.
Reported-by: P. Wassi
Signed-off-by: Jo-Philipp Wich
---
file.c | 13 +++--
lua.c| 2 +-
proc.c | 2 +-
uhttpd.h | 2 +-
4 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/file.c b/file.c
index a1775f5..5ca8db5 100644
--- a/file.c
+++ b/file.c
@@ -156,7 +156,7 @@ uh_path_lookup(struct client *cl, const char *url)
/* separate query string from url */
if ((pathptr = strchr(url, '?')) != NULL) {
- p.query = pathptr[1] ? pathptr + 1 : NULL;
+ p.query_offset = pathptr[1] ? (pathptr - url + 1) : 0;
/* urldecode component w/o query */
if (pathptr > url) {
@@ -239,8 +239,8 @@ uh_path_lookup(struct client *cl, const char *url)
ustream_printf(cl->us, "Content-Length: 0\r\n");
ustream_printf(cl->us, "Location: %s%s%s\r\n\r\n",
&path_phys[docroot_len],
- p.query ? "?" : "",
- p.query ? p.query : "");
+ p.query_offset ? "?" : "",
+ p.query_offset ? (url + p.query_offset) : "");
uh_request_done(cl);
p.redirected = 1;
return &p;
@@ -733,14 +733,13 @@ static int field_len(const char *ptr)
_field(root) \
_field(phys) \
_field(name) \
- _field(info) \
- _field(query)
+ _field(info)
static void
uh_defer_script(struct client *cl, struct dispatch_handler *d, struct
path_info *pi)
{
struct deferred_request *dr;
- char *_root, *_phys, *_name, *_info, *_query;
+ char *_root, *_phys, *_name, *_info;
cl->dispatch.req_free = uh_free_pending_request;
@@ -757,6 +756,8 @@ uh_defer_script(struct client *cl, struct dispatch_handler
*d, struct path_info
#undef _field
#define _field(_name) if (pi->_name) dr->pi._name = strcpy(_##_name,
pi->_name);
path_info_fields
+
+ dr->pi.query_offset = pi->query_offset;
} else {
dr = calloc(1, sizeof(*dr));
}
diff --git a/lua.c b/lua.c
index 3efe22b..2ad8d35 100644
--- a/lua.c
+++ b/lua.c
@@ -219,7 +219,7 @@ static void lua_main(struct client *cl, struct path_info
*pi, char *url)
str = strchr(url, '?');
if (str) {
if (*(str + 1))
- pi->query = str + 1;
+ pi->query_offset = str - url + 1;
path_len = str - url;
}
diff --git a/proc.c b/proc.c
index e360897..ca22430 100644
--- a/proc.c
+++ b/proc.c
@@ -145,7 +145,7 @@ struct env_var *uh_get_process_vars(struct client *cl,
struct path_info *pi)
extra_vars[VAR_SCRIPT_NAME].value = pi->name;
extra_vars[VAR_SCRIPT_FILE].value = pi->phys;
extra_vars[VAR_DOCROOT].value = pi->root;
- extra_vars[VAR_QUERY].value = pi->query ? pi->query : "";
+ extra_vars[VAR_QUERY].value = pi->query_offset ? (url +
pi->query_offset) : "";
extra_vars[VAR_REQUEST].value = url;
extra_vars[VAR_PROTO].value = http_versions[req->version];
extra_vars[VAR_METHOD].value = http_methods[req->method];
diff --git a/uhttpd.h b/uhttpd.h
index 374cd72..6e77457 100644
--- a/uhttpd.h
+++ b/uhttpd.h
@@ -145,7 +145,7 @@ struct path_info {
const char *phys;
const char *name;
const char *info;
- const char *query;
+ size_t query_offset;
bool redirected;
struct stat stat;
const struct interpreter *ip;
--
2.14.2
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATH] uhttpd: store relative query string offset
Hi, please give this patch a try. I was able to reproduce your issue and this patch fixed the issue for me. ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [RFC] A new developper documentation for OpenWrt/LEDE
Hi Baptiste,
first of all I think that is a great initiative!
> 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
The layout is okay and the ASCII markup looks reasonably simple to allow
for distraction-free text writing so LGTM here.
> 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:
That would be fine with me. There used to be some rudimentary
documentation in the past (see
http://git.lede-project.org/882f4d2d63272abce8c1966983aa10178e2e971f)
but it never got really updated.
> - 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;
Such a policy can be introduced once the docs are reasonably complete,
before that it would likely put off contributors.
> - 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;
I like that, yes.
> - 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].
That would be an upside as well; while I do not expect release branch
documentation to receive much maintenance it would at the very least
ensure that future documentation updates do not invalidate config that
used to be correct for a past release.
> 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).
That is a valid point but I would give it a try; after all I suspect
this documentation to target contributors already aware of how to use Git.
> 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 think we can figure out a way to automatically mirror the
documentation to the wiki so that users have a common location for user
and developer 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.
You can count me in on 1) and 2). 3) should be deferred until a
reasonable base line is established. To simplify bootstrapping the
project we can also setup a scratch repo somewhere with direct push
access to documentation contributors.
> Now for the questions:
>
> - does this seem to go in the right direction?
Definitely!
> - 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?
I cannot speak for the others but I am personally interested in working
on the documentation. I also wrote parts of the existing uci references
and generally like working on such things. I cannot promise that I'll
have much time to write lots of text but I can certainly explain things
and help with answering questions.
> - 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.
It might make sense to set up an etherpad here to gather some structural
ideas.
Cheers,
Jo
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Merged: kernel: enable CONFIG_ADVISE_SYSCALLS
Merged into my staging tree with http://git.lede-project.org/?p=lede/jow/staging.git;a=commitdiff;h=bc584ac5d1. Thank you! ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] uhttpd problems with env variable in cgi
Hi, I think the issue is me reusing the global "uh_buf" in uh_auth_check(). The same buffer is used to store the URL pieces referred to be the "path_info" struct. Will look into a fix for that. ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] merge: add OpenWrt branding
Hi,
comments inline.
> Signed-off-by: Imre Kaloz
Given the fact that we explicitely wanted to avoid @openwrt.org mails
and that this was one of the discussion points leading to the split I
find it delicate to seal the merging commit with exactly such a S-o-b.
Combined with ...
$ git log --author "Imre Kaloz " --format=%cD -1
Tue, 18 Oct 2016 11:42:06 +0200
... this looks to me like nothing was learned from past experiences and
that all that matters here is having the own name attached to the work
being done.
Anyhow, on to the code.
> diff --git a/Config.in b/Config.in
> index ddbc4e2..d30c048 100644
> --- a/Config.in
> +++ b/Config.in
[...]
> VERSION_REPO:=$(call qstrip_escape,$(CONFIG_VERSION_REPO))
> -VERSION_REPO:=$(if
> $(VERSION_REPO),$(VERSION_REPO),http://downloads.lede-project.org/snapshots)
> +VERSION_REPO:=$(if
> $(VERSION_REPO),$(VERSION_REPO),http://downloads.openwrt.org/snapshots)
We need to setup the server first or delegate downloads.openwrt.org to
downloads.lede-project.org or add a rewrite rule to redirect
http://downloads.openwrt.org/snapshots/(.*) to
http://downloads.lede-project.org/snapshots/$1 for now.
> VERSION_BUG_URL:=$(call qstrip_escape,$(CONFIG_VERSION_BUG_URL))
> -VERSION_BUG_URL:=$(if
> $(VERSION_BUG_URL),$(VERSION_BUG_URL),http://bugs.lede-project.org/)
> +VERSION_BUG_URL:=$(if
> $(VERSION_BUG_URL),$(VERSION_BUG_URL),http://bugs.openwrt.org/)
Likewise.
> VERSION_SUPPORT_URL:=$(call qstrip_escape,$(CONFIG_VERSION_SUPPORT_URL))
> -VERSION_SUPPORT_URL:=$(if
> $(VERSION_SUPPORT_URL),$(VERSION_SUPPORT_URL),http://forum.lede-project.org/)
> +VERSION_SUPPORT_URL:=$(if
> $(VERSION_SUPPORT_URL),$(VERSION_SUPPORT_URL),http://forum.openwrt.org/)
Undecided.
>
> VERSION_PRODUCT:=$(call qstrip_escape,$(CONFIG_VERSION_PRODUCT))
> VERSION_PRODUCT:=$(if $(VERSION_PRODUCT),$(VERSION_PRODUCT),Generic)
[...]
> diff --git a/package/base-files/files/etc/banner
> b/package/base-files/files/etc/banner
> index 4ec646a..af51b5a 100644
> --- a/package/base-files/files/etc/banner
> +++ b/package/base-files/files/etc/banner
> @@ -1,10 +1,13 @@
> - _
> -//\ ____ ___ ___
> - / LE/ \| | | __| \| __|
> - /DE /\ | |__| _|| |) | _|
> - // LE \ ||___|___/|___| lede-project.org
> - \\ DE /
> - \LE \/
> ---
> - \ DE\ /%N (%V, %C)
> -\\/
> ---
> -
> + ___ __
> + | |.-.-.-.| | | |..| |_
> + | - || _ | -__| || | | || _|| _|
> + |___|| __|_|__|__||||__| ||
> + |__| W I R E L E S S F R E E D O M
> + -
> + DESIGNATED DRIVER (%C, %R)
Please replace "DESIGNATED DRIVER" with "%N". "%V, %C" (17.01.4,
r3560-79f57e422d) are more useful under the new version scheme than "%C,
%R" (r3560-79f57e422d, r3560-79f57e422d)
> + -
> + * 2 oz. Orange Juice Combine all juices in a
> + * 2 oz. Pineapple Juice tall glass filled with
> + * 2 oz. Grapefruit Juice ice, stir well.
> + * 2 oz. Cranberry Juice
> + -
> diff --git a/package/base-files/files/etc/init.d/system
> b/package/base-files/files/etc/init.d/system
> index 8c5f677..54c0e3e 100755
> --- a/package/base-files/files/etc/init.d/system
> +++ b/package/base-files/files/etc/init.d/system
> @@ -7,7 +7,7 @@ USE_PROCD=1
> validate_system_section()
> {
> uci_validate_section system system "${1}" \
> - 'hostname:string:lede' \
> + 'hostname:string:openwrt' \
While we're at it we should properly capitalize the default to "OpenWrt".
> 'conloglevel:uinteger' \
> 'buffersize:uinteger' \
> 'timezone:string:UTC' \
[...]
> diff --git a/package/network/services/uhttpd/files/uhttpd.init
> b/package/network/services/uhttpd/files/uhttpd.init
> index 6b8be1c..fd8365a 100755
> --- a/package/network/services/uhttpd/files/uhttpd.init
> +++ b/package/network/services/uhttpd/files/uhttpd.init
> @@ -52,7 +52,7 @@ generate_keys() {
> [ -n "$GENKEY_CMD" ] && {
> $GENKEY_CMD \
> -days ${days:-730} -newkey rsa:${bits:-2048} -keyout
> "${UHTTPD_KEY}.new" -out "${UHTTPD_CERT}.new" \
> - -subj
> /C="${country:-DE}"/ST="${state:-Saxony}"/L="${location:-Leipzig}"/O="${commonname:-Lede}$UNIQUEID"/CN="${commonname:-Lede}"
> + -subj
> /C="${country:-DE}"/ST="${state:-Saxony}"/L="${location:-Leipzig}"/O="${commonname:-OpenWrt}$UNIQUEID"/CN="${commonname:-OpenWrt}"
Maybe we should adjust the defaults here to match the shipped config.
> sync
> m
Re: [LEDE-DEV] Linksys WRT54GL / image builder
Hi Mikael, try "make info", that should display the required package set per device. ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] KRACK (Key Reinstallation Attacks), now patched upstream in hostapd
Hi, > Why would that be? I don't see what the negative effects are if I update > just the hostapd and wpad* packages, other than using up some space, > instead of installing a new image with them included. Or am I missing > something? I think Stijn was referring to the idea of (silently) updating the already released 17.01.3 images to contain updated packages. ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Merged: mdadm: Fix config generation
Merged into my staging tree with http://git.lede-project.org/?p=lede/jow/staging.git;a=commitdiff;h=890205feb0. Thank you! ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] SDK Error: Makefile:48: *** DESCRIPTION:= is obsolete
Hi, try using "define Build/Compile" instead of "define Package/helloworld/compile". ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Kernel version in next major release
Hi Hauke, I prefer option 3 as well. ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Severe dnsmasq vulnerabilities affecting LEDE
The Google security team identified a number of critical security issues present in dnsmasq, the embedded DNS and DHCP server used by LEDE as well as many other different open and proprietary firmwares and network appliances. A total of six different flaws affecting both DNS and DHCP functionality have been identified in dnsmasq versions up to v2.77: - CVE-2017-14491 - Remote code execution, through DNS, due to heap overflow - CVE-2017-14492 - Remote code execution, through DHCP, due to heap overflow - CVE-2017-14493 - Remote code execution, through DHCP, due to stack overflow - CVE-2017-14494 - Information leak, through DHCP, potentially weakening ASLR - CVE-2017-14495 - Denial of service, through DNS, out-of-memory due missing free() - CVE-2017-14496 - Denial of service, through DNS, integer underflow causing huge memcpy() - CVE-2017-13704 - Denial of service, through DNS, integer underflow causing service crash According to Simon Kelley, the author of dnsmasq, most critical flaws are present in dnsmasq since a very long time, having even survived a number of audits. The security issues have been fixed in the most recent dnsmasq version, v2.78, which has been included into both the LEDE master and lede-17.01 release branches. MITIGATION In order to solve the security issues above you can either update the dnsmasq package through opkg: opkg update opkg upgrade dnsmasq Or update to a newer LEDE image. Master snapshots newer than revision r4969-67ac017fef and the upcoming LEDE release 17.01.3 images already contain a fixed dnsmasq version. WORKAROUND There is no secure workaround available, though the attack surface can be reduced somewhat by disabling the DNS service part of dnsmasq and only allowing trusted hosts to obtain DHCP leases in the local network. In order to disable the DNS service, issue the following commands: uci set dhcp.@dnsmasq[0].port="0" uci add_list dhcp.lan.dhcp_option="6,8.8.8.8" uci commit dhcp /etc/init.d/dnsmasq restart This will stop dnsmasq from serving DNS requests and instruct all DHCP clients to use Google's public DNS server instead of the router itself for name resolution. REFERENCES The orginal article published on the Google security blog: https://security.googleblog.com/2017/10/behind-masq-yet-more-dns-and-dhcp.html Dnsmasq security notice: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2017q4/011772.html Debian security advisory: https://www.debian.org/security/2017/dsa-3989 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC] adding CPE IDs to package Makefiles
Hi, > Can't we just take the version from the PKG_VERSION entry and provide a > way to overwrite it with some other variable in case the CVE database > uses a different version number format? yes, I was thinking something similar, like using $(PKG_CPE):$(PKG_VERSION) if there is no version included already. But I have not yet investigated if that would work in all cases, if the version numbers are usable as-is etc. > We could check if this version number is available in the CVE database > and warn the user if this is not the case, but we could probably cover > 90% of the packages. Yes, assuming that we do get the versions properly included. ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [RFC] adding CPE IDs to package Makefiles
Hi, I'd like to propose adding structured CPE information to package Makefiles in order to simplify mapping of discovered vulnerabilities to affected LEDE software components. The Common Platform Enumeration (CPE) specification provides a standardized way to name software packages and versions, which allows for automated processes to match security advisories containing CPE IDs with affected software. You can read up on CPE at [1]. FORMAT The proposed format for adding CPE IDs to Makefiles would be a new variable called "PKG_CPE" which is set to the corresponding ID of the package. Multiple ids may be specified, separated by space. For example the busybox package Makefile at package/utils/busybox/Makefile would contain an entry like: PKG_CPE:=cpe:/a:busybox:busybox USAGE The main intended use case for the PKG_CPE entries is automated vulnerability surveys by periodic jobs. A given CPE ID can be used to look up past and current security advisories affecting a specific component, making it easy to relate CVEs to Makefiles. Considering the busybox example above, we can use the value of PKG_CPE to obtain a list of advisories [2] and match them against our packages. IMPLEMENTATION Initially some effort is required to properly map important packages and their respective Makefiles accordingly, afterwards PKG_CPE variables can be added on a case-by-case basis, e.g. whenever a vulnerability for a not-yet tagged package is being handled. We may also encourage contributors to already provide suitable PKG_CPE entries in new package submissions. CONSIDERATIONS While the CPE IDs allow us to relate a given Makefile to a list of past and current CVEs, they provide no means to decide whether a given CVE already has been addressed by the LEDE developers and package maintainers. In order to track the vulnerability status of CVEs I propose to: - Define a cut-off date and develop the survey scripts to ignore any CVEs prior to that - For any security fixes made to a package after the cut-off date require developers to mention the fixed CVEs in either the commit subject or the commit message, for example: busybox: update to 1.24.0 This updates the busybox package to version 1.24.0 and fixes an access restriction bypass in modprobe (CVE-2014-9645). Signed-off-by: Package Developer Additional steps that can be taken to improve vulnerability tracking: - Add version vector to CPE entries, e.g. "cpe:/a:busybox:busybox:1.23.0" instead of "cpe:/a:busybox:busybox" Downside here is that it is easy to miss updates to the ID when bumping the package version. - Provide an additional out-of-band facility to mark CVEs as fixed, e.g. a "security.txt" file next to the package Makefile. Such a file would allow enumerating addressed advisories when a CVE ID was missed or misspelled in a commit. Structure and scope are yet to be defined. - Develop vulnerability survey scripts to take PKG_VERSION and PKG_REVSION fields into account when looking up CVEs to avoid false (past) positives. RESPONSIBILITY Given a consensus on a final proposal I am willing to implement the initial pieces of such a CVE mapping infrastructure, mainly: - Take care of adding the appropriate PKG_ID entries to core packages - Write CVE mapping and vulnerability reporting scripts - Implement an automatic advisory report and status tracking web page -- Please let me know what you think about this approach and feel free to drop some comments. Thanks, Jo -- 1: http://cpe.mitre.org/ 2: https://nvd.nist.gov/vuln/search/results?adv_search=true&cves=on&cpe_version=cpe:/a:busybox:busybox ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] is there a reason not to use "git --version" to check for git?
Hi, extracting, sanitizing and testing the version number would be a way more complex one-liner compared to just grepping for the required flag. ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] is there a reason not to use "git --version" to check for git?
Hi, extracting, sanitizing and testing the version number would be a way more complex one-liner compared to just grepping for the required flag. ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH uclient] uclient-http: fix Host: header for literal IPv6 addresses
Hi Matthias, > For literal IPv6 addresses, the host header must have the form > > Host: [...] > > including the square brackets, as it may also contain a port. Some > webservers ignore the missing brackets, while others will return > error 400. > > IPv6 addresses are determined by searching for ':' characters in the > host, as neither IPv4 addresses nor DNS names can contain colons. An > alternative would be to add a flag to the uclient_url struct; but as > this struct is exposed in public headers, such a change could be > considered an ABI change, making a backport difficult. > > Signed-off-by: Matthias Schiffer I would've solved it the same way so ... Acked-by: Jo-Philipp Wich ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] uhttpd/luci authentication using SSL client certificates
Hi Simon, this is not implemented in uhttpd. ~ J ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] uhttpd: add manifest support
Hi Adrian, the patch was whitespace mangled and thus not detected by patchwork. Applied manually in 3fd58e9. ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] busybox ntpd not syncing if any server is bad
Hi Karlp, > Presumably updating busybox in master isn't exactly on the roadmap. > Would a backport of this patch be acceptable for both 17.01 and > master? Definitely! ~ Jo signature.asc Description: OpenPGP digital signature ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH iwinfo 2/3] Allow storing more info about each frequency
On 08/15/2017 10:36 AM, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> This adds flags field which may be used to mark frequency not available
> under some conditions.
>
> Signed-off-by: Rafał Miłecki
Acked-by: Jo-Philipp Wich
> ---
> include/iwinfo.h | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/include/iwinfo.h b/include/iwinfo.h
> index bb2b20a..a5cafa9 100644
> --- a/include/iwinfo.h
> +++ b/include/iwinfo.h
> @@ -48,6 +48,13 @@
> #define IWINFO_AUTH_SHARED (1 << 1)
> #define IWINFO_AUTH_COUNT2
>
> +#define IWINFO_FREQ_NO_10MHZ (1 << 0)
> +#define IWINFO_FREQ_NO_20MHZ (1 << 1)
> +#define IWINFO_FREQ_NO_HT40PLUS (1 << 2)
> +#define IWINFO_FREQ_NO_HT40MINUS (1 << 3)
> +#define IWINFO_FREQ_NO_80MHZ (1 << 4)
> +#define IWINFO_FREQ_NO_160MHZ(1 << 5)
> +
> extern const char *IWINFO_CIPHER_NAMES[IWINFO_CIPHER_COUNT];
> extern const char *IWINFO_KMGMT_NAMES[IWINFO_KMGMT_COUNT];
> extern const char *IWINFO_AUTH_NAMES[IWINFO_AUTH_COUNT];
> @@ -126,6 +133,7 @@ struct iwinfo_freqlist_entry {
> uint8_t channel;
> uint32_t mhz;
> uint8_t restricted;
> + uint32_t flags;
> };
>
> struct iwinfo_crypto_entry {
>
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH iwinfo 3/3] nl80211: store info about freq being not available for some bandwidths
On 08/15/2017 10:36 AM, Rafał Miłecki wrote: > From: Rafał Miłecki > > Signed-off-by: Rafał Miłecki Acked-by: Jo-Philipp Wich > --- > iwinfo_nl80211.c | 13 + > 1 file changed, 13 insertions(+) > > diff --git a/iwinfo_nl80211.c b/iwinfo_nl80211.c > index f9b13dd..718e111 100644 > --- a/iwinfo_nl80211.c > +++ b/iwinfo_nl80211.c > @@ -2401,6 +2401,19 @@ static int nl80211_get_freqlist_cb(struct nl_msg *msg, > void *arg) > > !freqs[NL80211_FREQUENCY_ATTR_RADAR] > ) ? 1 : 0; > > + if > (freqs[NL80211_FREQUENCY_ATTR_NO_HT40_MINUS]) > + e->flags |= > IWINFO_FREQ_NO_HT40MINUS; > + if > (freqs[NL80211_FREQUENCY_ATTR_NO_HT40_PLUS]) > + e->flags |= > IWINFO_FREQ_NO_HT40PLUS; > + if > (freqs[NL80211_FREQUENCY_ATTR_NO_80MHZ]) > + e->flags |= > IWINFO_FREQ_NO_80MHZ; > + if > (freqs[NL80211_FREQUENCY_ATTR_NO_160MHZ]) > + e->flags |= > IWINFO_FREQ_NO_160MHZ; > + if > (freqs[NL80211_FREQUENCY_ATTR_NO_20MHZ]) > + e->flags |= > IWINFO_FREQ_NO_20MHZ; > + if > (freqs[NL80211_FREQUENCY_ATTR_NO_10MHZ]) > + e->flags |= > IWINFO_FREQ_NO_10MHZ; > + > e++; > arr->count++; > } > ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH iwinfo 1/3] nl80211: support receiving split frequencies
On 08/15/2017 10:36 AM, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> In order to get more details about each frequency we will need to set
> NL80211_ATTR_SPLIT_WIPHY_DUMP in the future. This will result in our
> callback being called multiple times. Modify it to support such a
> scenario:
> 1) Start putting new frequencies after the last set one
> 2) Make sure that attribute is set before iterating it
>
> Signed-off-by: Rafał Miłecki
Acked-by: Jo-Philipp Wich
> ---
> iwinfo_nl80211.c | 45 ++---
> 1 file changed, 26 insertions(+), 19 deletions(-)
>
> diff --git a/iwinfo_nl80211.c b/iwinfo_nl80211.c
> index db0fc42..f9b13dd 100644
> --- a/iwinfo_nl80211.c
> +++ b/iwinfo_nl80211.c
> @@ -2367,37 +2367,44 @@ static int nl80211_get_freqlist_cb(struct nl_msg
> *msg, void *arg)
> int bands_remain, freqs_remain;
>
> struct nl80211_array_buf *arr = arg;
> - struct iwinfo_freqlist_entry *e = arr->buf;
> + struct iwinfo_freqlist_entry *e;
>
> struct nlattr **attr = nl80211_parse(msg);
> struct nlattr *bands[NL80211_BAND_ATTR_MAX + 1];
> struct nlattr *freqs[NL80211_FREQUENCY_ATTR_MAX + 1];
> struct nlattr *band, *freq;
>
> - nla_for_each_nested(band, attr[NL80211_ATTR_WIPHY_BANDS], bands_remain)
> - {
> - nla_parse(bands, NL80211_BAND_ATTR_MAX,
> - nla_data(band), nla_len(band), NULL);
> + e = arr->buf;
> + e += arr->count;
>
> - nla_for_each_nested(freq, bands[NL80211_BAND_ATTR_FREQS],
> freqs_remain)
> + if (attr[NL80211_ATTR_WIPHY_BANDS]) {
> + nla_for_each_nested(band, attr[NL80211_ATTR_WIPHY_BANDS],
> bands_remain)
> {
> - nla_parse(freqs, NL80211_FREQUENCY_ATTR_MAX,
> - nla_data(freq), nla_len(freq), NULL);
> + nla_parse(bands, NL80211_BAND_ATTR_MAX,
> + nla_data(band), nla_len(band), NULL);
>
> - if (!freqs[NL80211_FREQUENCY_ATTR_FREQ] ||
> - freqs[NL80211_FREQUENCY_ATTR_DISABLED])
> - continue;
> + if (bands[NL80211_BAND_ATTR_FREQS]) {
> + nla_for_each_nested(freq,
> bands[NL80211_BAND_ATTR_FREQS], freqs_remain)
> + {
> + nla_parse(freqs,
> NL80211_FREQUENCY_ATTR_MAX,
> + nla_data(freq), nla_len(freq),
> NULL);
>
> - e->mhz =
> nla_get_u32(freqs[NL80211_FREQUENCY_ATTR_FREQ]);
> - e->channel = nl80211_freq2channel(e->mhz);
> + if (!freqs[NL80211_FREQUENCY_ATTR_FREQ]
> ||
> + freqs[NL80211_FREQUENCY_ATTR_DISABLED])
> + continue;
>
> - e->restricted = (
> - freqs[NL80211_FREQUENCY_ATTR_NO_IR] &&
> - !freqs[NL80211_FREQUENCY_ATTR_RADAR]
> - ) ? 1 : 0;
> + e->mhz =
> nla_get_u32(freqs[NL80211_FREQUENCY_ATTR_FREQ]);
> + e->channel =
> nl80211_freq2channel(e->mhz);
>
> - e++;
> - arr->count++;
> + e->restricted = (
> +
> freqs[NL80211_FREQUENCY_ATTR_NO_IR] &&
> +
> !freqs[NL80211_FREQUENCY_ATTR_RADAR]
> + ) ? 1 : 0;
> +
> + e++;
> + arr->count++;
> + }
> + }
> }
> }
>
>
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] About /etc/board.json
Hi Gio, > - Should we consider this stable? Yes. > - Is there some specification on how to write a board.json file for > new hardware? Right now the specification is the code in package/base-files/files/lib/functions/uci-defaults.sh > - From what I saw on devices I have under my hands the board.json > file doesn't come in the source code, but is generated by the old > scripts with all the hardware model big switch/case, is this to be > considered final or it is just a transition to shipping the > board.json file without the big switch/case? Consider this a transitional mechanism, eventually the per-device rootfs feature will allow to embed static board.json files directly into the image, however this is not the case yet. > - About switch ports in a TP-Link tl-wdr4310 I can see that port 0 > has different properties that other ports, like +"device": "eth0"+ > can we consider this equivalent to "the switch is connected to the > CPU via port 0 and it is seen as eth0" in all cases? Yes. Ports with a "device" attribute are "CPU ports". Keep in mind that there might be multiple like 0 @ eth0 and 8 @ eth1. > - How would board.json look like in case two switch chips are > present, can each switch have a port connected to the other switch > beside the one connected to the CPU? Not sure if I understand the question correctly but the few supported multi-switch devices I know do not have interconnected ports, they're simply two distinct switches with distinct CPU ports hooked to distinct netdevs. In order to join these switches, you'd have to software-bridge their CPU port vlan devices. > How would board.json look like if the other switch is connected only > to the other switch and not to the CPU? There exists no such case iirc and there likely never will be one in the future as the upcoming DSA architecture does not really support "unconnected" switches. > How would board.json look like if the other switch is connected to > the CPU only (this last seems simple to answhere)? See attached example.json > - In the TP-Link tl-wdr3500 there is a separate ethernet port eth1 > that is used as wan, in the board.json the only reference that i find > to that port is as network.wan.ifname That would be the authoritative source for "which netdev is expected to serve as wan port". > but there is not something like an "hardware description" like we > have for the switch section, is there any plan to inlude those extra > info like if it is gigabit, or the max MTU supported in board.json There are no such plans > or we have to guess the existence of ethernet ports iterating trought > the childs of network ? Yes. > - There is no information about wifi devices, also in cases they are > soldered in the device, is there a plan to include that information > in board.json too or there is another place where one can get in > wifi devices information in an equivalent format (JSON)? Either via "ubus call network.wireless status" or the iwinfo library bindings. > - There is already a JSON parsing/generation Lua library of choice > in LEDE? (I suppose there is at least in Luci) Package "luci-lib-jsonc" - despite its name it is mostly standalone, only depending on liblua and libjson-c. API docs at http://htmlpreview.github.io/?http://raw.githubusercontent.com/openwrt/luci/master/documentation/api/modules/luci.jsonc.html Regards, Jo example.json Description: application/json ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Lots of snapshot packages not building
Hi, this has been fixed with https://git.lede-project.org/9e64874fb2508e49e52898c238d817bd152bf2c2 and will propagate to the builders within the next two to three days. ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] build system question
Hi Torbjorn, use the IGNORE_ERRORS flag when invoking make: make ... IGNORE_ERRORS="n m" This will cause the build system to skip failing packages which are not marked builtin. ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH][ubox] Fixes log read starvation issue after threshold reached
Hi Ron,
thanks for your effort in sharing your fixes.
I have troubles understanding your patch, please find some comments
inline below.
~ Jo
--
On 07/11/2017 09:04 PM, Ron Brash wrote:
> This patch fixes a logread starvation error, which occurs after many
> logs are generated (around 16k if defaults are used). The log read
Do you have an easy test case for this? Is piping ~16K plaintext to the
logger enough to trigger the starvation? I'd like to understand the
problem some more before judging the patch.
> process seems to halt silently and yet continues running. A restart
> of the log services fixes it.
>
> This is problematic because logs should be logged, instead of silently lost
>
> Signed-off-by: “Ron Brash <“ron.br...@gmail.com”>
> ---
> log/logread.c | 24 ++--
> 1 file changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/log/logread.c b/log/logread.c
> index edac1d9..7eb028e 100644
> --- a/log/logread.c
> +++ b/log/logread.c
> @@ -230,8 +230,10 @@ static void logread_fd_data_cb(struct ustream *s,
> int bytes)
> break;
>
> cur_len = blob_len(a) + sizeof(*a);
> - if (len < cur_len)
> + if (len < cur_len) {
> + ustream_consume(s, len);
> break;
> + }
>
> log_notify(a);
> ustream_consume(s, cur_len);
> @@ -240,14 +242,28 @@ static void logread_fd_data_cb(struct ustream
> *s, int bytes)
> uloop_end();
> }
>
> +static void notify_fd_remove_cb();
If you move the static function here you do not need the forward
declaration.
> +
> static void logread_fd_cb(struct ubus_request *req, int fd)
> {
> static struct ustream_fd test_fd;
> -
> + uloop_register_notify_fd_remove(fd, notify_fd_remove_cb);
What is "uloop_register_notify_fd_remove()" ? It is not part of libubox
as far as I can see. Is it a function introduced by some other custom
changes of yours?
> test_fd.stream.notify_read = logread_fd_data_cb;
> ustream_fd_init(&test_fd, fd);
> }
>
> +struct ubus_context *context;
> +uint32_t ctx_id;
> +struct blob_buf * bb;
> +struct ubus_request request;
The "request" and "ctx_id" variables appear to be local to
"notify_fd_remove_cb()" and should be moved inside the function.
The "context" and "bb" variables should be declared "static" if they're
outside of the function context, however I am not sure if we actually
need them because those values can be usually obtained elsewhere in the
callback.
> +
> +static void notify_fd_remove_cb() {
> + ubus_lookup_id(context, "log", &ctx_id);
> + ubus_invoke_async(context, ctx_id, "read", bb->head, &request);
> + request.fd_cb = logread_fd_cb;
> + ubus_complete_request_async(context, &request);
> +}
> +
> int main(int argc, char **argv)
> {
> static struct ubus_request req;
> @@ -362,6 +378,9 @@ int main(int argc, char **argv)
> sender.fd = STDOUT_FILENO;
> }
>
> + context = ctx;
> + bb = &b;
> +
> ubus_invoke_async(ctx, id, "read", b.head, &req);
> req.fd_cb = logread_fd_cb;
> ubus_complete_request_async(ctx, &req);
> @@ -374,3 +393,4 @@ int main(int argc, char **argv)
>
> return ret;
> }
> +
> --
> 2.7.4
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
>
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] sysupgrade broken on brcm47xx
Hi, I think you're supposed to use "lede-brcm47xx-legacy-standard-squashfs.trx". ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] fstools fixes backport to lede-17.01
Hi Daniel, ack from me. ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Merged: openvpn: update to 2.4.3
Merged into my staging tree with http://git.lede-project.org/?p=lede/jow/staging.git;a=commitdiff;h=b671d3a0e1. Thank you! ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Merged: mbedtls: update to 2.5.1
Merged into my staging tree with http://git.lede-project.org/?p=lede/jow/staging.git;a=commitdiff;h=53527bcda9. Thank you! ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] uhttpd: fix PKG_BUILD_DEPENDS
Hi, that fix seems wrong to me as build depends must specify source packages. This should be solved in buildroot instead. ~ Jo > Am 22.06.2017 um 02:07 schrieb Daniel Golle : > > uhttpd refered to ustream-ssl as PKG_BUILD_DEPENDS. While this > intuitively seems like the correct thing to do, it turns out not to > have the desired effect: PKG_BUILD_DEPENDS needs to list the resulting > package name (ie. one of libustream-*) and not the source package name. > This seems a bit ugly, as PKG_BUILD_DEPENDS should actually really > reference source package names if you asked me. > However, to fix things for now, use libustream-mbedtls to fix > scripts/feeds and parallel builds which otherwise fail to build uhttpd. > > Reported-by: Paul Spooren > Signed-off-by: Daniel Golle > --- > package/network/services/uhttpd/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/package/network/services/uhttpd/Makefile > b/package/network/services/uhttpd/Makefile > index 3d483b692d..12896a1bb2 100644 > --- a/package/network/services/uhttpd/Makefile > +++ b/package/network/services/uhttpd/Makefile > @@ -18,7 +18,7 @@ > PKG_MIRROR_HASH:=2ac4ba8dc0b349d72174aac9ff693a73a214295a9890fe3d2a8eedcad54d06e > PKG_MAINTAINER:=Felix Fietkau > PKG_LICENSE:=ISC > > -PKG_BUILD_DEPENDS = ustream-ssl > +PKG_BUILD_DEPENDS = libustream-mbedtls > > include $(INCLUDE_DIR)/package.mk > include $(INCLUDE_DIR)/cmake.mk > -- > 2.13.1 > > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] procd: cherry-pick fixes into lede-17.01 branch
Allright, disregard my statement then and sorry for the short attention span. ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] procd: cherry-pick fixes into lede-17.01 branch
Hi, in principle I do not have any objections but I am not sure if we should really backport the sysupgrade changes yet. Are we sure that thestaged sysupgrade works as intended and was it properly tested? ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] tagged vlans on a TP-Link 841n v9
Hi. Please make a screenshot of your settings or paste the generated /etc/config/network here. Also consider doing the switch config via wireless, this allows for simpler recovery after a config mistake. ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Planning v17.01.2
Hi, > ... and, if I may throw my EUR 0.02 in, why not recompile dropbear > with "elliptic curve" support? whats the size impact? ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Merged: [LEDE-DEV,
Merged into my staging tree with http://git.lede-project.org/?p=lede/jow/staging.git;a=commitdiff;h=34e8aff93d. Thank you! ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Merged: ath10k-ct driver: use dma_alloc_coherent
Merged into my staging tree with http://git.lede-project.org/?p=lede/jow/staging.git;a=commitdiff;h=3b21c68e5f. Thank you! ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Merged: samba: Remove a few redundant options from the default
Merged into my staging tree with http://git.lede-project.org/?p=lede/jow/staging.git;a=commitdiff;h=744380bb74. Thank you! ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Merged: samba: remove browse/write able entries
Merged into my staging tree with http://git.lede-project.org/?p=lede/jow/staging.git;a=commitdiff;h=8a65d24691. Thank you! ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] openwrt and lede - remerge proposal V3
Hi, NACK from me - not that it makes a difference but I do not like to operate under the OpenWrt name. ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] LEDE v17.01.2 service release
The LEDE Community is proud to announce the second service release of stable LEDE 17.01 series. LEDE 17.01.2 "Reboot" incorporates a fair number of fixes back ported from the development branch during the last seven weeks. --- Some selected highlights of the service release are: * Linux kernel updated to version 4.4.71 (from 4.4.61 in v17.01.1) * Fixed TX power limit handling of ath9k * Various fixes to the rt2x00 wireless driver * Various fixes to odhcpd * Various fixes to firewall * Security fixes to vulnerabilities in Samba, Dropbear, OpenVPN and Linux kernel * Assorted platform fixes for ar71xx, bcm53xx, brcm63xx, ipq806x, lantiq, ramips and x86 For a detailed list of changes since 17.01.1 refer to https://lede-project.org/releases/17.01/changelog-17.01.2 --- For latest information about the 17.01 series, refer to the wiki at: https://lede-project.org/releases/17.01/ To download the v17.01.2 images, navigate to: https://downloads.lede-project.org/releases/17.01.2/ --- As always, a big thank you goes to all our active package maintainers, testers, documenters and supporters. Have fun! The LEDE Community ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Merged: Add missing APU1 reference to x86 board.d
Merged into my staging tree with http://git.lede-project.org/?p=lede/jow/staging.git;a=commitdiff;h=3f3d68c6f2. Thank you! ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Planning v17.01.2
Hi, I decided to delay 17.01.2 by another week to wait for Kernel 4.4.71 getting released which will fix a number of networking related vulnerabilities. The currently projected release date is Saturday, the 10th. Regards, Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Merged: dnsmasq: bump to 2.77
Merged into my staging tree with http://git.lede-project.org/?p=lede/jow/staging.git;a=commitdiff;h=88a52db822. Thank you! ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] dnsmasq: please revert/disable "dhcp-script" feature by default
Hi Dirk, the info reported by "top" (or "ps") is not useful to judge effective process memory usage, it does not account for c-o-w and simply displays the entire virtual allocated memory by a process. When I was asking for specific evidence I was thinking along the lines of OOM conditions that didn't happen before the change and other similar symptoms like that. Unfortunately the LEDE kernels do not provide /proc/$pid/smaps information which would make tracking actual memory usage way simpler but here's some useful links nonetheless which explain the topic a bit further: https://serverfault.com/questions/440115/how-do-you-measure-the-memory-footprint-of-a-set-of-forked-processes https://jameshunt.us/writings/smaps.html Regards, Jo signature.asc Description: OpenPGP digital signature ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
