g_ether wont apply host mac address

[xbipin]

i have the below in my cmdline.txt file
modules-load=dwc2,g_ether g_ether.dev_addr=8e:7a:7e:37:6f:bb g_ether.host_addr=8e:7a:7e:37:6f:aa

the problem is it applies the dev_addr mac id to usb0 but the host_addr doesnt apply at all so the PC sees a random mac id always.

im on the latest kernel 4.9.37

[xbipin]

it does on a windows machine but not on a freebsd machine even though its recognized as a RNDIS gadget

[burtyb]

When I had a similar issue I needed to add g_ether.use_eem=0 so the other (Linux in my case) end used cdc_ether rather than cdc_eem where IIRC the protocol doesn't support passing a MAC address - might be worth a try.

[xbipin]

i tried but its still same, below is what appears in freebsd

ugen0.2: <Linux 4.9.37+ with 20980000.usb> at usbus0
cdce0: on usbus0
cdce0: No valid alternate setting found
device_attach: cdce0 attach returned 6
cdce0: on usbus0
cdce0: faking MAC address
ue0: on cdce0
ue0: Ethernet address: 2a:3f:38:a3:80:00

i added that inline in the cmdline.txt, correct me if im wrong

[xbipin]

is there a way to set a vendor and product id so freebsd can recognize it as a know device so it can read the mac id which the rndis gadget supplies?

[maitredede]

Hi,
I am starting using usb gadget, and if I understand well, there are 2 ways to configure gadget mode.
First is yours (in first post), the other is by using libcomposite. I followed this tutorial for gadget configuration, and it seams that you can easily replace each bits...

[JamesH65]

This issue will be closed within 30 days unless further interactions are posted. If you wish this issue to remain open, please add a comment. A closed issue may be reopened if requested.

[gmcn42]

I can confirm that this bug still exists on Raspberry Pi Zero. The g_ether module will randomly not respect the host_addr option given to it, regardless if using the kernel command line, an option file in modprobe.d or simply "modprobe g_ether host_addr=00:11:22:33:44:55". All three approaches work only intermittently. More often than not, the host will have a randomly generated MAC regardless of what was specified.

Interestingly, the syslog output of the module seems to reflect that soemthing is wrong with the MAC generation internally:

Jul 23 08:50:59 raspberrypi kernel: [   82.963954] using random self ethernet address
Jul 23 08:50:59 raspberrypi kernel: [   82.963978] using random host ethernet address
Jul 23 08:50:59 raspberrypi kernel: [   82.963994] using host ethernet address: 00:22:82:ff:ff:20 **## This is the one I manually specified, so should be correct**
Jul 23 08:50:59 raspberrypi kernel: [   82.964000] using self ethernet address: 16:78:91:65:a2:e9
Jul 23 08:50:59 raspberrypi kernel: [   82.965526] usb0: HOST MAC 00:22:82:ff:ff:20
Jul 23 08:50:59 raspberrypi kernel: [   82.966796] usb0: MAC 16:78:91:65:a2:e9
Jul 23 08:50:59 raspberrypi kernel: [   82.966870] using random self ethernet address
Jul 23 08:50:59 raspberrypi kernel: [   82.966885] using random host ethernet address **## contradictory**
Jul 23 08:50:59 raspberrypi kernel: [   82.966992] g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
Jul 23 08:50:59 raspberrypi kernel: [   82.967005] g_ether gadget: g_ether ready
Jul 23 08:50:59 raspberrypi kernel: [   82.967025] dwc2 20980000.usb: bound driver g_ether

After this output usb0 had a random MAC on the host side. This makes it very hard to have a predictable DHCP setup. I would kindly ask that you reopen this issue.

[smanley]

Also having this issue w/most current pi zero build. host_addr is ignored.

Worked around it by manually greping dmesg after boot, mapping the port to the connected device and then configuring manually. This is not ideal and defeats the purpose of hotplugging.

Please reopen.

[xbipin]

this needs to be reopened

[smanley]

I did some more looking into this; I had the specified host_addr appear once after unplugging and plugging in the pi; it isn't consistent, though suggesting some sort of race maybe. It never worked from a cold boot, e.g. booting the host system and the pi at the same time.

It would be really sweet if this worked properly, using pi zeros as camera peripherals.

It appears this issue has existed for some time?

[pelwell]

Alright - I'll take a look.

[smanley]

Much appreciated and happy to help debug.