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

code/hostapd.conf

@@ -6,7 +6,3 @@ channel=11
 macaddr_acl=0
 auth_algs=1
 ignore_broadcast_ssid=0
-wpa=2
-wpa_passphrase=11help22help33
-wpa_key_mgmt=WPA-PSK
-rsn_pairwise=CCMP

code/hostapd.conf.bak

@@ -0,0 +1,12 @@
+interface=wlp0s20f0u1
+driver=nl80211
+ssid=t3u
+hw_mode=g
+channel=11
+macaddr_acl=0
+auth_algs=1
+ignore_broadcast_ssid=0
+wpa=2
+wpa_passphrase=11help22help33
+wpa_key_mgmt=WPA-PSK
+rsn_pairwise=CCMP

notes/journal/Mon, 25 March 2024.md

@@ -3,3 +3,8 @@ 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. 

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
+```