On Mon, Nov 27, 2017 at 11:12 AM, Borja Salazar <borja.sala...@fon.com> wrote:
> Hi,
>
> Our company is currently developing a service for controlling routers
> via ubus methods from a server. We also would like to received and
> handle different notification from the device, so we would like to
> send as many events as possible. Currently there is already a patch
> for dnsmasq that provides ubus notifications for DHCP ACK and RELEASE
> messages, it would be great if odhcpd implements the same
> functionality. To avoid unwanted notifications we could configure ubus
> notifications via configuration, or only send them if there is anyone
> subscribe to them. Our current use case only needs to know the first
> time a client is detected, so this would also work for us.
>
> Let me know what you think
Hi,
No objection to align both the ubus DHCP ACK and RELEASE notifications
with dnsmasq; but just as in dnsmasq only send the notifications when
there's a subscriber.
Hans
>
> Thanks
>
> Borja
>
>
> On Mon, Nov 27, 2017 at 10:47 AM, Hans Dedecker <dedec...@gmail.com> wrote:
>> On Fri, Nov 24, 2017 at 11:56 AM, Borja Salazar <borja.sala...@fon.com>
>> wrote:
>>> Signed-off-by: Borja Salazar <borja.sala...@fon.com>
>> Hi,
>>
>> Could you describe why you want an ubus event per sent DHCP ack
>> message as potentially this could generate a lot of ubus traffic
>> depending on the leasetime and number of connected clients. Depending
>> on your use case is it enough to have an ubus event when a clients
>> gets active ?
>>
>> Hans
>>> ---
>>> src/dhcpv4.c | 8 ++++++++
>>> src/odhcpd.h | 1 +
>>> src/ubus.c | 19 +++++++++++++++++++
>>> 3 files changed, 28 insertions(+)
>>>
>>> diff --git a/src/dhcpv4.c b/src/dhcpv4.c
>>> index 166582e..ad8d338 100644
>>> --- a/src/dhcpv4.c
>>> +++ b/src/dhcpv4.c
>>> @@ -870,6 +870,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 (msg == DHCPV4_MSG_ACK) {
>>> + char mac_str[13];
>>> + memset(&mac_str, 0, sizeof(mac_str));
>>> + odhcpd_hexlify(mac_str, reply.chaddr, ETH_ALEN);
>>> + ubus_event_bcast("dhcp.ack", mac_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..73e5a49 100644
>>> --- a/src/odhcpd.h
>>> +++ b/src/odhcpd.h
>>> @@ -296,6 +296,7 @@ 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);
>>> #endif
>>>
>>> int netlink_add_netevent_handler(struct netevent_handler *hdlr);
>>> diff --git a/src/ubus.c b/src/ubus.c
>>> index 95eeff7..e988b8e 100644
>>> --- a/src/ubus.c
>>> +++ b/src/ubus.c
>>> @@ -311,6 +311,25 @@ static const struct blobmsg_policy
>>> obj_attrs[OBJ_ATTR_MAX] = {
>>> [OBJ_ATTR_PATH] = { .name = "path", .type = BLOBMSG_TYPE_STRING },
>>> };
>>>
>>> +void ubus_event_bcast(const char *type, const char *mac, const char *ip,
>>> const char *name, const char *interface)
>>> +{
>>> +
>>> + if (!ubus)
>>> + 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
>>>
>>>
>>> _______________________________________________
>>> 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
