Audience: cybersecurity practitioners, Linux administrators, network engineers, field testers, incident responders, lab builders, and developers automating Linux network-attachment workflows.
Purpose: provide a reusable workflow for connecting a Linux laptop or dual-NIC dropbox to an authorised LAN, unfamiliar Ethernet port, direct-attached device, or authorised Wi-Fi network; observing the segment; establishing Layer-3 connectivity safely; and recording enough state that the process can be repeated or automated.
This is intentionally a generic Linux/networking guide. It is not tied to a particular appliance or product.
Scope and authorisation: use active discovery, DHCP requests, static-address trials, VLAN attachment, or local DHCP service only on networks you own or are authorised to test. Passive observation is lower impact, but connecting equipment to a production network can still trigger NAC, monitoring, or operational controls.
- The Workflow in One Page
- Before Connecting Anything
- Useful Linux Tooling
- Operational Modes
- Passive Ethernet Attachment
- What to Learn From Passive Traffic
- VLAN-Aware Attachment
- Normal DHCP Attachment
- IPv6 Is a First-Class Path
- Static Addressing
- Protecting the Management Session
- Wi-Fi Client Workflow
- NAC and 802.1X
- Isolated Direct-Attached Device Mode
- Practical Verification Checklist
- Addressing Reference
- Suggested Evidence / Session Record
- Cleanup / Reset
- Field Quick Reference
A typical field system has two interfaces:
- Management / uplink: the operator's reliable management path, such as Ethernet, Wi-Fi, or cellular.
- Target interface: the interface connected to the network being examined.
The target side should not bridge or route into the management side unless that behaviour is explicitly required.
flowchart LR
O["Operator"] --> M["Management interface<br/>mgmt0"]
M --> D["Linux laptop / dropbox"]
D --> T["Target interface<br/>target0"]
T --> N["Authorised LAN / device / AP"]
D -.-> S["Safety boundary:<br/>no bridge or forwarding by default"]
The general workflow is:
flowchart TD
A["Identify target interface"] --> B["Protect management path"]
B --> C{"Ethernet or Wi-Fi?"}
C -->|Ethernet| D["Bring link up with no L3 address"]
C -->|Wi-Fi| E["Associate to authorised SSID"]
E --> D
D --> F["Passive observation"]
F --> G{"802.1Q tags or known VLAN?"}
G -->|Yes| H["Create VLAN subinterface"]
G -->|No| I["Use untagged/base interface"]
H --> J["Observe selected VLAN"]
I --> J
J --> K{"DHCP or IPv6 RA available?"}
K -->|Yes| L["Acquire normal network configuration"]
K -->|No| M["Infer only from observed evidence"]
M --> N["Check candidate address for conflict"]
N --> O["Temporarily assign scoped static address"]
L --> P["Verify local connectivity"]
O --> P
P --> Q["Record address, prefix, gateway, DNS, VLAN, routes"]
Q --> R["Begin authorised testing"]
The useful mental model is:
Attach -> isolate -> observe -> classify -> configure -> verify -> record -> test -> reset
ip -br link
ip -br addr
ip route
ip -6 routeFor driver, carrier, and link information:
ethtool target0
ethtool -i target0
cat /sys/class/net/target0/carrier 2>/dev/nullA carrier value of 1 means Ethernet link is present; 0 means no carrier.
Before modifying the target side, capture the current management routing state:
ip route get 1.1.1.1
ip route show default
ip rule showIf you are connected remotely, this is critical. Do not allow a DHCP lease or manually added default route on the target interface to unexpectedly replace the route carrying SSH, VPN, or other management traffic.
Check:
sysctl net.ipv4.ip_forward
sysctl net.ipv6.conf.all.forwardingFor a non-routing dropbox:
sudo sysctl -w net.ipv4.ip_forward=0
sudo sysctl -w net.ipv6.conf.all.forwarding=0Also confirm that no bridge has accidentally joined the two trust zones:
ip -d link show type bridge
bridge linkThe exact package names vary by distribution. A practical toolkit includes:
iproute2/ipandbridge;ethtool;tcpdump;- Wireshark CLI tools (
dumpcap,tshark); iwandrfkill;- NetworkManager /
nmcliorsystemd-networkd; wpa_supplicant;- an
arpingimplementation that supports IPv4 Duplicate Address Detection; - optional
dnsmasqfor isolated lab DHCP service.
Debian/Ubuntu example:
sudo apt update
sudo apt install iproute2 ethtool tcpdump tshark iw rfkill \
network-manager wpasupplicant iputils-arping dnsmasqInstall only what fits the host's networking stack. A server using systemd-networkd does not need NetworkManager merely to follow this guide.
Example addresses in this document use the documentation-only
192.0.2.0/24range. Replace them with engagement or lab-specific addresses.
Use an explicit mode rather than letting several networking tools compete for the interface.
| Mode | Use case | Expected activity |
|---|---|---|
| Passive | Unknown production segment; first contact | Link only, packet capture, no deliberate L3 probes |
| DHCP client | Normal LAN attachment | DHCPv4 and/or IPv6 autoconfiguration |
| Known static | Address/prefix supplied by operator/client | Assign known address and scoped routes |
| Inferred static | No DHCP; evidence suggests a local subnet | Carefully test a candidate address |
| Wi-Fi client | Authorised WLAN | Associate first, then use one of the L3 modes above |
| VLAN client | Tagged VLAN is known or evidenced | Create 802.1Q subinterface, then run L3 mode on it |
| Isolated DHCP server | Direct-attached lab/device segment only | Dropbox provides addressing to the target |
Do not infer “safe to run a DHCP server” merely because no DHCPOFFER was observed. A production network may have DHCP relay, NAC, filtering, a temporarily silent server, or a VLAN mismatch. DHCP-server mode should be an explicit operator-authorised mode for an isolated/direct-attached segment.
The Linux kernel does not normally invent an IPv4 link-local address by itself; a userspace network manager may do so. Determine what manages the interface:
networkctl status target0 2>/dev/null
nmcli device status 2>/dev/null
ps -ef | grep -E 'NetworkManager|systemd-networkd|dhcpcd|dhclient' | grep -v grepWith NetworkManager, a field operator can temporarily mark only the target interface unmanaged:
sudo nmcli device set target0 managed noDo not stop networking globally on a remotely managed dropbox.
For a deliberately quiet passive observation phase, disable IPv6 processing while the link is down, flush old addresses, and only then bring the interface up:
sudo ip link set target0 down
sudo sysctl -w net.ipv6.conf.target0.disable_ipv6=1
sudo ip addr flush dev target0
sudo ip link set target0 up
ip -br addr show dev target0An interface with no assigned IPv4 or IPv6 address is unaddressed; it is not literally assigned 0.0.0.0. Disabling IPv6 processing prevents the host from participating in IPv6 autoconfiguration during the quiet phase; packet capture can still observe inbound Ethernet frames such as Router Advertisements.
Re-enable IPv6 before testing normal IPv6 connectivity:
sudo sysctl -w net.ipv6.conf.target0.disable_ipv6=0tcpdump enters promiscuous mode by default unless -p is supplied. -p means do not put the interface into promiscuous mode.
sudo mkdir -p /var/log/dropbox
sudo tcpdump -i target0 -nn -s 0 -w /var/log/dropbox/initial.pcapWith dumpcap:
sudo dumpcap -i target0 -w /var/log/dropbox/initial.pcapngUseful live summaries:
sudo tcpdump -ni target0 'arp or icmp6 or (udp port 67 or 68) or ether proto 0x8100 or ether proto 0x88cc or ether proto 0x888e'Useful protocol filters:
ARP arp
DHCPv4 udp port 67 or udp port 68
IPv6 NDP / RA icmp6
802.1Q VLAN ether proto 0x8100
LLDP ether proto 0x88cc
802.1X / EAPOL ether proto 0x888e
mDNS udp port 5353
LLMNR udp port 5355
SSDP udp port 1900
On a normal switched access port, promiscuous mode does not make the switch send you every other host's unicast frames. You normally see:
- frames addressed to your MAC;
- broadcasts;
- relevant multicast;
- some control-plane traffic;
- anything a TAP, hub, SPAN/mirror port, or other network configuration deliberately exposes.
For broad passive visibility, use a network TAP or switch mirror/SPAN session.
Look for evidence before making assumptions.
| Evidence | What it can tell you |
|---|---|
| ARP | Local IPv4 addresses, IP-to-MAC mappings, possible routers |
| DHCP | Server, offered address, subnet mask, router, DNS, domain, lease options |
| IPv6 Router Advertisements | IPv6 prefix, router, SLAAC behaviour, sometimes DNS information |
| NDP | IPv6 neighbours and active local addresses |
| mDNS / LLMNR / NBNS | Hostnames, local services, operating-system clues |
| SSDP | UPnP devices and service locations |
| LLDP / CDP | Switch identity and sometimes VLAN or management information |
| 802.1Q tags | Tagged VLAN IDs actually visible on the wire |
| EAPOL | Evidence that 802.1X port authentication/NAC may be in use |
| OSPF/RIP/VRRP/HSRP or other control traffic | Routing and redundancy clues, if exposed on the segment |
Useful quick extractions:
# Observed ARP
sudo tcpdump -nn -r /var/log/dropbox/initial.pcap arp
# VLAN IDs from a capture, if tshark is available
tshark -r /var/log/dropbox/initial.pcap -Y vlan -T fields -e vlan.id | sort -nu
# DHCP fields
tshark -r /var/log/dropbox/initial.pcap -Y 'bootp' \
-T fields \
-e ip.src -e bootp.option.dhcp_server_id \
-e bootp.option.subnet_mask -e bootp.option.router
# IPv6 router advertisements
tshark -r /var/log/dropbox/initial.pcap -Y 'icmpv6.type == 134'Do not treat every observed source address as proof of the local subnet. Captures may contain routed, tunneled, mirrored, malformed, stale, or intentionally deceptive traffic.
VLANs are a common reason an unfamiliar switch port appears to have “no network.”
Access port: the endpoint normally receives untagged Ethernet. The switch internally associates the port with a VLAN. The endpoint usually cannot determine the access VLAN ID merely from the absence of tags.
Tagged trunk: one or more VLANs are carried with 802.1Q tags. The Linux host must create a VLAN subinterface for each VLAN it is authorised to use.
Native/untagged VLAN on a trunk: untagged traffic may coexist with tagged VLANs.
flowchart TD
A["Physical link up"] --> B["Capture on base interface"]
B --> C{"Tagged frames observed?"}
C -->|No| D["Treat base interface as untagged path"]
C -->|Yes| E["Record observed VLAN IDs"]
E --> F{"VLAN authorised / expected?"}
F -->|No| G["Observe only"]
F -->|Yes| H["Create VLAN subinterface"]
H --> I["Run DHCP / IPv6 / static workflow on VLAN interface"]
D --> J["Run DHCP / IPv6 / static workflow on base interface"]
sudo tcpdump -eni target0 vlanOr:
tshark -i target0 -Y vlan -T fields -e vlan.idCheck for LLDP/CDP as supporting evidence, but do not assume they will reveal the complete trunk configuration.
Some NICs strip VLAN tags in hardware before packets reach the normal capture path. Check offload state:
ethtool -k target0 | grep -i vlanFor troubleshooting capture visibility, you can temporarily disable RX VLAN offload if the driver supports it:
sudo ethtool -K target0 rxvlan offRestore the original setting afterwards.
Example for VLAN 100:
sudo ip link add link target0 name target0.100 type vlan id 100
sudo ip link set target0 up
sudo ip link set target0.100 up
ip -d link show target0.100Then treat target0.100 as a normal Layer-3 interface:
sudo tcpdump -ni target0.100Remove it when finished:
sudo ip link delete target0.100An automated system should not blindly iterate VLAN IDs 1-4094 and transmit DHCP on each one unless the engagement explicitly authorises that behaviour.
Prefer this order:
- supplied VLAN ID;
- VLAN ID observed in tagged traffic;
- VLAN information from trusted LLDP/CDP or site documentation;
- operator-selected active enumeration only when authorised.
If the port is an access port, creating target0.<id> generally will not help because the switch expects untagged endpoint traffic.
When active attachment is authorised, DHCP is the most reliable way to learn IPv4 configuration because the server supplies the prefix and other options rather than forcing you to guess them.
Do not simultaneously run NetworkManager, systemd-networkd, dhcpcd, and dhclient against the same interface.
NetworkManager:
sudo nmcli device set target0 managed yes
sudo nmcli connection add type ethernet ifname target0 con-name dropbox-target ipv4.method auto ipv6.method auto
sudo nmcli connection up dropbox-targetsystemd-networkd: use a .network file with DHCP=yes, then:
sudo networkctl reconfigure target0
sudo networkctl renew target0ISC dhclient, if installed:
sudo dhclient -v target0BusyBox/udhcpc, if installed:
sudo udhcpc -i target0 -f -qInspect the result:
ip -br addr show dev target0
ip route show dev target0
resolvectl status target0 2>/dev/nullFor a VLAN, substitute target0.100 or the appropriate subinterface.
Possible causes include:
- wrong VLAN;
- NAC / 802.1X;
- switch port security;
- DHCP relay or server filtering;
- MAC allow-listing;
- physical link problems;
- exhausted DHCP scope;
- client identifier policy;
- unidirectional capture or firewall behaviour.
Treat “no lease” as an observation, not a conclusion.
A modern LAN may provide IPv6 even when IPv4 DHCP fails, and some environments can be IPv6-only.
Observe first:
sudo tcpdump -ni target0 'icmp6'Look for Router Advertisements (ICMPv6 type 134), prefixes, routers, and neighbour traffic.
After re-enabling IPv6 on an interface that was made passive:
sudo sysctl -w net.ipv6.conf.target0.disable_ipv6=0
ip -6 addr show dev target0
ip -6 route show dev target0If your normal network manager is configured for IPv6 autoconfiguration, allow it to manage the interface and then inspect the resulting SLAAC/DHCPv6 state.
Useful checks:
ping -6 -I target0 -c 2 ff02::1
ip -6 neigh show dev target0Do not assume that the absence of an IPv4 lease means the port is unusable.
The IPv4 header does not carry the sender's subnet mask. A capture can strongly suggest a subnet, but it may not prove the exact prefix length.
Prefer evidence in this order:
- DHCP lease/options;
- site documentation or operator-provided configuration;
- IPv6 RA for IPv6 prefixes;
- routing/control protocol information that explicitly contains prefixes;
- repeated local ARP/traffic patterns;
- cautious hypothesis testing.
Avoid old classful assumptions such as “10.x means /8” or “192.168.x means /24.” CIDR networks can use many prefix lengths.
Before assigning an inferred IPv4 address, first ensure it was not seen in passive traffic.
Then, if active probing is authorised, use Duplicate Address Detection with arping:
sudo arping -D -I target0 -c 3 192.0.2.50With the iputils implementation, arping -D is Duplicate Address Detection mode and exits 0 when no replies are received. Other arping implementations differ, so automation should detect the installed implementation and its exit semantics rather than assuming flags are portable.
sudo ip addr add 192.0.2.50/24 dev target0Inspect the automatically created connected route:
ip route show dev target0Do not add a target-side default route unless you actually need one. For local verification, test a known or inferred neighbour directly:
ping -I target0 -c 2 192.0.2.1
arping -I target0 -c 2 192.0.2.1
ip neigh show dev target0If a target default route is required, give it an intentionally higher metric than the management route or isolate the target into its own routing domain.
Example:
sudo ip route add default via 192.0.2.1 dev target0 metric 500Remove the trial configuration when done:
sudo ip addr flush dev target0
sudo ip route flush dev target0The original temptation is to try /24, /16, /23, /25, and so on. That is a poor generic rule because real networks are not statistically constrained to that sequence, and changing masks can change which destinations Linux treats as on-link.
Automation should score a candidate prefix using observed evidence and require a confidence threshold or operator approval before active trials.
For most discovery tasks, the target interface only needs its connected subnet route. Use interface-bound tools:
ping -I target0 192.0.2.1
curl --interface target0 http://192.0.2.10/
ssh -b 192.0.2.50 user@192.0.2.10A network namespace gives the target interface its own addresses, routes, ARP/NDP cache, and default route, protecting the host's management routing table.
Example:
sudo ip netns add targetns
sudo ip link set target0 netns targetns
sudo ip netns exec targetns ip link set lo up
sudo ip netns exec targetns ip link set target0 up
sudo ip netns exec targetns ip addr show
sudo ip netns exec targetns tcpdump -ni target0Static configuration inside the namespace:
sudo ip netns exec targetns ip addr add 192.0.2.50/24 dev target0
sudo ip netns exec targetns ip route add default via 192.0.2.1
sudo ip netns exec targetns ping -c 2 192.0.2.1Return the interface to the default namespace:
sudo ip netns exec targetns ip link set target0 netns 1
sudo ip netns delete targetnsWireless interfaces need additional care because Wi-Fi is associated with a wireless PHY and userspace supplicant; policy routing or moving/configuring the wireless PHY inside the namespace may be more appropriate than blindly moving only the netdev.
If moving the interface into a namespace is inconvenient, use a dedicated routing table so traffic sourced from the target address uses the target gateway without replacing the management default route:
sudo ip route add 192.0.2.0/24 dev target0 src 192.0.2.50 table 100
sudo ip route add default via 192.0.2.1 dev target0 table 100
sudo ip rule add from 192.0.2.50/32 table 100 priority 1000
ip rule show
ip route show table 100Remove the temporary policy when finished:
sudo ip rule del from 192.0.2.50/32 table 100 priority 1000
sudo ip route flush table 100Wi-Fi adds a Layer-2 association/authentication step before normal IP configuration.
flowchart TD
A["Identify Wi-Fi interface"] --> B["Scan / select authorised SSID"]
B --> C["Associate and authenticate"]
C --> D{"Association successful?"}
D -->|No| E["Inspect credentials, RF, security mode, NAC"]
D -->|Yes| F["Observe L2/L3 traffic"]
F --> G["DHCP / IPv6 / static workflow"]
G --> H["Verify routes and DNS"]
iw dev
iw dev wlan0 link
rfkill listnmcli device wifi list ifname wlan0
sudo nmcli device wifi connect 'ExampleSSID' password 'example-password' ifname wlan0For enterprise 802.1X/WPA-Enterprise, use an appropriate NetworkManager profile or wpa_supplicant configuration supplied for the engagement rather than embedding credentials into shell history.
Generate a WPA2-PSK block without hand-writing the PSK hash:
wpa_passphrase 'ExampleSSID' 'example-password' | sudo tee /tmp/wpa.conf >/dev/null
sudo wpa_supplicant -B -i wlan0 -c /tmp/wpa.confThen run the same DHCP/IPv6/static workflow used for Ethernet.
Check association:
iw dev wlan0 link
ip -br addr show dev wlan0A Wi-Fi client in normal managed mode generally sees traffic delivered to that station plus broadcast/multicast visible to it. Capturing all 802.11 frames requires monitor-mode capability, an appropriate channel, and different operational assumptions. Treat monitor-mode collection as a separate wireless assessment workflow rather than conflating it with ordinary network attachment.
A link light only proves physical/link-layer carrier. It does not prove that the network will permit normal IP traffic.
Look for EAPOL:
sudo tcpdump -eni target0 'ether proto 0x888e'Common causes of restricted connectivity:
- 802.1X authentication required;
- MAC Authentication Bypass (MAB);
- port security / sticky MAC;
- quarantined or guest VLAN;
- dynamic VLAN assignment;
- DHCP snooping or source guard;
- switch ACLs;
- NAC posture checks;
- captive portal;
- Wi-Fi client isolation.
An automation system should represent this as a distinct state such as ACCESS_CONTROLLED, not repeatedly guess IP addresses forever.
Sometimes the dropbox is not joining an existing LAN at all; it is connected directly to a device under test or to an isolated lab switch. In that case it can intentionally become the local network infrastructure.
Example static host setup:
sudo ip addr flush dev target0
sudo ip addr add 192.0.2.1/24 dev target0
sudo ip link set target0 upA DHCP server such as dnsmasq can be bound only to the target interface in an isolated lab:
port=0
interface=target0
bind-interfaces
dhcp-range=192.0.2.100,192.0.2.150,255.255.255.0,1h
# Suppress the default router and DNS options unless this box intentionally provides them.
dhcp-option=option:router
dhcp-option=option:dns-serverThen run:
sudo dnsmasq --keep-in-foreground --conf-file=/path/to/dropbox-dnsmasq.confNever automatically start this configuration merely because an unfamiliar production port did not answer DHCP.
Once an address exists, verify in layers rather than jumping straight to an Internet test.
ip link show target0
ethtool target0ip -br addr show dev target0
ip route show dev target0
ip -6 route show dev target0ip neigh show dev target0
ip -6 neigh show dev target0ping -I target0 -c 2 <gateway-or-local-host>resolvectl status target0 2>/dev/nullcurl --interface target0 http://<authorised-host>/sudo tcpdump -ni target0This makes failures explainable: no ARP reply, ICMP blocked, DNS wrong, route wrong, application closed, NAC active, and so on.
| Range | CIDR |
|---|---|
10.0.0.0 - 10.255.255.255 |
10.0.0.0/8 |
172.16.0.0 - 172.31.255.255 |
172.16.0.0/12 |
192.168.0.0 - 192.168.255.255 |
192.168.0.0/16 |
These are blocks, not default subnet masks. A network inside them may use /20, /23, /24, /27, /30, or another appropriate prefix.
| Range | Meaning |
|---|---|
127.0.0.0/8 |
Loopback |
169.254.0.0/16 |
IPv4 link-local |
100.64.0.0/10 |
Shared address space / CGNAT |
224.0.0.0/4 |
IPv4 multicast |
255.255.255.255/32 |
Limited broadcast |
Public IPv4 space can legitimately appear on enterprise, campus, ISP, hosting, or research networks. Do not assume “public means Internet uplink” or “private means LAN.”
These are all possible IPv4 CIDR prefix lengths. A prefix length specifies how many of the 32 IPv4 bits belong to the network portion of the address.
| CIDR | Subnet mask | Total addresses | Traditional usable hosts* |
|---|---|---|---|
/0 |
0.0.0.0 |
4,294,967,296 | 4,294,967,294 |
/1 |
128.0.0.0 |
2,147,483,648 | 2,147,483,646 |
/2 |
192.0.0.0 |
1,073,741,824 | 1,073,741,822 |
/3 |
224.0.0.0 |
536,870,912 | 536,870,910 |
/4 |
240.0.0.0 |
268,435,456 | 268,435,454 |
/5 |
248.0.0.0 |
134,217,728 | 134,217,726 |
/6 |
252.0.0.0 |
67,108,864 | 67,108,862 |
/7 |
254.0.0.0 |
33,554,432 | 33,554,430 |
/8 |
255.0.0.0 |
16,777,216 | 16,777,214 |
/9 |
255.128.0.0 |
8,388,608 | 8,388,606 |
/10 |
255.192.0.0 |
4,194,304 | 4,194,302 |
/11 |
255.224.0.0 |
2,097,152 | 2,097,150 |
/12 |
255.240.0.0 |
1,048,576 | 1,048,574 |
/13 |
255.248.0.0 |
524,288 | 524,286 |
/14 |
255.252.0.0 |
262,144 | 262,142 |
/15 |
255.254.0.0 |
131,072 | 131,070 |
/16 |
255.255.0.0 |
65,536 | 65,534 |
/17 |
255.255.128.0 |
32,768 | 32,766 |
/18 |
255.255.192.0 |
16,384 | 16,382 |
/19 |
255.255.224.0 |
8,192 | 8,190 |
/20 |
255.255.240.0 |
4,096 | 4,094 |
/21 |
255.255.248.0 |
2,048 | 2,046 |
/22 |
255.255.252.0 |
1,024 | 1,022 |
/23 |
255.255.254.0 |
512 | 510 |
/24 |
255.255.255.0 |
256 | 254 |
/25 |
255.255.255.128 |
128 | 126 |
/26 |
255.255.255.192 |
64 | 62 |
/27 |
255.255.255.224 |
32 | 30 |
/28 |
255.255.255.240 |
16 | 14 |
/29 |
255.255.255.248 |
8 | 6 |
/30 |
255.255.255.252 |
4 | 2 |
/31 |
255.255.255.254 |
2 | 2 on point-to-point links |
/32 |
255.255.255.255 |
1 | 1 host route |
*The traditional IPv4 host calculation is 2^(32-prefix) - 2, subtracting the network and broadcast addresses. That convention does not apply to /31 point-to-point links (RFC 3021), and /32 identifies a single host/route. For very large prefixes such as /0, the arithmetic is mathematically correct but does not imply that the entire range would normally be operated as one Ethernet subnet.
A useful dropbox should leave behind a small, understandable session record next to the PCAP.
session_id: 2026-08-19T08-30-00Z
interface: target0
link:
carrier: true
speed_mbps: 1000
mac: "02:00:00:00:00:10"
media: ethernet
vlan:
selected: null
observed: [100]
access_control:
eapol_seen: false
ipv4:
method: dhcp
address: 192.0.2.44
prefix: 24
gateway: 192.0.2.1
ipv6:
addresses: []
management_route_changed: false
capture: /var/log/dropbox/initial.pcap
notes:
- "VLAN 100 observed but not actively joined"The distinction between observed, inferred, and configured data is important. Do not write an inference into the log as though it were a fact.
A reusable dropbox needs a reliable return-to-baseline operation.
For a normal interface:
sudo ip addr flush dev target0
sudo ip route flush dev target0
sudo ip -6 route flush dev target0
sudo ip link set target0 downRemove temporary VLAN interfaces:
sudo ip link delete target0.100 2>/dev/null || trueRestore NetworkManager ownership if it was disabled:
sudo nmcli device set target0 managed yesRestore any NIC offload settings changed for capture diagnostics.
If a namespace was used, return the interface before deleting it.
Finally verify:
ip -br link
ip -br addr
ip route
ip ruleThe management path should be exactly where you expect it to be.
For an authorised unknown Ethernet port, a conservative operator workflow is:
# Identify
ip -br link
ip route show default
# Prepare target interface
sudo nmcli device set target0 managed no 2>/dev/null || true
sudo ip addr flush dev target0
sudo ip link set target0 up
# Observe first
sudo tcpdump -eni target0 -nn
# Look specifically for VLAN / NAC / DHCP / IPv6
sudo tcpdump -eni target0 -nn \
'vlan or ether proto 0x888e or ether proto 0x88cc or arp or icmp6 or udp port 67 or udp port 68'
# If an authorised VLAN 100 is required
sudo ip link add link target0 name target0.100 type vlan id 100
sudo ip link set target0.100 up
sudo tcpdump -ni target0.100
# Then use the site's normal DHCP method or assign a supplied static address.
# Verify locally before adding any target-side default route.For authorised Wi-Fi:
iw dev
nmcli device wifi list ifname wlan0
sudo nmcli --ask device wifi connect '<SSID>' ifname wlan0
ip -br addr show dev wlan0
ip route show dev wlan0The goal is not to “force an IP at any cost.” The goal is to establish correct, explainable, minimally disruptive connectivity while preserving evidence and the operator's management path.
- RFC 1918 — Address Allocation for Private Internets: https://datatracker.ietf.org/doc/html/rfc1918
- RFC 3021 — Using 31-Bit Prefixes on IPv4 Point-to-Point Links: https://datatracker.ietf.org/doc/html/rfc3021
- RFC 3927 — Dynamic Configuration of IPv4 Link-Local Addresses: https://datatracker.ietf.org/doc/html/rfc3927
- RFC 5737 — IPv4 Address Blocks Reserved for Documentation: https://datatracker.ietf.org/doc/html/rfc5737
- RFC 6598 — Shared Address Space (
100.64.0.0/10): https://datatracker.ietf.org/doc/html/rfc6598 - NetworkManager documentation: https://networkmanager.dev/docs/
- dnsmasq manual: https://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html
- iputils
arping: https://github.com/iputils/iputils
These references are implementation aids; the field workflow above is deliberately tool-agnostic where Linux distributions differ.