From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=none (p=none dis=none) header.from=njh.eu Received: from mail.notjusthosting.com (mail.notjusthosting.com [IPv6:2a01:4f8:a0:516f:1::1]) by passt.top (Postfix) with ESMTPS id D3EE65A0271 for ; Thu, 11 Sep 2025 21:47:57 +0200 (CEST) Received: from echelon-telekom.c-base.org ([80.147.140.51] helo=vlap) by mail.notjusthosting.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1uwnGv-00068S-AU; Thu, 11 Sep 2025 21:47:57 +0200 Date: Thu, 11 Sep 2025 21:47:56 +0200 From: Volker Diels-Grabsch To: Stefano Brivio Subject: Re: [PATCH v4] Send an initial ARP and NDP request to resolve the guest IP address Message-ID: References: <20250910113632.80620-2-v@njh.eu> <20250910113632.80620-4-v@njh.eu> <20250910163218.620bfef7@elisabeth> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250910163218.620bfef7@elisabeth> Message-ID-Hash: KCAPUB2BAYT3WIMLMFP7ATZTQKZEA2QR X-Message-ID-Hash: KCAPUB2BAYT3WIMLMFP7ATZTQKZEA2QR X-MailFrom: v@njh.eu X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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. > 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. I'll soon provide v5 of my patch. Best regards, Volker -- .---<<<((()))>>>---. | [[||]] | '---<<<((()))>>>---'