[Under Consideration][No ETA] WiFi support

Problem/Justification
While TrueNAS original audience is in the data center, at the latest since the TrueNAS Mini series, homelab, SoHo and even home users are part of the equation, too.
Many older homes are not wired for networking, and can at best use unreliable and slow ethernet over power line adapters to wire the home.
Futhermore, there are ISPs that provide in some country WiFi-only routers with 5G as last mile medium, and the routers that have ethernet ports generally are limited to 1Gbps ports.

Modern WiFi, particularly 3-band WiFi7 mesh setups, by far outperform in a typical apartment the slow poke ethernet over power line alternative and even 1Gbps ethernet, being competitive in many cases with 2.5Gbps or faster wired setups.


Source: Wi-Fi 7 speeds: What enterprises can expect

Given that the OS underlying TrueNAS supports WiFi out of the box, all that’s needed is that TrueNAS not go out of its way to disable that support, and allow the user to enter SSID, encryption standard, and WiFi password in the UI.

Impact
Those who don’t need WiFi will not impacted negatively, it’s just a feature like many others they may not use in their setup.
However, those who are stuck with unreliable slow-poke wired home networks will breathe a sigh of relief to finally have decent speeds, and in particularly being rid of the nightmare of having to power cycle ethernet over power line adapters that hang themselves due to interference or high data traffic.

User Story
Should be pretty obvious: place the NAS where it’s out of the way and where the noise doesn’t bother you, rather than where the most reliable ethernet port might be. A NAS humming next to the TV where the WiFi router sits isn’t exactly welcomed by family members who want to enjoy movies without hum, rattles and gurgles from disk access and fans.

Alternatively, the user in the home office will enjoy faster speeds than what can squeze over a few hundred mbps ethernet over power-line, if the NAS is placed elsewhere.

Seeing that the underlying OS already supports WiFi, the presence of the feature doesn’t impact those who don’t need it negatively, but that it constitutes a signifcant upgrade for those who actually could need it, there speaks little against implementing this, especially since in the larger context, it’s a relatively trivial to implement feature.

3 Likes

Upvote here

(If anyone wants an argument, it should really be over WHY not?)

1 Like

Voting is at the top :slight_smile:

Not to argue but I don’t see it fitting into the TrueNAS corporate sales. I don’t know of any company that would want a WiFi enabled NAS.

So getting them to implement and manage it, that takes profits away. Remember that we have a very different use case than a corporation would, which is where they make the big money.

I’d talk about security and speed, but that isn’t the issue. The issue is profit based. At least in my opinion.

Why would that reduce profits? Just don’t use the feature, if you don’t need it. A typical data center server has no WiFi hardware, so exactly nothing would happen there. I’d take your point if they actually had to implement WiFi support, but currently they must work hard to remove it, since it’s part of Debian by default. All that needs to be done is a relatively trivial UI addition, which doesn’t have to be looked at ever again until there’s a complete rewrite/redesign of the UI.

It’s not any different than allowing “unprofessional” SATA drives instead of mandating SAS, U.2/M.2 SSDs, etc.

Also, as I wrote, the project clearly has wide use in homelabs and SoHo applications, and while there may not be direct cash flows from that, it generates mind share and means more people beating on the system uncovering bugs, thus increasing reliability.

Not all benefits can be directly measured in monetary terms, even if in the long run they are reflected there.

Adding Wi-Fi drivers would just result in more bloat we don’t need.

Why not just get a WiFi AP and connect it to the ethernet port of your NAS?

4 Likes

That is not how software development works. It would reduce profits because you now have to dedicate resources (ie. developers, QA, etc.) to support such feature and that is not a free resource that could’ve been allocated to other features that would otherwise make money. This is the same reason why software companies deprecates older things that not many people use; because maintaining it takes away precious resources.

Manpower is money.

I’m afraid a company would say otherwise. It will benefit them in some way, even if it is to simply bring in more business.

Again, not trying to argue, just pointing out a few things that some people may not see.

The breakdown: (pulling this out of my rear, I have no idea what a billable hour costs for the TrueNAS company)

  1. One team to spend a few hours deciding the requirement. (150 hours)
  2. One person to figure out how to implement it in middleware. (40 hours)
  3. One person to design the GUI interface. (8 hours)
  4. Several people to perform regression testing. (120+ hours)
  5. Total man hours = over 318 hours, minimum to develop and implement.
  6. Continued support. (a few hours a month)

How much money is that? It depends on the billable hourly rate, which is the cost of an employee, cost of the facility (rent, utilities, sales force). And if you have a small company, this is very important stuff to stay alive. Larger companies can absorb a hit in the pocket book once in a while, smaller companies generally cannot so lucky.

My point is, it isn’t free. It requires specific involvement to make it happen. My numbers on the regression testing are probably a bit low, and that is if they find absolutely no issues. Stick in a problem and the numbers jump up fast.

When I was doing software development, I would be given 40 hours to perform a very small task. Making the change was the easy and quick part. Proving the change did not cause any problems to other aspects of the project took a huge amount of time. Back then we charged the customer $190/hr, which means for my tiny contribution it would have been $6400 USD (not what my paycheck looked like). Then you have independent testing going on and more money there, and they have a routine, scripted testing and it can last weeks with the final product. Not cheap.

The fact that we absolutely assist in testing of the products does not diminish the fact that they still have to do their testing. Ours does not replace any testing they must still do. We are an added bonus and our pay is the free use of the product. Some like the product, some don’t like it, and some don’t like the company direction. Personally I’m good.

This is my perspective. We can agree to disagree. And I’m off my soapbox for the day.

WiFi in general is one of those things we’re aware of maybe making sense to add at some point. Now that we’re on Linux and it actually has decent WiFi support that is :wink:

But no particular ETA here, maybe it happens down the road as part of a general networking overhaul / update, maybe not. But with Wifi7 and eventually 8 getting better/faster, there’s going to be more call for it for the SOHO market as well.

5 Likes

You missed the key word “directly”, as I then continued to lay out it reflects monetarily in indirect, delayed and not easily quantifiable ways.

I think you grossly overestimate the requirements. First, there’s nothing to implement in terms of WiFi networking, Debian already did all of that. One simply needs to not take out the required parts of the OS in whatever build scripts that now take Debian and transmogrify it into TrueNAS OS.

TrueNAS doesn’t need to maintain anything there, they can say we provide what Debian provides, and that’s it. Send your bugs/requests there, and they will filter into TrueNAS whenever they have it fixed/implemented/supported.

Debian simply expects SSID/encryption/password to be in a particular place.
If the TrueNAS team manages to write a UI that dumps a few lines of text into a file, that’s it. Anything else is a Debian issue. So unless Debian changes how it does WiFi or the UI changes, there’s no “maintenance” that needs to be done.

Again, the additional fields in the WebUI aside, there’s no new functionality to be implemented, it’s just a “don’t remove a preexisting feature”.

Is it zero effort? Of course not. But it’s largely a one-time effort, and compared to many other things, a rather small one at that.

If they want to keep efforts minimal, they can make it an unsupported Community Edition feature only, at least until it has proven there to just work and not cause any trouble (not that one should expect any).

I’d happily play guniea pig on that one…

How do you solve the conundrum that the NAS has to be on the network to access the interface where one provides the password to access the network?
Through a wired connection? Oh dear…

3 Likes

The same way one sets up any stupid network device that comes with a 192.1.1.1 default address: you stick a USB network adapter into the laptop, connect temporarily, while sitting next to it with a 1ft cable, connect to the web UI, set the value, and disconnect. Dough!
One can always invent silly conundrums that aren’t any.

Why? Added cost (a decent WiFi7 AP costs north of $100), added cables, added device that needs setup, firmware updates, power supply, power outlet, …and lots of other things that eat time and can break and complicate chasing down issues. Meanwhile the hardware available goes unused. Not my idea of efficiency nor my idea of a clean setup. It’s clutter and a hack.

Yeah, bloat :smiley: the few bytes a WiFi driver requires, which gets loaded on demand anyway. Linux had WiFi drivers when main memory was measured in megabytes and single core CPUs were standard. Talking about bloat in the context of modern hardware is just ludicrous. Even a RasPi the size of a chewing gum stick runs the Linux WiFi stack with ease. :roll_eyes:

Because an USB ethernet adapter I have around for traveling and device setup/debugging, not for permanent use. They are both dirt cheap, don’t require setup or drivers (beyond the USB class drivers), and they disappear in the travel kit right after the setup.

No, I don’t need to buy anything, I have that stuff already, and even if I had to buy it, it’s dirt cheap.

I don’t get why you go out of the way trying to tell me what I need or don’t need and what hacks I should use instead of a clean setup with Linux WiFi drivers. If you don’t need WiFi, don’t use it and/or don’t put your vote in, but there’s no need to try to sabotage others, just because YOU don’t want something. I’m not telling you how to use your system, either.

Why not just do this? Use the money you would have spend on a USB-to-Ethernet adapter and buy a wireless AP that you can connect the NAS to with an ethernet cable.

What you described seems a bit much for a home NAS to be brought into the local network after a reboot.

You’ll need to buy an ethernet cable and USB-to-Ethernet adapter to do what you just described in post 13.


With the NAS connected to a wireless AP, you’re done. You can now use your TrueNAS server in your home where it’s not possible to locate the server near your router or switch.

I know I am not supposed to mention the H word, but perhaps this is something that the HexOS GUI should be doing. They are more targeted to the small business and home users. (Of course, HexOS seems to charge a fee, so I can understand the desire for using TrueNAS CE which is free.)

The underlying drivers and userland packages could be added to TrueNAS, with clear and firm statements that this would not have TrueNAS GUI or iX support. Not sure how HexOS would save the configuration… (if the TrueNAS middleware does not support WiFi).

I can only speak to my own use case as a community user. my home office has no Ethernet. my gaming PC, my wife’s PC and printer are all wireless.
my power line adapters tap out at 60Mb, yet my wifi does 3 times that, 100% reliably.

1 Like

Given that we’re introducing support for the “terabit ethernet” family of adapters in Enterprise, I can’t see anyone clamoring for wifi there. :wink:

But as posted by @kris above this is one of those “likely to happen, but it’s not specifically on the road map right now” things.

We’d also want to set up the TUI (text interface) so that in scenarios where someone only has a wireless interface, we can have them walk through and enter the key (although that’s only going to work with PSKs, I can’t see anyone wanting to key in an 802.1x certificate)

1 Like

Given that TrueNAS has shell access, there are already standard Linux tools to set up WiFi from the terminal, so besides documenting which of these tools TrueNAS picked, there shouldn’t have to be much implementation, lest of course you decide to roll your own thing squeezing everything through your middleware layer, then that of course would take some extra work.

Anyway, glad this is on the horizon :champagne::partying_face:

You get a [“Maybe”] tag. Perhaps even [“Eventually”] :wink:

4 Likes