Differences

This shows you the differences between two versions of the page.

--- fuss:networking [2020/05/16 22:55] – [Determine ISP Address Blocks] office
+++ fuss:networking [2025/02/16 17:49] (current) – [Mirroring Packets using IPTables] office
@@ Line 169: / Line 169: @@
 | ''198.18.0.0/15''  | ''198.18.0.0–198.19.255.255''   | $131072$   | Inter-network communications between two separate subnets as specified in [[http://tools.ietf.org/html/rfc2544|RFC2544]]. |
 | ''fc00::/7''       | ''fc00::–fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff'' | $2^{121}$ | Unique local address. |
+or all in one line for a copy & paste:
+<code>
+.0.0.0/8 100.64.0.0/10 172.16.0.0/12 192.0.0.0/29 192.168.0.0/16 198.18.0.0/15 fc00::/7
+</code>
 ====== Adjusting Ring Parameters ======
@@ Line 213: / Line 219: @@
 </code>
 where:
-  * ''www.bing.com'' is the hostname to connect to
+  * ''<nowiki>www.bing.com</nowiki>'' is the hostname to connect to
   * ''80'' is the destination port
@@ Line 354: / Line 360: @@
 </code>
+====== Zooko's Triangle ======
+Zooko's triangle is a set of three properties where one rule is mutually exclusive with the other two that are generally considered desirable for names of participants on a network. The three properties are:
+  * Human-meaningful: Meaningful and memorable (low-entropy) names are provided to the users.
+  * Secure: The amount of damage a malicious entity can inflict on the system should be as low as possible.
+  * Decentralized: Names correctly resolve to their respective entities without the use of a central authority or service.
+Examples:
+  * DNSSec requires centralization and is thus not //Decentralized// but it is //Secure// and names are //Human-meaningful//,
+  * onion and bitcoin addresses are //Secure// and //Decentralized// but not //Human-meaningful//,
+  * i2p uses name-translation services and is thus not //Decentralized// but the names can be //Human-meaningful// and are //Secure// since they run locally.
+====== Testing a DHCP Server Request ======
+nmap can be used to issue a DHCP request to a DHCP server in order to analyze what the DHCP server offers to clients. Issue:
+<code bash>
+nmap --script broadcast-dhcp-discover -e wlan1
+</code>
+in order to issue a DHCP DISCOVER message and request through the ''wlan1'' network interface.
+The expected output is similar to:
+<code>
+Starting Nmap 7.93 ( https://nmap.org ) at 2024-03-14 19:09 UTC
+Pre-scan script results:
+| broadcast-dhcp-discover:
+|   Response 1 of 1:
+|     Interface: wlan1
+|     IP Offered: 192.168.100.68
+|     DHCP Message Type: DHCPOFFER
+|     Server Identifier: 192.168.100.1
+|     IP Address Lease Time: 1d00h00m00s
+|     Renewal Time Value: 12h00m00s
+|     Rebinding Time Value: 21h00m00s
+|     Subnet Mask: 255.255.255.0
+|     Broadcast Address: 192.168.100.255
+|     Domain Name Server: 192.168.100.1
+|_    Router: 192.168.100.1
+WARNING: No targets were specified, so 0 hosts scanned.
+Nmap done: 0 IP addresses (0 hosts up) scanned in 11.31 seconds
+</code>
+====== Automatically Create an IP Set for Amazon AWS ======
+The following script:
+<code bash>
+#!/usr/bin/env bash
+###########################################################################
+##  Copyright (C) Wizardry and Steamworks 2020 - License: GNU GPLv3      ##
+###########################################################################
+# Downloads Amazon AWS networks and adds all the ip blocks to an ipset.  ##
+###########################################################################
+`ipset list AMAZON-AWS 2>/dev/null >/dev/null`
+if [ $? = 1 ]; then
+    ipset create AMAZON-AWS hash:net family inet
+fi
+ipset flush AMAZON-AWS
+for NETWORK in `curl -s https://ip-ranges.amazonaws.com/ip-ranges.json -o - | \
+    jq '.prefixes[] | .ip_prefix' | grep -P -o '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\/[0-9]{0,2}'`; do
+    ipset add AMAZON-AWS "$NETWORK" 2&>1 >/dev/null
+done
+</code>
+will process the AWS networks provided by Amazon and will generate an ipset to hold all the addresses using a network hash.
+====== Mirroring Packets using IPTables ======
+The ''TEE'' extension from ''iptables'' can be used to mirror a matching packet and sent it towards a different machine.
+The following example will match TCP packets with the destination port set to ''55435'' and mirror the packets to ''192.168.0.80''
+<code bash>
+iptables -t mangle -A POSTROUTING -p tcp --dport 55435 -j TEE --gateway 192.168.0.80
+</code>
+====== How to Quickly Copy a Large Number of Files Quickly Between Two Servers ======
+{{fuss:fuss_networking_fastest_way_to_copy_files_between_servers.png?512}}
+====== On Wireless Range Extenders ======
+TL;DR There are no "wireless range extenders".
+Wireless range extenders are frequently marketed as solutions that can increase the wireless range.
+More than often, the solutions can be classified as:
+  * fake repeaters, ie: they create a different access point (sometimes even pettily named after the SSID of the first by adding some characters) and connect to the original access point requiring users of the extended network to connect to the secondary access point (it works, but clients must be reconfigured to connect to the new network),
+  * Apple extreme uses just standard networking principles with a networking bridge connecting Apple base-stations via Ethernet and then just transmit sing the same SSID (multiple BSSID, one SSID),
+  * signal amplifiers, in principle signal amplifiers can amplify the frequency on which the wireless radio operates on but powerful amplifiers are expensive,
+  * antennas, [[/fuss/ham_radio#the_3070_rule|antennas matter most]] in the setup and it is true that with a very large, perhaps a sectorial or a directed antenna, the range can be extended the most,
+  * mesh networking have infinite scaling in terms of range given that mesh networks form amongst peers and that their geometrical disposition of nodes is what determines the range but mesh networking requires nodes that can do mesh (ie: the phone won't be able to participate in this network seamlessly),
+===== Using hostapd and Multiple Computers to Extend the Network =====
+hostapd on Linux can be used to extend a wireless network if multiple computers are available with wireless cards (built-in or USB), preferably far from each other, simply by connecting the computers together via one network bridge and then running hostapd instances on all machines.
+Aside from range, another reason to do this is that a wireless device can typically only accept a given amount of wireless clients before it starts refusing them. For example, on Linux, an Intel wireless card will start failing after a certain number of clients with the error message //"IEEE 802.11: Could not add STA to kernel driver"//. The number of clients is not a configurable parameter and is typically a limitation of the hardware such that there would be no solution except to purchase a new device.
+<ditaa>
+          +            +            +
+          | wlan0      | wlan0      | wlan0
+          |            |            |
++------+  |  +------+  |  +------+  |
+| node +--+  | node +--+  | node +--+
++--+---+     +--+---+     +--+---+
+   |            |            |
+   | eth0       | eth0       | eth0
+   +------------+------------+
+               br0
+</ditaa>
+where:
+  * all ''wlan0'' interfaces run the same SSID (but have a different BSSID due to the networking equipment),
+  * the nodes are connected together, for example, via Ethernet cable with each node's interface ''eth0'' being part of a bridge ''br0''
+The previous will require a configuration similar to the following on each node in their corresponding hostapd configuration file ''hostapd.conf'':
+<code>
+interface=wlan0
+bridge=br1
+</code>
+and the rest will vary depending on optimizations.
+The channel selection might be important given that multiple devices are available such that the whole frequency band allocated can be covered by the channel selection. The following is a representation of $20MHz$ (and $40MHz$) wide channels for the $2.4GHz$ network in terms of frequency coverage from an [[https://www.researchgate.net/publication/334805446_An_Extension_of_Throughput_Drop_Estimation_Model_for_Three-Link_Concurrent_Communications_under_Partially_Overlapping_Channels_and_Channel_Bonding_in_IEEE_80211n_WLAN|article on overlapping channels]].
+{{fuss:fuss_networking_24ghz_channels_20mhz_width.png?512}}
+Given the chart, it seems sensible to run each hostapd instance on the channels that would cover the entire frequency range, namely channel ''1'', ''5'', ''9'' and ''13'' are all non-overlapping channels for a $20MHz$ wide frequency range such that they would make great candidates to be listening on a channel for every participating node.