[OpenWrt-Devel] [PATCH][odhcpd] Limit size of IPv4 DHCP reply

2015-09-29 Thread Dmitry Ivanov 
Limit size of IPv4 DHCP reply.
In other words, remove zero padding after end option (0xff).

Signed-off-by: Dmitry Ivanov 
---
 src/dhcpv4.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/dhcpv4.c b/src/dhcpv4.c
index a657e13..c8014ea 100644
--- a/src/dhcpv4.c
+++ b/src/dhcpv4.c
@@ -497,7 +497,7 @@ static void handle_dhcpv4(void *addr, void *data, size_t 
len,
inet_ntoa(dest.sin_addr));
}
 
-   sendto(sock, , sizeof(reply), MSG_DONTWAIT,
+   sendto(sock, , cookie - (uint8_t*)  - 1, MSG_DONTWAIT,
(struct sockaddr*), sizeof(dest));
 }
 
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] unsubscribe

2015-09-29 Thread Christian Beier 
Am Tue, 29 Sep 2015 12:00:02 +0200
schrieb openwrt-devel-requ...@lists.openwrt.org:

> Send openwrt-devel mailing list submissions to
>   openwrt-devel@lists.openwrt.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> or, via email, send a message with subject or body 'help' to
>   openwrt-devel-requ...@lists.openwrt.org
> 
> You can reach the person managing the list at
>   openwrt-devel-ow...@lists.openwrt.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openwrt-devel digest..."
> 
> 
> Today's Topics:
> 
>1. [PATCH v2] ar71xx: add support for TP-LINK  TL-WR941ND v6
>   (international version) (Matthias Schiffer)
>2. Re: [PATCH netifd] netifd-proto.sh: add table argument to
>   proto_add_ipv4_route() (Alexander Couzens)
> 
> 
> --
> 
> Message: 1
> Date: Tue, 29 Sep 2015 11:20:04 +0900
> From: Matthias Schiffer 
> To: openwrt-devel@lists.openwrt.org
> Subject: [OpenWrt-Devel] [PATCH v2] ar71xx: add support for TP-LINK
>   TL-WR941ND v6 (international version)
> Message-ID:
>   
> 
>   
> 
> The international version is completely different from the already
> supported Chinese version. The WLAN of the QCA956x SoC used by this router
> has been fixed in r46948.
> 
> Signed-off-by: Matthias Schiffer 
> ---
> v2: rebased on top of trunk + http://patchwork.ozlabs.org/patch/523133/
>   
>  
> The 700-MIPS-ath79-openwrt-machines.patch should only be ~10 added lines,  
> but git gets confused and makes the diff completely
> incomprehensible...
> 
> 
>  target/linux/ar71xx/base-files/etc/diag.sh |   3 +-
>  .../ar71xx/base-files/etc/uci-defaults/01_leds |   9 ++
>  .../ar71xx/base-files/etc/uci-defaults/02_network  |   1 +
>  target/linux/ar71xx/base-files/lib/ar71xx.sh   |   3 +
>  .../lib/preinit/05_set_preinit_iface_ar71xx|   1 +
>  .../ar71xx/base-files/lib/upgrade/platform.sh  |   1 +
>  target/linux/ar71xx/config-4.1 |   1 +
>  .../files/arch/mips/ath79/mach-tl-wr941nd-v6.c | 151 +++
>  target/linux/ar71xx/image/Makefile |   9 +-
>  .../700-MIPS-ath79-openwrt-machines.patch  | 166
> +++-- 10 files changed, 266 insertions(+), 79 deletions(-)
>  create mode 100644
> target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr941nd-v6.c
> 
> diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
> b/target/linux/ar71xx/base-files/etc/diag.sh index cfba6b4..d97de9f 100644
> --- a/target/linux/ar71xx/base-files/etc/diag.sh
> +++ b/target/linux/ar71xx/base-files/etc/diag.sh
> @@ -287,7 +287,8 @@ get_status_led() {
>   tl-wdr4300 | \
>   tl-wr703n | \
>   tl-wr710n | \
> - tl-wr720n-v3)
> + tl-wr720n-v3 | \
> + tl-wr941nd-v6)
>   status_led="tp-link:blue:system"
>   ;;
>   tl-wr841n-v9)
> diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
> b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds index
> fac4751..e8ee929 100644 ---
> a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds +++
> b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds @@ -503,6 +503,15
> @@ tl-wr941nd-v5) ucidef_set_led_wlan "wlan" "WLAN" "tp-link:green:wlan"
> "phy0tpt" ;;
>  
> +tl-wr941nd-v6)
> + ucidef_set_led_netdev "wan" "WAN" "tp-link:blue:wan" "eth0"
> + ucidef_set_led_switch "lan1" "LAN1" "tp-link:blue:lan1" "switch0"
> "0x10"
> + ucidef_set_led_switch "lan2" "LAN2" "tp-link:blue:lan2" "switch0"
> "0x08"
> + ucidef_set_led_switch "lan3" "LAN3" "tp-link:blue:lan3" "switch0"
> "0x04"
> + ucidef_set_led_switch "lan4" "LAN4" "tp-link:blue:lan4" "switch0"
> "0x02"
> + ucidef_set_led_wlan "wlan" "WLAN" "tp-link:blue:wlan" "phy0tpt"
> + ;;
> +
>  tl-wa830re-v2)
>   ucidef_set_led_netdev "lan" "LAN" "tp-link:green:lan" "eth0"
>   ucidef_set_led_wlan "wlan" "WLAN" "tp-link:green:wlan" "phy0tpt"
> diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
> b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network index
> 880953c..35cd05d 100644 ---
> a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network +++
> b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network @@ -242,6 +242,7
> @@ tl-mr3420-v2 |\ tl-wr841n-v8 |\
>  tl-wr842n-v2 |\
>  tl-wr941nd-v5 |\
> +tl-wr941nd-v6 |\
>  tl-wdr6500-v2 |\
>  wnr2000-v3 |\
>  wnr2000-v4 |\
> diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
> b/target/linux/ar71xx/base-files/lib/ar71xx.sh index ad98cfb..6dba074 100755
> ---

Re: [OpenWrt-Devel] periodic task checking for usb flash media?

2015-09-29 Thread Karl Palsson 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Karl Palsson  wrote:
> Hi,
> 
> I've got a custom board with an onboard USB flash media
> interface. It works well, I can mount and access micro SD cards
> nicely, and all that basic stuff.
> 
> However, card detection doesn't work. The USB flash interface
> is Mass Storage Bulk Only, and on my desktop linux system,
> there's a period task polling the device every two seconds,
> sending SCSI "TEST UNIT READY" and "REQUEST SENSE" commands,
> and this happily detects card insertions/removals, (after the
> next poll)
> 
> On openwrt, this doesn't happen. With usbmon I don't see any
> periodic traffic. Calling "block info" manually reliably detect
> any changes and gets new device nodes created, that works just
> fine, but do I really need to call that periodically myself?
> 
> Is this how it's meant to be? Am I missing some important
> package or config? I'm not asking about automounting, there's
> plenty of wiki help and options for that, but how do I get the
> card to be detected at all?
> 

fwiw, originally, the values of the kernel block checking task
were:

# cat /sys/block/sda/events_poll_msecs 
- -1
# cat /sys/module/block/parameters/events_dfl_poll_msecs 
0

And changing them to 2000 had no effect at all.
https://github.com/surkovalex/openpctv/blob/master/packages/systemd/patches/Set-default-polling-interval-on-removable-devices-as.patch
and others imply that those settings have no impact when the
block module is compiled in, as appears to be the case on
OpenWrt. So I've added a new patch that changes the default to
2000, but I still get no events of any sort when a card is
plugged in or removed.

Still, running "block info" will happily rescan and create/delete
the /dev/sda1 node.

Sincerely,
Karl Palsson

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJWColAAAoJEBmotQ/U1cr2lYIP/RPk5aFutiA90KL3gkImXdM8
TUUgMs7ICxwJSsFlGVMaYGR5PDkj6v6Xfy2nShJjYC4wdMOTFlL2bn7aTaLd8eep
aQYrwv0dFSNEd49zBvkbpdJvarEe+ZJtcwYD9dCZQCGbyjxZ0ZgfQDDlGL0oDxoG
205pgfXTSNUAuqVGYc5dFvZeK7rfbTnqIES06XnOo2hn5AAHpKWMy40OUc1clPdF
ka+4uqnh4978NOovzABk+Wbwj9s746m0Yp2U/StLi5clr8w11fT8x5N70apYQNk1
9uBEIwZOPyZzc1MYIaqOOLW4aHrZoEwY6GxpuBGCKkX7j7AMNk9LqFc8omSnjl+D
B+OHWlzGdpQ5/Wsexvt0YJjfIlRvlksTIoOQH+H+B5L7gpKBvTJiRyLu7Psd4R3a
zppzi+8O6pwjPRiUa6Z/p1vZe0XAeac66ebhkqGbQtP5J71V4MpNLNFkGF+86ylF
h9Y2hM4fTfoP7+5cr9Ral0ncrvly543/GiC3Us9ziPHZThZqAOxHzOxiQLYfqud9
jhbwE7ufNQojTlWDMQXL6QHddhI/jAOAvppoOzZfdSI4+Ee3ivYVRMFIhulFwIr6
aXO3HBtMJk2r2rukkl2WtFjML7pjiyDT+IPH3xVd4vS7u9SFRVVpcamx0Ed20roZ
EbkAGRK09Cz9X751aOPy
=qAKt
-END PGP SIGNATURE-
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH netifd] netifd-proto.sh: add table argument to proto_add_ipv4_route()

2015-09-29 Thread Alexander Couzens 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Steven,

you rejected this patch as well.

Why would you not allow to define a specific table for ipv4, but for
ipv6?

> cy...@openwrt.org

> NAK. Use "option ip4table" and "option ip6table" which works with
> all protocols already.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWClv2AAoJEMKenaag34YEpGUP/1j+pipA5j9C7vkfAMyYqkkU
ZzDR3k/rEXK9JeAXVABagSG3SRmfOGOCkgFMShW4vxapO7beKViAFU/tUroSB69K
+hdCFMqkUcKtAa9AMm0JDkA5tkNxQ3uBPNAnj/PTxNMFFRDk2+qX7Do05Y4KbB2g
FWeialu1K5pJydPFeu2fP1ajID05phOlJPHjalLyDjYLtPU2KDDSiGICmldGo18J
0RDgy4/9GVxGkU8v3+3S5szQWZxns2M/CJSJ0T182cHpLRzP2qOFvt802q+hdm1i
latOWvVJ6+qsX0rMJh3SlSMF75vWo6FkAkld4vpiWtF0KT718v1+xEF+DDou9pw4
QLhb/OO52Ic2Qv81St7kkknVQU45jcOA3JNQsB9UpDxRSng0QnTZyX507B8iHfJh
XfHOz5ZBgZ1J+OW/RgPf889ChUtGWYlFU31snZWPfBcSVsHuKpZ396SoKyqDWOZI
GuSnNQViYrgBQAba98Y0UlYQ+lFxHs4+Vivd2qzGE/9RxhR4wuSWbiI5vKic2S1r
anEklRrDpv0zo8tyaEKKetMyE9K2l2k3zEJ54jJhALC9vldX+cEnYnvqt5zN3ImE
hHO8BtlrjcdUGOu9xHyWG4Igsra23wGZ0UGAuGVDGyED3oBFX4kJlv3JF4g9DEiV
6xqiqLeAcZ/f5+gVaua3
=Xe6x
-END PGP SIGNATURE-
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] [SIGNED-OFF] Correct WeIO board name

2015-09-29 Thread Drasko DRASKOVIC 
Trivial parch to correct WeIO board name in the system.

Signed-off-by: Drasko DRASKOVIC 
---
 target/linux/ar71xx/base-files/lib/ar71xx.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh 
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index ad98cfb..4679a4b 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -850,7 +850,7 @@ ar71xx_board_detect() {
*"UniFi AP Pro")
name="uap-pro"
;;
-   *"WeIO")
+   "WeIO"*)
name="weio"
;;
*WHR-G301N)
-- 
2.5.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] periodic task checking for usb flash media?

2015-09-29 Thread Karl Palsson 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I've got a custom board with an onboard USB flash media
interface. It works well, I can mount and access micro SD cards
nicely, and all that basic stuff.

However, card detection doesn't work. The USB flash interface is
Mass Storage Bulk Only, and on my desktop linux system, there's a
period task polling the device every two seconds, sending SCSI
"TEST UNIT READY" and "REQUEST SENSE" commands, and this happily
detects card insertions/removals, (after the next poll)

On openwrt, this doesn't happen. With usbmon I don't see any
periodic traffic. Calling "block info" manually reliably detect
any changes and gets new device nodes created, that works just
fine, but do I really need to call that periodically myself?

Is this how it's meant to be? Am I missing some important package
or config? I'm not asking about automounting, there's plenty of
wiki help and options for that, but how do I get the card to be
detected at all?

Sincerely,
Karl Palsson

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJWCnR6AAoJEBmotQ/U1cr2+N0P/3ZJpWOKKVxJ5sS05LeVlQAT
FqNVVBVDlJVYp3nbc6QCFqYiPOp3ge4GtR/OvHiy4AUdeqZqTYlsOMGUiHEQO0Ho
0UVravWyJoKzTNvNETcqhUcb8iuzj1EoGCbEfUT0WlYV5GLeKneUKrLo/cQtUeoO
/CNJ+fU6gW/SmPsxrkQW+i4eR+Qbucln6Q8ee6SZThrT2ftmOqab+02RO80CSi8N
VyD4K9BbiZhj4Y8b4BYJkbvDJ+iS0XzobSzJ76LLZxZDHIDIvPjfWWnDdxm4P35l
rNU6/W0x7+8OA9l0TRY6KAbo5xABqTl2fu+vg6cLnTHRBgTQNsvUsbyLiOt/bBEs
buxsWfgbZAMcF7uxK0nim4IqIMPnbpS6ickx4D9R696bNXwA7kWGlAATkBtCN9V5
uSusnpAzLF1/rKuF7RZLRxqjsG+8LKhcJJ+GIxZFTn0dirA5YZ8NfzZnmf3xlwxg
7IC4+LbW/ELhEb3Z8ULPjUcKwhYIMbDTKWm6q7Li627Z90BAF4o1SO23/eVXlRaf
M1g3rS0+wyVy1O6KP9Hu/4ZOzLztV/WlRnt2cTYmX4EHgUwL/srQ/75cRYF8PCaw
dCNwHA32ctNOmfmwEpo+IedD8ESbyLw3O3kanIDA2E9fvugsJinJB+C4JFkl7hD8
EqHrrvUvrjRsHEc1adlk
=SDbi
-END PGP SIGNATURE-
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH netifd] netifd-proto.sh: add table argument to proto_add_ipv4_route()

2015-09-29 Thread Steven Barth 
Alexander,

I don't have a problem with that particular patch. However since the
other patch was redundant and the only user of this one it seemed
redundant to me as well. If you have another usecase for this then
please let us know.


Cheers,

Steven


On 29.09.2015 11:37, Alexander Couzens wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi Steven,
>
> you rejected this patch as well.
>
> Why would you not allow to define a specific table for ipv4, but for
> ipv6?
>
>> cy...@openwrt.org
>> NAK. Use "option ip4table" and "option ip6table" which works with
>> all protocols already.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJWClv2AAoJEMKenaag34YEpGUP/1j+pipA5j9C7vkfAMyYqkkU
> ZzDR3k/rEXK9JeAXVABagSG3SRmfOGOCkgFMShW4vxapO7beKViAFU/tUroSB69K
> +hdCFMqkUcKtAa9AMm0JDkA5tkNxQ3uBPNAnj/PTxNMFFRDk2+qX7Do05Y4KbB2g
> FWeialu1K5pJydPFeu2fP1ajID05phOlJPHjalLyDjYLtPU2KDDSiGICmldGo18J
> 0RDgy4/9GVxGkU8v3+3S5szQWZxns2M/CJSJ0T182cHpLRzP2qOFvt802q+hdm1i
> latOWvVJ6+qsX0rMJh3SlSMF75vWo6FkAkld4vpiWtF0KT718v1+xEF+DDou9pw4
> QLhb/OO52Ic2Qv81St7kkknVQU45jcOA3JNQsB9UpDxRSng0QnTZyX507B8iHfJh
> XfHOz5ZBgZ1J+OW/RgPf889ChUtGWYlFU31snZWPfBcSVsHuKpZ396SoKyqDWOZI
> GuSnNQViYrgBQAba98Y0UlYQ+lFxHs4+Vivd2qzGE/9RxhR4wuSWbiI5vKic2S1r
> anEklRrDpv0zo8tyaEKKetMyE9K2l2k3zEJ54jJhALC9vldX+cEnYnvqt5zN3ImE
> hHO8BtlrjcdUGOu9xHyWG4Igsra23wGZ0UGAuGVDGyED3oBFX4kJlv3JF4g9DEiV
> 6xqiqLeAcZ/f5+gVaua3
> =Xe6x
> -END PGP SIGNATURE-
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v3 1/3] ramips: Add DTS files for HiWiFi HC5x61 models

2015-09-29 Thread Comman Kang 
HiWiFi HC5661/5761/5861 models are manufactured by http://www.hiwifi.com. These 
models have similar hardware specs(MT7620A + 128M DDR2 + 16M flash). This patch 
adds support for them.

The original author is Justin Liu (rss...@gmail.com). I ported the patch to 
trunk and submitted it here with his approval.

v3 fix
  1: Merged most stuff into dtsi file
  2: Remove unnecessary empty lines.

Signed-off-by: Xiaoning Kang 


diff --git a/target/linux/ramips/dts/HC5661.dts 
b/target/linux/ramips/dts/HC5661.dts
new file mode 100644
index 000..b9a717b
--- /dev/null
+++ b/target/linux/ramips/dts/HC5661.dts
@@ -0,0 +1,32 @@
+/dts-v1/;
+
+/include/ "HC5XXX.dtsi"
+
+/ {
+   compatible = "HC5661", "ralink,mt7620a-soc";
+   model = "HiWiFi HC5661";
+
+   gpio-leds {
+   compatible = "gpio-leds";
+
+   system {
+   label = "hc5661:blue:system";
+   gpios = < 9 1>;
+   };
+
+   internet {
+   label = "hc5661:blue:internet";
+   gpios = < 11 1>;
+   };
+
+   wlan2g {
+   label = "hc5661:blue:wlan2g";
+   gpios = < 0 1>;
+   };
+
+   wlan5g {
+   label = "hc5661:blue:wlan5g";
+   gpios = < 7 1>;
+   };
+   };
+};
diff --git a/target/linux/ramips/dts/HC5761.dts 
b/target/linux/ramips/dts/HC5761.dts
new file mode 100644
index 000..a10904c
--- /dev/null
+++ b/target/linux/ramips/dts/HC5761.dts
@@ -0,0 +1,32 @@
+/dts-v1/;
+
+/include/ "HC5XXX.dtsi"
+
+/ {
+   compatible = "HC5761", "ralink,mt7620a-soc";
+   model = "HiWiFi HC5761";
+
+   gpio-leds {
+   compatible = "gpio-leds";
+
+   system {
+   label = "hc5761:blue:system";
+   gpios = < 9 1>;
+   };
+
+   internet {
+   label = "hc5761:blue:internet";
+   gpios = < 11 1>;
+   };
+
+   wlan2g {
+   label = "hc5761:blue:wlan2g";
+   gpios = < 0 1>;
+   };
+
+   wlan5g {
+   label = "hc5761:blue:wlan5g";
+   gpios = < 7 1>;
+   };
+   };
+};
diff --git a/target/linux/ramips/dts/HC5861.dts 
b/target/linux/ramips/dts/HC5861.dts
new file mode 100644
index 000..05857ea
--- /dev/null
+++ b/target/linux/ramips/dts/HC5861.dts
@@ -0,0 +1,92 @@
+/dts-v1/;
+
+/include/ "HC5XXX.dtsi"
+
+/ {
+   compatible = "HC5861", "ralink,mt7620a-soc";
+   model = "HiWiFi HC5861";
+
+   ethernet@1010 {
+   status = "okay";
+   mtd-mac-address = < 0x4>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins _pins _pins>;
+   ralink,port-map = "w";
+
+   port@4 {
+   status = "okay";
+   phy-handle = <>;
+   phy-mode = "rgmii";
+   };
+
+   port@5 {
+   status = "okay";
+   phy-handle = <>;
+   phy-mode = "rgmii";
+   };
+
+   mdio-bus {
+   status = "okay";
+
+   phy4: ethernet-phy@4 {
+   reg = <4>;
+   phy-mode = "rgmii";
+   };
+
+   phy5: ethernet-phy@5 {
+   reg = <5>;
+   phy-mode = "rgmii";
+   };
+   };
+   };
+
+   gsw@1011 {
+   ralink,port4 = "gmac";
+   };
+
+   gpio-leds {
+   compatible = "gpio-leds";
+
+   system {
+   label = "hc5861:blue:system";
+   gpios = < 9 1>;
+   };
+
+   wlan2g {
+   label = "hc5861:blue:wlan2g";
+   gpios = < 11 1>;
+   };
+
+   internet {
+   label = "hc5861:blue:internet";
+   gpios = < 0 1>;
+   };
+
+   wlan5g {
+   label = "hc5861:blue:wlan5g";
+   gpios = < 7 1>;
+   };
+
+   turbo {
+   label = "hc5861:blue:turbo";
+   gpios = < 10 1>;
+   };
+   };
+
+   gpio_export {
+   compatible = "gpio-export";
+   #size-cells = <0>;
+
+   usbpower {
+   gpio-export,name = "usbpower";
+   gpio-export,output = <0>;
+   gpios = < 13 0>;
+   };
+
+   sdpower {
+   gpio-export,name = "sdpower";
+

[OpenWrt-Devel] [PATCH V3 2/3] ramips: Add base-files for HiWiFi HC5x61 models

2015-09-29 Thread Comman Kang 
HiWiFi HC5661/5761/5861 models are manufactured by http://www.hiwifi.com. These 
models have similar hardware specs(MT7620A + 128M DDR2 + 16M flash). This patch 
adds support for them.

The original author is Justin Liu (rss...@gmail.com). I ported the patch to 
trunk and submitted it here with his approval.

v3 fix
   1: Fixed model order
   2: Remove manufacturer name from model name
   3: Use a hacky but prettier way to get mac address.


Signed-off-by: Xiaoning Kang 

diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds 
b/target/linux/ramips/base-files/etc/board.d/01_leds
index a9959e3..c75a993 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -132,6 +132,24 @@ fonera20n)
set_usb_led "$board:orange:usb"
set_wifi_led "$board:orange:wifi"
;;
+hc5661)
+   ucidef_set_led_default "system" "system" "$board:blue:system" "1"
+   ucidef_set_led_netdev "internet" "internet" "$board:blue:internet" 
"eth0.2"
+   set_wifi_led "$board:blue:wlan2g"
+   ;;  
+hc5761)
+   ucidef_set_led_default "system" "system" "$board:blue:system" "1"
+   ucidef_set_led_netdev "internet" "internet" "$board:blue:internet" 
"eth0.2"
+   set_wifi_led "$board:blue:wlan2g"
+   ucidef_set_led_netdev "wifi5g" "wifi5g" "$board:blue:wlan5g" "rai0"
+   ;;
+hc5861)
+   ucidef_set_led_default "system" "system" "$board:blue:system" "1"
+   ucidef_set_led_netdev "internet" "internet" "$board:blue:internet" 
"eth0.2"
+   set_wifi_led "$board:blue:wlan2g"
+   ucidef_set_led_netdev "wifi5g" "wifi5g" "$board:blue:wlan5g" "rai0"
+   ucidef_set_led_default "turbo" "turbo" "$board:blue:turbo" "0"
+   ;;
 hg255d)
set_wifi_led "$board:green:wlan"
set_usb_led "$board:green:usb"
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index 75cccae..94d69b9 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -170,6 +170,13 @@ ramips_setup_interfaces()
ucidef_add_switch_vlan "switch1" "1" "0 1 2 3 6t"
ucidef_add_switch_vlan "switch1" "2" "4 6t"
;;
+   hc5*61|\
+   y1s)
+   ucidef_set_interfaces_lan_wan "eth0.1" "eth0.2"
+   ucidef_add_switch "switch0" "1" "1"
+   ucidef_add_switch_vlan "switch0" "1" "1 2 3 4 5 6t"
+   ucidef_add_switch_vlan "switch0" "2" "0 6t"
+   ;;
m2m)
ucidef_add_switch "switch0" "4"
ucidef_set_interface_lan "eth0"
@@ -224,12 +231,6 @@ ramips_setup_interfaces()
ucidef_add_switch_vlan "switch0" "1" "1 2 6t"
ucidef_add_switch_vlan "switch0" "2" "0 6t"
;;
-   y1s)
-   ucidef_set_interfaces_lan_wan "eth0.1" "eth0.2"
-   ucidef_add_switch "switch0" "1" "1"
-   ucidef_add_switch_vlan "switch0" "1" "1 2 3 4 5 6t"
-   ucidef_add_switch_vlan "switch0" "2" "0 6t"
-   ;;
zbt-wr8305rt)
ucidef_set_interfaces_lan_wan "eth0.1" "eth0.2"
ucidef_add_switch "switch0" "1" "1"
@@ -293,6 +294,11 @@ ramips_setup_macs()
e1700)
wan_mac=$(mtd_get_mac_ascii config WAN_MAC_ADDR)
;;
+   hc5*61)
+   lan_mac=`mtd_get_mac_ascii bdinfo "Vfac_mac "`
+   [ -n "$lan_mac" ] || lan_mac=$(cat /sys/class/net/eth0/address)
+   wan_mac=$(macaddr_add "$lan_mac" 1)
+   ;;
ht-tm02)
lan_mac=$(cat /sys/class/net/eth0/address)
;;
diff --git a/target/linux/ramips/base-files/etc/diag.sh 
b/target/linux/ramips/base-files/etc/diag.sh
index 7fc6f29..5376759 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -104,6 +104,11 @@ get_status_led() {
f7c027)
status_led="$board:orange:status"
;;
+   hc5*61|\
+   mlw221|\
+   mlwg2)
+   status_led="$board:blue:system"
+   ;;
m2m)
status_led="$board:blue:wifi"
;;
@@ -115,10 +120,6 @@ get_status_led() {
zte-q7)
status_led="$board:red:status"
;;
-   mlw221|\
-   mlwg2)
-   status_led="$board:blue:system"
-   ;;
mr-102n)
status_led="$board:amber:status"
;;
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index d242235..b89a88c 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -169,6 +169,15 @@ ramips_board_detect() {
*"FreeStation5")
name="freestation5"

Re: [OpenWrt-Devel] Backporting from dev branch to stable

2015-09-29 Thread Jonathan Bennett 
Guys with more experience will certainly be better suited to answer, but
from what I've observed, something like new device support wouldn't be
appropriate to backport into a released branch.  Usually only critical
security patches are backported.  There has been discussion of 15.05
working as a LTS sort of release, with minor version updates, so a 15.05.1
might happen in a few months.  You *might* get your patches included for
that maintenance release.  That's certainly not for me to decide, though.

--Jonathan Bennett

On Tue, Sep 29, 2015 at 2:15 PM Drasko DRASKOVIC 
wrote:

> Hi all,
> how are the patches from main development branch backported to Chaos
> Calmer branch from dev branch?
>
> Do I have to re-post this patch-set
>
> http://git.openwrt.org/?p=openwrt.git;a=commit;h=c84682a79e36bb57f4f78d51aa589f7bfe3fb5e8
> against this branch:
> http://git.openwrt.org/?p=15.05/openwrt.git;a=summary?
>
> BR,
> Drasko
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] base-files: init/sysfixtime - exclude dnsmasq.time

2015-09-29 Thread Yousong Zhou 
Hi, hope this comment is not too late :)

On 23 September 2015 at 17:12, Steven Barth  wrote:
> Using --dnssec-no-timecheck is impractical since it reacts to SIGHUP which
> is already overloaded and might be triggered by e.g. config changes.
>

Agree.  I did not check the source code, but it's bad design if it is
indeed the case that dnssec time check will be enabled on any
condition on receiving SIGHUP signal which is already there for config
reload.

> Btw. an ntp hotplug infrastructure exists:
> https://dev.openwrt.org/changeset/43421
>
> Please also consider that some devices have an RTC, so disabling timecheck
> indiscriminately at startup might not be ideal either.
>

To be honest, I have little prior experience with the DNSSEC protocol
details.  But considering principles of least privilege and smaller
attack surface, the DNSSEC time check SHOULD be disabled by default
when no reliable time source is available.  The timestamp file is more
like a compromise and compromise is a negative word when talking about
security.

Then how do you guys think about the following proposal

 - An option like "dnssec_time_check" can be provided to let users
switch it on explicitly if they know what's the effect will be and are
okay with it
 - If no option was explicitly specified, then we might check the
availability of rtc in service script and enable the time check if
it's there

Regards,

yousong

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

Re: [OpenWrt-Devel] Backporting from dev branch to stable

2015-09-29 Thread L. D. Pinney 
Basically speaking ... one would take the working patch set from trunk and
apply it to CC ... fix all the errors, changes, etc.
Then once you have a working patch set for CC ... submit it.

A couple of recent examples :

https://patchwork.ozlabs.org/patch/505724/ and
https://patchwork.ozlabs.org/patch/499956/

Regards

Larry

On Tue, Sep 29, 2015 at 8:47 PM, Jonathan Bennett 
wrote:

> Guys with more experience will certainly be better suited to answer, but
> from what I've observed, something like new device support wouldn't be
> appropriate to backport into a released branch.  Usually only critical
> security patches are backported.  There has been discussion of 15.05
> working as a LTS sort of release, with minor version updates, so a 15.05.1
> might happen in a few months.  You *might* get your patches included for
> that maintenance release.  That's certainly not for me to decide, though.
>
> --Jonathan Bennett
>
> On Tue, Sep 29, 2015 at 2:15 PM Drasko DRASKOVIC <
> drasko.drasko...@gmail.com> wrote:
>
>> Hi all,
>> how are the patches from main development branch backported to Chaos
>> Calmer branch from dev branch?
>>
>> Do I have to re-post this patch-set
>>
>> http://git.openwrt.org/?p=openwrt.git;a=commit;h=c84682a79e36bb57f4f78d51aa589f7bfe3fb5e8
>> against this branch:
>> http://git.openwrt.org/?p=15.05/openwrt.git;a=summary?
>>
>> BR,
>> Drasko
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Backporting from dev branch to stable

2015-09-29 Thread Drasko DRASKOVIC 
Hi all,
how are the patches from main development branch backported to Chaos
Calmer branch from dev branch?

Do I have to re-post this patch-set
http://git.openwrt.org/?p=openwrt.git;a=commit;h=c84682a79e36bb57f4f78d51aa589f7bfe3fb5e8
against this branch:
http://git.openwrt.org/?p=15.05/openwrt.git;a=summary?

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