A: This Basilisk II feature implements TCP/IP Internet access
using your existing Windows Internet connection, should it be a dial-up
connection or something else.
A: Basilisk II ships with a complete DIX Ethernet / 802.2 support, and a serial port support complete enough to use a modem. They work for TCP/IP just great, but there are cases when they cannot be used to access the Internet without a proxy server. Having a proxy in between may not be the best option for some, and if a modem connection is made from Basilisk II, Windows cannot access the Internet at the same time.
If you already can use TCP/IP in Basilisk II with no problems, you should
not enable this module -- there is no point. True ip over ethernet is as
good as it can get; this solution will never be quite as complete.
A: Because the module is a combination of a NAT server and a router. The emulated Mac thinks that the module is a router in the LAN. Functionally it's a NAT server however, since it hides the true identity of the Mac from the rest of the world, doing an ip address translation and port mapping in both directions. As such, it serves as a [rather worthless] firewall for the Mac as well.
NAT stands for Network Address Translation, providing transparent access
to the rest of the IP network (usually Internet) via one gateway computer.
The computers all have unique ip addresses, but the outside world only
sees one address, the one of the server.
A: This feature is disabled by default. You need to navigate to the Basilisk II GUI "Router" page and enable it by checking the "Enable NAT/Router module" option.
You don't need to have Basilisk II ethernet driver installed, actually even an ethernet card is not necessary.
But you must have the ethernet installed on the Mac side. In your emulated Mac TCP/IP control panel:
Home users are free to use the class C addresses reserved for private networks, for example:
- Select "Connect via Ethernet"
- Select "Configure manually"
- The IP address can be any legal address, but don't use the same IP address that you have in Windows. It's always best to ask your network administrator for a unique ip address, because you may later disable the NAT/Router module and possibly cause an ip address conflict on your network.
- Subnet "255.255.255.0"
- The router address can be almost anything, but preferably the same as the Windows ip address. It must be different than the ip address you entered above.
- Name server address(es) must be correct. Use the same one(s) you have in Windows.
- Make sure that the option "Use 802.3" (if present) is not selected.
These should work fine even if you have a dial-up account that assigns you a different Windows ip address every time (DHCP) you dial to your Internet service provider..IP: 192.168.0.4
Subnet 255.255.255.0
Router: 192.168.0.1
If you don't know what DNS address to enter in Mac TCP/IP control panel, check the helpdesk pages of your ISP. While connected, you can also detect the DNS address that Windows is currently using by running the following command in Windows command prompt.
Under Windows NT:
Under Windows 95 and 98:C\> ipconfig /ALL
C\> winipcfg
IMPORTANT: Before using any form of Basilisk II networking
on a corporate LAN, please contact your network administrator to find out
whether you are allowed to do so, and what ip address you can use.
A: Windows sockets version 2 is required. All other Windows versions have it already installed, but not Windows 95. The update can be downloaded from:
http://www.microsoft.com/windows95/downloads/contents/wuadmintools/s_wunetworkingtools/w95sockets2Please note that Microsoft rearranges web sites often. If you get an error stating that the web page was not found, go to http://www.microsoft.com, click the search button and enter "Windows Sockets 2 for Windows 95".
A: The following information has been gathered so far:
- Outgoing TCP connections work (HTTP, POP3, SMTP)
- Incoming TCP connections work (server software), if you open the appropriate ports in the Router GUI page.
- FTP is a special case; see the next question.
- Outgoing UDP connections work (DNS).
- Incoming UDP connections generally do not work. There is a hack for DNS replies.
- ICMP datagrams work. Under NT4 and Windows 2000, administrator rights are required.
- NetBIOS over TCP/UDP does not work, so you may need to disable Dave and other similar NetBIOS drivers.
A: The following have been tested to some extent:
- Web browsers: work, tested with Netscape 3/4 and IE4.
- FTP clients: "Passive" mode works. Active mode works if you define the ftp ports (usually 21, others may be used too depending on the server) in the GUI router page. Tested with Fetch.
- FTP in web browsers: Netscape seems to use the "Passive" mode and works. IE4 lets the server initiate the data transfer and works only if the ftp ports are defined in the GUI.
- FTP servers: work (ftp ports and server ports must be defined). Tested with NetPresenz 4.x.
- Ping: you can ping the outside world from the Mac. See the comment about ICMP datagrams above. Pinging the Mac from outside would probably require some clever trickery. Since the Mac is hiding behind the NAT, you would have a hard time in telling who is responding anyway, Windows or the Mac.
- Traceroute: applications that use ICMP echo packets should work. Applications that use UDP may not work (Mac TCP Watcher). This is because the headers of the timed-out UDP packets are sent back to the Mac. The packets contain some information set by Windows, and the Mac compares them against the original information and thinks that they are not the same ones. The router module patches some of the data back, but it is not possible to recover all of them due to the Windows limitations.
- E-mail: both pop3 and smtp work. Tested with Eudora Light 3.1.
A: Yes. IP and ARP traffic is forwarded to the router, AppleTalk works the same as usual.
You can, however, use the router module even if you don't have a NIC
at all and the Basilisk II ethernet driver is not installed.
A: When the module is enabled, IP version 4 datagrams and ARP datagrams are extracted from the Basilisk II ethernet interface before they reach the NIC, and forwarded to the NAT/router module. The module changes the source ip address, does a port mapping and uses Windows sockets to forward the traffic to whatever destination they are targeted to.
Incoming IP and ARP packets from the LAN are ignored, effectively decoupling Basilisk II from the ethernet card (regarding TCP/IP traffic, but not AppleTalk).
TCP traffic is implemented by emulating the full-duplex TCP handshaking as specified in the Internet standard RFC 793 -- Transmission Control Protocol, featuring the basic state machine, flow control, sequence numbers and RST/SYN/FIN/ACK/PSH flags. Out-of-the-band data, the urgent pointer, window sliding, and some TCP options are not implemented. Nagle algorithm and other performance improvements are not properly implemented.
UDP packets are sent asynchronously to the target, and the same port is listened until it has been idle for one minute, then the port is closed. This is enough to make DNS work.
All ICMP packets arriving to the computer are sent to the Mac, never mind where they are targeted to. Since this is done using raw ICMP sockets, administrator rights are needed under Windows NT 4 and Windows 2000.
ARP requests are replied immediately using a fake hardware address with a non-existent ethernet card manufacturer code.
FTP data transfers initiated by a remote host require some extra care.
This is done by examining the outgoing ftp PORT commands and outgoing
server passive mode announcements. When a port command is detected, the
command is patched to change the ip address, and a temporary listening
port is opened. The port is listened to until an incoming connection is
detected or the ftp control connection is closed. Connection attempts originating
from any other IP addresses than the ftp server are rejected.
A: It's not that simple under Windows. The Windows sockets API has some serious limitations. Raw sockets in general (except ICMP) do not work on any Windows flavor before Windows 2000. Further, the crucial function setsockopt( ..., IP_HDRINCL, ... ) does not work.
Curiously enough, it might be because of these limitations/bugs that Windows "Tracert" utility uses ICMP echo request packets instead of UDP packets as most traceroute utilities do.
Further, there is no way to tell that an external host is attempting to connect to an arbitrary local port. That's why you must tell Basilisk II what ports to listen to if you want to run server software on your Mac.
It would be possible to write a TDI filter driver, an NDIS intermediate
driver or a Winsock layered service provider to handle the raw packet traffic.
None of these three options is a trivial one, let alone portable.
A: Probably.
I wouldn't use this module for bank transactions as yet -- that is,
if my own money would be involved :)
A: There are a lot of things actually. Some of them are:
- Performance could be improved by implementing the usual TCP optimizations, most importantly multiple buffers with TCP window sliding. This would not increase web browsing speed much as the rendering is the bottleneck instead of network speed.
- Support for UDP broadcast addresses.
- Support for incoming UDP datagrams.
A: Yes. There is no out-of-the-box NAT for Windows NT 4 (which
will be around for at least some years to come). It would be easy to use
this code to write a simple NAT server for NT4, allowing transparent Internet
access for all computers on your LAN through one gateway computer.
A: This code is a part of the Basilisk II distribution. Basilisk II is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
The program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA.
Please read the file COPYING in the main distribution archive.
A: My (Lauri Pesonen) e-mail address is lpesonen@nic.fi
A: Some asynchronous socket functions are used (function names starting with WSA*) that are Windows extensions to the BSD socket library. All other BSD functions are used in a compatible way.
Thread functions, critical sections and events are Windows-specific.
When porting to a platform with a proper support for raw sockets, consider
dropping all the tcp handshaking code, and use IP_HDRINCL instead.
A: Merry Christmas and a Happy New Year 2001.
December 26, 2000
Lauri