Properly impliment bootstrapping via a ZIP GetNetInfo request when configured as a non-seed router.

[NJRoadfan]

When configured as a non-seed router on an Ethernet interface, TashRouter does the following:
-Waits for a RTMP broadcast to learn the current network number range.
-Send a ZIP Query to build the zone list.

The above works perfectly on LocalTalk networks and is the way to bootstrap on those networks as ZIP GetNetInfo is NEVER used on LocalTalk. The problem with Ethernet networks is that this could lead to the wrong zone being chosen as the default zone. Right now, TashRouter assumes that the first zone on a zone list received from a ZIP Query is the default zone, which may not actually be the case (although if the seed router is netatalk's atalkd, this is always true). The only way to get the correct default zone for an extended network is to send a ZIP GetNetInfo packet.

Below is how the Shiva Fastpath starts itself if not configured to seed a network. Netatalk is similar with some key differences:
-On power-up or reset, the Fastpath sends an AARP probe for an address in the startup range.
-(If a RTMP broadcast occurs before the next step, the Fastpath will run another AARP probe in the detected network range)
-Once the Fastpath has an address, it broadcasts (or sends directly to a router if it got a RTMP packet already) a ZIP GetNetInfo packet without a zone name, as this always returns the default zone.
-Once the Fastpath receives a reply from this request, it builds the zone table using the default zone from the ZIP GNI reply and configures itself to the correct network range. If the Fastpath doesn't receive a response, it keeps periodically sending out ZIP GNI packets until somebody responds.
-Finally, the Fastpath sends a ZIP Query to the router on the network to finish building its zone information table. It does this regardless of what the "Only One Zone" flag is set to in the ZIP GNI reply.

Netatalk, does something similar to the above except that it never gleans network information from RTMP packets, it only configures itself from ZIP GNI responses. Its also possible to have stale network information in the atalk.conf configuration file, so it may broadcast the ZIP GNI packet from an invalid network number.

In addition, Netatalk supports "soft seeding". If configured to seed a network, it will send out three ZIP GNI packets to check if there isn't an existing seed router on the network. If one is found, it checks that its configuration matches its own. If so, it completes startup and starts RTMP broadcasts (you can have more then one seed router on a network), otherwise it stays offline and enters a ZIP GNI loop until the conflicting router is removed from the network.

One important thing about ZIP GetNetInfo requests. The router must keep track of when it sends packets out and ignore unsolicited ZIP GNI replies at all other times.