Subject: [netatalk-admins] Question about routing...

From: Bob Krzaczek <[email-masked]>
Date: Tue, 12 Jan 1999 22:00:30 -0500 (EST)

I've seen this asked previously on the list without an answer; I'm asking
it again, with a couple of alternative questions, in the hopes that
someone may have some useful advice.

First off, though, I'd like to report wild success with setting up a small
Solaris box as a print spooler (backended with LPRng) for several
networks. The increase in *perceived* speed to the user's workstation is
tremendous! (Papd pretty much accepts data as fast as it can, so from the
Mac's point of view, the job "completes" much faster than before, when we
printed directly to the devices).

My problem is this: the aforementioned Solaris box has several ethernets.
One of those is a "martian network" (192.168) that I don't want any
traffic routed into or out of. This network contains devices that I don't
want visible to any client machine. As has been mentioned before, netatalk
acts as a router between all interfaces present on the local machine; this
is a problem.

My first thought is: Is there a way I've overlooked to tell Netatalk *not*
to automatically route everywhere? If not, any suggestions on attacking
atalkd before I dive in?

My second thought: Is there a way I can name a Zone such that it won't
appear in the scroll list for AppleTalk Zones in a Mac's Chooser? That is,
is there a character, perhaps intentionally "bad" or "poor", that will
cause a Mac to disregard an entry? (Yes, I know this is bad juju.)

My third thought: What can I read to learn how printer "capturing" works
(a la NT)? I've suffered with it in the past, found lots of references
about it, but not found any that actually *describe* what is going on. I
might potentially add a capture utility (and extend papd accordingly) to
the existing netatalk suite, if this works out.

As you might guess, the goal here is to prevent certain devices from being
available to your average Mac user. I'm front-ending these devices with
Unix machines, mostly to do access control and reporting. (For example,
one type of dye-sub printer costs approx. $2.50 per page to run; leaving
this device wide open and accessible in a networked academic campus-wide
environment can become a bit of a problem.)

Thanks in advance for any feedback; I will summarize and post back to the
list whatever information anyone shares with me.

-- 
// Bob Krzaczek, RIT Center for Imaging Science, <[email-masked]>

---

From: Bob Krzaczek <[email-masked]>
Date: Mon, 18 Jan 1999 05:36:58 -0500 (EST)

[My apologies if you see this twice; I sent this on the 13th and never
 saw it in the list or its archives at zeitgeist. Since it's a patch that
 I suspect some might find useful (having seen questions similar to my
 first post on netatalk-admins before), I'm resending it Just In Case.]

Well, I continued looking around, and came across the patch for
Netatalk-1.3.3 by Stefan Bethke. Apparently, I've been looking in the
wrong FAQs... :-/

Based on what I saw in Stefan's patch, I made a similar one for
Netatalk-1.4.2 with the current asun-2.1.2 patchset (what I'm running
here). It adds a commandline "-R" option to atalkd that will disable
routing between all interfaces.

I note that the zone names are still advertised on multiple networks.
While less than optimum, it's okay for now; I simply needed to kill the
routing of traffic between network interfaces. Also, the patch is strictly
development quality: it could be sped up (for example, if we aren't going
send packet X, we don't need to build it. I left the code in place,
though, to disturb as little of atalkd as I could. When I'm more
comfortable with atalkd in the future (or if someone else beats me to it)
I'll clean it up.

The patch is attached, feel free to use it, edit it, improve it, and so
forth (it's a trivial patch). Caveat emptor: it's working for me on a
Solaris system with three ethernet interfaces, your experience may differ.

Cheers...