Add outline/ overview of what must be done to setup IoT experiment environment.

notes/wiki/AP configuration.md

@@ -1,6 +0,0 @@
-# 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]].
-

notes/wiki/EnvironmentSetup.md

@@ -0,0 +1,46 @@
+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.
+# 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. __Internet Service__ Enable any IoT device to connect to the Internet
+3. __Internet Service 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). That is, test machine must at least be a [[gateway]] and the IoT device should ideally be able to understand that without any configuration. 
+# 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]]

notes/wiki/firewalld.md

@@ -1 +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.

notes/wiki/hostapd.md

@@ -0,0 +1,31 @@
+```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
+```