The device sends its syslog datagrams from its WiFi address even when a wired Ethernet interface is up and carrying all other traffic. Syslog should prefer the wired LAN and use WiFi only when no LAN connection exists.
Current behaviour
Measured on 2026-09-05 and 2026-09-06 during release validation of C64 Ultimate 1.2RC. Both machines had wired Ethernet up and working, and both were configured with Network Settings / Log to Syslog Server = 192.168.1.185:5514.
| Device |
Firmware |
Commit |
FPGA |
Services answer on |
Syslog arrives from |
| C64 Ultimate |
1.2RC |
6e1530b0 |
125 |
192.168.1.146 (Ethernet) |
192.168.1.129 (WiFi) |
| Ultimate 64 Elite |
3.15 |
8fb73523 |
125 |
192.168.1.13 (Ethernet) |
192.168.1.70 (WiFi) |
The C64 Ultimate answers REST, FTP and Telnet on its Ethernet address. The Ultimate 64 Elite was checked over REST. Each device was sent a REST request, and the source address of the syslog lines that request produced was read off a collector bound to UDP 5514. In both cases the source address was the WiFi address, not the Ethernet address the request had been sent to.
Why this is a problem
A tool that resolves a device by hostname and then matches incoming syslog by source address cannot attribute the log. The name resolves to the Ethernet address, the datagrams carry the WiFi address, and nothing on the REST surface reports the device's interfaces, so the second address cannot be discovered automatically.
In this repository's own end-to-end harness the effect is visible: datagrams land in syslog-unknown-sender.txt and the run reports that the device sent nothing. The harness has to be told the WiFi address by hand through its U64_LOG_ADDRESSES environment variable before device logs are attributed at all. That variable exists because of this behaviour. Its own documentation in tests/lib/syslog_collector.py states that "an Ultimate 64 on both Ethernet and WiFi answers REST on one and sends its log from the other".
Requested behaviour
Send syslog over the wired LAN whenever a wired interface is connected. Fall back to WiFi only when there is no LAN connection.
Context, not part of the requested change
This section describes the wider principle for outgoing traffic so the reader can see where syslog sits. It is background only.
- For request/response services such as REST, FTP and Telnet, a reply should leave on the same interface the corresponding request arrived on.
- For traffic the device originates rather than answers, such as streaming and syslog, the device should always use LAN, and use WiFi only when no LAN is connected.
Out of scope
Audio streaming currently supports LAN only. This issue does not request any change to audio streaming, and should not be read as requesting one. Audio streaming is named above only to complete the picture of outgoing traffic. The change asked for here is limited to the interface syslog is sent from.
The device sends its syslog datagrams from its WiFi address even when a wired Ethernet interface is up and carrying all other traffic. Syslog should prefer the wired LAN and use WiFi only when no LAN connection exists.
Current behaviour
Measured on 2026-09-05 and 2026-09-06 during release validation of C64 Ultimate 1.2RC. Both machines had wired Ethernet up and working, and both were configured with
Network Settings / Log to Syslog Server = 192.168.1.185:5514.6e1530b08fb73523The C64 Ultimate answers REST, FTP and Telnet on its Ethernet address. The Ultimate 64 Elite was checked over REST. Each device was sent a REST request, and the source address of the syslog lines that request produced was read off a collector bound to UDP 5514. In both cases the source address was the WiFi address, not the Ethernet address the request had been sent to.
Why this is a problem
A tool that resolves a device by hostname and then matches incoming syslog by source address cannot attribute the log. The name resolves to the Ethernet address, the datagrams carry the WiFi address, and nothing on the REST surface reports the device's interfaces, so the second address cannot be discovered automatically.
In this repository's own end-to-end harness the effect is visible: datagrams land in
syslog-unknown-sender.txtand the run reports that the device sent nothing. The harness has to be told the WiFi address by hand through itsU64_LOG_ADDRESSESenvironment variable before device logs are attributed at all. That variable exists because of this behaviour. Its own documentation intests/lib/syslog_collector.pystates that "an Ultimate 64 on both Ethernet and WiFi answers REST on one and sends its log from the other".Requested behaviour
Send syslog over the wired LAN whenever a wired interface is connected. Fall back to WiFi only when there is no LAN connection.
Context, not part of the requested change
This section describes the wider principle for outgoing traffic so the reader can see where syslog sits. It is background only.
Out of scope
Audio streaming currently supports LAN only. This issue does not request any change to audio streaming, and should not be read as requesting one. Audio streaming is named above only to complete the picture of outgoing traffic. The change asked for here is limited to the interface syslog is sent from.