From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: References: <20180413181618.24144-1-sven@narfation.org> <78ec0422-9046-3db1-6a81-4c1c7d0c9968@unstable.cc> <1658833.3ZLkxubxK8@sven-edge> From: Antonio Quartulli Message-ID: Date: Sat, 14 Apr 2018 16:11:28 +0800 MIME-Version: 1.0 In-Reply-To: <1658833.3ZLkxubxK8@sven-edge> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tyRd6pWtka3IUFsNWRJdykft4yY2VP5r8" Subject: Re: [B.A.T.M.A.N.] [PATCH] batctl: Validate translated mac addresses List-Id: The list for a Better Approach To Mobile Ad-hoc Networking List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sven Eckelmann Cc: The list for a Better Approach To Mobile Ad-hoc Networking , Andre Kasper , linus.luessing@c0d3.blue This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tyRd6pWtka3IUFsNWRJdykft4yY2VP5r8 Content-Type: multipart/mixed; boundary="9Hanvker29eHvdwZGhuVpuU6yqtmKzrag"; protected-headers="v1" From: Antonio Quartulli To: Sven Eckelmann Cc: The list for a Better Approach To Mobile Ad-hoc Networking , Andre Kasper , linus.luessing@c0d3.blue Message-ID: Subject: Re: [B.A.T.M.A.N.] [PATCH] batctl: Validate translated mac addresses References: <20180413181618.24144-1-sven@narfation.org> <78ec0422-9046-3db1-6a81-4c1c7d0c9968@unstable.cc> <1658833.3ZLkxubxK8@sven-edge> In-Reply-To: <1658833.3ZLkxubxK8@sven-edge> --9Hanvker29eHvdwZGhuVpuU6yqtmKzrag Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 14/04/18 15:10, Sven Eckelmann wrote: > On Samstag, 14. April 2018 04:34:42 CEST Antonio Quartulli wrote: >> >> On 14/04/18 02:16, Sven Eckelmann wrote: > [...] >> We already handle the case of multiple originators handling the same M= AC >> address, no? In that case I think we pick the "best" originator. >=20 > Yes, but this doesn't make a lot of sense for multicast and zero mac=20 > addresses. The translate layer of batctl is usually used to ping/tracer= oute to=20 > some originator. But multicast and zero mac addresses don't represent a= =20 > "client" which can be used to identify some originator. So it doesn't s= eem to=20 > make sense to allow them here. Right. >=20 > Or even without the ping/traceroute stuff, the concept of calling `batc= tl=20 > translate` should give you an answer which you can understand. So it sh= ould=20 > tell you that batman-adv is very likely to transmit a unicast packet wi= th this=20 > destination address to this originator. But this cannot work for multic= ast=20 > destination addresses because multiple answer should be given here - wh= ich is=20 > out of scope for this command. Which reminds me that I should propose a= second=20 > patch which checks whether the input for translate_mac is "valid" befor= e=20 > trying to translate it. >=20 >> This case sounds more like a validity check because "a zero MAC should= >> not be in the translation table", or am I wrong? >=20 > Partially, yes. I personally don't care (at the moment) whether there i= s a=20 > zero mac address in the translation table. The current translation tabl= e code=20 > (batadv_tt_local_add) doesn't check whether there is a zero mac address= =20 > (is_zero_ether_addr). But Linus had some ideas when zero mac addresses = can be=20 > useful - maybe he tell us whether it makes sense/problems to have them = in the=20 > translation table. Yeah, I agree that zero "may appear" in the table and therefore we have to "check" what we are getting back and whether it makes sense for us in this context. Actually my comment was not about changing your approach, but just making it more explicit in the commit and in the error message. An error message like like "returned invalid all-zero mac address" (or "multicast address") might help to distinguish similar "ambiguities" in the future. No? Cheers, >=20 > Kind regards, > Sven >=20 --=20 Antonio Quartulli --9Hanvker29eHvdwZGhuVpuU6yqtmKzrag-- --tyRd6pWtka3IUFsNWRJdykft4yY2VP5r8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEERdCuyFSHc3WdqS4EB6U8WA7yzXQFAlrRt7AACgkQB6U8WA7y zXTpAw//b4rcU9XolEms6BdyONSbSyD4WNZXiXe2vhGwUORvvGpB/CXTgVWewHCV +WYhuoqZ2IRgQuLo+a2zkrMN1d4zgK5D/hc+m/yhExciP6WWffg3QqL5kSIMHXkd LwnW9upg0KAbaLHhkfdtZoGdp8z8Hi8qpwisagOMy9x7BA0rOlUwlRX6HtruJpbg nkTyIRm3I4fDlBxGEt/XOvzfx9b10MP2dhdzBB9tFadwssaRkVJHvG6wzDDgAoY6 xFU83QVl3Ins3KiaQR7qGLpRydzA5bc+CLhO89mV2TTF0YFFDbto6hoq0V5v1PMl EtLCfhC4If2fpD8n43xRQK4q7zm0eydooInkguMrlbNg1gF3IFsBiZg06BUwAvTj mUFIB+7B7LYDHVzT8UbuNx4Zh3OSYOUOCHhVDLfujpwfXGvqTkmTwaYEwbPLJD9b wvOSjaZyXSXa08ydF10FuGzEjncNmevqZVTUjhRSXXvGHABxTOQtQaOw3ssGyeKD 9hxb0DbJhMYqe2fahlW7XlOmSsNgavndUfBeaZu2KqPzUCDSOx/3nAoVNfrHJI5+ s1vadN3oAEkXz3p4fwgOKG6whlcZ4vqfJj5vWhrV1mdIiyvX/3oofpQrYoZn/6Fk q0+R6OkLlEF4l4k2Y1ZK6dCLhCtqPsKsfrEYXhrmAn74L75mBaY= =evEE -----END PGP SIGNATURE----- --tyRd6pWtka3IUFsNWRJdykft4yY2VP5r8--