With all the recent reports and issues with the WannaCry ransomware I wanted to restrict use of SMB v1 on my home network. My NAS blocks this to the outside world but I wanted to secure things internally as well. I can configure the NAS to not support SMB v1 but this then prevents the Sonos controller app from seeing the share. When will Sonos support later versions of SMB? I had seen another thread on this somewhere and it sounded like it wasn't going anywhere. Is it possible to get an update on this please.
Page 3 / 5
It's a software stack, no hardware needs to change. UNLESS you have an extremely out of date media server. and I am talking pretty close to last century! reality is any media server built since 2003 is capable of at least SMB 2. the difference is that SMB 1 was built when all networks were closed pre-internet networks. SMB 2 was the first file handler for connected networks and predates Sonos as a concept.
The software stacks are even available as libraries so no need to even write them from scratch just integrate the library into the network stack.
I also have a work around that works for me, but I can't sell Sonos to my Nan unless she can get an off the shelf media server that works with it. which at the current time she can't do. but she can use Samsung, or Philips or Apple or....
So the upshot of that is your Sonos kit becomes unusable as the company vanishes, outsold by inferior but more modern technology from the big money companies.
The software stacks are even available as libraries so no need to even write them from scratch just integrate the library into the network stack.
I also have a work around that works for me, but I can't sell Sonos to my Nan unless she can get an off the shelf media server that works with it. which at the current time she can't do. but she can use Samsung, or Philips or Apple or....
So the upshot of that is your Sonos kit becomes unusable as the company vanishes, outsold by inferior but more modern technology from the big money companies.
Agreed, it's indeed a software stack. But what if that software stack, with an inclusion/replacement of SMB V2 or 3 no longer fits in the memory available on the devices mentioned? There is, to my meager knowledge, a limit to the amount of memory available on the older devices. That leads me to the conclusion that the "stack" might not fit any longer, if they were to add an update to that library.
I don't know that for sure, and I'm not a programmer, nor have I looked in to exactly what the usage is currently, or the cost to update. My only point of reference is prior work in maintaining software in gaming, and an assumption that Sonos is actively trying to solve the problem. It's entirely possible that I'm way off base. But I do feel comfortable in saying that Sonos isn't ignoring the problem. It would be an odd stance for a software driven company to take.
I don't know that for sure, and I'm not a programmer, nor have I looked in to exactly what the usage is currently, or the cost to update. My only point of reference is prior work in maintaining software in gaming, and an assumption that Sonos is actively trying to solve the problem. It's entirely possible that I'm way off base. But I do feel comfortable in saying that Sonos isn't ignoring the problem. It would be an odd stance for a software driven company to take.
The problem is that if they don't solve it, and there is another high publicity hack on SMB 1, or just because why bother to include SMB 1 so Linux and Microsoft stop including it rather than the current default of including it but turning it off. SMB 3.1.1 as I understand it works with SMB 2 and is smaller than SMB 1 (all of the versions from 2.0 onwards use a fraction of the network bandwidth of SMB 1 which is actually a NetBios LAN based system from before the days of WAN)
It will be interesting to see when this item (that is allegedly on a to-do list per the Sonos CEO) will be fixed. I'm not holding my breath given that there is little future monetary income potential from doing so (bug fixes are rarely profitable). Streaming and voice integration are squarely the center of attention at Sonos right now.
Interesting to hear that the SMB 3.11 stack is smaller than the SMB1v1 stack. Does that go for Flash and RAM? I imagine that the RAM in the players is a limiting factor besides the 'mini-computer' CPU (not my description).
Interesting to hear that the SMB 3.11 stack is smaller than the SMB1v1 stack. Does that go for Flash and RAM? I imagine that the RAM in the players is a limiting factor besides the 'mini-computer' CPU (not my description).
Since I can't do anything about it I'm not spending hours looking into the guts of the issue but if one wanted to do that...
Remember it is a "stack" and you can't just update one component of that stack in many cases. What kernel is Sonos running, does that kernel support the latest SMB code? What fiddling has Sonos done to the various bits of code involved and how does that port to the newer releases that are needed to update the SMB.
I used to do a bit of embedded systems work before I retired and I can tell you that we missed a lot of release milestones over interactions and dependencies in the code we were upgrading, before we even got to glitches in the hardware support it offered. I've never had the lid off any of my gear to look but is there even hardware dubbing support available in the standard units sold or is that something they reserve for in-house test hardware?
I'll stick with my "too many worms for the can - it is a hard problem" theory over greed, stupidity or just evil.
Remember it is a "stack" and you can't just update one component of that stack in many cases. What kernel is Sonos running, does that kernel support the latest SMB code? What fiddling has Sonos done to the various bits of code involved and how does that port to the newer releases that are needed to update the SMB.
I used to do a bit of embedded systems work before I retired and I can tell you that we missed a lot of release milestones over interactions and dependencies in the code we were upgrading, before we even got to glitches in the hardware support it offered. I've never had the lid off any of my gear to look but is there even hardware dubbing support available in the standard units sold or is that something they reserve for in-house test hardware?
I'll stick with my "too many worms for the can - it is a hard problem" theory over greed, stupidity or just evil.
Hey Stanley, based on the GPL page, there are a variety of Linux distributions to choose among, see: http://www.sonos.com/documents/gpl/8.4/gpl.html
It's an interesting read. The latest Linux distribution in there (3.10.53) appears to have dedicated SMB1, SMB2, and SMB3-related files in it (see the /FS/CIFS folder) while the 2.6.35 version also hosted at Sonos just has a few smb2 references embedded inside its CIFS-related documents. So, I'd guess the appearance of SMB3 support in the Sonos universe would signal a switch to Linux 3.10.x from 2.x?
Hilariously, that version of Linux has also been deprecated as of last year (see https://www.linux.com/news/linux-kernel-310-reached-end-life-users-are-urged-move-linux-44-lts-1) with 3.10.x users being urged to switch to 4.4. The version of Linux hosted at Sonos appears to be outdated, even within the branch, as the last release was 3.10.108. That said, the Linux versions that the developers are using internally may quite possibly more recent than the stuff they're hosting on the Sonos GPL page.
It's an interesting read. The latest Linux distribution in there (3.10.53) appears to have dedicated SMB1, SMB2, and SMB3-related files in it (see the /FS/CIFS folder) while the 2.6.35 version also hosted at Sonos just has a few smb2 references embedded inside its CIFS-related documents. So, I'd guess the appearance of SMB3 support in the Sonos universe would signal a switch to Linux 3.10.x from 2.x?
Hilariously, that version of Linux has also been deprecated as of last year (see https://www.linux.com/news/linux-kernel-310-reached-end-life-users-are-urged-move-linux-44-lts-1) with 3.10.x users being urged to switch to 4.4. The version of Linux hosted at Sonos appears to be outdated, even within the branch, as the last release was 3.10.108. That said, the Linux versions that the developers are using internally may quite possibly more recent than the stuff they're hosting on the Sonos GPL page.
That link isn't a list of distributions, rather it is a list of links to the kernel versions, programs and libraries used by Sonos. The Attributions file gives some info but you'd have to dig into the actual sonos-kernel.tgz file to see which bits from where are used. Switching your Linux kernel is not a trivial operation and doing it on an embedded system is even more difficult.
There was a huge size increase in the core OS going from Linux v2.0 to Linux v2.6, if I recall correctly, which is why so many embedded devices never even attempted the change. The change from v2.6 to v3 was more cosmetic because they thought the 2.XX number was getting too big.
https://www.phoronix.com/scan.php?page=news_item&px=MTAxNDg
Version 2.4 I don't recall, Version 2.6 LTS (Long Term Support) looks to have ended active maintenance in 2016 sometime. Version 3.2 LTS likely ends in May of 18.
Many system maintainers continue to use the Linux kernel version that was originally released with their device and backport any needed operational or security fixes to that which makes their internal release numbers very different from the kernel's version numbers.
Any size increase in any area of the firmware in a Sonos device means there is less space available for something else. If features are added that fit in newer devices but don't fit in older ones we are faced with the CR-100 situation again. Older devices will soon be missing features and incur additional costs to maintain, edging closer to the "No longer supported" status that ended the life of the CR-100s.
There was a huge size increase in the core OS going from Linux v2.0 to Linux v2.6, if I recall correctly, which is why so many embedded devices never even attempted the change. The change from v2.6 to v3 was more cosmetic because they thought the 2.XX number was getting too big.
https://www.phoronix.com/scan.php?page=news_item&px=MTAxNDg
Version 2.4 I don't recall, Version 2.6 LTS (Long Term Support) looks to have ended active maintenance in 2016 sometime. Version 3.2 LTS likely ends in May of 18.
Many system maintainers continue to use the Linux kernel version that was originally released with their device and backport any needed operational or security fixes to that which makes their internal release numbers very different from the kernel's version numbers.
Any size increase in any area of the firmware in a Sonos device means there is less space available for something else. If features are added that fit in newer devices but don't fit in older ones we are faced with the CR-100 situation again. Older devices will soon be missing features and incur additional costs to maintain, edging closer to the "No longer supported" status that ended the life of the CR-100s.
That's an impressive graph, though as you note, the Sonos team can easily omit all sorts of included stuff that is not needed on an embedded system. The good news is that both of us have a workaround that protects the original sound files while serving up copies to the Sonos. Having worked on embedded systems for fun, I can also appreciate the RAM, Flash, etc. limitations that the coders at Sonos are likely grappling with.
I imagine that decoding secure streams in particular to be a challenge relative to the hardware they get to work with. Too bad that the RAM in zone players is not considered 'upgradeable' (assuming that's one of the limitations the coders have to contend with).
I imagine that decoding secure streams in particular to be a challenge relative to the hardware they get to work with. Too bad that the RAM in zone players is not considered 'upgradeable' (assuming that's one of the limitations the coders have to contend with).
I'm guessing RAM and Flash space are the two main issues, they were both expensive when the first Sonos gear was released. Upgradeable sounds nice but it forces the use of sockets for the upgradable components and that adds greatly to the failure rate over soldered attachment as well as cost. The possibility of soldered base level parts and expansion sockets is a good one, many laptops do that today but the cost of the sockets plus the can of worms opened by allowing users to poke about the innards isn't something to consider for most folks.
Backporting fixes and features can be very simple if it is a stand-alone bit but if it touches the dependency tree the problem grows rapidly, both in man-hours and in system impact, maybe in memory/flash footprint too.
I plan on keeping my home theater systems for another 5 years, before downsizing them and the house so I have a vested interest in seeing my SP-80s continuing to work until then. Worst case I can re-purpose my Gen 1 Play 5s and use the audio output from them if the ZPs are killed off like the CR-100 was. Well if they aren't killed too.
There used to be a lot more internal Sonos hardware info available until they did the v8 (or so) controllers that removed our access to it, I kind of miss the info and sure wish I'd thought to go in and snapshot it wile it was still available.
Backporting fixes and features can be very simple if it is a stand-alone bit but if it touches the dependency tree the problem grows rapidly, both in man-hours and in system impact, maybe in memory/flash footprint too.
I plan on keeping my home theater systems for another 5 years, before downsizing them and the house so I have a vested interest in seeing my SP-80s continuing to work until then. Worst case I can re-purpose my Gen 1 Play 5s and use the audio output from them if the ZPs are killed off like the CR-100 was. Well if they aren't killed too.
There used to be a lot more internal Sonos hardware info available until they did the v8 (or so) controllers that removed our access to it, I kind of miss the info and sure wish I'd thought to go in and snapshot it wile it was still available.
Yup, though the atheros WiFi cards are removable in the ZP80, ZP100, and the CR100, while the RAM (32MB ea.) is not. 32MB of Flash for the ZP80&100, only 16MB for the controller is pretty tiny by today's standards. See Figure 8 on this page for a good image of the motherboard inside the ZP80, for example: https://www.edn.com/Home/PrintView?contentItemId=4018421
Makes me wonder how they manage to index even 65k songs with that little RAM.
Interesting design choice to use a fully-designed mini-PCIe WiFi module with its own processor, etc. mounted inside a mini PCI-e slot. Makes sense for a 1st gen product... much like Apple relied on Lucent to deliver the motherboard (Lucent RG1000) and the Wifi cards (Lucent Orinoco Silver) for the first generation Apple Airport base stations (Silver). However, even the Connect seems to rely on a mini-PCIe based approach for mounting its WiFi module!
Anyhow, your point re: the RAM and Flash are well-taken. Few users will have the patience, capability, etc. to unsolder those components and install upgraded ones in their place. Never mind how higher-capacity RAM, FLASH chips could confuse bootloader for the CPU.
Buying a packaged RF solution avoids much government interaction!
Yes, ran into that when I built a DAQ system that uses a cellular link. Regs around Cellular RF make unlicensed bands look positively tame in comparison. I also suppose that reduces their business risk somewhat - using a known-good reference design. Plus, with the kinds of profit margins they enjoy, paying a small premium for the module is in the noise.
All that said, I also found it very interesting to hear that the SMB3.11 stack is smaller than the SMB1 stack. I hear your your points about code dependencies and so on, but if they're really scrounging for every bit of Flash and RAM as has been implied in all the emails detailing the woes associated with "mini-computer" CPUs, wouldn't one want to upgrade to SMB3.11?
All that said, I also found it very interesting to hear that the SMB3.11 stack is smaller than the SMB1 stack. I hear your your points about code dependencies and so on, but if they're really scrounging for every bit of Flash and RAM as has been implied in all the emails detailing the woes associated with "mini-computer" CPUs, wouldn't one want to upgrade to SMB3.11?
It would have been fun to download the Sonos kernel and try swapping the v2 code for v3 and seeing what the final code sizes were once all the dependencies of the v3 code were met but I'm too old and lazy to think that is much fun today.
You also need to consider just how much of the v2 SMB stack has been dropped from the Sonos code. I'm sure the printer support is gone. 🙂 How much else they dropped I don't know but if they are fighting for code space you can bet they sent in a man with an ax to do the trimming initially and maybe a couple more passes later in search of every last possible reduction.
I have no idea what Sonos is doing internally but if they don't have a team occasionally looking at the issues of moving to a newer kernel and supporting software I'd be surprised. Supporting obsolete kernels and other software is time consuming and folks that can do it well do not work cheap.
You also need to consider just how much of the v2 SMB stack has been dropped from the Sonos code. I'm sure the printer support is gone. 🙂 How much else they dropped I don't know but if they are fighting for code space you can bet they sent in a man with an ax to do the trimming initially and maybe a couple more passes later in search of every last possible reduction.
I have no idea what Sonos is doing internally but if they don't have a team occasionally looking at the issues of moving to a newer kernel and supporting software I'd be surprised. Supporting obsolete kernels and other software is time consuming and folks that can do it well do not work cheap.
I just guess that for compatibility reasons unfortunately the choice would be for Sonos as:
- just support samba 1;
- support samba 3 as well as 1 and 2 for backwards compatibility;
And this will take much more resources than samba 3 alone.
Just guessing...
- just support samba 1;
- support samba 3 as well as 1 and 2 for backwards compatibility;
And this will take much more resources than samba 3 alone.
Just guessing...
Seeing that a Samba team member from MSFT offered to help them implement SMB3 at Sonos, I cannot think of a better resource to make it happen. Given the lack of progress over the last year on this issue, I conclude that it's simply not a priority and it won't be until MSFT and other vendors won't even allow SMB1v1 to be used.
Currently, Sonos can get away with telling their home-hosting content customers to dumb down their network protocol security; that may not be an option in the future. However, the bet in the management suite may simply be that by the time MSFT makes it impossible for Windows users to even turn on SMB1v1 that enough people will accept streaming-only product and hence an update won't even be needed. No more support for a home NAS should open up some Flash / RAM too.
Yeah, they might lose a few customers over this but there is a precedent for that at Sonos now.
Why anyone who has voluntarily frozen their system at 8.4 keeps posting about wanting a future update to support SMB v2 is yet another question for the ages. So which is it, do you want to be able to freeze your system to legacy versions, or install a new version for SMB support? Because you can't have both (unless "getting both" is merely code for getting to complain about both).
One can freeze and sandbox part of their system so as not to be subject to the forced cr100 brickening by Sonos, and have a separate system with units where they get updates and thus wants updates.
Let's keep it friendly everyone, no need to be antagonistic toward anyone.
Some good discussion and speculation here, I can't share many details but we are looking at the SMB integration and ways to make changes for the future. We'll let you know as soon as there's more to say here. SMB is a tricky one, because of how we handle the music index on all players, including our legacy devices that, as Constantin and Stanley were talking about, are extremely limited when it comes to their hardware.
Some good discussion and speculation here, I can't share many details but we are looking at the SMB integration and ways to make changes for the future. We'll let you know as soon as there's more to say here. SMB is a tricky one, because of how we handle the music index on all players, including our legacy devices that, as Constantin and Stanley were talking about, are extremely limited when it comes to their hardware.
So I finally decided to get a set of Sonos Speakers. My two Play:3's arrived today. I went to set them up. I go to point them to my NAS and it won't connect. I do a little digging. SMBv1!? WTF!!!! Come on Sonos, it's 2018. SMB v2 has been out since 2006, SMB v3 since 2012. This is insane. It is utterly ridiculous that a supposedly premium product is using an ancient insecure version of SMB. I'm not trying to be rude, but this is incredibly disappointing. No, I don't want to stream. I want to play MY music collection from my speakers, without going back and downgrading the security settings on my NAS box. I still haven't heard a blessed thing out of my brand new speakers other than the setup chime.
So add a cheap NAS like the WD Live drives or even cheaper roll your own NAS using a Raspberry Pi and move on.
I'd love to have newer SMB but not at the cost of having to replace my older Sonos Zone Players because they don't have the hardware needed to support it. Look at the unhappiness over the ending of the CR 100 that for most folks was a minor issue.
I'd love to have newer SMB but not at the cost of having to replace my older Sonos Zone Players because they don't have the hardware needed to support it. Look at the unhappiness over the ending of the CR 100 that for most folks was a minor issue.
There's absolutely no reason that a brand new, premium product should require the use of an ancient insecure version of SMB. If I wanted to tinker with a Raspberry Pi or buy a second NAS I wouldn't have bought what was supposedly a easy to use, premium product. With respect to your older Zone players, there's also absolutely no reason that Sonos couldn't do different firmware versions with updated features for different products. Put another way, keeping their currently shipping products current doesn't mean that your older investment should be affected at all. Add SMBv2 or SMBv3 support to the Play:1, Play:3, and Play:5 such that those products can take advantage of it. Leave the older stuff alone. Sonos shouldn't have to hold the new products hostage to the old, nor should an upgrade to the new impact you one way or the other.
I stand by my position. This is broken. Sonos should fix it. Older products have nothing to do with it.
I stand by my position. This is broken. Sonos should fix it. Older products have nothing to do with it.
Do you have evidence that SMB2 and3 couldn't be made to work on old players, or is this merely supposition?
Supposition, based on looking at the Linux version that Sonos is using versus the version that works with the newer SMB releases. I'm retired now and a bit rusty at that kind of thing so no guarantee on my guess.
You can do the same research, all the source code is available from Sonos for their Linux version and the newer Linux kernels and
SMB stuff are on-line about anywhere.
If it was a simple thing Sonos would have had their Linux kernel maintainer do a bit of copy/paste and had SMB v3 working years ago.
If Sonos is truly evil and nasty, just jerking us around for their amusement despite it hurting their sales numbers then my (researched) guess is wrong.
You can do the same research, all the source code is available from Sonos for their Linux version and the newer Linux kernels and
SMB stuff are on-line about anywhere.
If it was a simple thing Sonos would have had their Linux kernel maintainer do a bit of copy/paste and had SMB v3 working years ago.
If Sonos is truly evil and nasty, just jerking us around for their amusement despite it hurting their sales numbers then my (researched) guess is wrong.
Yes, I thought so... I hadn't seen anything official from Sonos...
I doubt evil and nasty, just focussed on the bottom line. We're led to believe that a very high proportion of Sonos users purely stream, rather than use local storage, so it's just a numbers game.
Hi everyone, starting with today's update, Sonos 8.6, Windows computers will be able to set up shares to their local libraries to Sonos without using SMB file sharing. We aren't removing support for SMB at this time, and you will continue to need to use it for NAS drives, but Mac computer and Windows computers now both have the ability to share using our implementation of HTTP file sharing using the Sonos app. For more details, see the post here.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.