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