MOL 0.9.65 released

[Bill Fink]

On Thu, 5 Sep 2002, Samuel wrote:

> MOL 0.9.65 is now (finally) available for download. The major new feature 
> in this release is the MacOS X support. Both 10.1 and 10.2 (Jaguar) 
> are supported.
> 
> To boot MacOS X, specify the OS X boot disk in /etc/mol/molrc.osx
> and start mol with the --osx switch.
> 
> The 0.9.65 release also contains improved support for remote X connections.
> In particular, colors will now be correctly displayed on little endian
> displays.

Hi Samuel,

I just tried out the new MacOS X support in MOL 0.9.65 and it's really
great (the happy penguin hugging the apple on boot is a nice touch)!!!

I'm having a problem however with the networking.  I don't use the
tun interface since I use a unique static IP address (different than
the Linux side) for MacOS.  I therefore specify:

	netdev:	eth0 -sheep

in the /etc/mol/molrc.net file (and commented out the tun netdev line).
Actually, I changed the section:

ifeq ${boot_type} newworld oldworld {	# Configure for MacOS only
	netdev:	eth0 -sheep
}

to:

ifeq ${boot_type} newworld oldworld osx {	# Configure for MacOS only
	netdev:	eth0 -sheep
}

To start with, everything works fine with MacOS 9.  But with MacOS X,
when I tried to use Internet Explorer, it wouldn't load any web pages.
I started up a terminal window and discovered that i was able to ping
everywhere just fine.  The problem came in when I tried to ping with
a larger packet size.  The largest ping size that would work was 160
bytes, which was an IP payload of 168 bytes, an IP datagram size of
188 bytes, and an Ethernet packet size of 202 bytes.  Increasing the
ping size to 161 bytes would fail.

I then got on another system, and did a tcpdump to collect the ping
packets from the MOL/MacOS-X system.  Here is the good packet trace
from the ping with a size of 160 bytes:

16:26:45.548279 0:30:65:eb:32:4a 0:60:8:32:ef:ff 0800 202: 192.168.7.21 > 192.168.7.1: icmp: echo request (ttl 255, id 488)
			 4500 00bc 01e8 0000 ff01 29f2 c0a8 0715
			 c0a8 0701 0800 1541 015a 0000 3d7a 6104
			 000c 85d1 0809 0a0b 0c0d 0e0f 1011 1213
			 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
			 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
			 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243
			 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253
			 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263
			 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273
			 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283
			 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293
			 9495 9697 9899 9a9b 9c9d 9e9f
16:26:45.548716 0:60:8:32:ef:ff 0:30:65:eb:32:4a 0800 202: 192.168.7.1 > 192.168.7.21: icmp: echo reply (ttl 255, id 13602)
			 4500 00bc 3522 0000 ff01 f6b7 c0a8 0701
			 c0a8 0715 0000 1d41 015a 0000 3d7a 6104
			 000c 85d1 0809 0a0b 0c0d 0e0f 1011 1213
			 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
			 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
			 3435 3637 3839 3a3b 3c3d 3e3f 4041 4243
			 4445 4647 4849 4a4b 4c4d 4e4f 5051 5253
			 5455 5657 5859 5a5b 5c5d 5e5f 6061 6263
			 6465 6667 6869 6a6b 6c6d 6e6f 7071 7273
			 7475 7677 7879 7a7b 7c7d 7e7f 8081 8283
			 8485 8687 8889 8a8b 8c8d 8e8f 9091 9293
			 9495 9697 9899 9a9b 9c9d 9e9f

But here is the packet trace from the failed ping (using a size of
161 bytes):

16:28:17.953765 0:30:65:eb:32:4a 0:60:8:32:ef:ff 0800 60: truncated-ip - 21799 bytes missing!85.85.85.85 > 85.85.85.85: (frag 21845:21825@43688) [tos 0x55] (ttl 85, bad cksum 5555!)
			 5555 5555 5555 5555 5555 5555 5555 5555
			 5555 5555 5555 5555 5555 5555 5555 5555
			 5555 5555 5555 5555 5555 5555 5555
16:28:17.953797 0:30:65:eb:32:4a 45:0:0:bd:1:ec c0a8 189: 
			 0715 c0a8 0701 0800 eb07 015b 0000 3d7a
			 6161 000c 0fac 0809 0a0b 0c0d 0e0f 1011
			 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021
			 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031
			 3233 3435 3637 3839 3a3b 3c3d 3e3f 4041
			 4243 4445 4647 4849 4a4b 4c4d 4e4f 5051
			 5253 5455 5657 5859 5a5b 5c5d 5e5f 6061
			 6263 6465 6667 6869 6a6b 6c6d 6e6f 7071
			 7273 7475 7677 7879 7a7b 7c7d 7e7f 8081
			 8283 8485 8687 8889 8a8b 8c8d 8e8f 9091
			 9293 9495 9697 9899 9a9b 9c9d 9e9f a0

As you can see, there's first a bogus 60 byte packet of all 5's.  This
is followed with what looks like basically the correct packet, but with
the first 14 bytes stripped off (which happens to be the size of the
Ethernet header).  Of course the receiving system doesn't know what
to make of this and will just drop it as a bogus packet.

Any ideas what might be wrong?  I'm hoping it's something easy to fix.

						-Thanks

						-Bill