At 13:08 Uhr +0000 02.06.2000, Konstantin Reznitsky wrote:
>> I know the term "primary interface" only with MarsNWE. Could you explain this
>further?
>The first interface you define becomes the primary one. Afpd by default will bind to
>the first zone on this interface unless
>forced othewise in the startup of the afpd itself (something like
>server_name@zone_name).
Okay. But is that important if I configure all interfaces as seeding and allow routing?
eth0 -seed -phase 2 -net 40-49 -addr 41.1 -zone "PoC-Net"
eth1 -seed -phase 2 -net 50-59 -addr 51.1 -zone "PoC-Net"
tap1 -seed -phase 2 -net 5 -addr 5.2 -zone "PoC-Net"
>> > > asun recomended to upgrade to the latest by then kernel, but that did not help.
>> He wrote that to me, too.
>But with me it was RH-6.1 and I think kernel 2.2.12 :) awhile ago...
I used Kernel 2.0.33 this time. :-)
>If you really can deal with the code of atalkd (I'm not good enough, sorry) I can
>give you couple more tips:
>1. Could get it working not only when both primary interfaces were set for the link,
>but also with only one being on the link and
>another one on the external network (this might be the way to get it working in the
>longer chain);
Uhm. I'm thinking that it's not important where actually afpd binds to if one uses
atalkd as a router.
In the example above, tap1 is the last device. But a nbplkup shows:
leela:AFPServer 5.2:130
QMS-Spool:LaserWriter 5.2:128
leela:netatalk 5.2:4
leela:Workstation 5.2:4
So it binds all to the last defined interfaces.
>2. I want to confirm what you said about routing, rtmp and zip are actually working
>the problem seems to be in the propagation
>of the nbp information;
I confirmed that with (t)ethereal. Listening to the link (tap) device shows the
nbp-requests from the remote side. Listening to any other interface (eth0 or eth1)
doesn't show up the nbp-requests. So it's quite clear that forwarding nbp requests
won't actually happen with atalkd (as it should do).
>3. My experiment was not really clean - one of the boxes had different types (3Com
>PCI and ISA NE2000) of the network
>adapters and that seemed to affect the situation as well ( in the mater of swapping
>the network interfaces it was giving
>different results).
Let me citate from README.ASUN:
>problems with appletalk:
> certain ethernet card/drivers don't deal well with the fact
> that appletalk aggressively uses hardware multicast. here are
> a few ones that may cause problems:
> ne2000 clones
> 3Com501 cards (maybe others)
> intel etherexpress/pro
> set multicast_filter_limit=3 in linux if you're having
> problems with this card. to do that, add the following
> line to /etc/conf.modules:
> options eepro100 multicast_filter_limit=3
>(that's why I'm interested in the solution).
Quite clear :-)
>I hope this will give you something...
Not to much but may thanks for your explanations!
>I'm also still interesed in the information on the appletalk routing. I asked this
>question before and got contrary answers.
>It has to do with redundant routing and equal cost multipath, is it doable with
>appletalk? Any Ideas?
I didn't test it but as stated in my answer to your question a time ago, I think it
should work.
:wq! PoC
