Dear All,

   Yesterday you saw me use a Linux guest VM in VirtualBox on MacOS
with networking in both NAT mode and bridged mode (with my Ethernet
interface). The handling of packets in these two cases is different:
in NAT mode, the VirtualBox application does most of the packet
handling (such as NAT source/destination rewriting); in bridged mode,
it's up to the host kernel. 

   Look closely at the MAC src and dst addresses of a ping going out
from the guest VM. The MAC address of the virtual eth0 interface
inside the VM is used in these packets, and is learned by other
machines on the LAN (unlike the NAT mode, where it never shows up 
on in the LAN; it's always the src IP and MAC of the host, which
serves as the guest VM's gateway). 

   It's a good hacker-research question if other hosts on the LAN can
tell whether they are talking to a virtual machine bridged through an
Ethernet interface of a host machine, or to a host kernel running
on bare hardware without virtualization. Think about it -- whoever shows
me such a method gets an instant High Pass :)

   Note that bridging with a wireless interface works differently.
Specifically, all outgoing packets leaving the host OS will have the
host OS's wireless interface's MAC address as their source, and other
machines on the LAN will learn---through ARP---this same MAC address
for both the IPs of the host and the guest VM. You will see the guest
VM's MAC address get out in DHCP requests, though -- and this is
likely to make these requests not succeed, if the DHCP server compares
the actual source MAC in the packet with the MAC that a dynamic IP is
being requested for. 
  
   I suspect that some such check is being made on Dartmouth Public,
causing my DHCP requests to fail. I would be interested in finding out
exactly how it fails (another research question, for which you would
need to read up on the DHCP protocol).

   Why isn't the VM's virtual interface MAC address used on the WLAN
network despite bridging? I think this is because the 802.11 (Wi-Fi)
link layer is a lot more complex than Ethernet. Essentially, the Wi-Fi
hardware and its driver would have to pretend to have two MACs to let
the virtual MAC be used in all these functions, and it's too much
trouble for the 802.11 cards that must already do a lot of work.  For
example, the source MAC address is used in many more functions such as
acknowledging every frame by the receiver. This ACK must be sent
within less than 6 microseconds (for 802.11g); interrupt-driven
software running on the main CPU such as a driver is not fast enough
to do it consistently, so ACKs are sent by the card's firmware. There
are more such extra functions as compared to the simpler Ethernet
(802.3) link layer.

    How 802.11 link layer works around the problems of radio rather
than copper is fascinating. For example, an Ethernet card can listen
to the signal on the wire just as it's transmitting its own frames; a
digital radio card can't (the transmitted signal is so much stronger
than any of the other signals on the air). There is also the "hidden
node" problem: two transmitters may be far enough apart to not hear
each other, but their signals would be strong enough at a third node
located between them to jam each other. For this and other reasons,
_every_ 802.11 link layer frame is acknowledged by the receiver with a
special short ACK frame; if not so ACK-ed, it's presumed lost and is
retransmitted by the sender. In TCP/IP, you only find acks in the TCP
layer (layer 4). 802.11 also support fragmentation of frames on the
link layer (different from IP fragmentation!). Rather than collision
detection (as in Ethernet), 802.11 used collision _avoidance_, and so
on. Some of the reasons why this complexity is needed are listed here:
http://www3.nd.edu/~mhaenggi/NET/wireless/802.11b/Data%20Link%20Layer.htm
The best short book I could find about 802.11 is
http://www.amazon.com/802-11-WLAN-Hands-On-Analysis-Troubleshooting/dp/1425907350
I strongly recommend it if you want to understand Wi-Fi and digital radio.