Subject: Problems booting Indigo...

From: Jan-Benedict Glaw <[email-masked]>
Date: Tue, 30 May 2000 03:29:58 +0200

Hi!

I've now build a kernel which I would like to test on my Indigo;) The
problem is that I can't load it;( I tried bootpd as well as ISC dhcpd.
The result is actually just the same:

>> bootp()parkautomat:/tftpboot/vmlinux.ip12                                    
No server for parkautomat:/tftpboot/vmlinux.ip12                                

I tried to do with "parkautomat:", with IPs ("192.168.1.4:"), I leaved
the server totally off the string, I used bootpd and dhcps with rfc1048,
with cmu (bootpd), I checked the "SQE dip switch" at the AUI->10baseT
transceiver. setenv/unsetenv netaddr didn't make a difference, too...
I checked dozends of combinations, but there's no server seen by the
Indigo;(

/etc/bootptab:
ip12:\
        :ht=ethernet:\
        :ha=08006906ba2e:\
        :bs=auto:\
        :vm=cmu:\
        :ip=192.168.1.3:\
        :sm=255.255.255.0:\
        :sa=192.168.1.4:\
        :bf=vmlinux.ip12:\
        :to=7200:
        
tcpdump shows:

[root@parkautomat:/root] #> tcpdump -i eth0 -n
tcpdump: listening on eth0
01:46:03.979150 arp who-has 192.168.1.3 tell 192.168.1.3
01:46:03.979864 192.168.1.3.68 > 255.255.255.255.67: xid:0xa0d5 secs:5 C:192.168.1.3 [|bootp]
01:46:03.982352 192.168.1.4.67 > 255.255.255.255.68: xid:0xa0d5 secs:5 C:192.168.1.3 Y:192.168.1.3 S:192.168.1.4 [|bootp] [tos 0x10]
01:46:08.408974 192.168.1.3.68 > 255.255.255.255.67: xid:0xa0d5 secs:10 C:192.168.1.3 [|bootp]
01:46:08.411526 192.168.1.4.67 > 255.255.255.255.68: xid:0xa0d5 secs:10 C:192.168.1.3 Y:192.168.1.3 S:192.168.1.4 [|bootp] [tos 0x10]
01:46:13.408851 192.168.1.3.68 > 255.255.255.255.67: xid:0xa0d5 secs:15 C:192.168.1.3 [|bootp]
01:46:13.411166 192.168.1.4.67 > 255.255.255.255.68: xid:0xa0d5 secs:15 C:192.168.1.3 Y:192.168.1.3 S:192.168.1.4 [|bootp] [tos 0x10]
01:46:18.408664 192.168.1.3.68 > 255.255.255.255.67: xid:0xa0d5 secs:20 C:192.168.1.3 [|bootp]
01:46:18.411001 192.168.1.4.67 > 255.255.255.255.68: xid:0xa0d5 secs:20 C:192.168.1.3 Y:192.168.1.3 S:192.168.1.4 [|bootp] [tos 0x10]

So there are four requests, four replys, but none of them seems to be
seen;( Can anybody tell me how to boot the kernel? The "Diskless
Workstation Administration Guide" didn't help a lot... Maybe I can
(if nothing else helps...) boot the kernel through the tape? If so,
how di I have to put the kernel onto the tape? How to load it off?

MfG, JBG
PS: Hacking the kernel was done in one evening, trying to boot it costed
    dome days...

-- 
Fehler eingestehen, Größe zeigen: Nehmt die Rechtschreibreform zurück!!!
/* Jan-Benedict Glaw <[email-masked]> -- +49-177-5601720 */
keyID=0x8399E1BB fingerprint=250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB
     "insmod vi.o and there we go..." (Alexander Viro on linux-kernel)

---

From: Richard van den Berg <[email-masked]>
Date: Tue, 30 May 2000 09:46:24 +0200 (MET DST)

> No server for parkautomat:/tftpboot/vmlinux.ip12

Just after doing this, does the machine show in the server arp table with
`arp -a`? If so forget this mail, if not issue (of course with the right
addresses) `arp -s 192.168.1.15 08:00:2B:2D:90:C0`

DECstation <-> bootp has following quirk: power it on and let
automatically boot and all goes well. Power it on and leave for a while (a
quarter of an hour) at the PROM-console and then booting, forget it unless
I use the arp -s command...

Regards,
Richard

---

From: "J. Scott Kasten" <[email-masked]>
Date: Tue, 30 May 2000 11:36:59 -0300

Sounds like it's using RARP first to translate it's MAC into an IP
address, then hitting the bootp server secondly - already knowing it's IP
address - and just requesting info on the server/file to actually boot
strap itself.  Sun boxes work that way.  You need to add a static arp
entry for them if they netboot.  Otherwise, after about 10 - 15 minutes or
so when other boxes on the net start flushing their arp caches, your
stuck.

--

J. Scott Kasten
Email: jsk AT tetracon-eng DOT net

"The only future you have is the one
 you choose to make for yourself..."

---

From: Jan-Benedict Glaw <[email-masked]>
Date: Wed, 31 May 2000 00:11:12 +0200

> addresses) `arp -s 192.168.1.15 08:00:2B:2D:90:C0`

Good hint. After playing some (long...) more with different combinations
of any piece of software installed here, I'm currently making steps 
in the very right direction:

Here my uHowTo:
==========================================================================
- Server Side:
	- Kernel here is 2.4.0-test1-ac4, so arp(8) no longer knows "pub":

	  [root@parkautomat:/root] #> arp -s 192.168.1.3 08:00:69:06:BA:2E

	  192.168.1.3 is Indigo's IP address, 08:00:69:06:BA:2E is its
	  hardware address (one can find it by giving the "eaddr" command
	  at serial console)
	- ISC dhcpd from .deb (2.0-3) with very short config:
---------------->8========================
option domain-name "lug-owl.de";
option domain-name-servers 192.168.1.1;
option subnet-mask 255.255.255.0;
default-lease-time 600;
max-lease-time 7200;
subnet 192.168.1.0 netmask 255.255.255.0 {
}
host indigo {
  hardware ethernet 08:00:69:06:ba:2e;
  fixed-address 192.168.1.3;
  filename "/tftpboot/vmlinux.ip12";
  option tftp-server-name "192.168.1.4";
}
======================8<------------------------
	- in.tftpd installed (0.10-1)

Client Side:
	- You have to *remove* the netaddr variable:
	  >> unsetenv netaddr
	- Then try to boot:
	  >> boot bootp()/tftpboot/vmlinux.ip12

Effect: The Indigo gets its config, but unfortunately it seems that
incoming tftp UDP packets are not accepted. This might be because
the originating port is != 69 (which is tftp):

[root@parkautomat:/root] #> tcpdump -i eth0 -N not port ssh
tcpdump: listening on eth0
22:26:27.205401 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0xa223 secs:5 [|bootp]
22:26:27.376706 parkautomat.bootps > 255.255.255.255.bootpc: xid:0xa223 secs:5 Y:indigo S:parkautomat [|bootp] [tos 0x10]
22:26:27.377730 arp who-has indigo tell indigo
22:26:27.631528 parkautomat.bootps > indigo.bootpc: xid:0xa223 secs:5 Y:indigo S:parkautomat [|bootp] (DF)
22:26:27.638649 arp who-has parkautomat tell indigo
22:26:27.638814 arp reply parkautomat is-at 0:e0:98:16:22:80
22:26:27.639345 indigo.8740 > parkautomat.tftp: 35 RRQ "/tftpboot/vmlinux.ip12"
22:26:27.922485 parkautomat.1028 > indigo.8740: udp 516 (DF)
22:26:32.915339 parkautomat.1028 > indigo.8740: udp 516 (DF)
22:26:37.915225 parkautomat.1028 > indigo.8740: udp 516 (DF)
22:26:42.915152 parkautomat.1028 > indigo.8740: udp 516 (DF)
22:26:47.915233 parkautomat.1028 > indigo.8740: udp 516 (DF)
22:26:57.054788 indigo.8741 > parkautomat.tftp: 35 RRQ "/tftpboot/vmlinux.ip12"
22:26:57.125679 parkautomat.1028 > indigo.8741: udp 516 (DF)
22:27:02.125199 parkautomat.1028 > indigo.8741: udp 516 (DF)
22:27:07.125235 parkautomat.1028 > indigo.8741: udp 516 (DF)
22:27:12.125247 parkautomat.1028 > indigo.8741: udp 516 (DF)
22:27:17.125586 parkautomat.1028 > indigo.8741: udp 516 (DF)
22:27:27.054101 indigo.8742 > parkautomat.tftp: 35 RRQ "/tftpboot/vmlinux.ip12"
22:27:27.108923 parkautomat.1028 > indigo.8742: udp 516 (DF)
22:27:32.105253 parkautomat.1028 > indigo.8742: udp 516 (DF)
22:27:37.105143 parkautomat.1028 > indigo.8742: udp 516 (DF)
22:27:42.105251 parkautomat.1028 > indigo.8742: udp 516 (DF)
22:27:47.105618 parkautomat.1028 > indigo.8742: udp 516 (DF)
22:27:57.053731 indigo.8743 > parkautomat.tftp: 35 RRQ "/tftpboot/vmlinux.ip12"
22:27:57.125781 parkautomat.1028 > indigo.8743: udp 516 (DF)
22:28:02.125304 parkautomat.1028 > indigo.8743: udp 516 (DF)
22:28:07.125518 parkautomat.1028 > indigo.8743: udp 516 (DF)
22:28:12.125208 parkautomat.1028 > indigo.8743: udp 516 (DF)
22:28:17.125177 parkautomat.1028 > indigo.8743: udp 516 (DF)

Now the final question: How can I make in.tftpd to answer *from* port 69?

==========================================================================

I think this is the problem... Who can help???
	
MfG, JBG
PS: Sorry for this looong mail;)

---

From: Chris Ruvolo <[email-masked]>
Date: Tue, 30 May 2000 20:12:53 -0400 (EDT)

>	  [root@parkautomat:/root] #> arp -s 192.168.1.3 08:00:69:06:BA:2E

I didn't need to do this to get the bootp response.

>	- ISC dhcpd from .deb (2.0-3) with very short config:

I switched to this and it works.

>the originating port is != 69 (which is tftp):

Ok, I'm now in the same boat.

>Now the final question: How can I make in.tftpd to answer *from* port 69?

I'm not sure this is the problem.  I believe RFC-compliant TFTP servers
use system-assigned ports for each client connection.  At least, I've seen
this behavior on other TFTP servers.  But, you may be right.  The client
could be expecting replies only on port 69.  I don't know if this is
possible without modifying the TFTP server.

Can anyone confirm this?

Thanks,
Chris

PS: Please cc responses to me.

---

From: [email-masked] (William Fisher)
Date: Tue, 30 May 2000 21:10:28 -0700 (PDT)

> PS: Please cc responses to me.
	Ok, I looked at the ARCS prom code for the Indy series machine aka an IP22
	in SGI hardware speak.

This code is from the BSD 4.3 distribution with some minor additions to support
one of the last RFC's which added a few more options to the tftp protocol.

The code in main.c looks like:

struct  servent *sp;

main(argc, argv)
        char *argv[];
{
        struct sockaddr_in sin;
        int top;

        sp = getservbyname("tftp", "udp");
        if (sp == 0) {
                fprintf(stderr, "tftp: udp/tftp: unknown service\n");
                exit(1);
        }
        f = socket(AF_INET, SOCK_DGRAM, 0);
        if (f < 0) {
                perror("tftp: socket");
                exit(3);
        }
        bzero((char *)&sin, sizeof (sin));
        sin.sin_family = AF_INET;
        if (bind(f, &sin, sizeof (sin)) < 0) {
                perror("tftp: bind");
                exit(1);
        }
        strcpy(mode, "netascii");
        signal(SIGINT, intr);
        if (argc > 1) {
                if (setjmp(toplevel) != 0)
                        exit(0);
                setpeer(argc, argv);
        }
        top = setjmp(toplevel) == 0;
        for (;;)
                command(top);
}

The socket descriptor "f" is used to receive the data from the wire.

The standard line in the /etc/services file for "tftp" contains:

tftp            69/udp

which will be returned in the "struct  servent *sp" on the "getservbyname()" call.

I looked at both tftp and tftpd and nowhere is there any checks for
the UDP packet arriving on port 69. Are you sure this is the underlying
cause of the problem? I didn't look at your packet trace in gory details.

You can look at the stand BSD 4.X release for the nearly identical source
code that is used in the SGI proms.

-- Bill ([email-masked])

---

From: Chris Ruvolo <[email-masked]>
Date: Wed, 31 May 2000 04:23:59 -0400 (EDT)

>code that is used in the SGI proms.

Bill,
	Thanks for looking this up for us.  The port 69 issue was
speculation on our part.  I've been talking with someone that has the boot
PROM working with tftp, and it doesn't use port 69 exclusively.  Unless
the tftp code changed with different PROM versions, I think we can rule
that out.

	Any other ideas?

Thanks,
Chris

---

From: Jan-Benedict Glaw <[email-masked]>
Date: Wed, 31 May 2000 12:25:27 +0200

> the tftp code changed with different PROM versions, I think we can rule

I hacked the BSD tftpd last night (-> standalone and send from #69) but
you're right. It makes no difference at all. This morning, I played with
the transceiver again -- 2 switches, 4 possibilities. Tested all, but
no success. Some two month ago I booted that Indigo over net (okay, it
crashed immediately;) but the only difference is that we used a switched
port there... It's brain-dead, but I'll fetch a switch from my old school
and test it...

MfG, JBG
PS: Is there a way to boot the linux kernel off DAT tape or from local
    HDD? If so, HowTo?