[PATCH 2/2] lldpd: fix init.d script
John Crispin
john at phrozen.org
Fri Dec 11 06:44:33 EST 2020
On 11.12.20 09:30, Bjørn Mork wrote:
> John Crispin <john at phrozen.org> writes:
>
>> iff --git a/package/network/services/lldpd/files/lldpd.init b/package/network/services/lldpd/files/lldpd.init
>> index 7a5b25e016..8200556786 100644
>> --- a/package/network/services/lldpd/files/lldpd.init
>> +++ b/package/network/services/lldpd/files/lldpd.init
>> @@ -10,6 +10,10 @@ LLDPSOCKET=/var/run/lldpd.socket
>> LLDPD_CONF=/tmp/lldpd.conf
>> LLDPD_CONFS_DIR=/tmp/lldpd.d
>>
>> +service_triggers() {
>> + procd_add_reload_trigger lldpd
>> +}
>> +
>> find_release_info()
>> {
>> [ -s /etc/os-release ] && . /etc/os-release
>> @@ -38,6 +42,10 @@ write_lldpd_conf()
>> for iface in $ifaces; do
>> local ifname=""
>> if network_get_device ifname "$iface" || [ -e "/sys/class/net/$iface" ]; then
>> + if [ -e "/sys/class/net/$ifname/bridge" -o -e "/sys/class/net/$ifname/lower_bridge" ] ; then
>> + local ports=$(jsonfilter -i /etc/board.json -e "@.network.$iface.ifname")
>> + [ "${ports// /,}" ] && ifname="${ports// /,}"
>> + fi
>> append ifnames "${ifname:-$iface}" ","
>> fi
>> done
>
> Doesn't this assume too much about /etc/config/network names always
> matching /etc/board.json? How about just getting the bridge ports from
>
> /sys/class/net/switch/brif/*
>
> if the configured interface resolves to a bridge?
>
> Note BTW: The "bridge" in "lower_bridge" is the name of the symlink
> target. It's not a static name. Try creating a subinterface under
> something that isn't named "brigde" :-)
>
>
>
> Bjørn
Hi Bjørn,
correct, this is not the ideal solution right now. using
/sys/class/net/switch/brif/* is also quirky as devices might later be
added or removed (wifi). Right now the code is totally de-funct and this
patch will fix it for a vast number of std use cases. I plan to pay some
attention to lldpd post release and also add a small ubus interface.
This would then be usable to listen to netifd notifications, thus fixing
the problem properly.
This patch does however improve the current situation a lot.
John
More information about the openwrt-devel
mailing list