blog.crox.net (Entries tagged as network)

IPv6 Neighbor discovery

nospam@example.com (crox) — Wed, 11 Jul 2018 06:12:00 +0000

Discover/list other hosts:

ping6 -I eth0 ff02::1
ip -6 neigh show

To connect to a host using the link-local address you need to specify which interface to use (see "zone index"):

ssh -6 fe80::a00:aaaa:bbbb:cccc%eth0

OSMC NFS mount

nospam@example.com (crox) — Sun, 02 Aug 2015 14:19:46 +0000

It looks like you need some systemd "magic" to successfully mount an NFS share on OSMC. Adding "x-systemd.automount,noauto" to the mount options in /etc/fstab did the trick for me.

Enable IPv6 on OSMC (wired and wireless)

nospam@example.com (crox) — Sat, 01 Aug 2015 22:14:00 +0000

Despite having read the opposite, it looks like IPv6 is disabled by default on the latest OSMC release (2015.06-1). I've tried adding a sysctl.d file to set /proc/sys/net/ipv6/conf/eth0/disable_ipv6 to 0, but this did not help. It worked only when I ran the command manually. By going through numerous forum posts I eventually found out that you need to use the connmanctl CLI tool:

root@osmc:~# connmanctl
connmanctl> services
*AO Wired                ethernet_b827ebaabbcc_cable
connmanctl> config ethernet_b827ebaabbcc_cable --ipv6 auto preferred
connmanctl> quit
root@osmc:~#

This enables IPv6 with autoconfiguration, turns on Privacy Extensions and prefers these ephemeral addresses over the autoconfigured ones.

The same command works for wireless as well, you just need to select the appropriate interface (the service name will start with wifi_).

"help" will display basic usage info.

If for some reason you would like to disable IPv6, the command would be "config ... --ipv6 off".

Random MAC address generator for Arduino Ethernet Shield (static MAC generator)

nospam@example.com (crox) — Sun, 25 Jan 2015 22:42:01 +0000

I wanted a simple random MAC address generator for Arduino Ethernet Shields that lack one. I couldn't find one, so I wrote my own, which you can find here: https://ssl.crox.net/arduinomac/.

Inspired by http://nicegear.co.nz/blog/autogenerated-random-persistent-mac-address-for-arduino-ethernet/. The reason I'm not using this approach is that in most cases I want the MAC address to be static.

Huawei E3276s-150 (Swisscom branded - 12d1:1597) LTE stick with Linux

nospam@example.com (crox) — Mon, 27 Oct 2014 19:44:06 +0000

This works for me:

usb_modeswitch -W -c 12d1:156a -v 12d1 -p 1597

(after having unpacked /usr/share/usb_modeswitch/configPack.tar.gz to a temporary directory)

Update 2016-01-19: back in 2014 I reported this to the maintainers of various "modeswitch databases", and it seems it's made it's way into the Debian/Ubuntu version at least, according to the changelog (version 20151101-1).

"Convert" NTP to DCF77 - generate a DCF77 signal on an Arduino using an NTP time source

nospam@example.com (crox) — Sun, 31 Aug 2014 20:00:00 +0000

I hate having to set clocks. Most of our clocks at home get the time from Internet or from the DCF77 time signal.

The problem with the DCF77 time signal is that it is quite sensitive to environmental noise from lamps or other appliances, and the reception inside buildings can be problematic in some places.

I recently installed a clock in such a location. Using Udo Klein's DCF77 analysis tool it was clear that it would be nearly impossible to get the clock to work properly as initially planned, so I started looking for solutions:

- bigger antenna (eg this one)
- external antenna
- external receiver
- different time source

For different reasons, the only viable option seemed to be a different time source. But I did not want to change the clock design. While researching a solution, I came across the Chronvertor. Although this would allow to run the clock without DCF77 signal, the clock would still have to be set from time to time (due to lack of precision of the RTC, but at least twice per year for DST adjustments), so I quickly dismissed that option. However it provided inspiration for what I eventually ended up building: a NTP to DCF77 "adapter".

I had experimented previously with the TimeNTP example from the Arduino Time library, and there was plenty of information available online about the DCF77 signal, so this quickly appeared to be a viable option. This is the result: ntp2dcf.ino.

now with IPv6

nospam@example.com (crox) — Mon, 30 Jan 2012 19:23:26 +0000

In anticipation of World IPv6 Launch Day (6 June 2012), this website is now fully reachable over IPv6.

IPv6 test websites

nospam@example.com (crox) — Sun, 22 Jan 2012 23:33:00 +0000

http://ipv6-test.com/ (also has a speed test, shows your MAC address when available)

http://test-ipv6.com/ (provides detailed technical info and "readiness score")

http://whatismyv6.com/ (IPv4 only, IPv6 only)

http://www.whatismyipv6.net/ (provides traceroute and ping, also suports IPv4)

Enabling IPv6 Privacy Extensions on all interfaces (Ubuntu Linux, may work for other distros too)

nospam@example.com (crox) — Sun, 22 Jan 2012 23:22:01 +0000

According to the Wikipedia IPv6 article, Privacy extensions are, except for the Windows platform and Mac OS X since 10.7 as well as iOS since version 4.3, not enabled by default.

In theory, one can enable the IPv6 Privacy Extensions on all interfaces at once using sysctl like this:

sudo sysctl net.ipv6.conf.all.use_tempaddr=2

However, this currently doesn't work as expected, so I'm using this one-liner in /etc/rc.local:

for IF in `/bin/ls /proc/sys/net/ipv6/conf/*/use_tempaddr` ; do echo 2 > $IF ; done

This also sets "use_tempaddr" for "default", which means it should also apply to interfaces added to the system afterwards.

A simple check to verify that the new configuration is working: ipv6-test.com will print your MAC address when available...

See also: Linux Kernel Bug 11655

gulp - tcpdump alternative for lossless capture on Linux

nospam@example.com (crox) — Sun, 27 Feb 2011 23:37:00 +0000

tcpdump and wireshark are the tools that usually come to mind when you have to capture network traffic. But in some situations where you have to record a large amount of data and you want to avoid losing packets, tcpdump has some limitations. When I was hit myself by the tcpdump packet loss problem, I quickly found out that I was not alone and that a number of people had already researched the topic and/or provided alternatives.*

In particular, I found two different tools to perform the task: Corey Satten's gulp (http://corey.elsewhere.org/gulp/) and lindump from HP Labs (http://tesla.hpl.hp.com/opensource/)

I also found two interesting papers about capturing high volumes of traffic: http://www.usenix.org/events/fast09/tech/full_papers/anderson/anderson_html/ and http://docs.di.fc.ul.pt/jspui/bitstream/10455/3299/1/thesis-nhenriqu.pdf (the second quotes the first one among others, and also contains useful info to optimally spread the load among different cores)

After some tests I quickly became a happy gulp user, and thanks to the software being open source I was able to add features to it that I missed from the latest tcpdump versions:

-n - allows to change the default filename template
-t - allows to add a timestamp to the filename
-G - rotate pcap file every n seconds
-F - allows to skip the check for an ethernet interface
-Z - allows to specify a command to post-process each capture file

I've sent a patch to Corey Satten, who intends to setup a repository to hold the various contributions he gets for gulp. In the meanwhile, you can find my changes in the attached file (02-gulp-ntGFZ.patch.gz). For your convenience and for completeness, I also provide here the patch from Guy Harris that fixes issues on 64 bit systems (see http://seclists.org/wireshark/2009/Oct/105, apply that one first).

Updates:
2012-08-22: new version of my patch to fix the issue reported by SgtMalicious
2017-02-03: long-standing bug fixed

Downloads:
01-gulp-amd64.patch.gz: fix issues with 64-bit systems
02-gulp-ntGFZ.patch.gz: additional functionality as described above
gulp-1.58-crox.tgz: source with both patches applied

* other people have reported a performance drop with libpcap version 1.0 compared to previous builds, see http://thread.gmane.org/gmane.network.tcpdump.devel/4629 or http://seclists.org/tcpdump/2010/q3/index.html#11

hping - [send_icmp] Unsupported icmp type

nospam@example.com (crox) — Fri, 17 Sep 2010 20:47:01 +0000

When performing tests you may sometimes want to send specially crafted icmp packets. hping is a handy tool for that.

However, the default behavior is to refuse to send "unsupported" Type/Code combinations. eg

hping3 -c 1 --icmp -C 33 -K 0 192.168.70.1
HPING 192.168.70.1 (wlan0 192.168.70.10): icmp mode set, 28 headers + 0 data bytes
[send_icmp] Unsupported icmp type!

Fortunately, there is an (undocumented) --force-icmp option that you can add to bypass the check:

hping3 -c 1 --icmp --force-icmp -C 33 -K 0 192.168.70.1
HPING 192.168.70.1 (wlan0 192.168.70.10): icmp mode set, 28 headers + 0 data bytes

--- 192.168.70.1 hping statistic ---
1 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

pfSense dropping packets from specific hosts (outdated bogons lists)

nospam@example.com (crox) — Thu, 16 Sep 2010 21:14:52 +0000

After a fresh pfSense install, I found out that traffic from specific hosts was being dropped when it should have been allowed based on the firewall rules I defined.

It turned out that the option "block bogon networks" was activated on the WAN interface, and that fresh pfSense images come with a slightly outdated bogon list.

If you are facing this problem, you have three options:

1. disable the "Block bogon networks" option at the bottom of the WAN interface page

2. after at most one week, the list will be updated automatically as long as the box is online (there is a cron entry, grep your config file for bogon)

3. if you don't want 1. and can't wait for 2, you can trigger the update process manually by running:

/etc/rc.update_bogons.sh 0

Check the output from the Status -> System Logs -> System page (I ran it from a serial console, but it should work fine by ssh or from the exec.php page too)

Linksys WAG200G-EU stops routing UDP after a while (scripted reboot how-to)

nospam@example.com (crox) — Fri, 07 Mar 2008 10:04:25 +0000

It seems that after having been up for a couple of days, the WAG200G starts having issues routing UDP packets properly. This particularly affects VoIP traffic (here IAX2 on port 4569). The symptoms are that "regular surfing" works flawlessly, but the registration with the asterisk server fails. tcpdump shows no traffic on the server side. Restarting the WAG200G immediately solves the problem.

Here is how I restarted the router from the command line:

wget --http-user=admin --http-password=pa55w0rd \
     --post-data='reboot=1&save=Enregistrer+les+param%E8tres&todo=reboot&h_reboot=1&this_file=Reboot.htm&next_file=index.htm&message=' \
     http://192.168.0.1/setup.cgi

(replace password and IP address as appropriate)