Subject: Antwort: [netatalk-admins] atalkd dies away / buy which NIC / I would like to know...

From: [email-masked]
Date: Fri, 12 Nov 1999 15:07:26 +0100

Hihi,

> Admins,
> as a long time subscriber I always wondered about this "conflict-free" 
and 
> "emotionless" list. It was so disciplined. Clean. A bit to clean. Thank 
you 
> for the "I would like to know..." thread - now I know that there are 
people 
> on the other end!

Me too. ;-)))

> *buy which NIC.
> Thanks a lot to Sascha Knific for his "tip" with the Via-Rhine driver 
> enabled NICs. It made my Netatalk server show up in the chooser again. 
Even 
> though one of my networks has a server running the exact card 
> (D-Link550BTX) without any obvious troubles. Nevertheless I would like 
to 
> trash the card an put in another one. Any suggestions (I thought of a 
> 3com905BTX)?

This is not an easy question :-(((.

In the beginning of my liunx history I had a machine with a 3c905 or so 
("Boomerang"). There was a big driver problem - the nic driver closed up
under higher load or after 1 - 2 weeks. This was realy frustrating. So
I started to hate 3com nics (the switches are pretty fine - only to loud 
:-).

The next nics I used in customer PCs were tulip-based (first a 100/10 
Apple 
nic in a PC - runs execelent!; then D-Link). I had no problem with 
netatalk.

After one customer started to use Helios EtherShare we had a similar 
problem
which you had with your via-rhine-based nic (needs "ifconfig eth0 
allmulti"). 
This server has a D-Link DFE-540 (4-port tulip-based). Just to make it 
clear: 
There was no problem with netatalk on this machine - just with Helios!!!!

In my new privat machine I have a Intel EtherExpress Pro/100+ wake on 
lan,...
and I expected it to become a problem. But to my astonishment it ran "out 
of
the box" - no problems like in the past with this nic!!!(???)

I wouldn´t blame you via-rhine nic. As you see you could have this problem
with a DEM 600,- (ca. $ 350) nic. You should have a look at your whole 
enviroment: network, nic, kernel+driver and application (netatalk,...).

> *atalkd dies away.
> Okay some of us have "old" servers running - mine was/is 
> "netatalk-1_4b2+asun2_0a18_2_tar.gz" (running on SuSE6.0-6.2 - 
> 2.2.10kernel) - humin' without a flaw in a production environment. Now 
with 
> a new DES-1024 D-Link switch in the net, I would like to "bump up" the 
network.
> So I got "netatalk-1_4b2+asun2_1_3_tar.gz", compiled, wanted to start, 
BUT:
> atalkd dies away right after I start it with my "/sbin/init.d/atalk". If 
I 
> start atalkd with the "-d" switch, he/she stays up (sure debug goes to 
> STDOUT). I can then do the "network register" etc. Even compiled atalkd 
> with debug symbols, tracing the darn thing with ddd/gdb - but I just 
can't 
> seem to find the problem.
>
>Any ideas? Using the SuSE netatalk*.rpm is _not_ an option for me.
Good starting point!!!

I would first take a recent stable kernel (2.2.13). First I think there 
was
a memory leak in the TCP/IP stack till 2.2.11/12 or so. Second you have a
good chance that you also get a newer (maybe better) nic driver.

Then move all the data from the server to a Mac (client) and delete the
contents of the volumes (i don´t konw exactly in which version but there
was a change in the managment of the resource folk on netatalk - 
I remember that you don´t have to backup all the data but I my opinion
this is a really "clean" solution).

Get the latest netatalk form asun (a the moment 2.1.4-pre36a): 
ftp://ftp.cobalt.net/pub/users/asun/testing/
compile and install it. They are "pre" but really stable.

Move your configuration to the new config files so you will have a 
reference 
of the new options (they increased really a lot!) and check them agains 
the
reference. Don´t forget to restart the machine before you start netatalk 
so
that you don´t have any mess form the old "atalkd"!!!

After that I can´t see any reason why netatalk shouldn´t run smoothly. You 

should see your server in the chooser. If the server starts fine and you
don´t see it in the chooser issue "ifconfig eth0 allmulti" (put it 
somewhere
in the startup scripts).

Copy the data back to the server (watch out for permissions).

Now you should be home and dry.

Good luck,

Sascha Knific