Often for testing purposes it is necessary to restrict the speed of a network connection.
This can be achieved using the netem module to tc.
For example, to restrict the bandwidth on eth0 to classic dial-up speeds use the command:
tc qdisc add dev eth0 root netem rate 56kbit
This can be cleared with:
tc qdisc del dev eth0 root netem rate 56kbit
Alternatively, this rule can be executed on an Ethernet Bridge so that it is independent of the device being tested.
The isc-dhcp-server included in Debian 9 will attempt to start a DHCPv6 instance on servers which have a dual-stack (IPv4 & IPv6) config.
If DHCPv6 is unconfigured because for example, Router Advertisements are used for configuring IPv6 hosts, then the service will fail to start. The DHCP(v4) is running but Systemd reports the service as failed.
One work-around is to force isc-dhcp-server to only start the v4 instance, add the following line to /etc/default/isc-dhcp-server:
INTERFACESv4=eth0
where eth0 is the interface on which DHCP requests should be serviced.
After restarting the service, the DHCP server shall now only run on v4 and as long as the v4 config is correct, Systemd will report the service as successfully started.
Using Iperf version 2.0.9 on Debian (Stretch) it’s possible to test networks using a multicast connection.
On the receiving end execute the command:
iperf -s -u -B 239.1.1.10 -i 1
On the sending end execute the command:
iperf -c 239.1.1.10 -u -T 3 -t 10 -i 1 -b 100M
This will run a bandwidth test using UDP traffic at 100Mbps.
Note, if your system is multi-homed you must make sure your multicast traffic is routed out of the correct interface. For example:
ip route add 224.0.0.0/4 dev eth0
DHCP (RFC 2132) allows for vendor specific data to be distributed to clients.
Important notes:
– clients must request Option 43 in their Parameter Request List (Option 55).
– the Vendor Class Identifier (Option 60) sent by the client in the DHCP Request, must match ‘VendorName’ which is used in the ISC DHCP Server configuration below.
Example server configuration section from dhcpd.conf:
option space VendorName;
option VendorName.serviceName code 1 = text;
option local-encapsulation code 43 = encapsulate VendorName;
option VendorName.serviceName "data";
– where VendorName matches the value of the client’s Vendor Class Identifier (Option 60).
– ‘serviceName’ is used only as an internal reference within the DHCP server’s configuration, and must be different for each ‘code’ value.
Up to 256 codes may be used for each Vendor specific configuration. All fields will be returned to the client which matches the Vendor Identifier.
The DHCP server will return the Vendor attributes in the DHCP Response. The data returned is encoded in binary in the following format for each code:
Byte 0: code
Byte 1: length
Byte 2: data
…
Byte length+2: final data byte
… then follows the next field, starting with code, length, data…
IPv6 auto configuration on Linux will normally assign the same address every time when connecting to a specific network. This address would normally be formed from the network prefix and local interface MAC address.
When using IPv4 your identity is slightly masqued by NAT. Although your single public IP address may be tracked, it is hard to track individual devices that exist on the local network. This is not the case with IPv6 where there is no NAT. Every device has a visible unique public IP address that rarely changes.
RFC4941 (obsoletes 3041) defines privacy extensions to IPv6 which will randomly assign an additional Global IPv6 address to the interface. This additional random address will have the same network prefix and be used for outgoing internet connections.
To enable the privacy extensions under Linux (using Debian Wheezy):
echo 2 > /proc/sys/net/ipv6/conf/${ifname}/use_tempaddr
replace ${ifname} with the name of your interface, eg wlan0
Possible values for this setting:
(0=off, 1=assign, 2=prefer)
Now at least you will be anonymized amongst the other nodes of your local network.