[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