Subject: Antwort: [netatalk-admins] atalkd dies away / buy which NIC / I would like to know...
From: knific@ibm.net
Date: Fri Nov 12 1999 - 09:07:26 EST
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
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:17:25 EST