wifi

  1. services
  1. Wifi replacement project
    1. Requirements
    2. Possible models
      1. Discarded
    3. Other racks and hardware
    4. Why OpenWRT
    5. Current inventory
    6. Underground cross-connect
      1. Copper or optical?
      2. Direct burial or pipe?
      3. Safety warning
      4. Optical modules and modes
      5. Tentative build
      6. copper build
      7. Mixed build
      8. core router replacement
  2. AP public (désuet)
  3. Multicasting

Wifi replacement project

Discussed on reddit. The plan is to have three hotspots in the house, one for the whole second floor and two in the first floor.

Note that my wifi tuning procedures should probably be followed when setting up the new APs.

Requirements

Possible models

Update: got the tplink, bigger than expected but otherwise nice. Ships with an injector and seems like it can feed PoE for the next device as well but this must be enabled in the GUI. Support for that in OpenWRT undetermined. No bridge capability seems built in the stock firmware, so needs to be flashed with OpenWRT.

Update: The TP-Link was returned! I ordered it from Staples, on sale at 90$. WARNING: it was not an actual v3, Staples shipped me a v4. Filed a negative review and asked for refund. Canada Computers price matched and are now out of stock, BestBuy also B/O as of 2023-08-31. So, instead, I got the cute little Ubiquiti Access Point U6 Lite that was pretty much fire-and-forget. Device was setup as svetlana and has been humming on the ceiling reliably ever since.

Discarded

Other racks and hardware

Some other home lab had the following recommendations:

Why OpenWRT

The point of running OpenWRT on the APs is to get monitoring about traffic on each node, which can be done with the Prometheus node exporter that can be installed in OpenWRT.

But we could also use the existing implementation, with something like the snmp_exporter (complete with dashboard and alerts!) to monitor APs with SNMP, as long as they support that which is not the case for the Zyxel NWA50AX and doesn't seem to be the case for the Ubiquiti U6 Lite either...

The point is to not be locked into any one system and being able to fallback to OpenWRT if we don't like the basic system. It also allows us to run a heterogeneous environment and not be forced to use a single solution for all networking hardware.

Current inventory

Underground cross-connect

I need to cross connect a small office outside with the main patch panel. This is about 50' of distance, outdoors, preferably underground. We'll dig a trench for power and hop in for networking as well.

Copper or optical?

According to this post it's definitely worth passing fiber through, and I tend to agree: while I used Cat6a wiring inside the house because, right now, almost devices use copper connections, it's worth having an optical link for a longer distance like this, particularly outdoors.

There's multiple warnings about installing surge protectors on both ends of a copper circuit, and it seems like a nice idea to just avoid that problem altogether. There's also a risk of interference with the power run that will follow the network link right along the same trench.

Part of the problem is direct burial cable is new cable I need to buy, and it's typically 1000' spools, e.g. 340$ at prime cables, 250$ and B/O at monoprice, meanwhile a 60' run is about 60$ at cdw.ca (multimode, see other prices at cdw.ca) or 20$ at lextec (single mode!) So while that is more expensive, it's not that much more expensive, and it just gives me what I need instead of a giant spool I don't need. Also, I can buy it by weight at recyborg.

Heck, fs.com has 60' for 15$, a 1000' run is actually much cheaper than copper, at 115$, although that's for a plain PVC jacket, not a burial cable. That would still be more expensive, with fs.com quoting 630$ for an "industrial cable" that's suitable for outdoors use.

What's interesting with fiber is that, fundamentally, you do not need to bury the darn thing in the first place. It is perfectly fine through rain, snow and freeze, as it's not metal! I've seen outdoors fiber runs in the middle of the wood, just laid down on the ground, often buried under the last leaf fall...

Direct burial or pipe?

Direct burial seems ill-advised. Multiple reports of water eventually getting into wires, and the wires are much more expensive. There are fiber cables designed for burial, but those are more expensive as well.

PVC pipes are cheap, let's lay down two lines in the trench, this post suggests a ¾" PVC pipe, and "Most PVC conduit at home depot is rated for this" although this post suggests 1" pipes and "schedule 80 PVC".

I'll also need some glue not sure how that works.

Safety warning

Many suggest laying the pipes (or wires) at 16 to 18" deep and lay down some other layer, 6" deep, to warn future diggers. Something like this tape seem designed for this but maybe this narrower less explicit tape might also cut it. Some suggest even layout a layer of wood paneling or insulation to make a more robust warning. Possible to do both.

Optical modules and modes

Problem with fiber is we're not in the simple, "standard" RJ-45 jack (although there are of course many standards, from Cat5 to Cat8, they are generally compatible). There's many different fiber connectors, different cables, and different modules at the end. It's kind of a mess.

First off, there are different modules. The Turris Omnia has a "plain" SFP connector, rated at 2.5Gbit, which is probably the standard right before SFP+, so that's our target. According to WP, those are mostly on LC connectors.

Which brings us to connectors. It seems like I need a dual (or "duplex", one connector per direction) LC connector, so one needs to be careful because there are SC connectors out there as well, for example cdw has a couple of cheap LC/SC ones that show up on top. So LC/LC it is, I think. I guess it depends on the other end, but then again, I guess I'll just use the same SFP module on both ends, so LC/LC. FS.com has a good explainer on connectors.

Then we "just" need to pick the actual fiber. And that is confusing as heck. There is multi-mode fiber and single-mode fiber. According to this post:

The cost of multimode fiber suitable for high bandwidth so greatly exceeds the cost of singlemode equipment at the ends of the fiber that it makes no sense.

It turns out the multimode fiber has the promise of higher bandwidth and capacity, but that, presumably, means newer generations of cabling incompatible with previous ones. Unclear. This post from fs.com debunks some of that by showing how much more expensive SMF gets with higher speeds. That said, at the bandwidth target I'm going with (10Gbit), the cost difference for modules is marginal (7$)

So I guess I'll just go with whatever I find first. The point of having PVC pipes, after all, is that the wiring can be replaced, even though it's kind of hellish, from what I have heard.

One thing that is interesting is that at least some of the fs.com generic SFP modules are marked as compatible with the Omnia. That device is a tricky one though, because it needs a matching (but reversed!) transceiver on the other end! SMF.

Other SFP module options:

Note: I'm not getting into WDM here, but let's just say it's a way for either SMF or MMF to get higher bandwidth, for example this is how the 10GBASE-LX4 and 100GBASE-LR4 physical layers work.

Tentative build

copper build

The SFP/fiber requirement complicates significantly that setup so we might just pull our existing wiring through the pipe and see if we can reuse existing hardware instead of doing anything too complicated for now. We have a TP-Link AC1750 in a drawer (rosa) we could just reuse here, if we stay with copper. That way, the project becomes:

We just have to make sure to keep it possible to pull new wires through.

Also let's not forget the elephant in the room here, which is that excavation is much more expensive than any of this, in the order of thousands of dollars.

Mixed build

In this scenario, we do both: we pull a copper link and two fiber links for the future. The copper link is used at first, to avoid the hassle of figuring out a new router and just getting things going, but the fiber is used for future-proofing.

That's obviously the same price as the "tentative build" above.

core router replacement

Thinking outside the box: I need a biggest switch. The Omnia is full and I want to connect more ports. I ideally, I'd get rid of that PoE injector as well to be able to power more devices remotely. This goes back to the switch research I touched on in the wifi replacement project.

A OpenWRT forum participant suggested to just get a switch and a core router, which is a problem I completely forgot about but, now that I think of it, actually makes a lot of sense. GS1900-24HP would actually fit the bill perfectly: 24 gbit / PoE ports with 2 SFP ports. Then a 4-port (393$) or 2-port (273$) Protectli core router (with optional wifi, although that might be better served by a separate AP) could do the core router.

So, BOM:

Notes:

Another build could be done with the Turris Mox:

Trick with the MOX is the bandwidth between modules is limited to 2.5Gbps, so the traffic between the switch ports can get saturated more quickly than a normal switch. It's also on the expensive side for a switch, compared to a normal one. Still, it's an interesting project, with close-to-mainline support!

AP public (désuet)

J'ai depuis longtemps un point d'accès ouvert mais maintenant contrôlé pour donner accès publiquement à internet.

Cherchez le point d'accès acces.reseaulibre.ca.

C'est du wifi régulier, sur la fréquence 2.4 GHz, canal 1.

Ports ouverts: 22 (SSH), 53 (DNS), 80 (HTTP), 443 (HTTPS), 8080 (icecast), 123 (NTP), 587 (Mail submission agent), 993 (IMAPS), 5222, 8010, 7777, 5000 (XMPP), 1194 (OpenVPN), 11371 (HKP), ICMP (ping)

Update: le point d'accès public est fermé.

Multicasting

Je roule un multicast d'une radio interne (voir radio). Ceci a tendance à polluer le wifi catastrophiquement: contrairement à un réseau fillaire, où le multicast peut être diffusé de façon efficace (chaque paquet envoyé une seule fois pour tout le monde), un réseau sans fil a des problèmes avec le multicast (chaque paquet doit être envoyé séparément pour chaque client). Des explications des problèmes avec le multicast et le wifi sont bien décrits ici:

En bref, ceci est particulièrement un problème avec l'encryption parce que chaque client doit recevoir un paquet séparément encrypté même si le contenu est le même. Mais ceci est un problème même sans encryption car le AP doit envoyer les paquets à la vitesse la plus basse supportée par tous les clients, ce qui peut ralentir considérablement le transfert et donc prendre paradoxalement plus de temps d'antenne.

Il semblerait y avoir des solutions théoriques avec un truc appelé DTIM, mais je ne vois pas clairement comment ceci peut régler les problèmes de fond mentionnés plus haut. Pour moi, la question du multicast performant sur wifi est non-résolue. Je me suis pour l'instant concentré à désactiver la diffusion multicast sur le wifi.

Pour résoudre ce problème, j'ai configuré mes routeurs OpenWRT pour ne pas diffuser le traffic IGMP à moins que ceci soit demandé par les clients, en utilisant une fonctionalité nommée igmp_snooping (dans OpenWRT) ou multicast_snooping (dans le kernel). Ceci peut être activé avec:

echo "1" > /sys/devices/virtual/net/br-lan/bridge/multicast_snooping

ou en ajoutant option igmp_snooping 1 à la config du bridge dans /etc/config/network. (Source)

Malheureusement, je vois toujours du traffic multicast sur les interfaces bridges et pire, wifi, avec cette configuration. Le problème est peut-être dû au fait qu'il n'y a pas seulement l'audio qui passe par le multicast: le protocole "Bonjour" ou "Avahi" utilise également le multicast pour annoncer des services. Les machines Apple, en particulier, vont envoyer des annonces qui vont activer le multicast sur le wifi et ainsi recevoir du traffic...

J'ai fini par ignorer les questions de igmpproxy parce que ceci me semble plus conçu pour contourner des problèmes de NAT et forcer la diffusion des flux multicast. Je veux faire l'inverse. Voir la documentation de igmpproxy pour des infos à ce sujet.

À noter aussi que IPv6 utilise un autre protocole pour découvrir les hosts voulant du multicast, nommé MLD.

Bref: pas réussi à désactiver le multicast sur le wifi - il faudrait changer de pare-feu pour faire ça à ce niveau, et splitter les VLANs. Yerk. Voir aussi cette discussion.

The Freifunk community have done a bunch of patches to Enable bridge multicast snooping - that we may want to review.

Documentation about multicast settings on the bridge

Created . Edited .