For other network related things, see:

Networking basics - General
Layer 2 mostly - On MACs and EUIs · ARP notes · Spanning tree notes · Bridging notes · DHCP notes · Layer 2 unsorted notes
Layer 3 (IP mostly) - sockety things · IPv4 notes · IPv6 notes
Firewalling and other packet stuff
wireshark and tshark notes · tcpdump notes · nmap notes · other network tools

Also:

More technical VPN notes

📃 These are primarily notes, intended to be a collection of useful fragments, that will probably never be complete in any sense.

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Switches, routers, hubs, bridges, etc.

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

LAN, Broadcast domain, LAN segment, collision domain

Reducing broadcast domain size

Semi-sorted

Glossary

NIC - Network Interface Card. Used whenever it's not a given that a single computer has only one connection (and in documentation).

interface usually refers to how drivers provide (and how software uses) a NIC. Regularly used synonymously with NIC.

adapter - Regularly used synonymously with NIC.

node - usually means 'a single box of hardware', or something else coherent enough to be seen as a single actor. May have multiple NICs (that are or aren't related to each other). Examples include computers, routers, and more.

frame, packet, segment, PDU
- Theoretically/formally, frame means layer 2, packet means layer 3, segment means layer 4, and the generalizing term is PDU)
- In practice, the terms are fuzzy and there is no hard difference, except that 'frame' suggests lower layers (physical and link) and 'packet' suggests higher levels (layer 3 and above).

ICMPv6

NDP

Wake On Lan

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Hardware-wise

On-motherboard Ethernet that supports WOL should just work

PCI cards
- may need a cable, which signals the motherboard to boot. Not all motherboards have such a connector.
- PCI 2.2 can send it via power management events (support may vary?(verify))

Configuration:

PCs: Your BIOS should mention Wake on Lan (or some similar wording), usually in a power-related part of the BIOS.
Macs: ?

Triggers

Include...

Magic Packet (most common)
- Contains the MAC address of the computer to wake, typically broadcast on the subnet that host is on
- When WOL configuration doesn't mention ant of this list, it'll likely be Magic Packet.

Specified pattern within packet
- like magic packet, but configurable

SecureOn(verify), which is like Magic Packet, but adds 4 or 6 extra bytes to match
- that password (-of-sorts) is not secure against eavesdropping. It seems mostly intended to make accidental waking and brute force waking harder(verify)

Link Change (e.g. "computer tuns on when you plug its LAN cable into a switch"(verify))

There may be further options, e.g. reacting to specific types of traffic, but this is often impractical.

On Magic Packet, and the variant with a "password"

A magic packet is any layer-2 packet that contains:

a synchronisation stream, meaning six 0xFF bytes, directly followed by...
sixteen copies of the target NIC's MAC, in binary form (6 bytes each)
- in part to avoid being a runt?
- I've seen code with more than sixteen copies of the MAC, which works just as well (though may conflict with the password feature).
Optional: If both the NIC and the packet sender support passwords, this means that 4 or 6 pre-determined bytes should follow the above sequence.

The above sequence is allowed to appear anywhere in the packet - presumably so that WoL-capable NICs can completely ignore protocol encapsulation and just match this 102-byte sequence anywhere. (verify)

While NICs only look at all layer 2 packets they get, it is

usually Ethernet frames, because that's what most end networks use
usually IP, convenient for its routing
often UDP/IP, because it's a connectionless fire-and-forget protocol

(regularly UDP/IP broadcast -- related to routing behaviour, see below)

regularly on port 7 or 9 (or sometimes 0), primarily because they are unused ports you can use (forward) for this specific functionality (and even if they are used it's fine, because historically port 7 is echo, 9 is discard)

Networking / routing, in general and particularly for web based WOL

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Broadcasting is simple enough for same-subnet WOL, but things get more complex when you send WOL packets between subnets, which includes using web-based tools for WOL.

In general, your options for getting WOL packets where you want them to go, depending on your networking details, include:

broadcast the packet within the subnet
- usually the easiest option within the same subnet
- however
  - most network stacks will only create such a packet so if they are themselves (currently) configured to be on the subnet mentioned in the packet (for fairly good reason)
  - devices acting as routers (and, in some cases, bridges) tend to filter out broadcast packets; broadcast packets won't work between (sub)nets (again, for fairly good reason)

Get a host on the target subnet to generate a broadcast packet for you. A number of modems/APs can do this, or be easily made to. Other always-on hosts (e.g. LAN servers) can be helpful too, and sometimes more flexible.

using a routable unicast packet for a specific host (unicast)
- requires the router to have a static ARP entry for the target (because without it, that router will consider the packet non-deliverable when the host is off)
- for LANs with private IP addresses, this also means a forwarding rule (which itself means one port can serve at most one host)

use VPN as a way of belonging to the specific subnet - which can in some situations be an easy solution, but requires the VPN endpoint to always be active. If that's your modem/AP that's easy, but that may be harder to configure than VPN in general.

Slightly more concretely, assuming you want to use IP for routing between subnets, you have roughly these options:

route as unicast to the intended host
- depends on a static ARP entry (one for each WOL-wakeable host) so that the host is considered routeable on that subnet when the host is off
- you must know the IP at sending time (not all WOL clients let you do this)
- if you are on a private-IP subnet (10.*, 192.168.*, 172.16-31.*) this won't work as-is; you'ld need to...

route as unicast, forward (DNAT) all use of a single port to a specific host
- doesn't require you to know the IP, works for private-IP subnets
- requires a forwarding route per host
- requires that host having a non-changing IP (usually; depends on WOL-related features of forwarder)
- needs a static ARP entry (per host) so that the host is considered routable on that subnet even when/though it is off

route as unicast until you get to the target network, then rewrite into a broadcast
- Most devices and network stacks won't forward (DNAT) to a broadcast address, so you can rarely do this using just port forwarding (It's too easy to do bad/stupid things this way. A few devices are not clever enough to realize the risk, and allow it)(verify)
- ...so usually needs a program to be the endpoint for WOL, and broadcast them locally - fairly easy to write, but it needs to be on an always-on host

WOL senders

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

It's easy generate magic packets - given socket-level networking. It takes at most a few dozen lines of python, perl, ruby, PHP, etc.

For example, in python:

def broadcast_wol(mac, password_bytes='', ports=9):
    ''' Locally broadcasts a Wake-on-LAN packet (Magic Packet) with the given MAC.
        Arguments: 
         mac             should be a string. Will be stripped of everything not [0-9A-Za-f], 
                         so you can use most any form of MAC strings.
         password_bytes  if used, should be a bytestring
         ports           can be an integer, or iterable of integers, e.g. [7,9]
    '''
    import socket,struct,re

    #Remove all but hex so that we're robust to MACs with separator characters
    mac=re.sub(r'[^0-9A-Za-z]','',mac)
    if len(mac)!=12:
        raise ValueError('%r does not look like a valid MAC address'%mac)

    # Construct packet in hex form. It's easier and a little more readable
    hex_data = 'FF'*6
    hex_data += mac*16
    packet_data = hex_data.decode('hex_codec')  # ...then turn into the bytestring we want
    packet_data += password_bytes
    
    # Use low-level socket interface to broadcast the result via UDP
    sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)    # UDP socket
    sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1) # Broadcast socket
    if type(ports) in (int,long):
        ports=[ports]
    for port in ports:
        sock.sendto(packet_data, ('<broadcast>', port)) # '<broadcast>' refers to INADDR_BROADCAST, 255.255.255.255

Apps include:

http://ahh.sourceforge.net/wol/ (magic packet, windows)
http://www.depicus.com/wake-on-lan/wake-on-lan-gui.aspx (magic packet, linux)
http://www.coriolis.ch/en/wakeup/ (mac)

Web services include:

http://stephan.mestrona.net/wol/
http://www.wakeonlan.me/ and the more minimal version: http://www.wakeonlan.me/mobile
http://www.depicus.com/wake-on-lan/woli.aspx

NIC, protocol address, and name resolution

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

There are different things that resolve.

Ethernet and IP; ARP

Say our LAN is Ethernet, as most are.

The unit of communication at ethernet level is the ethernet frame, which has a source MAC and destination MAC, where MAC is unique identifier for a physical network device (and one of its ports, if it has multiple).

When you want to send to another ethernet node, you must first learn that unique identifier.

There were a few different ways of doing this, all of which amount to lookups of something more convenient than MACs, but we generally landed on doing everything with IP - so IP's addresses became central to a lot of things.

ARP is the glue between ethernet addresses (layer 2) and IP addresses (layer 3). Conceptually, ARP consists mostly of two messages:

"hey guys, what's the MAC for this IP address?"

"that would be me - this IP and this MAC"

And yes, this is a specific case of two layers interacting (typically avoided where possible).

For hosts

The above are broadcast messages, meaning everyone gets it - at least within the same Ethernet segment (which typically corresponds to an IP subnet). This means

you don't get all the world's ARP messages, which is sane and good

that you need a way to send messages to other ethernet segments

which is mostly solved at IP level -- but relevant in some of the below, means you'll have an IP (and soon the according MAC) usually used for "all other traffic".

For networking hardware

An ethernet node isn't necessarily aware of IP.

In particular for networking hardware. Before switches were the norm, you had hubs.

Hubs were Ethernet-only and not IP-aware - and didn't need to be, remember how layers make life simpler. But because it doesn't know on which port the target host is connected, it just duplicated all incoming ethernet frames on all other ports.

Hubs aren't made anymore, because IP-aware ethernet switches are much more efficient, and very little extra effort.

These will listen to ARP responses, and can ignore the IP part, because they just want to learn which physical port answered "that would be me" with the relevant MAC.

Switches act like hubs only for packets where the destination MAC isn't yet known to be on a port. Which is fine, both because that's a small part of all traffic, and because they will typically learn it very soon.

Uses and abuses

Beyond making IP over ethernet work, there are ARP-related tricks and attacks, such as

having multiple IPs on a physical port

having multiple hosts have the same IP

though only under very specific conditions

claiming all unused IPs for sniffing purposes

sending many random ARP responses, implicitly flushing real entries out of the limited-size ARP tables

bsically reducing the switch to a hub, making it easier snoop on traffic from hosts that are not the packet's actual target (but only from another host on the same switch/segment).

learning the IP of the gateway, then sending around ARP asnwers with incorrect MACs

so that you're the only device left for which IP routing still works.

A lot of these are possible because ARP is connectionless and stateless, implying answers without questions are trusted. ARP spoofing is abusing that fact.

There are switches that alleviate many of these attacks, because some things (e.g. a port basically claiming to have thousands of hosts) are pretty easy to detect.

Server names; DNS

Name to IP address resolution that particularly enables you to use human-rememberable names in your browser address bar (but can potentially serve anything IP-based), is actually fairly unrelated to basic networking. IP numbers are used for actual communication, and this service simply tells you the IP(s) for a name.

In fact, there are tricks that allow one IP to have multiple names, one name to cycle though pointing to various nodes (a type of load balancing),

There are other ways to do the same resolution step, for example the hosts file on at least unices (/etc/hosts) and windows (I'm not sure the location is the same, search for it) which essentially hardcodes a name to an IP address. This can interfere when incorrectly used, though. Some protocols, such as SMB (windows sharing / CIFS / samba) also allow netbios, wins and lmhosts to provide adresses for names - IP or netbios.

Netbios names; WINS

In some way analogous to both of the above are netbios names. Netbios was used by the early windows versions to provide naming on local networks without DNS. NetBIOS names work something like ARP, but a level higher.

NetBIOS could also be used on top of IPX/SPX, but is used with IP the resolution system is WINS, which resolves NetBIOS names to IP addresses. There is an lmhosts file that allows you to hardcode these. This is used in file sharing based on UNC paths, in which you can use IP address as well as netbios names.

Packet size, MTU and MSS, fragmenting

On the wire, the packet/frame's size is everything together, though people often list a size at the layer they are dealing with, or most commonly deal with.

Classical Ethernet's frames are at most 1518-byte things, with 18 bytes for its own purposes, so each IP packet put inside it can be at most 1500 bytes.

MTU (Maximum Transferable Unit) and MSS (Maximum Segment Size) refer to upper limits to sizes.

MTU refers to the encapsulated whole,

MSS refers to how much payload is in it.

Strictly speaking, neither term is tied to a layer(verify), which means one layer's MSS is another's MTU, which can get very confusing if you don't mention what layer we're talking about.

In practice

you can often guess from context,
nine times out of ten we're thinking at at IP level.

Say, 1500 byte MTU size and 1460 byte MSS size very much suggests you are talking about IP over ethernet, and TCP/IP over Ethernet, respectively.

While we often think of IP having an MTU of 1500, this is more about typical backwards-compatible LANs, and the internet, than about the IP protocol.

Technically, IPv4 has a maximum packet size of 65535, though no one really wants to use that, in part because over almost any real network it will get fragmented, and partly because the effectiveness of IP's CRC checksum becomes low when you go over ~11K (see [1]).

On a gBit LAN, though, jumbo frames of something like 9000 bytes can more easily bulk-transfer close to 1gBit than without it (at best, it also depends on other efficiency issues, including the program/protocol's cleveness).

...but if not all switches and hosts support jumbo frames, they will probably get dropped.

Using 1gBit at full speed with 1.5k frames means ~80kpackets/sec, which means a lot of driver overhead, and in one-packet-per-interrupt setups is actually quite heavy (interrupts by their nature have to pause other work, so make for general sluggishness). Jumbo frames are one way to lessen that, but in the real world often only help a little -- and if not all hosts and routers along the path support and are configured for it they may fragment or just drop packets, meaning little help or no function at all.

Other offloading methods tend to work better (and most are standard now).

On congestion

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

QoS

In a broad sense, Quality of Service (QoS) is the concept of trying for certain types of guarantees, in telephony as well as in data networking.

Apparently the term QoS was first used in ITU X.902, but the term is used in various standards now, with varying and sometimes broad definitions.

The guarantees are often something like low latency, low latency jitter (e.g. for VoIP, videoconferencing), guaranteed bandwidth (e.g. for TV over IP), and such.

Approaches

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

TOS

A common trick when using IPv4 is to use the TOS byte in its header, which was never used much. It is now used to encode data to support:

Differentiated services (also 'DiffServ'); the QoS needs map onto this fairly decently

Explicit Congestion Notification (ECN)

Fancy(-ish) routers support this, as do modern unices and some recent windows implementations.

VPN

See VPN notes

Link aggregation

VLANs

On encryption

Things like encryption can be done at every level above physical{[verify}}.

TLS/SSL security, in the IP sense, is snuck in between layer 4 and layer 5 by making it part of the layer 5 protocol, inside/under the real protocol (In the 7-layer view on IP, this can be said to be in multiple cooperating layers, mostly layer 6)

This usually means there is often a non-secure and a secure version of the same protocol defined at layer 5.

IPX, SPX, NWLink

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

IPX (Internetwork Packet Exchange) was a layer 3 protocol fairly commonly used up to the mid-nineties (which is approximately when the IP stack started replacing it, partly just because of convenience. (Note that while IP has a similar role to IPX, the two names and technologies are not particularly related).

SPX is a layer 4 protocol used on top of IPX.

Windows later added NWLink, which was an implementation of SPX/IPX, and NetBIOS on top of that.

IPX was commonly used for Netware, and by various DOS-era games.

NetBIOS was often transferred over IPX/SPX, and more recently also by TCP/IP (and more recently used primarily for SMB file sharing, which is currently done mostly over IP instead).

These days, IPX mostly matters to people wishing to play old games. IPX in DOS was a somewhat complex matter to set up. NWLink was supported from Win95 up to WinXP, but was dropped in Vista.

People report that in 32-bit vista, you can copy in XP's (32-bit) drivers (see things like [3]).

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Unsorted

Where to find nice images like: http://www.javvin.com/links.html ?

An IP-stack socket is effectively a 5-tuple: (protocol, local_address, local_port, remote_address, remote_port)

physically identify a card you have the name of

ethtool -p eth1

Steadily blinks LEDs on port

(in my case also used a different color -- ports tend to be two two-color LEDs)

Layer 2 unsorted notes

Contents

Switches, routers, hubs, bridges, etc.

LAN, Broadcast domain, LAN segment, collision domain

Reducing broadcast domain size

Semi-sorted

Glossary

ICMPv6

NDP

Wake On Lan

Networking / routing, in general and particularly for web based WOL

WOL senders

NIC, protocol address, and name resolution

Ethernet and IP; ARP

Server names; DNS

Netbios names; WINS

Packet size, MTU and MSS, fragmenting

On congestion

QoS

Approaches

TOS

See also (QoS)

VPN

Link aggregation

VLANs

On encryption

IPX, SPX, NWLink

Unsorted

physically identify a card you have the name of

Channel bonding

See also (general)

Navigation menu