Re: [LEDE-DEV] [PATCH odhcpd v2] dhcpv4: notify DHCP ACK and RELEASE via ubus
On Tue, Nov 28, 2017 at 3:08 PM, Borja Salazar wrote:
> if the ubus object has any subscription
> notify DHCP ACK and DHCP RELEASE events
> using ubus notifications.
>
> Signed-off-by: Borja Salazar
> ---
> src/dhcpv4.c | 16
> src/odhcpd.h | 2 ++
> src/ubus.c | 24
> 3 files changed, 42 insertions(+)
>
> diff --git a/src/dhcpv4.c b/src/dhcpv4.c
> index 166582e..9fd6a8d 100644
> --- a/src/dhcpv4.c
> +++ b/src/dhcpv4.c
> @@ -723,6 +723,14 @@ static void handle_dhcpv4(void *addr, void *data, size_t
> len,
> req->chaddr[0],req->chaddr[1],req->chaddr[2],
> req->chaddr[3],req->chaddr[4],req->chaddr[5]);
>
> +#ifdef WITH_UBUS
> + if (ubus_has_subscribers() && reqmsg == DHCPV4_MSG_RELEASE) {
> + char req_chaddr_str[13];
> + memset(&req_chaddr_str, 0, sizeof(req_chaddr_str));
> + odhcpd_hexlify(req_chaddr_str, req->chaddr, ETH_ALEN);
> + ubus_event_bcast("dhcp.release", req_chaddr_str,
> inet_ntoa(req->ciaddr), hostname, iface->ifname);
> + }
> +#endif
> if (reqmsg == DHCPV4_MSG_DECLINE || reqmsg == DHCPV4_MSG_RELEASE)
> return;
>
> @@ -870,6 +878,14 @@ static void handle_dhcpv4(void *addr, void *data, size_t
> len,
> req->chaddr[3],req->chaddr[4],req->chaddr[5],
> inet_ntoa(dest.sin_addr));
>
> +#ifdef WITH_UBUS
> + if (ubus_has_subscribers() && msg == DHCPV4_MSG_ACK) {
> + char reply_chaddr_str[13];
> + memset(&reply_chaddr_str, 0, sizeof(reply_chaddr_str));
> + odhcpd_hexlify(reply_chaddr_str, reply.chaddr, ETH_ALEN);
> + ubus_event_bcast("dhcp.ack", reply_chaddr_str,
> inet_ntoa(reply.yiaddr), hostname, iface->ifname);
> + }
> +#endif
> sendto(sock, &reply, sizeof(reply), MSG_DONTWAIT,
> (struct sockaddr*)&dest, sizeof(dest));
> }
> diff --git a/src/odhcpd.h b/src/odhcpd.h
> index 45badd3..7ee4f44 100644
> --- a/src/odhcpd.h
> +++ b/src/odhcpd.h
> @@ -296,6 +296,8 @@ int ubus_init(void);
> const char* ubus_get_ifname(const char *name);
> void ubus_apply_network(void);
> bool ubus_has_prefix(const char *name, const char *ifname);
> +void ubus_event_bcast(const char *type, const char *mac, const char *ip,
> const char *name, const char *interface);
> +bool ubus_has_subscribers(void);
> #endif
>
> int netlink_add_netevent_handler(struct netevent_handler *hdlr);
> diff --git a/src/ubus.c b/src/ubus.c
> index 95eeff7..741daed 100644
> --- a/src/ubus.c
> +++ b/src/ubus.c
> @@ -311,6 +311,30 @@ static const struct blobmsg_policy
> obj_attrs[OBJ_ATTR_MAX] = {
> [OBJ_ATTR_PATH] = { .name = "path", .type = BLOBMSG_TYPE_STRING },
> };
>
> +bool ubus_has_subscribers(void)
> +{
> + return main_object.has_subscribers;
> +}
> +
> +void ubus_event_bcast(const char *type, const char *mac, const char *ip,
> const char *name, const char *interface)
> +{
> +
> + if (!ubus || !main_object.has_subscribers)
> + return;
> +
> + blob_buf_init(&b, 0);
> + if (mac)
> + blobmsg_add_string(&b, "mac", mac);
> + if (ip)
> + blobmsg_add_string(&b, "ip", ip);
> + if (name)
> + blobmsg_add_string(&b, "name", name);
> + if (interface)
> + blobmsg_add_string(&b, "interface", interface);
> +
> + ubus_notify(ubus, &main_object, type, b.head, -1);
> +
> +}
>
> static void handle_event(_unused struct ubus_context *ctx, _unused struct
> ubus_event_handler *ev,
> _unused const char *type, struct blob_attr *msg)
> --
> 2.11.0
Patch re-worked and applied as
https://git.lede-project.org/?p=project/odhcpd.git;a=commit;h=c516801e3dbb992ce1ea5274439b9b30888d9fb1
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] [PATCH v2] ramips: add support for Asus RT-N11P / RT-N12+ / RT-N12E b1
This is a variant of the MT7620N-based Asus routers.
Specifications:
- MT7620N (580 MHz)
- 32 MB RAM
- 8 MB Flash
- 5x 10/100Mbps Ethernet (built-in switch)
- 2.4 GHz WLAN
- 2x external, non-detachable antennas
- UART (J2) header on PCB (115200 8n1)
Flash instructions:
1. Configure PC with static IP 192.168.1.75
2. Connect PC with one of LAN ports, press the reset button, power up
the router and keep button pressed for around 6-7 seconds. All 4 LEDs will
start to blink, which is when the router will accept firmware files via TFTP.
No known limitations on firmware filenames, just send it with a TFTP client
to 192.168.1.1.
3. Router will download file from server, write it to flash and reboot.
Changes in v2:
- update LED config for LAN/WAN
- disable USB
- drop incorrectly added mt76 from DEVICE_PACKAGES
(wlan is supported by rt2x00)
Signed-off-by: Zoltan HERPAI
---
target/linux/ramips/base-files/etc/board.d/01_leds | 6 ++
.../linux/ramips/base-files/etc/board.d/02_network | 1 +
target/linux/ramips/base-files/lib/ramips.sh | 3 +
.../ramips/base-files/lib/upgrade/platform.sh | 1 +
target/linux/ramips/dts/RT-N12-PLUS.dts| 117 +
target/linux/ramips/image/mt7620.mk| 6 ++
6 files changed, 134 insertions(+)
create mode 100644 target/linux/ramips/dts/RT-N12-PLUS.dts
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 74e405e..0c97dc9 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -340,6 +340,12 @@ rt-ac51u)
set_wifi_led "$board:blue:wifi"
set_usb_led "$board:blue:usb" "1-1"
;;
+rt-n12p)
+ ucidef_set_led_default "power" "power" "$board:green:power" "1"
+ ucidef_set_led_netdev "lan" "lan" "$board:green:lan" eth0.1
+ ucidef_set_led_netdev "wan" "wan" "$board:green:wan" eth0.2
+ set_wifi_led "$board:green:air"
+ ;;
rt-n14u)
ucidef_set_led_default "power" "power" "$board:blue:power" "1"
ucidef_set_led_netdev "lan" "lan" "$board:blue:lan" eth0.1
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 6ad64e6..db797c6 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -100,6 +100,7 @@ ramips_setup_interfaces()
psg1208|\
psg1218a|\
r6220|\
+ rt-n12p)
sap-g3200u3|\
sk-wb8|\
u7621-06-256M-16M|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh
b/target/linux/ramips/base-files/lib/ramips.sh
index 76ca3d1..bf19a4c 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -460,6 +460,9 @@ ramips_board_detect() {
*"RT-N10+")
name="rt-n10-plus"
;;
+ *"RT-N12+")
+ name="rt-n12p"
+ ;;
*"RT-N13U")
name="rt-n13u"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 0d5b6bb..3181da2 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -130,6 +130,7 @@ platform_check_image() {
rt-ac51u|\
rt-g32-b1|\
rt-n10-plus|\
+ rt-n12p|\
rt-n13u|\
rt-n14u|\
rt-n15|\
diff --git a/target/linux/ramips/dts/RT-N12-PLUS.dts
b/target/linux/ramips/dts/RT-N12-PLUS.dts
new file mode 100644
index 000..f3e0284
--- /dev/null
+++ b/target/linux/ramips/dts/RT-N12-PLUS.dts
@@ -0,0 +1,117 @@
+/dts-v1/;
+
+#include "mt7620n.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "asus,rt-n12p", "ralink,mt7620n-soc";
+ model = "Asus RT-N12+";
+
+ chosen {
+ bootargs = "console=ttyS0,115200";
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ wan {
+ label = "rt-n12p:green:wan";
+ gpios = <&gpio2 4 GPIO_ACTIVE_LOW>;
+ };
+
+ lan {
+ label = "rt-n12p:green:lan";
+ gpios = <&gpio1 15 GPIO_ACTIVE_LOW>;
+ };
+
+ power {
+ label = "rt-n12p:green:power";
+ gpios = <&gpio2 3 GPIO_ACTIVE_LOW>;
+ };
+
+ air {
+ label = "rt-n12p:green:air";
+ gpios = <&gpio3 0 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ gpio-keys-polled {
+ compatible = "gpio-keys-polled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ poll-interval = <20>;
+
+ reset {
Re: [LEDE-DEV] [PATCH] base-files: config_generate: keep ipv6 interface in sync
On 12/06/2017 12:40 AM, Roman Yeryomin wrote:
> On 2017-12-05 21:52, Hans Dedecker wrote:
>> On Tue, Dec 5, 2017 at 5:22 PM, Roman Yeryomin wrote:
>>> It's better not to configure ifname separately since they
>>> are tied together.
>>>
>>> Signed-off-by: Roman Yeryomin
>>> ---
>>> package/base-files/files/bin/config_generate | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/package/base-files/files/bin/config_generate
>>> b/package/base-files/files/bin/config_generate
>>> index a8311fc595..d7a6829d77 100755
>>> --- a/package/base-files/files/bin/config_generate
>>> +++ b/package/base-files/files/bin/config_generate
>>> @@ -113,7 +113,7 @@ generate_network() {
>>> set network.$1.proto='dhcp'
>>> delete network.${1}6
>>> set network.${1}6='interface'
>>> - set network.${1}6.ifname='$ifname'
>>> + set network.${1}6.ifname='@${1}'
>>> set network.${1}6.proto='dhcpv6'
>>> EOF
>>> ;;
>>> --
>>> 2.14.1
>> NACK
>>
>> This makes the IPv6 interface dependant on the operational status of
>> the IPv4 interface; meaning the IPv6 interface will not be started if
>> the IPv4 interface does not get an IP address.
>> Especially this would break wan connectivity if the wan link only
>> supports IPv6
>>
>
> Hmm... right, will just ${1} be better?
>
> Regards,
> Roman
No, there is no real interface called 'wan', so it will simply not work at
all. Logical netifd interface names can only be used in alias
configurations, but aliases always add a depenency on the 'up' state of the
aliased interface (so aliases are mostly useful for interfaces that
actually depend on each other, like a interface depending on a lower interface.
If you want two configurations not to depend on each other, as we usually
want for IPv4/IPv6 setup, the current version '$ifname' is exactly right.
It is also the clearest solution semantically: IPv4 and IPv6 uplink are two
independent configurations that just share the same physical link in the
most common setups.
Regards,
Matthias
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] base-files: config_generate: keep ipv6 interface in sync
On Wed, Dec 06, 2017 at 05:58:18PM +0100, Matthias Schiffer wrote:
> On 12/06/2017 12:40 AM, Roman Yeryomin wrote:
> > On 2017-12-05 21:52, Hans Dedecker wrote:
> >> On Tue, Dec 5, 2017 at 5:22 PM, Roman Yeryomin wrote:
> >>> It's better not to configure ifname separately since they
> >>> are tied together.
> >>>
> >>> Signed-off-by: Roman Yeryomin
> >>> ---
> >>> package/base-files/files/bin/config_generate | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/package/base-files/files/bin/config_generate
> >>> b/package/base-files/files/bin/config_generate
> >>> index a8311fc595..d7a6829d77 100755
> >>> --- a/package/base-files/files/bin/config_generate
> >>> +++ b/package/base-files/files/bin/config_generate
> >>> @@ -113,7 +113,7 @@ generate_network() {
> >>> set network.$1.proto='dhcp'
> >>> delete network.${1}6
> >>> set network.${1}6='interface'
> >>> - set network.${1}6.ifname='$ifname'
> >>> + set network.${1}6.ifname='@${1}'
> >>> set network.${1}6.proto='dhcpv6'
> >>> EOF
> >>> ;;
> >>> --
> >>> 2.14.1
> >> NACK
> >>
> >> This makes the IPv6 interface dependant on the operational status of
> >> the IPv4 interface; meaning the IPv6 interface will not be started if
> >> the IPv4 interface does not get an IP address.
> >> Especially this would break wan connectivity if the wan link only
> >> supports IPv6
> >>
> >
> > Hmm... right, will just ${1} be better?
> >
> > Regards,
> > Roman
>
> No, there is no real interface called 'wan', so it will simply not work at
> all. Logical netifd interface names can only be used in alias
> configurations, but aliases always add a depenency on the 'up' state of the
> aliased interface (so aliases are mostly useful for interfaces that
> actually depend on each other, like a interface depending on a lower
> interface.
>
> If you want two configurations not to depend on each other, as we usually
> want for IPv4/IPv6 setup, the current version '$ifname' is exactly right.
> It is also the clearest solution semantically: IPv4 and IPv6 uplink are two
> independent configurations that just share the same physical link in the
> most common setups.
In case the interface-name changes dynamically during runtime (such as
for L2TPv3, ...) we could introduce a common parent with proto 'none'
and then have two child interfaces wan4 and wan6 which refer to the
common parent using the '@' notation.
Cheers
Daniel
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] ar71xx: add support for Comfast CF-E312A V2
The Comfast CF-E312A V2 is a 5 GHz radio with a built-in directional antenna,
much like a Ubiquiti NanoStation M5.
Specifiation:
- SoC: AR9344 at 650 MHz
- Flash: 16 MiB (W25Q128FVSG)
- RAM: 64 MiB DDR2 (W9751G6KB)
- Ethernet: 1 x WAN (100 Mbps) and 1 x LAN (100 Mbps)
- Button: 1 x reset button, 1 x PoE pass-through switch
- LED: 8 x LEDS (Power, LAN, WAN, Wireless, 4 signal LEDs)
- UART: 1 x UART with header on PCB (GND, RX, TX, 3.3V)
It is very similar to the CF-316N - similar chipset, etc. The major
differences are:
* It operates at 5 GHz, not 2.4
* All the LEDs are white
* It has 4 signal LEDs
Of note: the eth1 port has an optional PoE pass-through, controlled with a
slider switch.
Most of the changes are in the file
target/linux/ar71xx/files/arch/mips/ath79/mach-cf-e316n-v2.c - the code
for the E316N was copied and modified to support the additional LEDs, the
LED colors, and a few changes in the GPIOs.
Firmware can be flashed on these units by the following method:
1.) Apply power to the unit
2.) Immediately AFTER applying power, hold down the reset button
3.) The WAN, LAN, and wireless lights will flash - wait three seconds
(three flashes) and then release the button.
4.) After a second, the lights will "flutter" quickly and the unit will
be visible at 192.168.1.1. A web page will be available to enable quick
and simple uploading and flashing of firmware.
During the boot process, these units also look for a tftp server at
192.168.1.10. If one is present, the firmware can be uploaded as a file
called "firmware-auto.bin"
Signed-off-by: bmoff...@bmoffitt.com
---
target/linux/ar71xx/base-files/etc/board.d/01_leds | 5 +
target/linux/ar71xx/base-files/etc/diag.sh | 1 +
target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 +
.../ar71xx/base-files/lib/upgrade/platform.sh | 1 +
target/linux/ar71xx/config-4.4 | 1 +
target/linux/ar71xx/config-4.9 | 1 +
.../ar71xx/files/arch/mips/ath79/Kconfig.openwrt | 10 ++
target/linux/ar71xx/files/arch/mips/ath79/Makefile | 1 +
.../files/arch/mips/ath79/mach-cf-e316n-v2.c | 127 +
.../linux/ar71xx/files/arch/mips/ath79/machtypes.h | 1 +
target/linux/ar71xx/image/generic.mk | 8 ++
11 files changed, 159 insertions(+)
diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds
b/target/linux/ar71xx/base-files/etc/board.d/01_leds
index e5baa90..c55a8bc 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -182,6 +182,11 @@ carambola2)
ucidef_set_led_netdev "wan" "WAN" "$board:orange:eth1" "eth1"
ucidef_set_led_wlan "wlan" "WLAN" "$board:green:wlan" "phy0tpt"
;;
+cf-e312a)
+ ucidef_set_led_netdev "lan" "LAN" "$board:white:lan" "eth0"
+ ucidef_set_led_netdev "wan" "WAN" "$board:white:wan" "eth1"
+ ucidef_set_led_wlan "wlan" "WLAN" "$board:white:wlan" "phy0tpt"
+ ;;
cf-e316n-v2)
ucidef_set_led_netdev "lan" "LAN" "$board:blue:lan" "eth0"
ucidef_set_led_netdev "wan" "WAN" "$board:blue:wan" "eth1"
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
b/target/linux/ar71xx/base-files/etc/diag.sh
index 6cbb357..45939ea 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -119,6 +119,7 @@ get_status_led() {
cap4200ag)
status_led="senao:green:pwr"
;;
+ cf-e312a|\
cf-e316n-v2|\
cf-e520n|\
cf-e530n)
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 285fa68..7491f2d 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -504,6 +504,9 @@ ar71xx_board_detect() {
*"Carambola2"*)
name="carambola2"
;;
+ *"CF-E312A")
+ name="cf-e312a"
+ ;;
*"CF-E316N v2")
name="cf-e316n-v2"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 172a58b..fd81bf1 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -215,6 +215,7 @@ platform_check_image() {
bullet-m|\
c-55|\
carambola2|\
+ cf-e312a|\
cf-e316n-v2|\
cf-e320n-v2|\
cf-e355ac|\
diff --git a/target/linux/ar71xx/config-4.4 b/target/linux/ar71xx/config-4.4
index 3ba3853..9682af1 100644
--- a/target/linux/ar71xx/config-4.4
+++ b/target/linux/ar71xx/config-4.4
@@ -67,6 +67,7 @@ CONFIG_ATH79_MACH_C55=y
CONFIG_ATH79_MACH_CAP324=y
CONFIG_ATH79_MACH_CAP4200AG=y
CONFIG_ATH79_MACH_CARAMBOLA2=y
+CONFIG_ATH79_MACH_CF_E312A=y
CONFIG_ATH79_MACH_CF_E316N_V2=y
CONFIG_ATH79_MACH_CF_E320N_V2=y
CONFIG_ATH79_MACH_CF_E355AC=y
diff --git
[LEDE-DEV] [PATCH] strace: Update to 4.20
Compiled and tested on mvebu. Mainly a kernel 4.14 change. Also reordered the Makefile a little bit. Signed-off-by: Rosen Penev --- package/devel/strace/Makefile | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/package/devel/strace/Makefile b/package/devel/strace/Makefile index c7290c6..6209dc5 100644 --- a/package/devel/strace/Makefile +++ b/package/devel/strace/Makefile @@ -9,13 +9,12 @@ include $(TOPDIR)/rules.mk include $(INCLUDE_DIR)/kernel.mk PKG_NAME:=strace - -PKG_VERSION:=4.19 +PKG_VERSION:=4.20 PKG_RELEASE:=1 -PKG_HASH:=7c93ebc6c29280f47c24a0eb86873a99ccb2cac6512c60a60ba4ef99ab807281 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz PKG_SOURCE_URL:=@SF/$(PKG_NAME) +PKG_HASH:=5bf3148dd17306a42566f7da17368fdd781afa147db05ea63a4ca2b50f58c523 PKG_LICENSE:=BSD-3c PKG_LICENSE_FILES:=COPYRIGHT -- 2.7.4 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH resend 3/3] hostapd: bump PKG_RELEASE
On 14-11-17 21:41, Timo Sigurdsson wrote: > Increase PKG_RELEASE after latest changes to hostapd, so downstream > users can fetch updates via opkg. > You should have bumped PKG_RELEASE in the previous commit. I've done that in my staging tree. Thanks, Stijn ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
