Bug#1002656: bridge-utils: bridge_hw: add random option like for ifupdown hwaddress

2023-06-11 Thread Martin-Éric Racine
On Sat, Jun 10, 2023 at 6:04 AM Martin-Éric Racine
 wrote:
>
> On Fri, 7 Oct 2022 22:34:17 +0200 Santiago Garcia Mantinan
>  wrote:
> > > The kernel using the MAC of a real device, if none is specified, is
> > > precisely what we wanna avoid.  Systemd is not involed.
> >
> > Like I said, if we don't specify the mac address systemd will set up a fake
> > one for us, so... systemd is involved and the kernel is not allowed to use a
> > real one, that's why I said that bridge-utils shouldn't do a thing about
> > this.
>
> No, systemd does not set up a fake MAC address. Rather, the MAC
> address of any PHY attached to the bridge is used if no MAC address is
> specified.

Btw, I vaguely recall you having had to modify the code to stop
showing the IPv6 local-link of wireless devices. Is that correct? If
yes, simply reverting this to have all devices show IPv6 local-link
would be a suitable fix. It would of course introduce a shift in
expected behavior from Bulleseye, but it would at least act
consistently for all interfaces.

Martin-Éric



Bug#1002656: bridge-utils: bridge_hw: add random option like for ifupdown hwaddress

2023-06-09 Thread Martin-Éric Racine
On Fri, 7 Oct 2022 22:34:17 +0200 Santiago Garcia Mantinan
 wrote:
> > The kernel using the MAC of a real device, if none is specified, is
> > precisely what we wanna avoid.  Systemd is not involed.
>
> Like I said, if we don't specify the mac address systemd will set up a fake
> one for us, so... systemd is involved and the kernel is not allowed to use a
> real one, that's why I said that bridge-utils shouldn't do a thing about
> this.

No, systemd does not set up a fake MAC address. Rather, the MAC
address of any PHY attached to the bridge is used if no MAC address is
specified.

Martin-Éric



Bug#1002656: bridge-utils: bridge_hw: add random option like for ifupdown hwaddress

2022-10-07 Thread Santiago Garcia Mantinan
> The kernel using the MAC of a real device, if none is specified, is
> precisely what we wanna avoid.  Systemd is not involed.

Like I said, if we don't specify the mac address systemd will set up a fake
one for us, so... systemd is involved and the kernel is not allowed to use a
real one, that's why I said that bridge-utils shouldn't do a thing about
this.

Regards.
-- 
Manty/BestiaTester -> http://manty.net



Bug#1002656: bridge-utils: bridge_hw: add random option like for ifupdown hwaddress

2022-10-06 Thread Martin-Éric Racine
On Fri, Oct 7, 2022 at 1:01 AM Santiago Garcia Mantinan
 wrote:
> > It would be desirable for bridge_hw to be able to generate a random MAC
> > address as per ifupdown's generic hwaddress syntax.
>
> I don't know if I get this right or not... if you don't want to specify a
> MAC or get it from an interface... then you better not assign any MAC and so
> systemd will do his thing and assign a "random" one.
>
> I really don't think that the code on bridge-utils should generate such a
> random MAC, systemd already causes a lot of trouble by overriding the
> address that the kernel would select, I don't think we need another actor
> here.
>
> Can you justify your request?

The kernel using the MAC of a real device, if none is specified, is
precisely what we wanna avoid.  Systemd is not involed.

Martin-Éric



Bug#1002656: bridge-utils: bridge_hw: add random option like for ifupdown hwaddress

2022-10-06 Thread Santiago Garcia Mantinan
Hi!

> It would be desirable for bridge_hw to be able to generate a random MAC
> address as per ifupdown's generic hwaddress syntax.

I don't know if I get this right or not... if you don't want to specify a
MAC or get it from an interface... then you better not assign any MAC and so
systemd will do his thing and assign a "random" one.

I really don't think that the code on bridge-utils should generate such a
random MAC, systemd already causes a lot of trouble by overriding the
address that the kernel would select, I don't think we need another actor
here.

Can you justify your request?

Otherwise I'll close the bug.

Regards.
-- 
Manty/BestiaTester -> http://manty.net



Bug#1002656: bridge-utils: bridge_hw: add random option like for ifupdown hwaddress

2021-12-26 Thread Martin-Éric Racine
Package: bridge-utils
Version: 1.7-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

It would be desirable for bridge_hw to be able to generate a random MAC address 
as per ifupdown's generic hwaddress syntax.

Possible values for bridge_hw would thereafter be:

MAC
interface
random

MAC|interface would continue working as currently, while random would generate 
a random MAC address for the bridge.

- -- System Information:
Debian Release: 11.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-10-amd64 (SMP w/8 CPU threads)
Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bridge-utils depends on:
ii  libc6  2.31-13+deb11u2

bridge-utils recommends no packages.

Versions of packages bridge-utils suggests:
ii  ifupdown  0.8.36

- -- Configuration Files:
/etc/default/bridge-utils changed:
BRIDGE_HOTPLUG=yes


- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmHIyO0ACgkQrh+Cd8S0
17Yraw/+ORSlJr3mNO42CukYENJpgIQ+DPGgHNsaJJvzYZIqFR+3NS9hJXQpoEJ/
TmFd10iLwzIshvpyc+Bs7LqceXw+PDYR3wW+rPJy567seD7H9ddf9H0XNdY5diFR
NO4z4IK+NDyfs/Bjy1cn4SuOC5YO8exRnZLZgrDQ/uGNalk6haOmoZag3J637b9y
y7Dw7edhvxo5wQw036mx5cc+46gtMOgaphH4jOmfy9lp3UMxsNMRJCSlzcZIbYy/
0K62PVhHaFDbmk/kSKDenmtVySklPhbow3uQtHuybYTNjGlXOwImA2LTHDPcEECi
ZfdOM3n2h80iwlk2qLFrySDMbSGQDQwR6YMsjPY4Yd6oSGSovlkPgrd4YZ2o6xvf
I91CsdICodkbydQjzJkrvhjnI1W/LqXj49+eeSz5fYqE7TbVqp6KD6uoiclW2yI+
qVUdzP7jJVqUeE3StzvL09sXqiw/JrjXyl1y412hCRoVGJQl2Lgj7vvKYcItRZs7
cMWk8P+KYHhyxXkrddjdGJvVylMquu7H1b6AHNVjniu+ui88vvb1zpLudzvpHwh2
wpdAd4M/a+4/j8/jVl3wydp8rvHmrc9MkB84MsXTB+uaJP86GSJeo24XOas1uN5m
yjIkl8Vexjh1+QQaWcP14T2upnM7uY1Sj/5AyFrjk8SJIL5+mlM=
=P6wb
-END PGP SIGNATURE-