Need Help Improving Zero USB Ethernet Gadget setup / HOWTO

[jlanawalt]

I finally got a Pi Zero and am using it as a pocket-portable USB networked computer with a case and a micro-B plug to A plug USB cable. There are a few guides out there on setting this up, some linked from posts in this forum, but they often seem overly brief. Not keeping up with recent changes like ssh being disabled by default and it's easy work-around is understandable, but other aspects that totally gloss over the underlying networking seems to just lead to confusion. I'd like some help sorting out what's really happening and what works best in general.

Just SSH

For simply ssh'ing to the USB attached Raspberry Pi Zero running in USB device / peripheral / gadget mode we just need a few 'simple' things:

1. dwc2 and g_ether to enable ethernet gadget mode
2. ssh enabled by putting a file named ssh in the boot partition of the SD card
3. a couple of IP addresses in the same subnet, one for the Pi and one for the host computer
4. name resolution so you don't have to know the IP address

The guides are great at point 1. Point 2 can be found documented under ssh on raspberrypi.org. The third point is often glossed over. The fourth point usually works fine from a Mac and recent Linux host and needs help in Windows but this is also discussed.

Using a Zeroconf based IP addresses here seems ideal. We don't need to know what the Pi's address is as long as we can use a name to reach it, and it doesn't care what the host computer's is as long as they are on the same subnet. Ideally a system uses some form of Dynamic Configuration of IPv4 Link-Local Addresses (RFC 3927) to self-assign a link-local IPv4 address after determining that another method like DHCP is not available.

Unfortunately it seems some current Linux based hosts, like Ubuntu for example, default to DHCP and disable the interface instead of falling back to link local addressing when it fails. I am not yet sure how raspbian handles this, it is likely the same. The guides by gbman have you hard code a link-local address, 169.254.64.64, into the Pi.

Internet Sharing

So you can SSH into the Pi and start doing some stuff, but as soon as you try to do anything that requires an Internet connection you're stuck. To get past this hurdle we need a few more things.

1. The host computer's IP address at the other end of our USB network to use as a default route gateway.
2. DNS server address(es) to resolve names with.
3. An advertised routable IP address or to have the host NAT us.

This is the step where Mac and Windows guides say to enable internet connection sharing, but I'm skeptical that that takes care of everything. I can see how it enables NAT (for a Linux host you'd enable a NAT firewall rule) but does enabling that on Mac and PC also enable a DHCP server on the host system for that network?

If so, that could provide to the Raspberry Pi some DNS server addresses and the default route IP address. If not, we've glossed over another detail for people to stumble over. Also, even if it does those things, your Zero had better be configured to use DHCP instead of that hard-coded link local address or, better yet, be configured to automatically switch to DHCP from link local addressing.

At the moment I only have a Ubuntu Linux host to test against, and it's not configured to send DHCP to a random (dev enp0s26f0u1i1) USB network connection when it appears. I'd really rather do as little as possible to the host system. If Ubuntu has an internet sharing button or checkbox that enables NAT and starts a DHCP service on that interface, perfect.

If Mac, Windows, and Linux don't start a DHCP server on the interface they are sharing the Internet connection with then we need to solve the DNS and routing issue on the Zero. It seems the simplest way to do this would be to install and configure dnsmasq for the usb0 interface. It would do this just to give the host computer's end a fixed IP address that we could hard-code as the default route. We could also hard-code some stable public DNS servers, like Google's 8.8.8.8 & 8.8.4.4.

Using dnsmasq provides a chicken and the egg problem. We have to discover the auto-assigned IP at least once to configure our default route. Maybe some scripts wrapping the arp tool would be sufficient. Then the host's IP could be random but we could discover what it is and configure the route.

Once all those pieces are in place it seems you could not only ssh into the Zero over the USB connection, but you could then use the host's Internet connection from the Zero.

Am I on track or up in the night?

Is there already a comprehensive guide that does this?

I would like help finding and writing up the most reliable steps to get this kind of setup working as close to automagically as possible. I would love a solution that works across as many host systems as is reasonable. I'd like to plug into a chromebook and have http://raspberrypi.local/ work, if I were running a webserver on port 80 of the Pi.

--
Jacob

[unisa]

I heartily agree with this post. I had to access numerous web sites to get this going on my mac. The following is the ongoing story with windows in our nteworked computer pools....

For teaching we have been trying setup pi zero in a computer lab using networked computers. In the process i have managed to get on the go working on a personal Mac, and on personal windows. In the computer lab there are restrictions on using administrator mode in Windows 7 and internet shareing is banned becuse of security concerns. Without internet sharing windows does not assign a IP address using DHCP to the gadget end point (is that what you call the device on the host that talks to the zero via ip over usb?). This in turn means that binjour cannot get the address of the pi zero. Assigning a known static Ip address to the pi can be made to work on windows only by manually assiging an IP address to the RNDIS device (gadget end point) but this needs administrator privilidge which students dont have. (Each time you plug in the zero you get a different RNDIS assignment so it cannot be preassigned).

We then tried to use an ubuntu virtual machine on the winodws host using virtual box. But there is very little information on how to set up on the go devices on ubuntu. Strangly enough I got it to work using an ubuntu VM on my mac by setting the network manager to have internet sharing on on both the ubuntu main interface and the gadget endpoint. But when using a ubuntu vM on a windows host this no longer works!

Our last try will be to use link local and assign the pi to a static Ip address in the link local range. Not yet completed

The use of a zero with on the go ethernet mode is potentially very usefull since students can afford to own their personal zeros. But there there needs to be much more documentation to explain how on the go works as far as networking goes. If we ever get it to work on the networked machines I will post a complete run down. In the mean time the labs we plan to run are looking like going down because I cannot understand how on the go interacts with unbuntu.

[tweak42]

At the moment I only have a Ubuntu Linux host to test against, and it's not configured to send DHCP to a random (dev enp0s26f0u1i1) USB network connection when it appears. I'd really rather do as little as possible to the host system. If Ubuntu has an internet sharing button or checkbox that enables NAT and starts a DHCP service on that interface, perfect.

To enable internet sharing on Ubuntu using the Network Manager GUI: edit the wired connection assigned to the Pi Zero, select IPv4 (or IPv6) Settings tab, change the Method from Automatic (DHCP) to Shared to other computers. Wait for the ethernet interface to assign 10.x.x.1 address. The Pi Zero should see the dhcp server advertisement and request an address. On my system the raspberrypi.local name never resolves so I have to find the IP address using avahi-discover or a netdiscover scan.

Note: since the mac address to the Pi Zero changes at every boot, you need to change the Shared to other computers setting every time booting the Zero. There's probably a way to assign a static mac address to avoid that, but I haven't looked yet.

[jlanawalt]

Thank you for both your insights. I hope we're able to share what works and find a setup, or a few setups, that are flexible and can really take advantage of the Zero's Ethernet Gadget mode.

It seems that the ideal setup for attaching to a Mac, Windows, or Linux computer should be using a zeroconf auto assigned link-local address that will switch over to a DHCP assigned address should the host computer provide one. The default configuration of the dhcpcd5 software on the current Raspbian does this. With this setup if things are working right then Windows, and Mac are suppose to, and Linux should, assign their interface an IPv4 link-local (IPv4LL) address. If they listen on that interface with Bonjour then raspberrypi.local should resolve to whatever address the Pi self-assigned. If they enable internet connection sharing, they will send a DHCP announcement and the Pi Zero should switch over to that address and work.

Ubuntu

Testing with Ubuntu the first problem I ran into was that the default Network Manager DHCP setting doesn't seem to fall back to IPv4LL addressing when it isn't given an address via DHCP. If I switch the connection to Link-Local only things generally work fine and the avahi daemon resolves raspberrypi.local for me so it doesn't matter what IP the Pi Zero self-assigns on the link-local network. If I switch the interface to Shared with other comptuers, the Pi picks up the DHCP assigned address and DNS setting and is able to access the Internet. Before I figured those settings out I was using the suggested hard-coded link-local address for the Pi Zero and setting a manual IP address in the same 169.254.0.0/16 network.

If I could figure out how to make the IPv4 DHCP option fall back to link-local addressing this would have been smoother. Also the host end of the link-local connection appears to get a random MAC each time, making a new Network Manager connection entry each time. Switching the Device in the Ethernet settings for the connection to just the device name, ejp0s26f7u1, stopped new ones from appearing. These same tweaks should apply to any Linux based Desktop system using Network Manager.

Windows

Windows used the Automatic Private Internet Protocol Addressing to assign a link-local address to their end of the USB "ethernet network" and the Pi did the same on it's end, but it was a pain to find the address since raspberrypi.local wasn't resolving despite Bonjour being installed. At one point it resolved to it's IPv6 address but I wasn't able to get even that to repeat. Enabling Internet Connection Sharing made Windows give a DHCP address to and act like a DNS proxy for the Pi Zero. It was easier to find the Pi on the /24 network it assigned than it was on the /16 link-local network. If zeroconf name resolution was more reliable, this would have been an easy setup.

Macintosh

I haven't gotten a system to test this yet, but from what I've read the internet connection sharing should work similarly to the one for Windows. It will give a DHCP address to devices on the link-local interface, give them DNS and NAT their requests to the Internet.

Chromebook

In normal mode I wasn't ever able to see the USB interface. Using an SSH browser plug-in to access raspberrypi.local never seemed to work. I think the Chromebook doesn't expect to share a network connection or work with IPv4LL addressing. Switching to developer mode I was able to manually assign an address on the USB interface within the link-local network and ssh to the Pi Zero once I found it's random IP address. When the lock screen happened the connection seemed to go away and sometimes took a lot of extra steps to reset the connection.

While the Mac, WIndows, and Linux solutions had some trouble, it seems they will work best with the Pi using a link-local address and being able to sense and switch to a DHCP offered address for Internet access. It would be helpful if the Pi could use a static link-local address and still fall back to DHCP. We woudn't have to rely on a broken Bonjour setup or trying to arp-ping or nmap the whole /16 network and could just ssh to a known address like 169.254.3.14.

For the Chromebook, it might help if the Pi Zero ran a DHCP server to offer the Chromebook host an IP address for the other end of the link. I still have a lot more testing to do on this.

[michaelnewham]

Chromebook

..Switching to developer mode I was able to manually assign an address on the USB interface within the link-local network and ssh to the Pi Zero once I found it's random IP address..

Hi jlanawalt,

Could you provide steps on how to do the above? Have tried unsuccessfully to ssh over USB on a MacBook and now trying same using Chromebook.

I can ssh over wireless using my own network - but - not through USB as i can't find USB when i use the command 'ifconfig' after ssh'ing in over wireless.

All i see with that command is -
lo Link encap:Local Loopback
and
wlan0 Link encap:Ethernet

All help appreciated!
Michael.

Ifconfig only showing two interfaces

Ifconfig.jpg (55.02 KiB) Viewed 12491 times

[ElderOfPsion]

I've been working on this issue also. The tutorial at NovaSpirit is marvelous, up to a point. Ditto, the Adafruit tutorial.

The device boots, the homemade USB connector works, and the device can be accessed from the host computer via ssh. The Zero can even give the host PC its own IP address (huzzah for DHCP, /etc/network/interfaces, and dnsmasq). Unfortunately, the host computer refuses to use the Zero's DNS server, even when explicitly told to do so.

The command 'dig @192.168.42.1 google.com' returns a sensible value. Everything is working except the DNS resolution. IP forwarding is on, the firewall is set up properly, and yet the techniques that worked on the Pi 3 don't work on the Pi Zero.

Could it be related to the fact that the device emulates Ethernet via USB? That would explain why bridging doesn't work.

[scruss]

It also helps to have a stable MAC address so that your host machine can recognize the same Zero on the same connection setup.

[callahanp]

Like many on this thread, I've been puzzling through the various bits of information and howto pages on connecting a raspberry pi through USB using the g_ether driver, dwc2 and the RNDIS protocol. At this point I can ssh from Linux to the Pi. One problem with this is that when I boot the Linux box and the PI together, the MAC address is not the one I configured on the Pi. So for Now I'm powering up the Pi after Linux is up and running. The other problem is a lengthy amount of time spent in network manager, possibly waiting for the pi connection to resolve.

There's a large number of posts on this forum and many others with questions and partial answer to the problem of connecting a Pi-Zero via USB.

Here's the problem in a nutshell:

We need ssh access to the PI-Zero AND we need access to the internet from the pi-zero at the same time. We want the connection to be automatic, and to not require re-configuration after each boot. While this is almost trivial for Pi models with Ethernet or wireless features, it's not so easy for the Pi-Zero.

I'd like to form a team willing to work on properly documenting ssh and a working Pi internet connection for the special case of a PI-Zero.

I'd want to end up with not just a cookbook of configuration details, but information on the underlying technologies and software. I'd like to know what the configuration details actually do to make the connections work on each platform. While there's lots of configuration specifics out there for the Pi-Zero, There's little information about how these connections work behind the scenes and the differences making the connections on different Operating Systems.

Any takers? If you want to work on this with me, contact me through the forum by sending me an e-mail. Click on callahanp at the right.

- Pat Callahan
Dec 2017
Masschusetts USA

Here's what I'm looking for on each platform: Linux, MacOS, Windows.

In general, I want information on every aspect of the connection between the pi, the box running ssh and the internet. This includes not just configuration items, but the software pieces that use the configuration item or otherwise process the IP packets. I want information not just on how the software sets up a connection but what the software does during an exchange of IP packets.

On the PI:
* What drivers are loaded to make the connection to the PI. What causes them to load, When they are loaded and what specific configuration items do they use. What exactly are dwc2 and g_ether? Are they configured? How? When?
* When and how is the Pi's MAC address on the USB connection determined
* Why booting the pi and my linux box at the same time gives me different MAC addresses even though the Pi is configured with a static MAC address.
* How and when does the Pi gets its IP address, Gateway IP address and DNS information when making the USB connection.
* How and when does the Pi get its host name.

On the box running ssh
* What drivers are loaded to make the connection to the PI. What causes them to load, When they are loaded and what specific configuration items do they use. What are Bonjour and Avahi and what specifically do they do with configuration items? How are they involved in a connection over USB or the internet.
* How to delay the connection so the PI determines the MAC for both ends of the USB connection..
* How to ensure that the IP packets for Internet connections on the PI make it from and to the PI.
* How does the USB connection get it's IP address. Is anything else needed to make the internet connection.
* How does routing work with a USB connection.
* Can we configure a specific host name for the PI, without using .local
* Can we ssh to raspberrypi.local and still get to the internet from the pi?

PI-Zero <--> software/config? <--> USB Port <--> Cable <--> USB Port <--> software/config? <--> usbx* <--> software/config? <--> SSH

PI-Zero <--> software/config? <--> USB Port <--> Cable <--> USB Port <--> software/config? <--> usbx* <--> software/config? <--> The Internet

* as seen in ipconfig or ifconfig

[scruss]

Andrew Mulholland still actively maintains his documents: Raspberry Pi Zero – Programming over USB! (Part 1) | Andrew's blog

On the network sharing from a host computer issue, that will need some constant vigilance. Search engines make this harder as they favour older results as being “settled” answers. When facts change quickly it's very hard to find the right answers. F'rinstance, searching for "ubuntu share network" gave useful information that worked up until last year. From Ubuntu 2017.10, though, the network setup has changed completely but Google and others still return the old incorrect answers over the newer, correct results (which I'm yet to find …)

[callahanp]

I've read Andrew's posts and they don't really address the internet connection, except in a very general way. Its more focused on connecting a single device via ssh.
I'm beginning to understand the elements that make up the connection from the PI through USB to my linux box and to understand what configuration items are needed to make both ssh to the pi and access to the internet from the pi work at the same time.

I'm doing the setup in a bash script for linux here: https://github.com/callahanp/raspberryp ... h-internet

If you have time, take a look and tell me what you think.

-Pat

By the way, I too have noticed that the internet is getting more and more cluttered with:

Questions that people have about an issue, with requests for help or more information, often without any response from anyone
When there are responses, they're either further questions, or they are answers that fall into these categories:

* A few really good insightful answers
* More pretty good answers
* Good answers that don't address your particular situation
* Good answers at the time they were given, but that no longer apply to current versions of software
* Incomplete answers
* Ill conceived, irrelevant or just plain wrong answers.

[thagrol]

It might be better to use network bridging on the USB host end rather than NAT/connection sharing. With bridging the pi should get its IP address from your router and be on the same subnet as the host with full access to that network and the internet if present.

Also for what it's worth, I've got a part written python script to generate fixed MAC addresses for g_ether. Give me a few days and I'll put it up on github.

[scruss]

I'm beginning to understand the elements that make up the connection from the PI through USB to my linux box and to understand what configuration items are needed to make both ssh to the pi and access to the internet from the pi work at the same time.

I'm doing the setup in a bash script for linux here: https://github.com/callahanp/raspberryp ... h-internet

The script seems mostly to repeat Andrew's work of setting up the modules and overlays in /boot, rather than focus on the network configuration. Also, running gedit under sudo will cause xhost issues (== not work at all) on some machines like this Ubuntu box.

[thagrol]

Also, running gedit under sudo will cause xhost issues (== not work at all) on some machines like this Ubuntu box.

Use gksudo instead, it has magic that copes with the xhost security issues or gksudo --disable-grab if you don't want it to block your entire x server.

[ejolson]

Also for what it's worth, I've got a part written python script to generate fixed MAC addresses for g_ether. Give me a few days and I'll put it up on github.

I would like to see how you do fixed MAC addresses. It would appear that only locally administered MAC addresses, that is those with the second bit of the first octet set, can be used with the host_addr and dev_addr module options for g_ether. At the same time
/lib/udev/rules.d/73-usb-net-by-mac.rules generates predictable device names only for universally administered MAC addresses, that is, those which have the second bit of the first octet set. The assumption appears that locally administered MAC addresses will be randomly generated and there is no point in adding a randomly generated suffix to the network device.

So I set the MAC address using the g_ether.host_addr and g_ether.dev_addr options to a nonrandom locally administered MAC address as a boot option. They appear to work and generate the expected messages in the log files from legacy/ether. However, there are also log messages which appear twice stating that random MAC address have been generated. Furthermore, if you disconnect the USB gadget and then reconnect it, the random one appears in place of the fixed one I set. Any help fully disabling the random MAC addresses would be very much appreciated.

[thagrol]

I've a python script that generates a couple of MAC addresses from the Pi's serial number. It then passes those to g_ether via a modprobe command to load g_ether. And yes, those are in the locally administered block.

You can find it here: https://github.com/thagrol/usb-gadget

For what it's worth, I'm still using jessie on all my PIs, and don't generally hot-plug on the PC end with the PI powered seperately. After all why use two cables to the PI when one will do?

[thagrol]

Just checked hot plugging.

With dtoverlay=dwc2 in /boot/config.txt, the default /boot/cmdline.txt, nothing related to g_ether in /etc/modules and calling my script either from /etc/rc.local or manually from a root shell I get consistent MAC address derived from the PI's serial number across both hotplugs at the host end (with PI powered seperately) and across cold plugs (PI powered down and unplugged).

As an aside, for a project I'm working on I'm looking into extending that script to set a unique hostname and make both hostname and IP address available to the host. No eta on that at the moment though.

Edit:
Might be a strech vs jessie issue. Will investigate if I can find a spare SD card though I know next to nothing about udev.

[callahanp]

Let's take a look at where things stand. We have a number of approaches to this problem. That's fine, if we can keep them all straight.
There's no one right way to do this. Consider Unisa's perspective about the security issues in a lab. I hadn't thought about such things. These are things that will need to be taken into account if we're trying to document procedures for the wider community.

Rather than try to write about your approaches, I'm going to let you do that.

I'll review anything you write in this thread closely.

I think there's much to be gained if we can clearly explain to each other our approaches and the issues we encounter while trying to get them fully working.

My approach is this:

Configure everything statically on the SD card before the first boot. The card gets plugged in and you can simply ssh into a known host pi-zero and its already on the internet. That's a goal folks. I don't have it fully working yet, but I am making progress.

There's a wiki at at https://github.com/callahanp/raspberryp ... ernet/wiki.
If you like, you can include something on your approach there. I'd like to see that wiki include information about different approaches and a list of tasks needed for each different approach.. Feel free to include links to your own projects related to connectivity for the Pi-zero. The wiki's just a bunch of notes to myself right now, but I'll try to get it more organized soon.

-Pat

[thagrol]

The approach I'm taking is to put together a set of tools that will auto configure g_ether and hostname with unique values and mkae those easily visible to the USB host along with the PI's ip address.

The end goal is to have one SD card image that will allow multiple PI zeros to be connected to one USB host with no preboot configuration needed.

[thagrol]

OK. I think I've got things working, at least with linux hosts. There's an issue with windows that stops it installing drivers for g_multi.

If you want to try this, grab fdd.img, g_ether_fixed_mac.py, getserial.py, set_hostname.py, and set_id.py from https://github.com/thagrol/usb-gadget

Make sure all files are in the same directory and that at least set_id.py is executable.

Run

Code: Select all

sudo ./set_id.py

The first time you run this, or if you run it after moving the SD card to a different PI you'll get a reboot when the hostname is changed so if running over ssh expect to lose your connection. There is also a built in 15 second delay to allow the network to come up.

What you get after running set_id.py is

• A new hostname in the form "pi-<serial number>"
• A pair of MAC addresses generated from prefixes in the locally adminstered block and the PI's serial number which are then passed to the gadget driver
• Two files in /boot (hostname.txt & ip_address.txt) containing the new hostname and a list of IP addresses for the PI.
• A small, read only USB mass storage device containing the above files. This can be mounted on the host (e.g. sudo mount /dev/sda /mnt) to access their contents

For a more permanent installation arrange that set_id.py is called by root at the end of the boot sequence.

Know issues:

• Not working with windows hosts due to g_multi driver issue mentioned above

• Code: Select all

  dtoverlay=dwc2

  must be present in /boot/config.txt
• The usb gadget moudle (g_multi, g_ether etc) is loaded by set_id.py and must not be loaded by any other method.
• It's probably best to remove any existing configuration you have for g_ether etc from the usual places.
• No check for PI hardware model/version is present so expect weird stuff to happen if run on models that don't support gadget mode. At the very least the hostname will still change.
• Has only been tested on jessie

This is very alpha. Use entirely at your own risk.

The easiest way to change your hostname back is

Code: Select all

sudo hostnamectl set-hostname <new name>
sudo reboot

[ejolson]

So I have a zero connected to a B+ through a Sabrient 7 Port USB hub which powers both devices and am looking at the output from netperf. My results are

Code: Select all

Source      Destination       Throughput
 Pi B+       Pi Zero           47.59 Mbps
 Pi Zero     Pi B+             84.90 Mbps

Simultaneous Transfers
 Pi B+ to Zero        Pi Zero to B+
  4.27 Mbps            93.95 Mbps

which indicates that throughput in one direction is faster and the discrepancy increases when there is traffic in both directions. Similar results have been reported in a previous thread.

Setting MTU to jumbo packets using "ip link set usb0 mtu 7418" on both devices results in

Code: Select all

Improved Results Using Jumbo Packets

Source      Destination       Throughput
 Pi B+       Pi Zero           78.99 Mbps
 Pi Zero     Pi B+            134.12 Mbps

Simultaneous Transfers
 Pi B+ to Zero        Pi Zero to B+
  60.71 Mbps           110.68 Mbps

which is much more reasonable.

While it is known that jumbo packets increase GB Ethernet throughput, I haven't seen a discussion about using jumbo packets with Pi Zero gadgets. At anyrate, it apparently works and works well.

[ejolson]

So I have a zero connected to a B+ through a Sabrient 7 Port USB hub which powers both devices and am looking at the output from netperf.

I now have an initramfs that I can place in a boot partition that switches the Zero to gadget mode and mounts the root filesystem over NFS. This required adding about 5 modules to the standard initramfs and then specifying boot=nfs and other usual Linux Debian options in cmdline.txt for mounting root over nfs. Thus, it is not necessary to purchase an expensive sdcard for the Zero, as the sdcard only needs to be large enough to hold the boot partition.

[callahanp]

Where things stand for Linux:
There are several individuals in this thread, working on this from various perspectives and with varying skillsets.
There are at least two github projects, one using python, one using bash for scripting.

Issues encountered:
* Local Only IP Addresses can't be bridged
* Network Manager connection gets broken when you let it handle the RNDIS connection
* Repeated connect and disconnect messages from Network Manager
* Strange behavior by certain NICs - The device is there but can't be used without removing the RNDIS connection from network Manager and rebooting.
* Changing random IP and MAC addresses with each reboot
* Assigning Random Mac addresses even when the configuration on the pi specifies a specific MAC
* Timing the loading and use of g_ether module on the PI so we don't end up with a random MAC address
* Routing packets from the USB Ethernet connection to the WAN is not automatic under Network Manager

All of these issues have solutions noted somewhere. I don't think there's a comprehensive answer yet, but there are people who have been successful configuring the pi and the connection to achieve a fully connectable Pi-Zero using a combination of the following techniques:

* Start the g_ether module only after the main computer has fully booted and connected to the internet. This has been done by loading g_ether after a timed delay.
* Assign static mac addresses for both ends of the USB connection. Thagrol's script assigns the MAC address based on the pi-Zero serial number.
* Using DHCP to assign ip addresses to both ends of the USB connection. Static routing will also work. "Local Only" IP addresses prevent connection to the internet so don't use them. This will mean that you do not ssh to RaspberryPi.local
* Using a bridge or IP Masqerade to get the pi on the internet. Note that Local only connections apparently can't be used.
* ssh to the pi can be done using the pi's IP address. We can probably configure things to use the pi's hostname with some routing configuration.

I think these are the scripts we'll need

1. On the host (which could be a regular Raspberry Pi or some other Linux box):
a. while the sd card is attached to the host, install the script for the pi (2) and do any configuration not handled in realtime by the script.
b. configure the host
2. On the Pi: Delay until the host is up and running. Load the module and start the rndis connection. Also for testing, some kind of restart option, with or without the delay.
if needed:
3. On the host, re-configure or start anything on the host as needed after the pi starts up and the rndis connection is present.

I'm off to read Thagrol's script and will be back with more of a spec of what the parts of the scripts need to do, step by step.

As this is for the Raspberry Pi, Python looks to me like the best bet for readability by the largest number of potential users. Bash can be a bit inscrutable to the beginner so I'm tossing my version out. C or C++ only if absolutely needed.

[ejolson]

* Start the g_ether module only after the main computer has fully booted and connected to the internet.

Another method, which seems to be working well here, is to boot the Zero using rpiboot. Copy the boot partition from Zero's SD card to the main computer and then make the SD card non-bootable by deleting the files from the boot partition. At power on the Zero waits on the main computer to transfer the files that would have been in the boot partition through USB using the rpiboot program. Now, since the Zero can't even start booting until the main computer transfers the needed files, this ensures that the main computer is fully up and running before the Zero loads the Ethernet gadget.

[callahanp]

rpiboot seems like a reasonable way to proceed.

What is the difference in time between booting over usb vs from an sd card?

Does your host run linux?

Is your host another Pi?

[ejolson]

What is the difference in time between booting over usb vs from an sd card?

In the simplest case, the bootstrap, kernel and some drivers are transferred using rpiboot in 15 seconds, then everything else proceeds from the SD card as before. Thus, rpiboot adds at most 15 seconds to the boot time. If you are booting multiple Zero's there is a bigger performance hit, because the transfers using rpiboot can only be performed one Zero at a time.

Does your host run linux? Is your host another Pi?

Yes, I'm using a Pi B+ as the host. I'm not sure whether rpiboot can be made to work with Microsoft Windows or Apple OS/X. Using a heterogeneous mixture of different operating systems and system architectures definitely makes things more complicated.