[Simh] Klh10 vs Simh

[TJ Merritt]

https://www.safaribooksonline.com/library/view/80211-wireless-networks/0596100523/ch04.html

This provides some nice graphics for different topologies.  For bridging 
to work (aka the simh), the WDS case is required.  Most consumer wifi 
for mobile devices figure that they only have to support their own MAC 
address and do not support WDS correctly. That is why SimH on your 
laptop cannot tunnel packets sent over WiFi.  It's out going packets go 
out to the AP in infrastructure mode (Fig. 4-10).  The RA is the Mac 
address of the base station, SA is the MAC address of the laptop, and DA 
is the dest. address from the tap/tun interfaces ethernet frame.  Note 
that the source address from the frame has now been dropped.   The Reply 
packet to SimH will be received by the laptop (Fig. 4-9) with DA set to 
the MAC address of the laptop's WiFi interface, TA set to the base 
stations Mac Address, and SA set to the source address from the original 
ethernet frame.  Note that the SimH MAC address is not included, so the 
frame will not be bridged to the tap/tun interface and seen by SimH.   
If WDS is used, then you can still have issues with base stations not 
processing the frames correctly.  Higher end WiFi access points 
generally work correctly, but it doesn't help you run SimH on your 
laptop with a consumer grade WiFi interface.  Any easy way to see what 
is happening in your configuration is to run tcpdump on the wifi 
interface of your laptop.  You will likely see the frames that should go 
to SImH being received by the laptop, but the destination ethernet 
address will be that of the laptop not that of the SimH tap/run 
interface.  Your host OS won't know what to do with them, and they will 
be dropped by your laptop.

On 02/28/2016 05:28 AM, Johnny Billquist wrote:
> I must admit that my WiFi knowledge is a bit sketchy, but on the other 
> hand do I think that I know ethernet...
>
> But reading up on 802.11, I don't see what you mean by 802.1. I'm not 
> even sure what 802.1 actually says.
>
> However, 802.11 uses 802.2 for packets, which is unlike ethernet, 
> which is not an 802 protocol at all.
>
> Also, reading up on 802.11, it appears that source and destination MAC 
> address are always present. However, there are potentially two more 
> MAC addresses in the packet, which I have not found much good 
> information about yet. Wikipedia suggest the third is for filtering 
> purposes, and do not even explain the fourth one.
>
> What I do know, from observation, is that if I have something like 
> simh setup to communicate over WiFi, packets do get sent out, but my 
> simh instance will not receive any unicast packets to it, which 
> suggests that the switch do not send such packets out over WiFi to the 
> correct destination. I would assume it is because switches knows which 
> stations actually do exist, but that is a guess on my part.
>
>     Johnny
>
> On 2016-02-28 07:29, Peter Svensson wrote:
>> Hi all,
>>
>> The answers given last time were not all that accurate. WiFi for
>> historical reasons conserve bandwidth by assuming that the client side
>> 802.11 mac address is the same as the 802.1 sender mac address and thus
>> omits the latter. This is the so called 3-address mode. This does not
>> leave any room for more than one 802.1 mac address on a client.
>>
>> However, there is also a 4 address mode for WiFi which does support
>> bridging since the 802.1 frames are transported verbatim. This mode has
>> many different names from vendors. Most commonly it goes by the name
>> WDS, but that name is unfortunately also used by a bunch of non
>> transparent mechanisms from other vendors.
>>
>> See e.g. http://linuxwireless.org/en/users/Documentation/iw/
>>
>> 802.11 does not care about broadcast one way or another. It is just
>> transported. It does not care what layer 3 is used (except only one
>> layer 2 sec address in 3 address mode).
>>
>> The decision to save 6 bytes is an unfortunate historical artefact. The
>> (802.11 standard) option to not save these bytes is not always exposed
>> on wifi equipment. Some does, and most can I'd you run OpenWrt or
>> similar software on them. Not sure about Windows though.
>>
>> Peter
>>
>> On February 27, 2016 11:01:31 PM GMT+01:00, Johnny Billquist
>> <bqt at softjar.se> wrote:
>>
>>     On 2016-02-27 20:14, Andreas Davour wrote:
>>
>>         On Sat, 27 Feb 2016, Johnny Billquist wrote:
>>
>>             On 2016-02-27 17:53, Michael Kerpan wrote:
>>
>>                 It's not that multiuser is impossible using KLH10
>>                 networking emulation
>>                 and native TOPS-20 TCP/IP, it's that it's a lot harder
>>                 to set up than a
>>                 SIMH virtual multiplexer. Wifi (under Linux at least)
>>                 doesn't play all
>>                 that well with bridging and virtual networking stuff,
>>                 which makes
>>                 setting up networking in KLH10 nigh impossible for those
>>                 of us stuck on
>>                 wireless. I can't even really set up a VM and run KLH10
>>                 in a guest,
>>                 because Virtualbox's bridged mode doesn't work for me.
>>                 Additionally, the
>>                 idea of putting anything running a 30 year old TCP/IP
>>                 stack onto the
>>                 Internet scares me, even if the folks at twenex.org
>>                 <http://twenex.org> <http://twenex.org>
>>                 have done so.
>>
>>
>>             The WiFi problem is easy to solve. It's called a router.
>>             Your host
>>             routes IP between the WiFi interface and the virtual network
>>             the host
>>             and your virtual machine shares.
>>
>>             Trouble setting up networking on the virtual machine? Maybe.
>>             But this
>>             boils down to - if you want to run that host, you should
>>             learn how to
>>             manage it.
>>
>>             Security issues are mostly non-issues. How many script
>>             kiddies today
>>             even know what a TOPS-20 host is. There are most certainly
>>             vulnerabilities, but they are very different from the ones
>>             presented
>>             by modern machines.
>>
>>             I have an RSX system on the Internet, and it gets constant
>>             probing
>>             over telnet and http, but they are all probing in ways that
>>             just don't
>>             make sense. So I have never felt more secure.
>>
>>
>>         To Johnnys suggestions I might add that (I don't know exactly 
>> what
>>         problems you're having) maybe openvswitch might help out?
>>
>>
>>     The problem is that WiFi is not really like ethernet (I think we 
>> covered
>>     this a month ago, but maybe it was on a different list). Anyway, 
>> if you
>>     have a simh instance using WiFi for the network, it do not work, 
>> since
>>     putting the interface in promiscuous mode, and pretend you have a 
>> second
>>     machine with a different MAC address do not work, since with 
>> WiFi, the
>>     base station actually knows which MAC addresses are connected, 
>> and if a
>>     packet comes in for a device for which the MAC address is not
>>     registered, the packet will not be send out over WiFi, so you 
>> will not
>>     get anything, even though you think you have your
>>     interface in
>>     promiscuous mode, and are sending packets out with a different 
>> source
>>     MAC address, which you might think the WiFi switch would learn, 
>> as it
>>     would had it been ethernet.
>>
>>       Johnny
>>
>
>