Feature Request / Enhancement

Hi,
Not sure if this is the right place to make a firmware enhancement request, so please migrate this elsewhere as required.

Enhancement Request.
Currently using firmware release 1.1.0063_Release r205 on 7249 and 7258

Please include the hostname in the remote syslog statement.
Currently the log statements are pushed out as follows:

<13>Jul 28 13:19:49 lora_pkt_fwd[1622]: # PUSH_DATA datagrams sent: 0 (0 bytes)

But it would very helpful if this were more compliant with any of the syslog RFCs and included the hostname, for example:

<13>Jul 28 13:19:49 my-rak-7249-001 lora_pkt_fwd[1622]: # PUSH_DATA datagrams sent: 0 (0 bytes)

I’ve got a bunch of these behind a client’s FW and the syslog parser is trying to extract the hostname as per RFC3164 which gives incorrect info and i’m having to create a syslog server port for EACH gateway to be able to identify them individually.

Thanks

Rob

Thanks

While it would seem that according to

https://openwrt.org/docs/guide-user/base-system/system_configuration

the “log_hostname” feature of OpenWRT remote logging only appears in later versions of OpenWRT, it happens that a “log_prefix” is already supported.

From the command line rather than the gui, this should work:

uci set system.@system[0].log_prefix='my-rak-7249-001'
uci commit system
/etc/init.d/log restart

Changes should persist on the overlay filesystem, if they seem not to be you could also modify /etc/init.d/log to inject your prefix somehow. The actual code in even this version of ubox logread.c seems to support a hostname as well as a prefix, its the init script which doesn’t take that from uci and inject it into the daemon.

Thank you.
This is a reasonable workaround for the time being.
The prefix is added but with an extra ‘colon’

PREFIX: message

So the RFC-based parser pulls out the hostname as

my-rak-7249-001:

… with the extra colon on the end.

Presumably your linking to the OpenWRT docs implies that we wait until the RAK firmware is using more recent OS base?

Thanks again.

The enourmous scope of work involved in working around hardware incompatibilities that would come up in changing version makes it quite unlikely, but as explained above you could modify /etc/init.d/log to read the system.@system[0].hostname uci key and pass it to logd with the -h command line option much the way later versions presumably do

--- /etc/init.d/log
+++ /etc/init.d/log
@@ -12,6 +12,7 @@
 validate_log_section()
 {
 	uci_validate_section system system "${1}" \
+                'hostname:string' \
 		'log_file:string' \
 		'log_size:uinteger' \
 		'log_ip:ipaddr' \
@@ -64,7 +65,7 @@
 {
 	PIDCOUNT="$(( ${PIDCOUNT} + 1))"
 	local pid_file="/var/run/logread.${PIDCOUNT}.pid"
-	local log_ip log_port log_proto log_prefix log_remote log_trailer_null
+	local hostname log_ip log_port log_proto log_prefix log_remote log_trailer_null
 
 	validate_log_section "${1}" || {
 		echo "validation failed"
@@ -80,6 +81,7 @@
 		"tcp") [ "${log_trailer_null}" -eq 1 ] && procd_append_param command -0;;
 	esac
 	[ -z "${log_prefix}" ] || procd_append_param command -P "${log_prefix}"
+        [ -z "${hostname}" ] || procd_append_param command -h "${hostname}"
 	procd_close_instance
 }

Or for a minimal but non-standard change, just turn the -P into a -h and pass the existing log_prefix as if it were a hostname

I forget if the stock builds have vi at worst they probably have sed