News items for tag network - Koos van den Hout

I talked about the latest developments in the fiber to the shed project with someone who has more experience in home fiber network and the suggestion was to order a 15 meter single mode lc-lc patch cable to have one cable from shed to the switch. I ordered such a cable at fs.com and added an 100base-LX SFP so the fiber can terminate directly in the downstairs switch.

Now waiting for the equipment to arrive, and there will be more work in the crawlspace in my near future.

Update 2020-02-04: The ordered fiber and SFP arrived late in the afternoon. Fast service from fs.com. It was shipped via DHL Express and they tried several times to remind me to pick a DHL shop to pick up the package but currently I'm not going anywhere most working days so my doorstep is a perfect delivery address.

Update 2020-02-05: After several tries it is clear my netgear switches have SFP slots that do not want to work with a 100base-LX SFP module. So one step back to the plan with two fiber-optic transceivers.

The first part of the fiber path has been done.

Today I gathered all the tools to work on this project and removed most of the contents of our shed to work in there.

When I started digging in the shed I soon noticed the plastic pipe from the shed to the crawlspace of our house takes a 45 degree angle first and the next 45 degree angle is under the garden. I was not going to do that much digging so the plan had to be adjusted. The working solution was to pull the fiber through one of the old heating pipes. So my wife pushed a wire-pulling cable through one of the heating pipes while I was laying in the crawlspace waiting for it to show up. When we tried the second heating pipe it did show up, and pulling the fiber back to the shed worked fine. I did put some tape around the connectors to make sure they wouldn't hook behind something and I made sure the bit of rope that was pulling on the fiber was actually pulling on the main fiber and not on the connectors. The fiber came up in the shed nicely.

I wanted to hang the fibre in the crawlspace, since it could get damaged easily lying on the in the sand down there. I installed an electricity pipe hanging under the floor beams. After that there was still a bit of length to get to the nearest switch but not enough fiber left, so I had to leave that hanging for when I get a connector for an extension.

While I was in the crawlspace I made sure some other cables were mounted better, since the mess down there annoys me a bit. And I don't want other maintenance in the crawlspace to have a chance of disconnecting important things.

So the project isn't finished yet, but there is serious progress. It feels like I almost spent as much time making sure I had the right tools available and cleaning and storing them again as I spent actually working on it!

I wanted to get an idea whether the network over the fiber optic transceivers is reliable. So at the moment our dining room table looks like a network lab.

For testing networks there is iperf. I found out the Raspberry Pi 3B+ can't keep up with 100 Mbit/second UDP packets, so I searched for a speed where the Pi performs ok. This turns out to be 30 mbit, at higher speeds there is packet loss. I also had to reduce packet size to avoid fragmentation which costs CPU. I use IPv6 because that's what I'm used to. It turned out later the maximum speed without loss is higher with IPv4 than with IPv6.

Server on the raspberry pi:

koos@raspberrypi:~ $ iperf --version
iperf version 2.0.9 (1 June 2016) pthreads
koos@raspberrypi:~ $ iperf -s -V -u
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size:  160 KByte (default)
------------------------------------------------------------

Test without fiber optic transceivers in the path. Layer 2 route: virtual machine - host machine - utp - network switch - utp - network switch - utp - raspberry pi

koos@wozniak:~$ iperf --version
iperf version 2.0.9 (1 June 2016) pthreads
koos@wozniak:~$ iperf -V -u -b30M -i 10 -t 120 -M 10 -l 1400 -c ..
------------------------------------------------------------
Client connecting to .., UDP port 5001
Sending 1400 byte datagrams, IPG target: 373.33 us (kalman adjust)
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
..
[  3]  0.0-120.0 sec   429 MBytes  30.0 Mbits/sec
[  3] Sent 321430 datagrams
[  3] Server Report:
[  3]  0.0-120.0 sec   429 MBytes  30.0 Mbits/sec   0.004 ms    0/321430 (0%)

Test with fiber optic transceivers in the path. Layer 2 route: virtual machine - host machine - utp - network switch - utp - network switch - utp - fiber optic transceiver - fiber - fiber optic transceiver - utp - raspberry pi

koos@wozniak:~$ iperf -V -u -b30M -i 10 -t 120 -M 10 -l 1400 -c ..
------------------------------------------------------------
Client connecting to .., UDP port 5001
Sending 1400 byte datagrams, IPG target: 373.33 us (kalman adjust)
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
[  3]  0.0-120.0 sec   429 MBytes  30.0 Mbits/sec
[  3] Sent 321430 datagrams
[  3] Server Report:
[  3]  0.0-120.0 sec   429 MBytes  30.0 Mbits/sec   0.007 ms    0/321430 (0%)

Trying with IPv4 shows that packet loss starts to occur above 45 mbit. This is an interesting difference.

But the important conclusion is that there is no packet loss over the fiber path. There may be a bit more latency, but that's not a surprise. As a last test I looked at purely ping traffic using IPv6.

Without fiber in the path:

koos@wozniak:~$ ping -c 100 -i 0.2 -q ..
PING ..(.. (2001:xxxx)) 56 data bytes

--- .. ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 20192ms
rtt min/avg/max/mdev = 0.567/0.680/0.866/0.063 ms

With fiber in the path:

koos@wozniak:~$ ping -c 100 -i 0.2 -q ..
PING ..(.. (2001:xxxx)) 56 data bytes

--- .. ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 20191ms
rtt min/avg/max/mdev = 0.625/0.738/0.828/0.046 ms

This also shows a bit more latency over fiber.

The extra latency is probably due to the fiber optic transceivers containing a network switch.

There is no fiber to our home in the near future but I am working on laying another fiber route: from the switch in the cupboard downstairs to the shed. This is because the NTP server in the shed still has intermittent connectivity issues when using 2.4 GHz wifi due to the 2.4 GHz wifi channels being very crowded. The wifi dongle has no 5 GHz support and I don't think I would get it very reliable. But other options are also not ideal. As a radio amateur I can't go back to using powerline (network over power cables) and I wouldn't feel safe with a network cable running that far should a lightning strike ever occur. I should write "occur again" since I have had a network switch with probable lightning damage before.

The only option left is what you guessed from the title of this post: fiberoptic cable. No interference to my radio reception and a lot less chance of lightning blowing up parts of the network and connected computers. But a whole new world of fiber types, fiber lengths, wavelengths, connector types and interface types opened up to me. The switch in the cupboard downstairs has SFP ports, but how to get beyond that.

The raspberry Pi 3B+ that I use is 100 mbit only and I wasn't sure how to handle that. So I asked someone who is very good with fiber networks to explain to me what options are available and that person dug up some lengths of fiber that are no longer used and some 100 mbit fiberoptic transverters that were also a wrong purchase. So I already have the connectivity hardware available.

Now all I need is a physical route between the shed and the rest of the network. There is an old plastic pipe from the shed to the crawlspace of our house that was once used for heating will probably do the trick once I figure out how to remove the old heating pipes from it. I guess there is some real dirty work below the floor of our house and in the shed in my near future. I will also need to buy plastic tubing to safely guide the vulnerable fiber. And some hooks to hang this tube and other cables from the floor instead of having them lie in the sand in the crawlspace.

Since there is also an old gas pipe in the plastic pipe I will make really really sure first that one isn't connected somewhere.

This was all triggered by adding the ntp server in the shed to the NTP pool and having the pool monitoring system gripe about the server becoming unreachable as soon as I have wifi problems. The things I will do for serving the right time!

I decided to have a look whether I can set up the static routes like those needed to get ads-b data out to plane finder via the dhcp server. This works a lot better than having to set those routes by hand after a reboot.

This can be done with the rfc3442 classless static routes extension in DHCP, which isn't supported out of the box by isc dhcpd. But there is support in the dhclient configuration on raspbian, so I only had to add the server side.

All the samples I could find for adding this to the server side added arrays of bytes which is harder to read/comprehend. I had a look at the dhcp-options manpage which showed the option to add a structured record with IPv4 addresses.

Main configuration adding the option:

option rfc3442-classless-static-routes code 121 = array of { integer 8, ip-address, ip-address };
# netmask bit count, destination, via

Specific host configuration using the option with the current address for pfclient-upload.planefinder.net. Which may change!

        host joy {
            hardware ethernet b8:27:eb:ae:ad:47;
            option rfc3442-classless-static-routes 32 80.84.58.2 10.42.2.1;
        }

This pushes route to 80.84.58.2/32 via 10.42.2.1.

Hosts that get this option via dhcp should ignore the default router option so if you need that too you will need to add a route for 0.0.0.0/0. In my specific usecase I don't want to set a default IPv4 route.

Today I noticed weird problems with the network in a desktop computer. It kept losing packets on the local network, with other computers in the same switch having no problems. In the end I switched to a different networkcard in the same computer to get rid of the problem. And that solved the problem.

The most probable reason is a lightning storm that came very close yesterday evening.

Update: The original 'suspect' was an Intel E1000 network card which had the first problems so I changed to a different card in the same computer. A week or so later similar problems started happening with a different computer on the same switch. I changed the switch which made the problem go away.

On opening the suspect switch I saw a capacitor with a big bulge on the top so the internal power is probably unstable, which can be the root cause of really weird problems.

Update: The replacement switch has only 5 ports, so I ordered an 8-port switch (my home office needs enough ports). After putting the 8-port switch in place I tested with the Intel E1000 again and it worked fine.

Recently the wireless access-point decided that I should not have access to the management interface. I even tried both the IPv4 address I assigned and the default IPv4 address it gets. And the last days I noticed strange delays, which may have been caused by channel overlaps. So I wanted access to the management interface to check the channel settings. I noticed the management interface decided to respond again on the IPv4 address I assigned, and I saw new firmware available which should also help with some stability issues.

Firmware upgraded, and after the upgrade and automatic reboot my access was gone again. Time for the suggested factory reset to get everything back to normal. Done, and I was able to set it up again from scratch with the right configuration.

Maybe I should start running some kind of wiki or something to keep internal documentation of my home network. I had a hard time remembering several details of my own setup recently.

I was looking at on-line offers of shielded/foiled network cable and found out it's not that expensive anymore. And with the 'keystone' connectors it looks like it's not that complicated to make neat and very well shielded connections.

But it's always a good plan to check the local electronics hobby shop. We still have one in the center of Utrecht: radio centrum where they had 1 meter and 2 meter patchcables for a very nice price (competitive with on-line shops) right up for grabs. So the first set of short cables that are always in use for gigabit are now s/ftp category 6 cables. I hope this improves radio reception.

I still think I will order longer cable and keystone connectors and holders for the longer cables.

I have two Raspberry Pi's running in the house, currently with IPv4 still enabled on them. They both run Raspbian 8.0. I was wondering whether I can disable IPv4 on the Raspberry Pi, but a google search does not yield very helpful answers, most of the search terms I try still find pages about disabling IPv6. I want to disable the legacy IP protocol.

Only one way to find out: go for it. Now rebooting one with the statement ipv6only in /etc/dhcpcd.conf.

First thing I noticed was that the searchdomain was not set in /etc/resolv.conf which was indeed only available via the DHCP process for IPv4. So now radvd advertises the search domain via the DNSSL option in /etc/radvd.conf:

   RDNSS 2001:980:14ca:42::18 {
   };
   DNSSL idefix.net {
   };

The first results are:

• It turned out the ntp config on the raspberry had one IPv6-only and one IPv4-only server. Added a dual-stack server.
• And ndpmon really does not like the DNSSL option, even when I add it in the config_ndpmon.xml file as

                    <dnssl>
                      <domain lifetime="600">idefix.net</domain>
                    </dnssl>
  

  Fixed by changing it to

                    <dnssl>
                      <domain lifetime="600">^Fidefix^Cnet</domain>
                    </dnssl>
  

  yes, with literal ctrl-F and ctrl-C characters, showing that there is some error in the parsing somewhere.
• rwhod is IPv4-only so the status is not visible in my network anymore. A workaround for that is not disabling IPv4 completely but just removing the default route, not using ipv6only in /etc/dhcpcd.conf but using the option nooption routers.

So I now have some cloudstorage space available also via webdav and I am working on using this for backups. The main idea is to have a daily backup to the cloud service and do the tape backups less often.

I still want incremental backups so I can go back to specific older versions of files. So I want to use amanda for backups. I installed the davfs2 package to be able to mount the webdav filesystem and access it from Linux. The first few clues come from Set Up Virtual Tapes - Amanda Howto but I had to switch to the chg-multi driver as described in Backup to Virtual Tapes on a non-UNIX Filesystem - Amanda Howto because the webdav filesystem does not support symlinks.

I/O performance during the backup isn't ideal and the vdsl uplink is completely full during the filetransfer. Maybe I need to slow down the backup process a bit and ratelimit the webdav transfer.