Hi again!, I got it sorted and I realize I didn't mention how the network was setup and that was probably the cause for all of this. The non-functional setup was the secondary nic dc0 being set to 10.0.0.1 with the different daemons listening to it. The only other host was the Sparc.
Looking and comparing tcpdumps I saw ARP requests not getting a response. I think this is because no router was on the network, or a router being set. I'm really sorry for sending a mail to the mailing-list for such a trivial mistake on my part. When I ran the same setup facing my local network everything just worked. Thanks for the great questions that lead to my answer! In hindsight I should have waited a day before I posted my question. I'll have to figure a bit more on why it didn't work when running it over a cross-over link, but now I know there was never an issues with the software or hardware. 2015-12-02 9:47 GMT+01:00 Meelis Roos <mr...@linux.ee>: >> It seems like the IP 10.0.0.10 is set OK via rarp, based on that the >> file 0A00000A.SUN4C is being requested. However that seems to be as >> far as it gets. After this it is in an endless loop sending a new >> request over and over. tftpd sends the first block of boot.net binary, >> doesn't get a response and tries this five times before the SUN gives >> up and sends a new request. If I tftp localhost I can get the >> 0A00000A.SUN4C file without any issues. > > Years ago I wrestled with a similar tftp problem on an old computer > (might have been 32-bit Sun, might have been something else from that > era that used tftp). With Linux server there was a difference between > tftp servers (don't remember which one worked and whether it was kernel > version related, but I got it to work). I also compared tcpdumps, it > might have been zero UDP or IP ID-s, or DF bit. Perhaps the last bit can > help you some. > > -- > Meelis Roos (mr...@linux.ee) I got some time to check into this again and per your recommendation I started to compare tcpdumps. They looked very similar, same requests and so forth. The only difference was ARP requests sneaking in from the SPARC machine. I think they didn't get a response because there was no router on this network, only the two hosts connected with a cross-over cable. 2015-12-02 9:50 GMT+01:00 Riccardo Mottola <riccardo.mott...@libero.it>: > Hi Stuart, > > Stuart Henderson wrote: >> >> It seems like the IP 10.0.0.10 is set OK via rarp, based on that the >> > >>file 0A00000A.SUN4C is being requested. However that seems to be as >> > >>far as it gets. After this it is in an endless loop sending a new >> > >>request over and over. tftpd sends the first block of boot.net binary, >> > >>doesn't get a response and tries this five times before the SUN gives >> > >>up and sends a new request. If I tftp localhost I can get the >> > >>0A00000A.SUN4C file without any issues. > > > do you have perhaps by chance a third computer in that subnet to tftp from, > instead of using localhost? That may guarantee that tftp is working besides > local and that the problem restricts to some configuration of your venerable > IPX. > > Riccardo > Per your recommendation I started testing accessing the different services from other machines and by doing so connecting them to my local network, instead of the cross-over link I started out with. I'm not completely sure but I think the issue was caused by there being no router on the network that could respond to ARP requests. When I put all the machines and services onto the local network it just started to work. Anyways I managed to install OpenBSD onto the Sparc from my i386 laptop running OpenBSD (amazed by how well the kernel handle the very broken ACPI on the T23 Thinkpad). So now I can get on with using this system! :) Cheers!, Adrian.
