[SHR-testing] problem connecting to pc, and solution

[Previdi Roberto]

hello. after having upgraded the shr-testing (reflash, wifi-> opkg
update, opkg upgrade) i wasn't able to connect to my pc, because the
g_ether module insisted to use his default 00:1f.... mac address, and
when connecting to pc the pc udev assigned to him an ethX interface
name instead of usbX, disabling all the iptables and ifconfig
configured settings.
the solution i found was to give some options to the g_ether module, like this:

root@om-gta02 ~ $ touch /etc/modprobe.d/options
root@om-gta02 ~ $ echo "options g_ether host_addr=32:99:58:ea:d0:49
dev_addr=32:99:58:ea:d0:50" >> /etc/modprobe.d/options

(it's 2 lines, the second one will probably appears truncated in the email)
(i think you can invent the mac addresses by your fantasy, i just
think they should be different, and don't start with 00. anyway, these
2 works for me)
so, if anybody is having the same probem, you know what to do.

now some questions to somebody more expert:
- i tried to put this "options" file in /etc/modutils/ and executed
update-modules, but at the reboot the module completely ignored it.
after executing update-modules i found the /etc/modules.conf file
empty (just a "this file is generated..." comment at start) and
another /etc/modules file with the merged lines from /etc/modutils,
and with my options too. still, this file seems not to be used at the
module loading time. My question is: can /etc/modutils/*,
/etc/modules.conf and /etc/modules altogether be removed so people
don't lose hours trying to use them? or maybe they must be used in a
way i didn't understand?
- if i set a different mac address for each one of my om
distributions, could i assign a different ip address (from my pc
side), in order to not have all the ssh key conflicts each time i
reflash or just change my fr running distribution? i think it's matter
of writing some configuration rules for ifconfig, but is there some
example around?

btw, many compliments to all the developers of shr and fso, this is
getting very good!

--
roby

_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel

[Mike Westerhof (mwester)]

Previdi Roberto wrote:
> hello. after having upgraded the shr-testing (reflash, wifi-> opkg
> update, opkg upgrade) i wasn't able to connect to my pc, because the
> g_ether module insisted to use his default 00:1f.... mac address, and
> when connecting to pc the pc udev assigned to him an ethX interface
> name instead of usbX, disabling all the iptables and ifconfig
> configured settings.

Yes, this is actually a bugfix.  The "default 00:1f...." mac address you
mention is not a default at all -- that's the real mac address assigned
to the USB interface from the factory for your GTA02.  The bug was that
when g_ether was built as a module, the real mac address (passed in on
the command line by Qi) was being ignored.  This inconsistency is now
fixed; for SHR g_ether will always honor the bootloader's options.

BTW, the reason Qi does this in the first place (beyond the fact that
letting g_ether use random mac addresses when Openmoko has provided
proper ones is just silly) is that the use of a fixed mac address makes
the usb network connection play nicer with many network manager
applications on host systems, including Windows systems.  (Yes, we
support Windows hosts - we may not prefer to use them, but we do support
them.)

> the solution i found was to give some options to the g_ether module, like this:
>
> root@om-gta02 ~ $ touch /etc/modprobe.d/options
> root@om-gta02 ~ $ echo "options g_ether host_addr=32:99:58:ea:d0:49
> dev_addr=32:99:58:ea:d0:50" >> /etc/modprobe.d/options
>
> (it's 2 lines, the second one will probably appears truncated in the email)
> (i think you can invent the mac addresses by your fantasy, i just
> think they should be different, and don't start with 00. anyway, these
> 2 works for me)

Actually, you really can't just "invent" them; there is a pattern that
is required in order to ensure that the mac address signifies a local
(i.e. random) address, and is not a multicast (IIRC) address.  Someone
can look up the details with google if interested.

> so, if anybody is having the same probem, you know what to do.

That's only part of the "solution" -- the startup scripts for SHR take
care to pass in the options from Qi, which will conflict with the
host_addr and dev_addr added here.  See below for my thoughts on how to
address this.

> now some questions to somebody more expert:
> - i tried to put this "options" file in /etc/modutils/ and executed
> update-modules, but at the reboot the module completely ignored it.
> after executing update-modules i found the /etc/modules.conf file
> empty (just a "this file is generated..." comment at start) and
> another /etc/modules file with the merged lines from /etc/modutils,
> and with my options too. still, this file seems not to be used at the
> module loading time. My question is: can /etc/modutils/*,
> /etc/modules.conf and /etc/modules altogether be removed so people
> don't lose hours trying to use them? or maybe they must be used in a
> way i didn't understand?

This is a good question for the upstream folks to sort out.  IIRC, there
are a lot of ways to handle modules, and different distros have done so
differently, and some of this is deprecated...

> - if i set a different mac address for each one of my om
> distributions, could i assign a different ip address (from my pc
> side),

Well, that is EXACTLY the problem that this fix was designed to address
in the first place!

To revisit: Qi reads the unique mac address assigned to the GTA02 from
its "factory" partition at boot -- this mac address is passed in on the
kernel boot command line.  This mac address is not only unique -- it's
official (it comes from a block of mac addresses assigned to Openmoko).

So clearly, that is the mac address you wish to use.

The problem you encountered (eth<n> on the host instead of usb<n>) is a
problem you need to fix on the *host* side, not on the FR side.  You can
try to find the code in your host's udev configuration that detects the
mac address as being local (and names the interface usb<n> therefore)
and fix it so that all mac addresses are treated that way.  But frankly,
I think you would find it far far easier to just adjust your network
configs to support eth<n> instead.  It might help to think about the
configuration in terms of what happens when you have two FR plugged in:
you'll have (for example) eth1 and eth2 appearing.  The udev mechanism
on your host will sort out which FR is eth1 and which is eth2, and will
get it right each time (because g_ether is passing the correct Openmoko
mac address on each FR).  So you need to assign network addresses and
netmasks such that routing is done correctly.

 in order to not have all the ssh key conflicts each time i
> reflash or just change my fr running distribution? i think it's matter
> of writing some configuration rules for ifconfig, but is there some
> example around?

It's far easier than that -- you just have to edit the
/etc/network/interfaces file to set the static IP address and netmask
you have determined each of your FRs should have (matching the setup you
configured on your host system).

No examples are documented; at this level the configuration is not
unique to the FR, nor even to USB-based networking -- it's stock,
standard, TCP/IP network configuration.

Footnote: For users of u-boot who may wish to use this functionality, it
is relatively easy to add this to your u-boot options.

 - First, find the mac address assigned to your FR: mount the factory
partition (mount -o ro -t ext2 /dev/mtdblock5 /mnt).  Then cat the
contents of the usb file (cat /mnt/usb).  The output will look like
"U:00:1F:11:12:34:56"; your mac address is 00:1f:11:12:34:56 (and 57,
the next one in the sequence is also assigned to your FR and available).

 - Boot to NAND flash, connect to u-boot in the normal way, then edit
your bootargs variable to append the correct parameters in the same way
that Qi would do.  Mine looks rather like this when I'm done:

bootargs_base=rootfstype=jffs2 root=/dev/mtdblock6
console=ttySAC2,115200 console=tty0 loglevel=8 ro
g_ether.host_addr=00:1F:11:12:34:56 g_ether.dev_addr=00:1F:11:12:34:57

 - Save your changes in u-boot after you have verified that all looks well.

 - Boot.  Once booted up, use "ifconfig" on the FR to view the mac
address being used by the FR, if you did everything correctly, you'll
see your mac address being honored.


Footnote to the Footnote: if this is rather too complicated, and you
u-boot users feel strongly that it needs to work without any
modifications to the u-boot environment, then somebody should open a bug
on the SHR trac, and all interested parties should comment on that bug
-- if there is sufficient interest, we can investigate a means to
automatically do this for u-boot users as well.


Final Footnote: if you feel that you really don't like this change, and
you wish to revert to the old (broken) way -- just rename the
/etc/init.d/g_ether.sh file to something else.


Regards,
Mike (mwester)

Absolutely Final Footnote:  It would be nice if someone who finds this
useful would add it to the SHR wiki.

_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel

[sirio marchi]

> when connecting to pc the pc udev assigned to him an ethX interface
> name instead of usbX, disabling all the iptables and ifconfig
> configured settings.

i made my fix adding a specific rule to udev.
i prefix that i use a gentoo and i have only modified an auto generated rule in /etc/udev/rules.d/70-persistent-net.rules file but i think it works fine in other distributions.
the rule is:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="your-usb-interface-mac-address", ATTR{type}=="1", KERNEL=="eth*", NAME="neo-eth"
which means that udev matches the moko "eth*" and renames it with "neo-eth" throught the mac address of your USB interface.
you have to pay attention that only the first rule that assigns the key NAME (NAME="neo-eth") to a specific device is valid, the next ones will be ignored.
for the meanings of other rules read the udev man page.

at the and you have to:
1) reload udev rules with: udevadm control --reload_rules
2) unplag/plag the moko
3) see changes with: udevadm info --attribute-walk --path=/sys/class/net/neo-eth

you can increase the log amount with: udevadm control --log_priority=debug

also in gentoo:
1) i have to make a link to /etc/init.d/net.lo: ln -s /etc/init.d/net.lo /etc/init.d/net.neo-eth
2) and i need to mv my old /etc/conf.d/net.usb0 configuration to /etc/conf.d/net.neo.eth

finally, you can make a ifconfig and see the "neo-eth" interface up

sirio

_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel