Support for SMB v2 or v3

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.

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.

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).

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.

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.

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.

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'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.

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.

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.