seb/2024-bsc-sebastian-lenzlinger
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

WHAT

Browse Source
This commit is contained in:
Sebastian Lenzlinger
2024-06-28 23:49:16 +02:00
commit 86f60da6ec
107 changed files with 25057 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

0
notes/.gitkeep Normal file
View File

34
notes/2024-04-28-meeting/IoTdb.md Normal file
View File

@@ -0,0 +1,34 @@
IoT.db/
├── Device1/
│ ├── Rawdata/
│ │ ├── measurement#D1#1/
│ │ │ ├── capfile
│ │ │ └── meta
│ │ └── measurement#D1#2/
│ │ └── ...
│ ├── Experiments/
│ │ ├── exp1#D1/
│ │ │ └── files etc
│ │ └── exp2#D1/
│ │ └── ...
│ └── Device 1 (Fixed) metadata
├── Device2/
│ ├── Rawdata/
│ │ ├── measurement#D2#1/
│ │ │ ├── capfile
│ │ │ └── meta
│ │ └── ...
│ ├── Experiments/
│ │ ├── exp1#d2/
│ │ │ └── ...
│ │ └── ...
│ └── Device 2 fixed metadata
└── .../
├── .../
│ ├── ..
│ └── ..
├── .../
│ ├── .../
│ │ └── ...
│ └── ...
└── ...

34
notes/2024-04-28-meeting/IoTdb.txt Normal file
View File

@@ -0,0 +1,34 @@
IoT.db/
├── Device1/
│ ├── Rawdata/
│ │ ├── measurement#D1#1/
│ │ │ ├── capfile
│ │ │ └── meta
│ │ └── measurement#D1#2/
│ │ └── ...
│ ├── Experiments/
│ │ ├── exp1#D1/
│ │ │ └── files etc
│ │ └── exp2#D1/
│ │ └── ...
│ └── Device 1 (Fixed) metadata
├── Device2/
│ ├── Rawdata/
│ │ ├── measurement#D2#1/
│ │ │ ├── capfile
│ │ │ └── meta
│ │ └── ...
│ ├── Experiments/
│ │ ├── exp1#d2/
│ │ │ └── ...
│ │ └── ...
│ └── Device 2 fixed metadata
└── .../
├── .../
│ ├── ..
│ └── ..
├── .../
│ ├── .../
│ │ └── ...
│ └── ...
└── ...

51
notes/2024-04-28-meeting/IoTdb2_3.txt Normal file
View File

@@ -0,0 +1,51 @@
Reasoning is that experiments might want data from measurements of multiple
devices.
IoT.db2/
├── Devices/
│ ├── Dev1/
│ │ ├── devmeta
│ │ └── Measurements/
│ │ ├── m1/
│ │ │ ├── raw
│ │ │ ├── meta
│ │ │ └── spec
│ │ └── m2/
│ │ └── ...
│ ├── Dev2/
│ │ ├── devmeta
│ │ └── Measurements/
│ │ ├── m1/
│ │ │ ├── raw
│ │ │ ├── meta
│ │ │ └── spec
│ │ ├── m2/
│ │ │ └── ...
│ │ ├── m3/
│ │ │ └── ...
│ │ └── ...
│ └── Dev3/
│ └── ....
└── Experiments/(Or projects? Or cleaned data)
├── E1/
│ ├── involved measurements
│ ├── filters/ feature extraction algo etc.
│ └── etcetc...
├── E2/
│ ├── .....
│ ├── ..
│ ├── ...
│ └── ..
└── ....
IoT.db3/
├── Measurements/
│ ├── m1/ (Specification of device in this substructure)
│ │ ├── follows from above
│ │ └── ...
│ ├── m2
│ └── ....
└── Experiments/
├── e1/
│ ├── follows from above
│ └── ...
├── e2
└── ...

15
notes/2024-04-28-meeting/IoTdb4.txt Normal file
View File

@@ -0,0 +1,15 @@
Like IoTdb but has no opinion on experiments
IoT.db4/
├── Dev1/
│ ├── Measurements (basically raw data)/
│ │ ├── m1/
│ │ │ └── ....
│ │ └── m2/
│ │ └── ....
│ └── Cleaned?/Features extracted?/Merged?/
│ └── -- Where to put clean data?
├── Dev2/
│ └── Measurements/
│ └── ...
└── Algos/Scripts?/
└── ..

92
notes/2024-04-28-meeting/further considerations.md Normal file
View File

@@ -0,0 +1,92 @@
# Testbed
- What is a testbed?
- "[...] wissenschaftliche Plattform für Experimente" german [Wikipedia](https://de.wikipedia.org/wiki/Testbed)
- What is a "Platform"?
- Example [ORBIT](https://www.orbit-lab.org/) Testbed as wireless network emulator (software I guess) + computing resources. Essence of offered service: Predictable environment. What is tested: Applications and protocols.
- [APE](https://apetestbed.sourceforge.net/) "APE testbed is short for **Ad hoc Protocol Evaluation testbed**." But also ["What exaclty is APE"](https://apetestbed.sourceforge.net/#What_exactly_is_APE): "There is no clear definition of what a testbed is or what it comprises. APE however, can be seen as containing two things:
- An encapsulated execution environment, or more specifically, a small Linux distribution.
- Tools for post testrun data analysis."
- [DES-Testbed](https://www.des-testbed.net) Freie Universität Berlin. Random assortment of sometimes empy(?!) posts to a sort of bulletin board.
## IoT Automation Testbed
#### From Abstract:
In this project, the student de-
signs a testbed for the **automated analysis** of the **privacy implications** IoT devices, paying particular
attention to features that support reproducibility.
#### From Project description:
To study the privacy and security as-
pects of IoT devices **_systematically_** and **_reproducibly_** , we need an easy-to-use testbed that _automates_ the
**_process of experimenting_** with **_IoT devices_**.
**Automation recipes**:
Automate important aspects of experiments, in particular:
- Data Collection
- Analysis (= Experiment in most places)
**FAIR data storage**
making data
- Findable
- Accessible
- Interoperable
- Reusable
### Implications/Open questions
#### FAIR Data Storage
1. Who are the stakeholders? What is the scope of "FAIRness"?
1. PersonalDB? --> [X], Tiny scope, $\lnot$ FAIR almost by definition. would only be tool/ suggestion on layout.
2. ProjectDB? --> [X], no, probably a project _uses_ a testbed
3. Research Group --> Focues on **F a IR**. Accessibility _per se_ not an issue. Findability -> By machine AND Human. Interoperable --> Specs may rely on local/uni/group idiosyncracies.
4. AcademicDB --> (Strict)Subset of 3. Consider field-specific standards. Must start decerning between public/non-public parts of db/testbed. One may unwittingly leak privacy information: Like location, OS of capture host, usernames, absolute file paths etc.See [here](https://www.netresec.com/?page=Blog&month=2013-02&post=Forensics-of-Chinese-MITM-on-GitHub) and [pcapng.com](https://pcapng.com/) under "Metadata Block Types"
5. Public DB --> (Strict) Subset of 4.
2. Seems like something between 3. and 4. Some type of repository. Full Fledged DB? Probably unnecessary. Mix text + low spec like sqlite? Could still be tracked by git probably.
3. Interoperability $\cap$ Automation recipes --> Recipes built from and depend only on widly available, platform-independent tools.
4. Accessibility $\cap$ Autorec --> Built from and only depend on tools which are 1. widly available and (have permissive license OR have equivalent with permissive license). Human: Documentation.
5. Reusable $\cap$ Autorec --> Modular tools, and accessible (license, etc.) dependencies (e.g. experiment specific scripts).
6. Findable $\cap$ Autorec--> Must assume that recipe is found and selected manually by researcher.
7. Interoperable --> Collected Data (Measurements) across different must follow a schema which is meaning full for
#### Usage paths/ Workflows:
Data Collection --> Deposit in FAIR repository
Primary Experiment --> Define Spec. Write script/code --> Access FAIR repo for data. Possibly Access FAIR repo for predefined scripts --> Where do results go. Results "repo"
Replication Experiment --> Chose experiment/benchmark script from testbed. --> Execute --> Publish (Produces Replication Result, i.e. same "schema" as primary experiment)
Replication Experiment Variant --> Chose experiment/benchmark. add additional processing and input --> run --> posibbly publish
How to define static vs dynamic aspect of experiment?
Haven't even thought about encryption/decryption specifics....
But also could go like this:
First design analysis/experiment --> Collect data --> data cleaned according to testbed scripts --> #TODO
Get new device and want to perform some predefined tests --> first need to collect data
For _some_ device (unknown if data already exists) want to perform test _T_ --> run script with device spec as input -> Script checks if data already available; If not, perform data collection first -> run analysis on data --> publish results to results/benchmark repo of device; if was new device, open new results branch for that device and publish initial results. _Primary Experiment_ with data collection.
Types of Experiments:
"Full Stack": Data Collection + Analysis
"Model Test": Data Access (+ Sampling) + Model (Or complete Workflow). Test subject: Model
"Replicaton Experiment": _secondary_ data collection + testbed model + quality criteria? Test Subject: Collection scheme + analysis model = result
"Exploratory Collection + Analysis": aka unsupervised #TODO
**Note**:
#TODO What types of metadata are of interest. Are metadata simple, minimal compute features. Complicated extracted/computed features? Where do we draw the line.
#TODO Say for the same devices. When is data merged, when not? I.e. under what conditions can datasets automatically be enlarged? How is this tracked as to not tamper with reproducibility?
### Reproducibility:
What are we trying to reproduce?
What are possible results from experiments/tests?
Types of artifacts:
Static:
Raw data.
Labaled Data.
Computational/ Instructive:
Supervised Training. Input: Labaled Data + Learning algo. Output: Model.
Model Applicability Test: Input: unlabeled data + model. Output: Predication/Label
Feature Extraction: (raw, labeled?) data + extraction algo. Output: Labaled Dataset.
New Feature Test: labeled data + feature extraction algo + learning algo. Output: Model + Model Verification -> Usability of new features... ( #todo this case exemplifies why we need modularity: we want to apply/compose new "feature extraction algo" e.g. to all those devices where applicable and train new models and verify "goodness" of new features per device/dataset etc.... )
### data collection and cleaning (and features):
How uniform is the schema of data we want to collect accross IoT spectrum. Per device? Say two (possibly unrelated) datasets happen to share the same schema, can we just merge them, say, even if one set is from a VR headset and another from a roomba?
Is the scheema always the same e.g. (Timestamp, src ip, dst ip, (mac ports? or unused features), payload?, protocols?).
If testbed data contains uniform data --> only "one" extraction algo and dataset schema = all relevant features
Alternativly, testbed data is heterogeneous --> feature extracts defines interoperability/mergeability of datasets.
Training Algo: Flexible schema, output only usable on data with same schema(?)
Model Eval: Schema fixed, eval data must have correct schema
Say a project output is model which retrieves privacy relevant information from the network traffic of IoT device. #TODO how to guaranty applicability to other devices? What are the needs in the aftermath? Apply same model to other data? What of raw data schema match, but incompatible labels?
#todo schema <-> applicable privacy metric matching

11
notes/journal/2024-03-11-mon.md Normal file
View File

@@ -0,0 +1,11 @@
### Completed:
- All Devices unpacked except [[xiaomi tv stick]].
- [[ledvance led strip]] wont enter pairing mode.
- [[echodot]] is setup and works.
- [[mi 360 home security camera]] needs microsd card.
## Plan for this week:
- Get microsd card
- MAINLY: Get AP working or find other way to capture traffic.
## Misc.:
Much time lost resetting router. [[ledvance led strip]] will only connect to 2.5GHz networks.
If laptop is connected to internet via ethernet, then I can make a AP, but iPhone wont connect to it. But IoT devices connect

4
notes/journal/2024-03-12-tue.md Normal file
View File

@@ -0,0 +1,4 @@
- Bought two USB Wifi Adapters (Completes [[TODO1]]):
- tp-link AC1300 Archer T3U (Mini Wireless MU-MIMO USB Adapter).
- tp-link AC1300 Archer T3U Plus (High Gain Wireless Dual Band USB Adapter)

12
notes/journal/2024-03-14-fri.md Normal file
View File

@@ -0,0 +1,12 @@
Plan: Setup wifi adapter to capture Amazon echodot.
Flow for setting up Access Point:
1. Setup Access Point
2. Configure Routing/Bridge or similar so IoT device can access internet.
Tried [linux-wifi-hotspot](https://github.com/lakinduakash/linux-wifi-hotspot) repo. Running it makes AP visible to iPhone, but issue is IP Address. Need to configure dhcp server or manually assign address.
Problem: Wifi Adapter In monitor mode sees nothing.
Neither Adapter has driver for modern macos
Archer T3U is using rtw_8822bu driver from kernel, this supports mac
Decide to go down hostapd route.

119
notes/journal/2024-03-19-tue.md Normal file
View File

@@ -0,0 +1,119 @@
Example [hostapd.conf](http://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf)
Simple article for basic setup [here](https://medium.com/p/3c18760e6f7e)
AP can be started an iPhone manages to connect. Now must 1:.ensure WPA2 or WPA3 and 2. enable ipmasquerading for internet connection. Then finally should be able to setup devices properly and start sniffing on traffic.
# 1st attempt AP setup
### Config files
File:`/etc/dnsmasq.d/dhcp-for-ap.conf`
Content:
```config
interface=wlp0s20f0u1
dhcp-range=10.0.0.3,10.0.0.20,12h
```
**BEWARE**: Must load above into `/etc/dnsmasq.conf` with a line that goes `conf-file=/etc/dnsmasq.d/dhcp-for-ap.conf` or `conf-dir=/etc/dnsmasq.d/,*.conf` see [here](https://wiki.archlinux.org/title/Dnsmasq#Configuration)
Other configs in `code/` directory.
## Used commands
See `code/` dir commit `devel@299912e` .
## Sanity Check
```bash
$ sudo hostapd ./hostapd.conf
# Output upon trying to connect with iPhone
wlp0s20f0u1: interface state UNINITIALIZED->ENABLED
wlp0s20f0u1: AP-ENABLED
wlp0s20f0u1: STA f2:10:60:95:28:05 IEEE 802.11: authenticated
wlp0s20f0u1: STA f2:10:60:95:28:05 IEEE 802.11: authenticated
wlp0s20f0u1: STA f2:10:60:95:28:05 IEEE 802.11: associated (aid 1)
wlp0s20f0u1: AP-STA-CONNECTED f2:10:60:95:28:05
wlp0s20f0u1: STA f2:10:60:95:28:05 RADIUS: starting accounting session 9C7F40AA0385E2B2
wlp0s20f0u1: STA f2:10:60:95:28:05 WPA: pairwise key handshake completed (RSN)
wlp0s20f0u1: EAPOL-4WAY-HS-COMPLETED f2:10:60:95:28:05
```
Connection established but no internet as expected.
## Test
*Input*
```bash
sudo ./initSwAP wlp
```
*Output*
```
net.ipv4.ip_forward = 1
wlp0s20f0u1: interface state UNINITIALIZED->ENABLED
wlp0s20f0u1: AP-ENABLED
wlp0s20f0u1: STA f2:10:60:95:28:05 IEEE 802.11: authenticated
wlp0s20f0u1: STA f2:10:60:95:28:05 IEEE 802.11: associated (aid 1)
wlp0s20f0u1: AP-STA-CONNECTED f2:10:60:95:28:05
wlp0s20f0u1: STA f2:10:60:95:28:05 RADIUS: starting accounting session C77A903F5D15F3B3
wlp0s20f0u1: STA f2:10:60:95:28:05 WPA: pairwise key handshake completed (RSN)
wlp0s20f0u1: EAPOL-4WAY-HS-COMPLETED f2:10:60:95:28:05
```
Unfortunatly still no internet connection.
## Analysis
Had forgot to import dhcp config file.
**Changes**: Add dnsmasq dhcp config and change wpa=3 to wpa=2 s.t. only WPA2 is used -> Now iPhone doesn't warn for security.
Unfortunatly still no internet connectino can be established.
## Todays 2nd attempt at Establishing an internet connection.
__Remarks/Observations:__
- iPhone connects to AP. Receieves IP Address `169.254.196.21` with subnet mask `255.255.0.0`. I
- P is a reserved non-routable for link-local ->Thus it seems that iPhone did not get an address from dhcp server.
- Could firewall be the problem? TODO -> iptables for dns and dhcp
- Maybe need to set static ip first etc as mentioned [here](https://woshub.com/create-wi-fi-access-point-hotspot-linux/)
```bash
# nano /etc/network/interfaces
auto wlp0s20f0u1
iface wlp0s20f0u1 inet static
address 10.10.0.1
netmask 255.255.255.0
```
- `/etc/network/interfaces` doesn't exist on my machine...
### Some configs to remember for later
dnsmasq:
```
#interface=wlp0s20f0u1
listen-address=10.0.0.2
dhcp-range=10.0.0.3,10.0.0.20,12h
dhcp-option=3,192.168.1.1
dhcp-option=6,192.168.1.1
domain-needed
bogus-priv
filterwin2k
server=1.1.1.1
no-hosts
```
Maybe need to enable ipv6 forwarding?
```
net.ipv4.ip_forward = 1
net.ipv4.conf.all.forwarding = 1
net.ipv6.conf.all.forwarding = 1
```
Flushing iptables: `iptables -F` flushes all tables. For more see [archwiki/iptables/Reset Rules](https://wiki.archlinux.org/title/Iptables#Resetting_rules)
- `sudo systemctl status iptables` says there is no such service unit!? -> Fedora uses [[firewalld]], which _is_ reported as running .........
#### Firewalld exploring
```bash
sudo firewall-cmd --get-active-zones
# Output:
# FedoraWorkstation (default)
# interfaces: wlp44s0
```
### Steps taken after restarting with [[firewalld]]
1. Followed steps in chapters 2.3.3 and 2.4 [here](https://wiki.archlinux.org/title/Internet_sharing#Enable_packet_forwarding). This should have enabled masquerading and have the ports ACCEPT for dns and dhcp.
2. Firewalld is not powerfull enough it seems
### nftables
* #TODO : What is the source of this info?!
Overview of a common configuration and packet flow
A host acting as a simple firewall and gateway may define only a small number of nft chains, each matching a kernel hook:
a prerouting chain, for all newly-arrived IP traffic
an input chain, for traffic addressed to the local host itself
an output chain, for traffic originating from the local host itself
a forward chain, for packets the host is asked to simply pass from one network to another
a postrouting chain for all IP traffic leaving the firewall
For configuration convenience and by convention, we group the input, output, and forward chains into a filter table. Most rules in setups like this attach to the forward chain.
If NAT is required, we follow the convention of creating a nat table to hold the prerouting and postrouting chains. Source-NAT rules (where we rewrite the packet source) attach to the postrouting chain, and destination-NAT rules (where we rewrite the packet’s destination) attach to the prerouting chain.
Packet flow is straightforward. Only one chain attaches to each hook. The first accept or drop rule a packet matches wins.

0
notes/journal/2024-03-24-tue.md Normal file
View File

10
notes/journal/2024-03-25-mon.md Normal file
View File

@@ -0,0 +1,10 @@
First success using mac mini.
Could record some data of amazon echo.
Setup gues network on router without any security, this enabled some capture since no keys had to be configured or handshakes captured (would be an issue without any channel controll)
Issue: Channalhopping -> missing a lot of traffic
To avoid channelhopping: Somehow fix the channel on router.
By leaving out any authentication/security config in hostapd.conf one can create an unsecured AP (on the usb wifi card) on my linux machine to. Having an open auth AP seems fine for this use case.
In the end this seems to be the way. For doing experiments we want to record all traffic. For this we cannot loose traffic just because we are not connected. This is why we'd want an access point we controll fully. We don't want to rely an some other router. But even then there would still be much manual config (channel, making an open access vlan or whatever).
Essentially we need to know the channel exaclty and don't want to deal with any more cryptography than we must. So, ideally we can create an AP on a laptop or local computer, using a low cost wifi adapter. (Since we are talking about testing IoT devices we must rely on wireless internet, since this is how virtually all of them work.) We should be able to configure that device to be an AP. Then we need to forward to whatever interface the experiment computer has internet access to.

0
notes/journal/2024-03-26-tue.md Normal file
View File

7
notes/journal/2024-04-09-tue.md Normal file
View File

@@ -0,0 +1,7 @@
New promising setup:
- Raspberry Pi 5
- Wired connection to router for internet
- Can very easily create wifi network and also connect to it (tested form iPhone 13)
- Can capture on the wifi card while still providing internet access to iPhone
- Sanity Test: Opening Youtube app on iPhone produces a large flow of QUIC packets, likely from the video that starts autoplaying.

177
notes/journal/2024-05-08-sun.md Normal file
View File

@@ -0,0 +1,177 @@
# Commands to remember + sample output
Used commands: [[nmcli]], [[iw]], [[grep]], [[sed]]
Resources: [Capturing Wireless LAN Packets in Monitor Mode with iw](https://sandilands.info/sgordon/capturing-wifi-in-monitor-mode-with-iw)
Foreign BSSIDs have been made anonymous by replacing with `XX:XX:XX:XX:XX:XX`.
## [[nmcli]]
Useful for getting channel needed to setup monitor mode properly.
### `nmcli dev wifi`
```
IN-USE BSSID SSID MODE CHAN RATE SIGNAL BARS SECURITY
XX:XX:XX:XX:XX:XX FRITZ!Box 5490 PB Infra 6 195 Mbit/s 75 ▂▄▆_ WPA2
* 4C:1B:86:D1:06:7B LenbrO Infra 100 540 Mbit/s 67 ▂▄▆_ WPA2
4C:1B:86:D1:06:7C LenbrO Infra 6 260 Mbit/s 64 ▂▄▆_ WPA2
B8:BE:F4:4D:48:17 LenbrO Infra 1 130 Mbit/s 62 ▂▄▆_ WPA
XX:XX:XX:XX:XX:XX -- Infra 6 260 Mbit/s 60 ▂▄▆_ WPA2
XX:XX:XX:XX:XX:XX FRITZ!Box 5490 PB Infra 60 405 Mbit/s 37 ▂▄__ WPA2
XX:XX:XX:XX:XX:XX FRITZ!Box Fon WLAN 7360 BP Infra 1 130 Mbit/s 34 ▂▄__ WPA1 WPA2
XX:XX:XX:XX:XX:XX FRITZ!Box 5490 PB Infra 6 195 Mbit/s 34 ▂▄__ WPA2
XX:XX:XX:XX:XX:XX Sunrise_Wi-Fi_09FB29 Infra 7 540 Mbit/s 34 ▂▄__ WPA2 WPA3
XX:XX:XX:XX:XX:XX Madchenband Infra 11 260 Mbit/s 34 ▂▄__ WPA2
XX:XX:XX:XX:XX:XX LenbrO Infra 36 270 Mbit/s 34 ▂▄__ WPA2
XX:XX:XX:XX:XX:XX FibreBox_X6-01EF47 Infra 1 260 Mbit/s 32 ▂▄__ WPA2
XX:XX:XX:XX:XX:XX -- Infra 11 260 Mbit/s 32 ▂▄__ WPA2
XX:XX:XX:XX:XX:XX EEG-04666 Infra 1 405 Mbit/s 30 ▂___ WPA2
XX:XX:XX:XX:XX:XX Salt_2GHz_8A9170 Infra 11 260 Mbit/s 29 ▂___ WPA2
XX:XX:XX:XX:XX:XX -- Infra 11 260 Mbit/s 24 ▂___ WPA2
XX:XX:XX:XX:XX:XX FRITZ!Box 5490 PB Infra 60 405 Mbit/s 19 ▂___ WPA2
```
### `nmcli -t dev wifi`
```
XX\:XX\:XX\:XX\:XX\:XX:FRITZ!Box 5490 PB:Infra:6:195 Mbit/s:79:▂▄▆_:WPA2
:XX\:XX\:XX\:XX\:XX\:XX::Infra:6:260 Mbit/s:75:▂▄▆_:WPA2
:4C\:1B\:86\:D1\:06\:7C:LenbrO:Infra:6:260 Mbit/s:74:▂▄▆_:WPA2
*:4C\:1B\:86\:D1\:06\:7B:LenbrO:Infra:100:540 Mbit/s:72:▂▄▆_:WPA2
:B8\:BE\:F4\:4D\:48\:17:LenbrO:Infra:1:130 Mbit/s:65:▂▄▆_:WPA2
:XX\:XX\:XX\:XX\:XX\:XX:Sunrise_Wi-Fi_09FB29:Infra:7:540 Mbit/s:52:▂▄__:WPA2 WPA3
:XX\:XX\:XX\:XX\:XX\:XX:FRITZ!Box 5490 PB:Infra:60:405 Mbit/s:50:▂▄__:WPA2
:XX\:XX\:XX\:XX\:XX\:XX:FRITZ!Box Fon WLAN 7360 BP:Infra:1:130 Mbit/s:47:▂▄__:WPA1 WPA2
:XX\:XX\:XX\:XX\:XX\:XX:FRITZ!Box 5490 PB:Infra:6:195 Mbit/s:45:▂▄__:WPA2
:XX\:XX\:XX\:XX\:XX\:XX:Zentrum der Macht:Infra:1:195 Mbit/s:44:▂▄__:WPA2
:XX\:XX\:XX\:XX\:XX\:XX:FibreBox_X6-01EF47:Infra:1:260 Mbit/s:42:▂▄__:WPA2
:XX\:XX\:XX\:XX\:XX\:XX:Madchenband:Infra:11:260 Mbit/s:40:▂▄__:WPA2
:XX\:XX\:XX\:XX\:XX\:XX:LenbrO:Infra:36:270 Mbit/s:37:▂▄__:WPA2
:XX\:XX\:XX\:XX\:XX\:XX::Infra:11:260 Mbit/s:34:▂▄__:WPA2
:XX\:XX\:XX\:XX\:XX\:XX:EEG-04666:Infra:1:405 Mbit/s:30:▂___:WPA2
:XX\:XX\:XX\:XX\:XX\:XX:Salt_2GHz_8A9170:Infra:11:260 Mbit/s:29:▂___:WPA2
:XX\:XX\:XX\:XX\:XX\:XX:FRITZ!Box 5490 PB:Infra:60:405 Mbit/s:27:▂___:WPA2
:XX\:XX\:XX\:XX\:XX\:XX:Madchenband2.0:Infra:100:540 Mbit/s:25:▂___:WPA2
:XX\:XX\:XX\:XX\:XX\:XX::Infra:11:260 Mbit/s:24:▂___:WPA2
:XX\:XX\:XX\:XX\:XX\:XX:FibreBox_X6-01EF47:Infra:44:540 Mbit/s:20:▂___:WPA2
```
## [[iw]]
### `iw dev`
Useful to list interfaces and see which hardware they correspond to.
Can use that to create a monitor interface with an easier to remember name.
```
phy#1
Unnamed/non-netdev interface
wdev 0x100000002
addr 3c:21:9c:f2:e4:00
type P2P-device
Interface wlp44s0
ifindex 5
wdev 0x100000001
addr e6:bf:0c:3c:47:ba
ssid LenbrO
type managed
channel 100 (5500 MHz), width: 80 MHz, center1: 5530 MHz
txpower 22.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets
0 0 0 0 0 0 0 0 0
phy#0
Interface mon0
ifindex 7
wdev 0x2
addr a8:42:a1:8b:f4:e3
type monitor
channel 6 (2437 MHz), width: 20 MHz (no HT), center1: 2437 MHz
txpower 20.00 dBm
Interface wlp0s20f0u6
ifindex 4
wdev 0x1
addr a8:42:a1:8b:f4:e3
type monitor
channel 6 (2437 MHz), width: 20 MHz (no HT), center1: 2437 MHz
txpower 20.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets
0 0 0 0 0 0 0 0 0
```
Here, `phy#1` is my laptops built-in WiFi card, and `phy#0` is a WiFi USB adapter.
### `iw [phy phy<index> | phy#<index>] info | grep -f monitor -B 10`
```
➜ iw phy phy0 info | fgrep monitor -B 10
* CMAC-256 (00-0f-ac:13)
* GMAC-128 (00-0f-ac:11)
* GMAC-256 (00-0f-ac:12)
Available Antennas: TX 0x3 RX 0x3
Configured Antennas: TX 0x3 RX 0x3
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
--
* register_beacons
* start_p2p_device
* set_mcast_rate
* connect
* disconnect
* set_qos_map
* set_multicast_to_unicast
* set_sar_specs
software interface modes (can always be added):
* AP/VLAN
* monitor
```
Can do better
### `iw phy#0 info | grep monitor`
```
* monitor
* monitor
```
Concise but possible need more context to be sure?
### `iw phy phy0 info | sed -n '/software interface modes/,/monitor/p'`
More concise but with good context. Assuming only sw interfaces need to support monitor mode
```
software interface modes (can always be added):
* AP/VLAN
* monitor
```
### Getting a monitor interface
```
iw phy#0 interface add mon0 type monitor
```
Add a easy interface to wifi hw and make it a monitor. Can check again with 'iw dev' to make sure it is really in monitor mode. If there is an other interface it must be taken down or deleted e.g with
```
iw dev <phy#0 other interface> del # or
ip link set <phy#0 other interface> down
```
Then to enable `mon0` interface,
```
ip link set mon0 up
```
To effectively capture packets, we should set the interface to the correct frequency. For this we get the channel e.g. via the above mentioned `nmcli dev wifi`. We can see that, e.g. the BSSID I am connected to (marked with `*`) is on channel 100. We can also see that it there is also a BSSID belonging to the same SSID with the interface on channel 6. I.e., it is running one interface in 2.4 GHz (802.11b/g/n/ax/be) and one in 5 GHz (802.11a/h/n/ac/ax/be). We chose which which channel to tune our `mon0` interface to, then we can lookup what the center frequency is on [wikipedia(List of Wifi Channels)](https://en.wikipedia.org/wiki/List_of_WLAN_channels). E.g. for channel 6 (i.e. 2.4 GHz radio) we see that the center frequency is 2437. We set our interface to that frequency:
```
iw dev mon0 set freq 2437
```
Now double check that the interface is in monitor mode and tunedto the correct frequency:
```
iw dev mon0 info
```
Should give an output like
```
Interface mon0
ifindex 7
wdev 0x2
addr a8:42:a1:8b:f4:e3
type monitor
wiphy 0
channel 6 (2437 MHz), width: 20 MHz (no HT), center1: 2437 MHz
txpower 20.00 dBm
```
This concludes preparing the wifi card for packet capture in monitor mode.
### [remarks]
- `sudo` is probably required for these commands
- These network tools are what is available on fedora 40, on $(uname -r)= 6.8.8 Linux Kernel. It might be that other OSs still use older tools, which are being phased out. But other operating systems might still be using older versions of these commands. For a table on how they match up, see [this](https://www.tecmint.com/deprecated-linux-networking-commands-and-their-replacements/) recent article (July 2023), according to which the old commands are even deprecated in recent Debian and Ubuntu releases.
- If smth is not working run `rfkill list` to check device is blocked. If it is, `rfkill unblock 0`, where `0` is the same index used above and represents `phy0` /`phy#0`.
- To ensure that [[NetworkManager]] not managing you card, `nmcli device set wlp0s20f0u6 managed no` if the interface is called `wlp0s20f0u6`. Check with `nmcli dev`, the STATE should be "unmanaged".
- See resources on how to put interface/wifi hardware back into managed mode, if you need the card for personal use.
# Important
Monitor mode is actually completely useless, unless we can observe the EAPOL handshake. That means the Wifi AP should be using WPA/WPA2 with psk. Also we need to know the SSID and passphrase. So it is still better if we can setup an environment where we can just do port mirroring from the wifi router, or setup ourselves in AP mode, but then we need to be able to bridge to the internet somehow, which I haven't managed reliably. Have done some testing on raspberry pi seemed to work. But raspberry pi sometimes goes to sleep so the AP goes down which means the IoT device loses connection.
If we happen to know the MAC address we need, then in wireshark we can filter `wlan.addr == [MAC]`. In tcpdump we can use the filter

14
notes/journal/2024-05-15-wed.md Normal file
View File

@@ -0,0 +1,14 @@
# `IOTTB_HOME`
I introduced the environment variable `IOTTB_HOME` into the code. It is used to configure where the root of a iottb database is. #TODO this means that some code needs refactoring. But, I think it will streamline the code. The path in `IOTTB_HOME` shall be used to define the database root. Then, all the code handling adding devices and running captures can rely on the fact that a canonical home exists. Unfortunately I've hard coded quite a bit of ad-hoc configuration to use `Path.cwd()`, i.e. the current working directory, by default. So there will be some refactoring involved in switching over to using `IOTTB_HOME`s value as the default path.
# Adding Functionality
## Quick and dirty capture
I want to have a mode which just takes a command and runs it directly with its arguments.
The question is weather to only allow a preconfigured list of commands or in principle allow any command to be passed and write the output. I tend toward providing a subcommand for each utility we want to support. The question is what to do about the syntax errors of those commands. Maybe the thing to do is only write a file into the db if the command runs successfully.
### Refactoring the tcpdump capture
With the above idea it would be possible to also refactor or rewrite how tcpdump is called completely. But, the command has a lot of options and maybe its better also offer some guidance to users via `-h`, e.g. to only input the needed and correct filters for example. Choosing the wrong filter could make the capture potentially useless and one might only see that after the capture has completed.
## Converting pcap to csv
I want an option such that one can automatically convert a captures resulting file into a csv. Probably will focus on tcpdump for now, since other tools like [[mitmproxy]] have different output files.
## Defining Experiment
I want a pair of commands that 1. provide a guided cli interface to define an experiment and 2. to run that experiment -> Here [Collective Knowledge Framework](https://github.com/mlcommons/ck) might actually come in handy. The already have tooling for setting up and defining aspects of experiments so that they become reproducible. So maybe one part of the `iottb` as a tool would be to write the correct json files into the directory which contain the informatin on how the command was run. Caveat: All all option values are the same, basically only, if it was used or not (flagging options) or that it was used (e.g. an ip address was used in the filter but the specific value of the ip is of no use for reproducing). Also, Collective Minds tooling relies very common ML algos/framework and static data. So maybe this only comes into play after a capture has been done. So maybe a feature extraction tool (see [[further considerations#Usage paths/ Workflows]]) should create the data and built the database separately.

0
notes/testbed/data analysis/privacy metrics.md Normal file
View File

16
notes/testbed/data collection/Design document.md Normal file
View File

@@ -0,0 +1,16 @@
# Needed Metadata
- _Must_ contain IP address of *IoT* device
- _Can_ contain IP addr of capture host
# Options
## tcpdump options
see [[tcpdump]]
## kybcap options
| Option | Desciption|
| ------- | ---------- |
| `--setup` | Go through guided setup process |
| `--meta-config` | Go through guided meta data setup |
| `--mdevice=` | _Metadata_ : Specify device name |
| `--mipdev=` | _Metadata_ : Specify device ip address |
| `--mmac=` | _Metadata_ : Specify device MAC address |
| `--to-csv` | _post_processing: extract pcap into csv |

1
notes/testbed/scope.md Normal file
View File

@@ -0,0 +1 @@
What is scope if testbed as a system?

14
notes/testbed/testbed design and architecture.md Normal file
View File

@@ -0,0 +1,14 @@
FAIR data + privacy metric evaluation algos.
Dataset offers some schema.
Privacy metric requires some set of features.
**Case 1**
dataset schema = required features by privacy metric
**Case 2**
dataset schema $\subset$ required features ->
_2.1:_ feature extraction algo(s) exists, which can computed missing features
_2.2:_ missing features CANNOT be computed form available schema/data
**Case 3**
dataset schema $\supset$ required features -> project schema down into relevant feature space/ leave out uneeded data
**Case 4**
Unknown relationship -> further investigaton needed
Is this realistic case?

14
notes/todos/todo.md Normal file
View File

@@ -0,0 +1,14 @@
- [ ] !Need microsd card for Mi 360 home camera
- [ ] Cannot get Ledvance LED strip into discovery mode s.t. connection could be established
- [ ] Have not managed to setup AP/Hotspot: Amazon echodot needs iOS app but iPhone will not connect to AP on fedora Laptop
- [x] ~~Ask Valentyna/Nima for other approach to capture traffic~~ Preliminary Fix: USB Plugable Wifi Adapters.
- [ ] Look into how to route to internet!
IEEE 802.11: www.ieee802.org/11/
FCC 2.4 GHz: https://transition.fcc.gov/Bureaus/Engineering_Technology/Orders/2000/fcc00312.pdf
WPA3 Specification: www.wi-fi.org/download.php?file=/sites/default/files/private/WPA3_Specification_v3.0.pdf
Wireless LAN Display Filters: www.wireshark.org/docs/dfref/w/wlan.html
WPA-PSK Key Generator Tool: www.wireshark.org/tools/wpa-psk.html

48
notes/wiki/EnvironmentSetup.md Normal file
View File

@@ -0,0 +1,48 @@
Here I try to document the setup needed to perform reliable captures of IoT device traffic. Setting up the environment properly is a precondition for capture tools like
[[Wireshark]] et al. to capture ALL traffic needed reliable (while also avoiding nosie).
Since most IoT devices use the internet, it is vital that any capturing mechanism/setup does not interfear with their ability to phone home.
At this point I can descerne the following steps.
Essentially, all this is to enable reliable [[monitoring]] of IoT network traffic.
# Overview/Big Picture
Assumption: The machine used to capture traffic has internet acces either wired (ethernet) or wireless (wifi, maybe bluetooth?).
Since IoT devices work wirelessly the testing/experiment environment needs at least none wifi card which supports AP mode (see [[iw]]). It will act as the AP for the device to be tested.
Since many IoT devices are internet enabled we need a way to bridge the IoT<->AP network to the internet.
Problem: How do we get internet access to an IoT device?
1. It connects to a router. The router must then be able to: Mirror ports/run required capturing software itself
2. It connects to an AP on some other machine. The other machine is connected via some other iterface to the internet.
1. Wired Internet: Either using a (software) bridge or NAT make sure traffic IoT<->Internet can be established and that it can capture all needed packets.
2. Wifi Internet: Same as wired. But special care must be taken on a "unclean" system. Desktop systems tend to come with running network management utilities and daemons running. To avoid them interfereing with the AP card special care must be taken, see e.g. [[nmcli]].
So what must a toolkit which sets up the experiment environment be able to do:
1. __AP Service__ Through config or detection setup a properly configure AP, possibly on a external adapter
2. __IP networking dependencies__ Since the experiment machine is replacing some functionality usually offered by the router to connecting host, some router functionality must be offerd. In particular [[dhcp]] (IoT device needs an IP) and [[dns]] (IoT device needs some way to get IPs of hosts it wants to connect to).
3. __Internet Gateway__ Enable any IoT device to connect to the Internet. That is, test machine must at least be a [[gateway]] and the IoT device should ideally be able to understand that without any configuration.
4. Any firewall must allow for [[dhcp]] and [[dns]] services to be accepted by experiment host.
# AP Configuration
## Using NetworkManager
See [here](https://variwiki.com/index.php?title=Wifi_NetworkManager#Configuring_WiFi_Access_Point_with_NetworkManager). Can use the command line tool [[nmcli]].
## Using [[hostapd]]
Must first make sure that the interface is not managed by nmcli, see [[nmcli]].
It turns out that _**leaving out**_ those parts of the config file which have to do with security and auth:
```
# hostapd.conf
# Do not include in config if we wish to have an open auth AP!
wpa=2
wpa_passphrase=11help22help33
wpa_key_mgmt=WPA-PSK
rsn_pairwise=CCMP
```
Further more we set the config option `auth_algs` appropriatly so open auth is allowed:
```
auth_algs=1
```
see [[hostapd]] for description of the option.
# DNS and DHCP
#TODO
Tools: [[dnsmasq]]
# Internet
#TODO
Possible tooling: [[iw]], [[firewalld]], [[iptables]], [[netables]]

9
notes/wiki/Tools.md Normal file
View File

@@ -0,0 +1,9 @@
# Wifi Tools
- [[aircrack-ng]]can easily enable monitor mode
- [[nmcli]] NetworkManager cli
- [[hostapd]]
- [[iw]]
# Wifi Adapter not found anymore
- __Issue__: After using `airmon-ng` to put my wifi adapter into monitor mode and then supposedly back into normal mode: network manager couldn't find wifi adapter anymore.
- `sudo nmcli dev` showed that `wlp44s0` interface was "unmanaged".
- __Fix__: `sudo nmcli set wlp44s0 managed yes`

1
notes/wiki/aircrack-ng.md Normal file
View File

@@ -0,0 +1 @@
#tldr : #TODO

33
notes/wiki/dnsmasq.md Normal file
View File

@@ -0,0 +1,33 @@
#tldr : #TODO
**Resources**:
- https://variwiki.com/index.php?title=Wifi_NetworkManager#Configuring_WiFi_Access_Point
- https://wiki.archlinux.org/title/Dnsmasq
- https://thekelleys.org.uk/dnsmasq/doc.html
- https://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html
- https://thekelleys.org.uk/dnsmasq/docs/FAQ
## Configuring WiFi Access Point with NetworkManager
NetworkManager can also be used to turn WiFi interface into Access Point.
The benefit of using NetworkManager in this scenario is the complete automation of WiFi, DHCP server and NAT configuration.
### Disabling standalone dnsmasq service
Dnsmasq is a lightweight DNS forwarder and DHCP server.
By default dnsmasq runs as a standalone service and will conflict with dnsmasq instance launched by NetworkManager.
To prevent the conflict, disable dnsmasq service by running the following commands:
```
systemctl disable dnsmasq
```
```
systemctl stop dnsmasq
```
For NetworkManager to run dnsmasq as a local caching DNS server, edit/create /etc/NetworkManager/NetworkManager.conf and add the following
```system
[main]
dns=dnsmasq
```
#note: Maybe must disable #NetworkManager #dnsmasq and enable system service dnsmasq.

3
notes/wiki/firewalld.md Normal file
View File

@@ -0,0 +1,3 @@
Resources: [Firewalld](https://wiki.archlinux.org/title/Firewalld), [Internet Sharing](https://wiki.archlinux.org/title/Internet_sharing#With_firewalld)
Fazit: Not really viable since not enough fine grain control.

33
notes/wiki/hostapd.md Normal file
View File

@@ -0,0 +1,33 @@
#tldr : #TODO
```bash
# For nl80211, this parameter can be used to request the AP interface to be
# added to the bridge automatically (brctl may refuse to do this before hostapd
# has been started to change the interface mode). If needed, the bridge
# interface is also created.
bridge=br0
```
# Operation mode
```bash
# (a = IEEE 802.11a (5 GHz), b = IEEE 802.11b (2.4 GHz),
# g = IEEE 802.11g (2.4 GHz), ad = IEEE 802.11ad (60 GHz); a/g options are used
# with IEEE 802.11n (HT), too, to specify band). For IEEE 802.11ac (VHT), this
# needs to be set to hw_mode=a. For IEEE 802.11ax (HE) on 6 GHz this needs
# to be set to hw_mode=a. When using ACS (see channel parameter), a
# special value "any" can be used to indicate that any support band can be used.
# This special case is currently supported only with drivers with which
# offloaded ACS is used.
# Default: IEEE 802.11b
hw_mode=g
```
```bash
# IEEE 802.11 specifies two authentication algorithms. hostapd can be
# configured to allow both of these or only one. Open system authentication
# should be used with IEEE 802.1X.
# Bit fields of allowed authentication algorithms:
# bit 0 = Open System Authentication
# bit 1 = Shared Key Authentication (requires WEP)
auth_algs=3
```

32
notes/wiki/ip-forwarding.md Normal file
View File

@@ -0,0 +1,32 @@
Resources:
[archwiki-internet-sharing](https://wiki.archlinux.org/title/Internet_sharing#Configuration)
[archwiki-sysctl](https://wiki.archlinux.org/title/Sysctl#Configuration)
[kernel-sysctl](https://www.kernel.org/doc/html/latest//networking/ip-sysctl.html)
Remark: Many resources mention that all #firewall config should be executed in one go from a script.
They also mention to make sure to flush all previous rules/tables/chains before beginning the setup.
Order of rules matter.
*Check current settings*
```bash
sudo sysctl -a | grep forward
```
# Config
```
net.ipv4.conf.all.bc_forwarding = 0 # broadcast?
net.ipv4.conf.all.forwarding = 1 # Enable IP forwarding on this interface.
```
Latter above controls whether packets received _on_ this (in this case on _all_) interface can be forwarded.
```
net.ipv4.conf.all.mc_forwarding = 0 # Multicast routing
```
## Locations
### Preloaded
# Tags
#firewall #nat
#sysctl
#ip-forwarding
#masquerading

10
notes/wiki/iw.md Normal file
View File

@@ -0,0 +1,10 @@
#tldr: show / manipulate wirless devices and their configs.
# Commands used:
- `iw list` shows extensive info about all wirless devices.
- To check if any devices is AP ready:
```bash
iw list | grep -i ap -A 5 -B 5
```

19
notes/wiki/monitoring.md Normal file
View File

@@ -0,0 +1,19 @@
#tldr How to monitor/sniff wifi network traffic of IoT Devices. Two strategies:
Use a wifi adapter to setup an #AP and have the devices connect to via that or use wifi card in monitor mode.
# Funnel traffic via AP
**Issues**: iPhone has problems connecting to the provided APs. But need iPhone to configure network connection of devices.
# Monitor Mode
---
## HowTo
Insert wifi adapter and make sure it shows up as a interface with e.g. `nmcli dev`.
### Manually activate:
1. Find out which interfaces already exist with names like`mon_N_`: `ifconfig -a`.
2. `iw dev _interface_ interface add _mon_num_ type monitor`
3. `ifconfig _mon_num up`
### Using [[aircrack-ng]] :
Activate monitor mode on interface `wlp0s20f0u1`:
```bash
sudo airmon-ng start wlp0s20f0u1
```
Output:

53
notes/wiki/nmcli.md Normal file
View File

@@ -0,0 +1,53 @@
#tldr : Command line utility of [NetworkManager](https://networkmanager.dev)
Resources:
- https://wiki.archlinux.org/title/Software_access_point#NetworkManager_is_interfering
- https://wiki.archlinux.org/title/NetworkManager#Ignore_specific_devices
Benefit: Automates setting up WiFi, DHCP server and NAT config, according to [here](https://variwiki.com/index.php?title=Wifi_NetworkManager#Configuring_WiFi_Access_Point_with_NetworkManager).
# Commands
```bash
nmcli dev #list network devices
```
```bash
nmcli con down <name> # disable AP config
```
```bash
nmcli con delete <name> # permanently delete AP configuration
```
```bash
sudo systemctl restart NetworkManager # for config changes to take effect
```
```bash
sudo nmcli device set <interface-name> managed no # make sure itnerface is not managed by NetworkManager. Can use d instead of device.
```
More examples [here](https://networkmanager.dev/docs/api/latest/nmcli-examples.html)
# Config
## Ignoring specific devices
This is mostly taken from different parts of [archwiki/NetworkManager](https://wiki.archlinux.org/title/NetworkManager). This is desirable so it wont interfere with our [[hostapd]] or [[dnsmasq]] config.
In ``/etc/NetworkManager/conf.d/unmanaged.conf`` :
MAC addr based:
```config
[keyfile]
unmanaged-devices=mac:<hwaddr>
```
Interface name based:
```config
[keyfile]
unmanaged-devices=interface-name:<ifname>
```
After modifying run
```bash
sudo nmcli general reload
```
Must avoid having conflicting [[dnsmasq]] instances between #systemd managed and #NetworkManager built in.
# Troubleshooting
## Wifi adapter not found anymor
See [[Tools]].

1
notes/wiki/python-libs.md Normal file
View File

@@ -0,0 +1 @@
# `argparse`

22
notes/wiki/tcpdump.md Normal file
View File

@@ -0,0 +1,22 @@
[docs](https://www.tcpdump.org/manpages/tcpdump.1.html)
### Options
#### `tcpdump`
| Option | Description |
| ------- | ------------ |
| `-c` _count_ <br/> `--count` | to specify number of packets to capture |
| `-i` _interface_ <br/> `--interface=` | specify the interface e.g. 'eth0' or 'wlan0' etc. |
| `-F` _file_ | Get filter expression from _file_ |
| `-I` <br/> `--monitor-mode` | Put interface into monitor mode|
| `-n` | No name resolution for addresses (host, port no. etc) |
| `-#` <br/> `--number` | Print a packet number at beginning of line |
|`-t` | _Don't_ print a timestamp on each dump line. |
|`-tt` | Print the timestamp, as seconds since January 1, 1970, 00:00:00, UTC, and fractions of a second since that time, on each dump line. |
| `-ttt` | Print a delta (res dep on `--time-stamp-precision` option) between current and previous line on each dump line. default is microsecond resolution. |
| `-tttt` | Print a timestamp, as hours, minutes, seconds, and fractions of a second since midnight, preceded by the date, on each dump line. |
| `-ttttt` |Print a delta (res dep on `--time-stamp-precision`) between current and first line on each dump line. default is microsecond resolution. |
| `-w` _file_ | Write raw packets to _file_ |
| `-e` | print link level header. See manpage for more details |