On Thu, 11 Sep 2025 21:47:56 +0200
Volker Diels-Grabsch
Stefano Brivio wrote:
memcpy(c->guest_mac, eh->h_source, ETH_ALEN); + info("Guest MAC address: %s", eth_ntop(c->guest_mac, bufmac, sizeof(bufmac)));
This is one line you can break easily instead. But I don't think it should be info(), otherwise the guest can happily spam system logs on the host.
I'm undecided between suggesting debug() or trace(), because on one hand it's a rather relevant information (maybe say "New guest MAC address"?), on the other hand nothing prevents a guest from using a different MAC address every other frame, and make debugging with --debug impossible if this happens.
For debugging this issue that message was extremely helpful, so I strongly recommend to not hide it in trace(). I personally would even like to keep it info(), but I'll demote it to debug() as you request.
I think you're right, it should ideally be info(), but as long as we don't have a mechanism to rate limit messages, we need to be mindful of potential denial of service vectors. System loggers will, in general, not limit us much.
We don't have (yet) a generic rate limiting mechanism for prints. Maybe we could go with trace() for the moment, and the day we have it, switch this to a rate-limited debug() (or even info(), at that point).
In the unlikely case a client really does spam us with an every changing MAC address, we can still easily grep those messages out.
...unless we're using a log file (quite common if we debug) and we exceed the maximum size. There's a mandatory limit on it, again for security reasons, and once we exceed it we start overwriting entries. Of course, if we're debugging a specific issue in this sense, we can just increase the size limit, so debug() should be kind of fine as well.
I'll soon provide v5 of my patch.
Thanks! I'll review it in a bit. -- Stefano