Re: tftp

[Martin <inkubus@interalpha.co.uk>]

> > > I can turn the thing on, set the mac address to something sensible,
> > > get an ip from rarpd running on a linux box and start downloading
> > > linux-a.out [for sparc] by tftpboot. The problem is that it doesnt
> > > download the whole image, it stops at some arbitary [spelling?]
> > > point and then tries to execute what it's got -obviously that doesnt
> > > work as it hasnt got the whole image. Any ideas? the tftpd seems to
> > > work ok as i can download the entire image using a tftpclient on
> > > another machine.
> > I've had a similar problem with an SLC stopping at 1ec00 every boot.
> > This was because OpenBoot doesn't respond to ARP requests while it is
> > downloading the image.
> yeah, was watching tcpdump while it downloaded and i couldnt work out
> why the server was continually arping whohas 192.168.0.14 when it should
> know -it just assigned it!! [from /etc/ethers]
Sounds about right - check your arp tables before, during and after the
download - see if that gets you anywhere.

> > Solution - hardware the SPARCs MAC address on the server (arp -s IIRC
> > or /etc/ethers) or increase the ARP time out beyond the couple of
> > minutes taken to tftp the kernel.
> hmm a little googling gives 
> 
> echo 60000 > /proc/sys/net/ipv4/arp_timeout
> but...
> 
> root@nomessin:~# echo 60000 > /proc/sys/net/ipv4/arp_timeout
> bash: /proc/sys/net/ipv4/arp_timeout: No such file or directory
Hmm... your right.
> 
> right, im running kernel 2.4.18 and i think rarpd and arpd are seperate
> from the kernel?
rarpd was moved to userspace in 2.4, arpd (IIRC) is optional - you can
use it or use the kernel's handling.  arpd is more flexible and handles
larger arp table in a better way I'm told.

> root@nomessin:/proc/sys/net/ipv4# rarp -a
> This kernel does not support RARP.
That sounds abotu right.

> root@nomessin:/proc/sys/net/ipv4# /bin/ps ax |grep [r]arpd
>   492 ?        S      0:00 /usr/sbin/rarpd -e -v
> 
> any idea how to increase the arp timeout?
Not off the top of my head... sorry.  However a quick hack around this
is to use arp -s to 'hardwire' the Sun's MAC address - not perfect but
it does work.

> > Additionally I've had problems with a more loaded network - it seems
> > early versions of OpenBoot don't retry if they loose a packet in the
> > middle of the download - they just appear to stop.
> yeah, if the arp thing doesnt work, ill try it with a crossover cable
> (the sparc is on a rather cheap and sometimes busy hub atm)
Sounds like an ARP problem TBH.

> Hugh Saunders [GCv3.12] GCS d- s: a--- C+++ UL++>$ P+ L+++ E--- W-- N++
> K- w-- M- V? PS-- Y PGP- t-- !5 X- R- tv-() b- DI+ D- G++ e- h++ r z?
G!>M d--- s: a-- C++ ULIS++ P+ L+++ E W+ N o? K? w--(---) !O !M !V
PS+(++) PE--() Y+ PGP>++ t 5 X(+) R(+) tv-() b+() DI+ D+ G e>+++(++++)
h(+) r-(*) y++(**)

:-P
 
Sweet Dreams,
 - Martin

-- 
Martin
inkubus@interalpha.co.uk
"Seasons change, things come to pass"