On Wed, 14 Jul 2004, Collin Baillie wrote: > > So it seems to try to get a file some times and gives up on it. > > Oh.. I think it asks for the file, but the mopd server is not sending it. I > am only guessing though. It looks so. You may try to verify with `tcpdump', too. > > By the way, which mopd are you using? There are several of them around, > > some quite unuseable... > > Umm.. 2.5.3. I downloaded one from linux-mips.org, and applied all the > patches in the order listed in the spec file, but it doesn't compile. So I Hmm, there's no mopd at linux-mips.org. Do you refer to one at my site, i.e. "ftp://ftp.ds2.pg.gda.pl/pub/macro/";? If so, then please report compiler errors to me. > compiled another 2.5.3 (79k as opposed to the 48k tgz file I got from > linux-mips.org) and it compiles and responds, but still no file transfer. (I > am compiling/running on i386 arch, so I am wondering if all those patches > are necessary...) They are. They are not processor-dependent. > I've read that MOP images usually have some special header in them (NetBSD > website) and someone mentioned that mopd-linux will fudge those headers if > the kernel doesn't have them... or something... You've been misled. The MOP protocol sends raw data annotated with addresses. It's up to the MOP server to obtain both of them. For example they can be retrieved from ordinary ELF images. > I am perservering with it, and will eventually get there... but for now, I > just thought someone might have more of a clue than I do. Try running `mopchk <your-image-file>' to check if it's interpreted correctly. Maciej
