AppleWin/help/uthernet-wifi-workaround.html

49 lines
1.9 KiB
HTML

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>WiFi workaround</title>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
</head>
<body style="FONT-FAMILY: verdana; BACKGROUND-COLOR: rgb(255,255,255)" alink="#008000"
link="#008000" vlink="#008000">
<h2 style="COLOR: rgb(0,128,0)">WiFi workaround</h2>
<hr size="4">
<p style="FONT-WEIGHT: bold">Overview:
</p>
<p>A (heavyweight) workaround for the WiFi issue.</p>
<p style="FONT-WEIGHT: bold">Details:
</p>
<p>Installing a virtualization solution like the (free) VMware
Workstation Player provides a virtual ethernet card. Then installing
WinPcap inside the virtual machine allows access to the internet via
WiFi from AppleWin.</p>
<p>VMware allows you to configure the virtual ethernet card in two ways:</p>
<ul>
<li>Bridged, this means that the virtual Uthernet card becomes visible
with its MAC address in the WiFi net and that an Apple II DHCP client
gets its address from the usual DHCP server (typically a WAN router).
<li>NAT, this means that the virtual Uthernet card is part of a virtual
network with three participants:
<ul>
<li>A virtual Ethernet card added by VMware to the "outside" (aka host) Windows.
<li>The virtual Ethernet card used by the "inside" (aka guest) Windows.
<li>The virtual Uthernet card.
</ul>
<br>
That virtual network has its own IP address range and has its own DHCP
server (being part of VMware). An Apple II DHCP client gets its
address from that DHCP server.
</ul>
<p>Another positive aspect of that "emulation inside vitualization"
approach is that the "inside" (aka guest) Windows always has just one
single network interface: that virtual ethernet card mentioned above.
And that interface has always the same name (even when switching
between Bridged and NAT) so one never has to fiddle with network
setting of the emulators using WinPcap.</p>
</body>
</html>