[LEDE-DEV] firewall: flood protection feature

2017-05-19 Thread Alin Năstac 
Hi Jo,

I need to add  flood protection feature to firewall.

The ratelimit section parameters would be: proto, src_port, dest_port,
family, global_limit, global_burst, per_srcip_limit, per_srcip_burst,
per_srcip_mask, per_srcip_buckets. These rules will have effect on a
raw table user chain called ratelimits, linked with PREROUTING chain
and populated with rules such as these:
  iptables -t raw -A ratelimits -p ... -m hashlimit --hashlimit-mode
srcip --hashlimit-name 
--hashlimit-above /second --hashlimit-burst
 --hashlimit-htable-size  -j DROP
  iptables -t raw -A ratelimits -p ... -m limit --limit
/second --limit-burst  -j RETURN
  iptables -t raw -A ratelimits -p ... -j DROP

Would you be interested in such feature? If the answer is yes I will
prepare a firewall patch, otherwise I will have to implement it in the
form of a firewall script.

Cheers,
Alin

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

[LEDE-DEV] [PATCH] dnsmasq: write resolv.conf also when noresolv = 1

2017-05-19 Thread Paul Oranje 
When UCI dhcp.dnsmasq.noresolv is true, dnsmasq ignores the (wan) resolv.conf
for upstream name resolution and the dnsmasq init script ialso skips writing
/tmp/resolv.conf (/etc/resolv.conf soft links that file).

Not using the local running DNS service when noresolv is true does not make
sence; the semantics of that config value do not imply this. With this patch
the init script also writes /tmp/resolv.conf when noresolv is true.

fixes FS#785

Signed-off-by: Paul Oranje 
---
This patch replaces an earlier patch with subject
  dnsmasq: also write /tmp/resolv.conf when UCI dhcp.dnsmasq.noresolv is '1'
which is obsoleted because that subject was required to be shorter.
---
 package/network/services/dnsmasq/files/dnsmasq.init | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
b/package/network/services/dnsmasq/files/dnsmasq.init
index 30fec7a4ee..197aae9de1 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -947,7 +947,7 @@ dnsmasq_start()
echo >> $CONFIGFILE_TMP
mv -f $CONFIGFILE_TMP $CONFIGFILE
 
-   [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
+   [ "$noresolv" = "1" -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
rm -f /tmp/resolv.conf
[ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
echo "search $DOMAIN" >> /tmp/resolv.conf
@@ -982,7 +982,7 @@ dnsmasq_stop()
config_get resolvfile "$cfg" "resolvfile"
 
#relink /tmp/resolve.conf only for main instance
-   [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
+   [ "$noresolv" = "1" -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
[ -f /tmp/resolv.conf ] && {
rm -f /tmp/resolv.conf
ln -s "$resolvfile" /tmp/resolv.conf
-- 
2.13.0


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

Re: [LEDE-DEV] [PATCH v5] dnsmasq: also write /tmp/resolv.conf when UCI dhcp.dnsmasq.noresolv is '1'

2017-05-19 Thread Hans Dedecker 
On Fri, May 19, 2017 at 4:13 PM, Paul Oranje  wrote:
> Question: when the subject is changed in order the make it less than 50 
> characters long, does that result in a distinct new patch ?
> Paul
Yes that results into a new distinct patch in patchwork

Hans
>
>> Op 19 mei 2017, om 12:58 heeft Paul Oranje  het volgende 
>> geschreven:
>>
>> Oké, I’ll submit another version with the requested changes later today.
>> This trivial change is turning out a ping pong lesson. Thanks anyway,
>> Paul
>>
>>
>>> Op 18 mei 2017, om 16:53 heeft Hans Dedecker  het 
>>> volgende geschreven:
>>>
>>> On Sun, May 14, 2017 at 8:22 PM, Paul Oranje  wrote:

 fixes FS#785

>>> Hi,
>>>
>>> Thanks for the patch but be more verbose in the comment description
>>> what problem you're trying to solve; the commit subject should be
>>> limited to 50 characters.
>>> See also https://lede-project.org/submitting-patches

 Signed-off-by: Paul Oranje 
 ---
 package/network/services/dnsmasq/files/dnsmasq.init | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
 b/package/network/services/dnsmasq/files/dnsmasq.init
 index 30fec7a4ee..197aae9de1 100644
 --- a/package/network/services/dnsmasq/files/dnsmasq.init
 +++ b/package/network/services/dnsmasq/files/dnsmasq.init
 @@ -947,7 +947,7 @@ dnsmasq_start()
   echo >> $CONFIGFILE_TMP
   mv -f $CONFIGFILE_TMP $CONFIGFILE

 -   [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
 +   [ "$noresolv" = "1" -o "$resolvfile" = "/tmp/resolv.conf.auto" ] 
 && {
   rm -f /tmp/resolv.conf
   [ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
   echo "search $DOMAIN" >> /tmp/resolv.conf
 @@ -982,7 +982,7 @@ dnsmasq_stop()
   config_get resolvfile "$cfg" "resolvfile"

   #relink /tmp/resolve.conf only for main instance
 -   [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
 +   [ "$noresolv" = "1" -o "$resolvfile" = "/tmp/resolv.conf.auto" ] 
 && {
>>> noresolv needs to be read from the config which is not the case
   [ -f /tmp/resolv.conf ] && {
   rm -f /tmp/resolv.conf
   ln -s "$resolvfile" /tmp/resolv.conf
>>> this will generate an error now if resolvfile is empty
 --
 2.12.2


 ___
 Lede-dev mailing list
 Lede-dev@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/lede-dev
>>>
>>> Hans
>>>
>>> ___
>>> 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
>

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

[LEDE-DEV] [PATCH 2/2] mac80211: add support for rtl8821ae pcie adapter

2017-05-19 Thread Hans Ulli Kroll 
Add support for Realtek RTL8821AE/RTL8812AE PCIe adapter.
This device supports 802.11ac and bluetooth

testet on PC Engines APU with AP and STA mode

Signed-off-by: Hans Ulli Kroll 
---
 package/kernel/mac80211/Makefile | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/package/kernel/mac80211/Makefile b/package/kernel/mac80211/Makefile
index fb72a892f9..71aae89360 100644
--- a/package/kernel/mac80211/Makefile
+++ b/package/kernel/mac80211/Makefile
@@ -42,8 +42,8 @@ PKG_DRIVERS = \
rt2800-lib rt2800-mmio rt2800-pci rt2800-soc rt2800-usb \
rt61-pci rt73-usb \
rtl8180 rtl8187 \
-   rtlwifi rtlwifi-pci rtlwifi-usb rtl8192c-common rtl8192ce rtl8192se \
-   rtl8192de rtl8192cu \
+   rtlwifi rtlwifi-pci rtlwifi-btcoexist rtlwifi-usb rtl8192c-common \
+   rtl8192ce rtl8192se rtl8192de rtl8192cu rtl8821ae \
rtl8xxxu \
wlcore wl12xx wl18xx \
zd1211rw
@@ -1314,6 +1314,15 @@ define KernelPackage/rtlwifi-pci
   HIDDEN:=1
 endef
 
+define KernelPackage/rtlwifi-btcoexist
+  $(call KernelPackage/mac80211/Default)
+  TITLE:=Realtek BT coexist support
+  DEPENDS+= +kmod-rtlwifi
+  
FILES:=$(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtlwifi/btcoexist/btcoexist.ko
+  AUTOLOAD:=$(call AutoProbe,btcoexist)
+  HIDDEN:=1
+endef
+
 define KernelPackage/rtlwifi-usb
   $(call KernelPackage/mac80211/Default)
   TITLE:=Realtek common driver part (USB support)
@@ -1363,6 +1372,13 @@ define KernelPackage/rtl8192cu
   AUTOLOAD:=$(call AutoProbe,rtl8192cu)
 endef
 
+define KernelPackage/rtl8821ae
+  $(call KernelPackage/mac80211/Default)
+  TITLE:=Realtek RTL8821AE support
+  DEPENDS+= +kmod-rtlwifi-btcoexist +kmod-rtlwifi-pci +rtl8821ae-firmware
+  FILES:= 
$(PKG_BUILD_DIR)/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/rtl8821ae.ko
+  AUTOLOAD:=$(call AutoProbe,rtl8821ae)
+endef
 
 define KernelPackage/rtl8xxxu
   $(call KernelPackage/mac80211/Default)
@@ -1627,12 +1643,14 @@ config-$(call config_package,zd1211rw) += ZD1211RW
 
 config-$(call config_package,rtlwifi) += RTL_CARDS RTLWIFI
 config-$(call config_package,rtlwifi-pci) += RTLWIFI_PCI
+config-$(call config_package,rtlwifi-btcoexist) += RTLBTCOEXIST
 config-$(call config_package,rtlwifi-usb) += RTLWIFI_USB
 config-$(call config_package,rtl8192c-common) += RTL8192C_COMMON
 config-$(call config_package,rtl8192ce) += RTL8192CE
 config-$(call config_package,rtl8192se) += RTL8192SE
 config-$(call config_package,rtl8192de) += RTL8192DE
 config-$(call config_package,rtl8192cu) += RTL8192CU
+config-$(call config_package,rtl8821ae) += RTL8821AE
 config-$(CONFIG_PACKAGE_RTLWIFI_DEBUG) += RTLWIFI_DEBUG
 
 config-$(call config_package,rtl8xxxu) += RTL8XXXU
@@ -1835,12 +1853,14 @@ $(eval $(call KernelPackage,rtl8180))
 $(eval $(call KernelPackage,rtl8187))
 $(eval $(call KernelPackage,rtlwifi))
 $(eval $(call KernelPackage,rtlwifi-pci))
+$(eval $(call KernelPackage,rtlwifi-btcoexist))
 $(eval $(call KernelPackage,rtlwifi-usb))
 $(eval $(call KernelPackage,rtl8192c-common))
 $(eval $(call KernelPackage,rtl8192ce))
 $(eval $(call KernelPackage,rtl8192se))
 $(eval $(call KernelPackage,rtl8192de))
 $(eval $(call KernelPackage,rtl8192cu))
+$(eval $(call KernelPackage,rtl8821ae))
 $(eval $(call KernelPackage,rtl8xxxu))
 $(eval $(call KernelPackage,wlcore))
 $(eval $(call KernelPackage,wl12xx))
-- 
2.13.0


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

[LEDE-DEV] [PATCH 1/2] firmware: add firmware for rtl8821ae support

2017-05-19 Thread Hans Ulli Kroll via Lede-dev 
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
add needed firmware to support rtl8821ae pcie adapter

Signed-off-by: Hans Ulli Kroll 
---
 package/firmware/linux-firmware/realtek.mk | 8 
 1 file changed, 8 insertions(+)

diff --git a/package/firmware/linux-firmware/realtek.mk 
b/package/firmware/linux-firmware/realtek.mk
index 8c3770eeea..fdd92c9a42 100644
--- a/package/firmware/linux-firmware/realtek.mk
+++ b/package/firmware/linux-firmware/realtek.mk
@@ -55,3 +55,11 @@ define Package/rtl8192su-firmware/install
$(INSTALL_DATA) $(PKG_BUILD_DIR)/rtlwifi/rtl8712u.bin 
$(1)/lib/firmware/rtlwifi
 endef
 $(eval $(call BuildPackage,rtl8192su-firmware))
+
+Package/rtl8821ae-firmware = $(call Package/firmware-default,RealTek RTL8821AE 
firmware)
+define Package/rtl8821ae-firmware/install
+   $(INSTALL_DIR) $(1)/lib/firmware/rtlwifi
+   $(INSTALL_DATA) $(PKG_BUILD_DIR)/rtlwifi/rtl8821aefw.bin 
$(1)/lib/firmware/rtlwifi
+   $(INSTALL_DATA) $(PKG_BUILD_DIR)/rtlwifi/rtl8821aefw_wowlan.bin 
$(1)/lib/firmware/rtlwifi
+endef
+$(eval $(call BuildPackage,rtl8821ae-firmware))
-- 
2.13.0


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

Re: [LEDE-DEV] [PATCH v2 00/19] Universal staged sysupgrade and assorted fixes

2017-05-19 Thread Lucian Cristian 

On 13.05.2017 22:56, Matthias Schiffer wrote:

Text from my RFC mail:

---
When talking about
https://bugs.lede-project.org/index.php?do=details_id=685 with jow
and lynxis, we came to the conclusion that the best way to fix sysupgrades
would be to generalize the staged sysupgrade used on NAND devices to work
on all targets. That is what this patchset does, with some nice extras
like staged sysupgrade support from failsafe mode (which did not work at
all on NAND devices before).

I have tested these patches on ar71xx (squashfs+jffs2), ramips (squashfs+
ubifs) and x86 (ext4), and they seems to work perfectly; they should be
tested on a lot more targets before they are applied though.

The same patchset can be found the "sysupgrade" branch of my staging tree
at https://git.lede-project.org/?p=lede/neoraider/staging.git;a=summary

Note: the diffstat looks a lot scarier than it should; most of the added
lines are the procd patches that I have included in the LEDE repo for now
to facilitate testing the series.
---

Some highlights of v2:
* split whitespace fixes into separate patches
* add missing include guards to new procd header sysupgrade.h
* support sysupgrade -p again (suggested by from Daniel Golle)
* various x86 sysupgrade fixes (now sysupgrade with growing kernel
  partition actually works)
* apply x86 sysupgrade fixes to sunxi as well

It would be great if someone with access to sunxi hardware could test my
changes, the sunxi patches were not tested at all.

Thanks for the feedback I got so far.

Matthias


Matthias Schiffer (19):
   procd: clean up trailing whitespace in nand.sh
   procd: prepare NAND sysupgrade for making upgraded dynamically linked
   procd: system: always support staged sysupgrade
   procd: upgraded: link dynamically, chroot during exec
   procd: upgraded: add support for passing a "command" argument to
 stage2
   procd: remove procd-nand package
   base-files: always use staged sysupgrade
   fstools: clean up trailing whitespace in snapshot script
   fstools: snapshot: handle jffs2 conversion using upgraded
   procd: remove code that has become unnecessary after sysupgrade
 changes
   procd: init: add support for sysupgrades triggered from preinit
   base-files: sysupgrade cleanup
   base-files: add support for staged sysupgrades from failsafe mode
   ramips: sysupgrade: move nand_do_upgrade call to platform_do_upgrade
   x86: sysupgrade: move partition table change check to
 platform_check_image
   x86: sysupgrade: refactor platform_do_upgrade
   x86: sysupgrade: explicitly rescan disk after writing partition table
   sunxi: sysupgrade: don't write partitions twice
   sunxi: sysupgrade: sync with x86

  package/base-files/Makefile|  13 +-
  .../files/lib/preinit/40_run_failsafe_hook |   6 +-
  .../files/lib/preinit/99_10_failsafe_login |  11 +-
  package/base-files/files/lib/upgrade/common.sh | 167 +++--
  .../files => base-files/files/lib/upgrade}/nand.sh |  63 +
  package/base-files/files/lib/upgrade/stage2| 149 +++
  package/base-files/files/sbin/sysupgrade   |  77 +++---
  package/system/fstools/Makefile|   2 +-
  package/system/fstools/files/snapshot  |  16 +-
  package/system/procd/Makefile  |  41 +--
  package/system/procd/files/nand-preinit.sh |  21 --
  ...1-system-always-support-staged-sysupgrade.patch | 112 +
  ...raded-link-dynamically-chroot-during-exec.patch | 231 +
  ...d-support-for-passing-a-command-argument-.patch | 104 
  ...-that-has-become-unnecessary-after-sysupg.patch | 120 +
  ...pport-for-sysupgrades-triggered-from-prei.patch | 278 +
  .../ramips/base-files/lib/upgrade/platform.sh  |   9 +-
  target/linux/sunxi/Makefile|   2 +-
  .../linux/sunxi/base-files/lib/upgrade/platform.sh | 120 +
  .../linux/x86/base-files/lib/upgrade/platform.sh   | 104 +---
  20 files changed, 1259 insertions(+), 387 deletions(-)
  rename package/{system/procd/files => base-files/files/lib/upgrade}/nand.sh 
(89%)
  create mode 100755 package/base-files/files/lib/upgrade/stage2
  delete mode 100644 package/system/procd/files/nand-preinit.sh
  create mode 100644 
package/system/procd/patches/0001-system-always-support-staged-sysupgrade.patch
  create mode 100644 
package/system/procd/patches/0002-upgraded-link-dynamically-chroot-during-exec.patch
  create mode 100644 
package/system/procd/patches/0003-upgraded-add-support-for-passing-a-command-argument-.patch
  create mode 100644 
package/system/procd/patches/0004-Remove-code-that-has-become-unnecessary-after-sysupg.patch
  create mode 100644 
package/system/procd/patches/0005-init-add-support-for-sysupgrades-triggered-from-prei.patch


Sunxi: Olimex A20-OLinuXino-LIME2

wrote the image to sdcard, setup something, used the same image as 
sysupgrade and everything went fine

Re: [LEDE-DEV] Toolchain/Buildroot requirements, testing and common lowest denominator?

2017-05-19 Thread Florian Fainelli 
On 05/19/2017 02:10 AM, Daniel Engberg wrote:
> Long story short:
> * Updated tools/sparse
> * Compiles fine on my side (Debian 8)
> * Blows up on buildbot (slave-lede-local) because it runs GCC 4.7 (lacks
> bswap, 4.8+ works according to
> https://sourceware.org/bugzilla/show_bug.cgi?id=20530)
> 
> Having a look at the buildbots, it shows that tictex-02 uses GCC 4.9
> (probably Debian 8) while slave-lede-local runs Debian 7 (LTS).
> I have on idea what the phase2 buildbots uses however as the web
> interface doesn't say.
> 
> However this bring my question about what we are targeting and what's
> the view on supported versions and common lowest denominator?
> 
> Version of base GCC on common distros, haven't looked at external packages:
> Debian 7 (LTS): 4.7
> Debian 8: 4.9
> RHEL/CentOS 7.3: 4.8
> Ubuntu 16.04.2 (LTS): 5.3.0
> Ubuntu 17.04: 6.3.0
> Arch Linux: 6.3.1
> Linux Mint 17.3: 4.8.4
> FreeBSD 10.3/11.0: 5.4.0 (default via ports)
> 
> We already have requirements for a few utils and libs so I don't think
> it's a huge deal in the end.
> https://github.com/lede-project/source/blob/master/include/prereq-build.mk#L17
> 
> This should probably be adjusted as it tests for really old versions of
> GCC etc.
> 
> While hacking in bswap in this case isn't an issue it however raises the
> question of what we want to support and for how long. Also, do we want
> unified buildbots? It's been mentioned on Github that some build bots
> doesn't support all download protocols or at least have issues with a
> few such as svn, I don't if that's the case anymore but do we have any
> guidelines for such setups? Bots also have different software installed
> meaning that some packages fails depending on bot, however I'm not sure
> if that applies to any of the current packages but it occurred in the
> past. Jo-Philipp Wich also pointed out on irc that using different
> versions also irons out bugs, while this is true it also adds a lot more
> of complexity to debugging. Perhaps we should try to have a unified
> setup first and have "experimental" bots later on if there's capacity?

Having experimental buildbots would be interesting if they were
representative, of e.g: next LTS Debian/Ubuntu release, if they are not,
then we should standardize so we have a larger unified compute power
that we can leverage for daily builds.

Regarding reproducing build bug reports reported by users, we can always
fire up containers/virtual machines to reproduce what users have and
over time, the number of distribution specific build issues should be
much much lower to the point where having experimental buildbots just
for that should not be worth it.

My 2 cents.
-- 
Florian

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

[LEDE-DEV] GSOC 2017 - Implement NetJSON output in ubus (OpenWRT/LEDE) - Progress Report 2

2017-05-19 Thread Arun Kumar 
Hi Mentors and Developer Community,

This is the 2nd week's progress report of the project:
Implement NetJSON output in ubus (OpenWRT/LEDE)

1. Refined the timeline of the proposal and updated.
2. CLI is made to support other inputs as in [1] but the backend
functions havent been implemented.
3. Efforts made to understand the json schema of SCAL plugin. Added
debugs inside the code to know more about the working of JSON schema.

To be done next week:
1. As per Felix's comment, make the ubus object to support those data
models which are not supported in the SCAL module. Efforts to
understand the scope of this in detail is required as its critical for
completion of the project.
2. Commit the code changes made till now to the github public repository.

[1] 
https://docs.google.com/document/d/1b6zersOA_GjUqbOjuaXvFd4E40l1MqUXjIyVagLLd08/edit?usp=sharing

Thanks,
Arun

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

Re: [LEDE-DEV] [PATCH v5] dnsmasq: also write /tmp/resolv.conf when UCI dhcp.dnsmasq.noresolv is '1'

2017-05-19 Thread Paul Oranje 
Question: when the subject is changed in order the make it less than 50 
characters long, does that result in a distinct new patch ?
Paul

> Op 19 mei 2017, om 12:58 heeft Paul Oranje  het volgende 
> geschreven:
> 
> Oké, I’ll submit another version with the requested changes later today.
> This trivial change is turning out a ping pong lesson. Thanks anyway,
> Paul
> 
> 
>> Op 18 mei 2017, om 16:53 heeft Hans Dedecker  het 
>> volgende geschreven:
>> 
>> On Sun, May 14, 2017 at 8:22 PM, Paul Oranje  wrote:
>>> 
>>> fixes FS#785
>>> 
>> Hi,
>> 
>> Thanks for the patch but be more verbose in the comment description
>> what problem you're trying to solve; the commit subject should be
>> limited to 50 characters.
>> See also https://lede-project.org/submitting-patches
>>> 
>>> Signed-off-by: Paul Oranje 
>>> ---
>>> package/network/services/dnsmasq/files/dnsmasq.init | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>> 
>>> diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
>>> b/package/network/services/dnsmasq/files/dnsmasq.init
>>> index 30fec7a4ee..197aae9de1 100644
>>> --- a/package/network/services/dnsmasq/files/dnsmasq.init
>>> +++ b/package/network/services/dnsmasq/files/dnsmasq.init
>>> @@ -947,7 +947,7 @@ dnsmasq_start()
>>>   echo >> $CONFIGFILE_TMP
>>>   mv -f $CONFIGFILE_TMP $CONFIGFILE
>>> 
>>> -   [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
>>> +   [ "$noresolv" = "1" -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && 
>>> {
>>>   rm -f /tmp/resolv.conf
>>>   [ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
>>>   echo "search $DOMAIN" >> /tmp/resolv.conf
>>> @@ -982,7 +982,7 @@ dnsmasq_stop()
>>>   config_get resolvfile "$cfg" "resolvfile"
>>> 
>>>   #relink /tmp/resolve.conf only for main instance
>>> -   [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
>>> +   [ "$noresolv" = "1" -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && 
>>> {
>> noresolv needs to be read from the config which is not the case
>>>   [ -f /tmp/resolv.conf ] && {
>>>   rm -f /tmp/resolv.conf
>>>   ln -s "$resolvfile" /tmp/resolv.conf
>> this will generate an error now if resolvfile is empty
>>> --
>>> 2.12.2
>>> 
>>> 
>>> ___
>>> Lede-dev mailing list
>>> Lede-dev@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>> 
>> Hans
>> 
>> ___
>> 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


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

Re: [LEDE-DEV] [PATCH v5] dnsmasq: also write /tmp/resolv.conf when UCI dhcp.dnsmasq.noresolv is '1'

2017-05-19 Thread Paul Oranje 
Oké, I’ll submit another version with the requested changes later today.
This trivial change is turning out a ping pong lesson. Thanks anyway,
Paul


> Op 18 mei 2017, om 16:53 heeft Hans Dedecker  het 
> volgende geschreven:
> 
> On Sun, May 14, 2017 at 8:22 PM, Paul Oranje  wrote:
>> 
>> fixes FS#785
>> 
> Hi,
> 
> Thanks for the patch but be more verbose in the comment description
> what problem you're trying to solve; the commit subject should be
> limited to 50 characters.
> See also https://lede-project.org/submitting-patches
>> 
>> Signed-off-by: Paul Oranje 
>> ---
>> package/network/services/dnsmasq/files/dnsmasq.init | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
>> b/package/network/services/dnsmasq/files/dnsmasq.init
>> index 30fec7a4ee..197aae9de1 100644
>> --- a/package/network/services/dnsmasq/files/dnsmasq.init
>> +++ b/package/network/services/dnsmasq/files/dnsmasq.init
>> @@ -947,7 +947,7 @@ dnsmasq_start()
>>echo >> $CONFIGFILE_TMP
>>mv -f $CONFIGFILE_TMP $CONFIGFILE
>> 
>> -   [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
>> +   [ "$noresolv" = "1" -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
>>rm -f /tmp/resolv.conf
>>[ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
>>echo "search $DOMAIN" >> /tmp/resolv.conf
>> @@ -982,7 +982,7 @@ dnsmasq_stop()
>>config_get resolvfile "$cfg" "resolvfile"
>> 
>>#relink /tmp/resolve.conf only for main instance
>> -   [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
>> +   [ "$noresolv" = "1" -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
> noresolv needs to be read from the config which is not the case
>>[ -f /tmp/resolv.conf ] && {
>>rm -f /tmp/resolv.conf
>>ln -s "$resolvfile" /tmp/resolv.conf
> this will generate an error now if resolvfile is empty
>> --
>> 2.12.2
>> 
>> 
>> ___
>> Lede-dev mailing list
>> Lede-dev@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
> 
> Hans
> 
> ___
> 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

[LEDE-DEV] Fwd: Re: convention on uid/gid for packages

2017-05-19 Thread Karl Palsson 
Resending to the list properly as planned...


I've modified one of my packages (mosquitto) to use the
autoassignment style, as it never cared about the actual uid/gid.

However, is this really the expected behaviour?

# cat /etc/passwd 
root:x:0:0:root:/root:/bin/ash
daemon:*:1:1:daemon:/var:/bin/false
ftp:*:55:55:ftp:/home/ftp:/bin/false
network:*:101:101:network:/var:/bin/false
nobody:*:65534:65534:nobody:/var:/bin/false
avahi:x:105:105:avahi:/var/run/avahi:/bin/false
dnsmasq:x:453:453:dnsmasq:/var/run/dnsmasq:/bin/false
mosquitto:x:100:102:mosquitto:/var/run/mosquitto:/bin/false <<<
100:102??


I know I don't care, but getting 100 for uid and 102 for gid
seems somewhat unexpected? Is it issuing ids from the same
sequence or something?

Sincerely,
Karl Palsson


Yousong Zhou  wrote:
> On 16 May 2017 at 00:02, Val Kulkov 
> wrote:
> > I agree that not depending on the manual cooperation across groups of
> > people would be ideal. However, updating 35+ packages to use the
> > auto-allocation mechanism is not an easy undertaking.
> 
> Updating 35+ packages is easy with a few lines of shell
> scripting.
> 
> > Besides, some of
> > the packages might actually rely on particular numeric uid/gid's - we
> > don't know until we run tests with these packages.
> 
> Thanks for the reminder. It feels secure that you know someone
> is watching your back. If the changes are to be made for good,
> we should of course fix those beforehand those we already know
> will break. As for the unknown, how bad and in what scale and
> how high the possibilities they will break?
> 
> >
> > Here is another suggestion. make menuconfig might collect all USERID:=
> > strings from all packages and produce a list of uids and gids that
> > have been taken so that the auto-allocation mechanism will stay away
> > from these uids/gids. Such lists will likely be fairly compact, taking
> > perhaps less than 500 bytes. This will (1) avoid conflicts between
> > packages, (2) avoid the need to re-do the uid/gid allocation for 35+
> > packages, and (3) not require manual cooperation between groups of
> > people in the future.
> >
> 
> Future posts may refer to this one as "these are legacies of a
> previous decision for historical reasons".
> 
> Thinking that we have talked too much and given enough
> proposals in this thread, I prepared a doc trying to do a quick
> sum up. Please give further comments there. Hopefully we can
> come to a conclusion and take actions thereafter.
> 
> https://docs.google.com/document/d/15kD_-9wCW5mjI8aJaCT03Uoxde3rrtCdZWcaz-5mEtA/edit?usp=sharing
> 
> Regards,
> yousong
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

signature.html
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH netifd] system-linux: parse 6rd specific settings as nested json data object

2017-05-19 Thread Hans Dedecker 
Parse 6rd specific settings prefix, relay-prefix as nested json data objects.
At the same time improve 6rd error handling.

Signed-off-by: Hans Dedecker 
---
 system-linux.c | 89 ++
 system.c   | 12 ++--
 system.h   |  7 +
 3 files changed, 76 insertions(+), 32 deletions(-)

diff --git a/system-linux.c b/system-linux.c
index ddc31d8..0ac4ae6 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -81,6 +81,9 @@ static struct nl_sock *sock_rtnl = NULL;
 
 static int cb_rtnl_event(struct nl_msg *msg, void *arg);
 static void handle_hotplug_event(struct uloop_fd *u, unsigned int events);
+static int system_add_proto_tunnel(const char *name, const uint8_t proto,
+   const unsigned int link, struct 
blob_attr **tb);
+static int __system_del_ip_tunnel(const char *name, struct blob_attr **tb);
 
 static char dev_buf[256];
 
@@ -2705,6 +2708,59 @@ failure:
 }
 #endif
 
+static int system_add_sit_tunnel(const char *name, const unsigned int link, 
struct blob_attr **tb)
+{
+   struct blob_attr *cur;
+   int ret = 0;
+
+   if (system_add_proto_tunnel(name, IPPROTO_IPV6, link, tb) < 0)
+   return -1;
+
+#ifdef SIOCADD6RD
+   if ((cur = tb[TUNNEL_ATTR_DATA])) {
+   struct blob_attr *tb_data[__SIXRD_DATA_ATTR_MAX];
+   unsigned int mask;
+   struct ip_tunnel_6rd p6;
+
+   blobmsg_parse(sixrd_data_attr_list.params, 
__SIXRD_DATA_ATTR_MAX, tb_data,
+   blobmsg_data(cur), blobmsg_len(cur));
+
+   memset(, 0, sizeof(p6));
+
+   if ((cur = tb_data[SIXRD_DATA_PREFIX])) {
+   if (!parse_ip_and_netmask(AF_INET6, blobmsg_data(cur),
+   , ) || mask > 
128) {
+   ret = -EINVAL;
+   goto failure;
+   }
+
+   p6.prefixlen = mask;
+   }
+
+   if ((cur = tb[SIXRD_DATA_RELAY_PREFIX])) {
+   if (!parse_ip_and_netmask(AF_INET, blobmsg_data(cur),
+   _prefix, ) || 
mask > 32) {
+   ret = -EINVAL;
+   goto failure;
+   }
+
+   p6.relay_prefixlen = mask;
+   }
+
+   if (tunnel_ioctl(name, SIOCADD6RD, ) < 0) {
+   ret = -1;
+   goto failure;
+   }
+   }
+#endif
+
+   return ret;
+
+failure:
+   __system_del_ip_tunnel(name, tb);
+   return ret;
+}
+
 static int system_add_proto_tunnel(const char *name, const uint8_t proto, 
const unsigned int link, struct blob_attr **tb)
 {
struct blob_attr *cur;
@@ -2853,37 +2909,10 @@ int system_add_ip_tunnel(const char *name, struct 
blob_attr *attr)
link = iface->l3_dev.dev->ifindex;
}
 
-   if (!strcmp(str, "sit")) {
-   if (system_add_proto_tunnel(name, IPPROTO_IPV6, link, tb) < 0)
-   return -1;
-
-#ifdef SIOCADD6RD
-   if ((cur = tb[TUNNEL_ATTR_6RD_PREFIX])) {
-   unsigned int mask;
-   struct ip_tunnel_6rd p6;
-
-   memset(, 0, sizeof(p6));
-
-   if (!parse_ip_and_netmask(AF_INET6, blobmsg_data(cur),
-   , ) || mask > 
128)
-   return -EINVAL;
-   p6.prefixlen = mask;
-
-   if ((cur = tb[TUNNEL_ATTR_6RD_RELAY_PREFIX])) {
-   if (!parse_ip_and_netmask(AF_INET, 
blobmsg_data(cur),
-   _prefix, 
) || mask > 32)
-   return -EINVAL;
-   p6.relay_prefixlen = mask;
-   }
-
-   if (tunnel_ioctl(name, SIOCADD6RD, ) < 0) {
-   __system_del_ip_tunnel(name, tb);
-   return -1;
-   }
-   }
-#endif
+   if (!strcmp(str, "sit"))
+   return system_add_sit_tunnel(name, link, tb);
 #ifdef IFLA_IPTUN_MAX
-   } else if (!strcmp(str, "ipip6")) {
+   else if (!strcmp(str, "ipip6")) {
struct nl_msg *nlm = nlmsg_alloc_simple(RTM_NEWLINK,
NLM_F_REQUEST | NLM_F_REPLACE | NLM_F_CREATE);
struct ifinfomsg ifi = { .ifi_family = AF_UNSPEC };
diff --git a/system.c b/system.c
index 3d4a979..bf3fd77 100644
--- a/system.c
+++ b/system.c
@@ -23,8 +23,6 @@ static const struct blobmsg_policy 
tunnel_attrs[__TUNNEL_ATTR_MAX] = {
[TUNNEL_ATTR_DF] = { .name = "df", .type = BLOBMSG_TYPE_BOOL },
[TUNNEL_ATTR_TTL] = { .name = "ttl",

[LEDE-DEV] Toolchain/Buildroot requirements, testing and common lowest denominator?

2017-05-19 Thread Daniel Engberg 

Long story short:
* Updated tools/sparse
* Compiles fine on my side (Debian 8)
* Blows up on buildbot (slave-lede-local) because it runs GCC 4.7 (lacks 
bswap, 4.8+ works according to 
https://sourceware.org/bugzilla/show_bug.cgi?id=20530)


Having a look at the buildbots, it shows that tictex-02 uses GCC 4.9 
(probably Debian 8) while slave-lede-local runs Debian 7 (LTS).
I have on idea what the phase2 buildbots uses however as the web 
interface doesn't say.


However this bring my question about what we are targeting and what's 
the view on supported versions and common lowest denominator?


Version of base GCC on common distros, haven't looked at external 
packages:

Debian 7 (LTS): 4.7
Debian 8: 4.9
RHEL/CentOS 7.3: 4.8
Ubuntu 16.04.2 (LTS): 5.3.0
Ubuntu 17.04: 6.3.0
Arch Linux: 6.3.1
Linux Mint 17.3: 4.8.4
FreeBSD 10.3/11.0: 5.4.0 (default via ports)

We already have requirements for a few utils and libs so I don't think 
it's a huge deal in the end.

https://github.com/lede-project/source/blob/master/include/prereq-build.mk#L17
This should probably be adjusted as it tests for really old versions of 
GCC etc.


While hacking in bswap in this case isn't an issue it however raises the 
question of what we want to support and for how long. Also, do we want 
unified buildbots? It's been mentioned on Github that some build bots 
doesn't support all download protocols or at least have issues with a 
few such as svn, I don't if that's the case anymore but do we have any 
guidelines for such setups? Bots also have different software installed 
meaning that some packages fails depending on bot, however I'm not sure 
if that applies to any of the current packages but it occurred in the 
past. Jo-Philipp Wich also pointed out on irc that using different 
versions also irons out bugs, while this is true it also adds a lot more 
of complexity to debugging. Perhaps we should try to have a unified 
setup first and have "experimental" bots later on if there's capacity?


Best regards,
Daniel

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

[LEDE-DEV] [PATCH][procd] ubus: use ubus_auto_connect() logic

2017-05-19 Thread Alexandru Ardelean 
Admittedly, the semantic is a bit different, in the sense
that there are no progressive retry timeouts.

ubus_auto_connect() uses 1 second fixed retry intervals.
Whereas the old logic would start at 50 millisecs and
progress up to 1 second.

Other than that, the rest should be the same overall logic.
This should cleanup the code a bit.

For reference, the `ubus_add_uloop()` call is handled
by ubus_auto_connect() as well.

Signed-off-by: Alexandru Ardelean 
---
 ubus.c | 55 +--
 1 file changed, 5 insertions(+), 50 deletions(-)

diff --git a/ubus.c b/ubus.c
index 8d521ac..5dd5452 100644
--- a/ubus.c
+++ b/ubus.c
@@ -20,68 +20,23 @@
 #include "procd.h"
 
 char *ubus_socket = NULL;
-static struct ubus_context *ctx;
-static struct uloop_timeout ubus_timer;
-static int timeout;
-
-static void reset_timeout(void)
-{
-   timeout = 50;
-}
-
-static void timeout_retry(void)
-{
-   uloop_timeout_set(_timer, timeout);
-   timeout *= 2;
-   if (timeout > 1000)
-   timeout = 1000;
-}
+static struct ubus_auto_conn conn;
 
 static void
-ubus_reconnect_cb(struct uloop_timeout *timeout)
+ubus_auto_connect_cb(struct ubus_context *ctx)
 {
-   if (!ubus_reconnect(ctx, ubus_socket)) {
-   ubus_add_uloop(ctx);
-   return;
-   }
-
-   timeout_retry();
-}
-
-static void
-ubus_disconnect_cb(struct ubus_context *ctx)
-{
-   ubus_timer.cb = ubus_reconnect_cb;
-   reset_timeout();
-   timeout_retry();
-}
-
-static void
-ubus_connect_cb(struct uloop_timeout *timeout)
-{
-   ctx = ubus_connect(ubus_socket);
-
-   if (!ctx) {
-   DEBUG(4, "Connection to ubus failed\n");
-   timeout_retry();
-   return;
-   }
-
-   ctx->connection_lost = ubus_disconnect_cb;
ubus_init_service(ctx);
ubus_init_system(ctx);
watch_ubus(ctx);
 
DEBUG(2, "Connected to ubus, id=%08x\n", ctx->local_id);
-   reset_timeout();
-   ubus_add_uloop(ctx);
procd_state_ubus_connect();
 }
 
 void
 procd_connect_ubus(void)
 {
-   ubus_timer.cb = ubus_connect_cb;
-   reset_timeout();
-   timeout_retry();
+   conn.path = ubus_socket;
+   conn.cb = ubus_auto_connect_cb;
+   ubus_auto_connect();
 }
-- 
2.7.4


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

Re: [LEDE-DEV] [netifd]Merged: Remove redundant check for strtoul() return value

2017-05-19 Thread Hans Dedecker 
Merged into project/netifd.git, branch master with
https://git.lede-project.org/?p=project/netifd.git;a=commit;h=a063705a03a6c5a41b5f7aed251bfb3ba5c844c3

Thanks

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

Re: [LEDE-DEV] [PATCH v3] ramips: add support for GL-inet GL-MT300N-V2

2017-05-19 Thread Mathias Kresin 
2017-05-17 12:18 GMT+02:00 kysonlok :
> This patch adds supports for the GL-inet GL-MT300N-V2.
>
> Specification:
> - SoC: MediaTek MT7628AN
> - Flash: 16 MiB (W25Q128FVSG)
> - RAM: 128 MiB DDR
> - Ethernet: 1 x WAN (100 Mbps) and 1 x LAN (100 Mbps)
> - USB: 1 x USB 2.0 port
> - Button: 1 x switch button, 1 x reset button
> - LED: 3 x LEDS (system power led is not GPIO controller)
> - UART: 1 x UART on PCB (JP1: 3.3V, RX, TX, GND)
>
> Installation through Luci:
> - The original firmware is LEDE, so both LuCI or sysupgrade can be used.
> - Do not keep settings, for sysupgrade please use the -n option.
>
> Installation through bootloader webserver:
> - Plug power and hold reset button until red LED blink to bright.
> - Install sysupgrade image using web interface on 192.168.1.1.
>
> Signed-off-by: kyson Lok 
> ---
>  target/linux/ramips/base-files/etc/board.d/01_leds |   3 +
>  .../linux/ramips/base-files/etc/board.d/02_network |   4 +
>  target/linux/ramips/base-files/etc/diag.sh |   3 +
>  target/linux/ramips/base-files/lib/ramips.sh   |   3 +
>  .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
>  target/linux/ramips/dts/GL-MT300N-V2.dts   | 133 
> +
>  target/linux/ramips/image/mt7628.mk|   8 ++
>  7 files changed, 155 insertions(+)
>  create mode 100644 target/linux/ramips/dts/GL-MT300N-V2.dts

Merged to my staging tree with a little bugfix. Will push it to master
during the next days.

Thanks!

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