Official moOde 8 support thread

[Lukesan]

I made an incorrect statement above. It is about two zero 2w. I already changed it. Also have a normal zero w just tested with the new image. This does not find my router either. I have another system with a Raspberry Pi-3B . This is connected via ethernet . His wifi also finds neither my router nor my repeater. It seems to be a problem of my router (TP-Link Archer VR900v). The previous versions of Moode worked flawlessly on all my Raspberrys  .

No problem here on a Netgear 7800 and a Deco M3 on the zero 2w.   Can you check which channel your router is on?  (not channel 14 ?)

For me still the same stuttering on my zero 2w in BT as in previous builds while playing a stream on Pi OS it works perfectly.

[petfr]

I made an incorrect statement above. It is about two zero 2w. I already changed it. Also have a normal zero w just tested with the new image. This does not find my router either. I have another system with a Raspberry Pi-3B . This is connected via ethernet . His wifi also finds neither my router nor my repeater. It seems to be a problem of my router (TP-Link Archer VR900v). The previous versions of Moode worked flawlessly on all my Raspberrys  .

No problem here on a Netgear 7800 and a Deco M3 on the zero 2w.   Can you check which channel your router is on?  (not channel 14 ?)

For me still the same stuttering on my zero 2w in BT as in previous builds while playing a stream on Pi OS it works perfectly.

Problem solved . Please note post #85 .

[DRONE7]

@Sunfish

@Tim Curtis
Thanks for the suggestions. Without Kali there is an hardware volume control, but as soon as Kali is introduced and the proper drivers selected sound disappears.
Re-checked all settings as per @DRONE7 and changed plug:hw to Direct (hw) which resulted in sound only on the right channel.
For now I will stick to version 7.6.1. Which also gives no hardware volume control, but is working flawless.

'sound' is progress... if in only one channel this would indicate a hardware or cabling problem.

 Are you using the correct Piano 2.1 outputs ?
Do you have a subwoofer and using those output/s ?  If so have you downloaded the Piano 2.1 firmware for that operation. ?

I have today  rechecked my Kali-Piano 2.1 and can confirm that it operates fine in both dual-mono and dual-stereo modes and outputs both channels.
That would indicate there is no problem with the code in MoOde 8.

cheers,
bob,

[Tim Curtis]

I remember that odd "only one channel" behavior with the Piano and I think if you bump the volume a couple of times either in moOde or alsamixer both channels start outputting and it stays that way. Something like that.

[Sunfish]

@Sunfish

@Tim Curtis
Thanks for the suggestions. Without Kali there is an hardware volume control, but as soon as Kali is introduced and the proper drivers selected sound disappears.
Re-checked all settings as per @DRONE7 and changed plug:hw to Direct (hw) which resulted in sound only on the right channel.
For now I will stick to version 7.6.1. Which also gives no hardware volume control, but is working flawless.

'sound' is progress... if in only one channel this would indicate a hardware or cabling problem.

 Are you using the correct Piano 2.1 outputs ?
Do you have a subwoofer and using those output/s ?  If so have you downloaded the Piano 2.1 firmware for that operation. ?

I have today  rechecked my Kali-Piano 2.1 and can confirm that it operates fine in both dual-mono and dual-stereo modes and outputs both channels.
That would indicate there is no problem with the code in MoOde 8.

cheers,
bob

I'm 100% sure that the used outputs are correct. Only difference is that I use a thumbdrive for moOde 7.6.1. For moOde 8.0.0 I use an high quality new sd-card (after removing the thumbdrive).
I only use the piano 2.1 in stereo mode, so that must be ok.
Just 10 minute ago I retried the process of burning an image and setting up the system from scratch. The result was a beautifull sound of silence. Frustrating.
Will give it another try tomorrow.

[Sunfish]

I remember that odd "only one channel" behavior with the Piano and I think if you bump the volume a couple of times either in moOde or alsamixer both channels start outputting and it stays that way. Something like that.

will give that a try tomorrow when I will do a new run. thanks

[TheOldPresbyope]

...

@carmol

A log message like

Code:

CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers

is informational and not a statment of error.

From the IP address it appears you are using a file-sharing function on your router as your NAS. What is the router? How have you made sure the share name is "CD"? How have you inferred that "ntlm" is in play and the protocol level version is "1.0"?

As Phil has said, you can force these parameters in the Advanced flags settings in the Music Source screen but they have to be correct for the source.

ETA - and as Tim has said, the SCAN function does a good job of figuring out the protocol level version in play.

Regards,
Kent

router is Zyxel 8825

share name is correct,
the same configuration worked flawlessy in moode 7;
no luck with the scan function.

It seems that ntlm is not supported anymore

So moOde is just building a mount command string to pass to the Raspberry Pi OS command interpreter. Here's the relevant option descriptions taken from the man page for mount.cifs on the moOde 8 image

Code:

      vers=arg
             SMB protocol version. Allowed values are:

             • 1.0 - The classic CIFS/SMBv1 protocol.

             • 2.0 - The SMBv2.002 protocol. This was initially introduced in Windows Vista Service Pack 1, and Windows Server 2008. Note that the ini‐
               tial release version of Windows Vista spoke a slightly different dialect (2.000) that is not supported.

             • 2.1 - The SMBv2.1 protocol that was introduced in Microsoft Windows 7 and Windows Server 2008R2.

             • 3.0 - The SMBv3.0 protocol that was introduced in Microsoft Windows 8 and Windows Server 2012.

             • 3.02 or 3.0.2 - The SMBv3.0.2 protocol that was introduced in Microsoft Windows 8.1 and Windows Server 2012R2.

             • 3.1.1 or 3.11 - The SMBv3.1.1 protocol that was introduced in Microsoft Windows 10 and Windows Server 2016.

             • 3 - The SMBv3.0 protocol version and above.

             • default - Tries to negotiate the highest SMB2+ version supported by both the client and server.

             If no dialect is specified on mount vers=default is used.  To check Dialect refer to /proc/fs/cifs/DebugData

             Note too that while this option governs the protocol version used, not all features of each version are available.

             The  default since v4.13.5 is for the client and server to negotiate the highest possible version greater than or equal to 2.1. In kernels
             prior to v4.13, the default was 1.0. For kernels between v4.13 and v4.13.5 the default is 3.0.

       sec=arg
              Security mode. Allowed values are:

              • none - attempt to connection as a null user (no name)

              • krb5 - Use Kerberos version 5 authentication

              • krb5i - Use Kerberos authentication and forcibly enable packet signing

              • ntlm - Use NTLM password hashing

              • ntlmi - Use NTLM password hashing and force packet signing

              • ntlmv2 - Use NTLMv2 password hashing

              • ntlmv2i - Use NTLMv2 password hashing and force packet signing

              • ntlmssp - Use NTLMv2 password hashing encapsulated in Raw NTLMSSP message

              • ntlmsspi - Use NTLMv2 password hashing encapsulated in Raw NTLMSSP message, and force packet signing

              The default in mainline kernel versions prior to v3.8 was sec=ntlm. In v3.8, the default was changed to sec=ntlmssp.

              If the server requires signing during protocol negotiation, then it may be enabled automatically. Packet signing may also be enabled auto‐
              matically if it's enabled in /proc/fs/cifs/SecurityFlags.

Since this is all vanilla Raspberry Pi OS stuff you might be better served asking over at the Raspberry Pi Forum.

If I force my OMV Samba server to use only SMBv1 (sec=NT1) then the scan function doesn't find it but manual mounting it in moOde works whether I explicitly set vers=1.0 in the flags or not. I'm not interested in exploring security protocols such as NTLM. Perhaps someone else is.

Regards,
Kent

[Phil323UK]

...

@carmol

A log message like

Code:

CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers

is informational and not a statment of error.

From the IP address it appears you are using a file-sharing function on your router as your NAS. What is the router? How have you made sure the share name is "CD"? How have you inferred that "ntlm" is in play and the protocol level version is "1.0"?

As Phil has said, you can force these parameters in the Advanced flags settings in the Music Source screen but they have to be correct for the source.

ETA - and as Tim has said, the SCAN function does a good job of figuring out the protocol level version in play.

Regards,
Kent

router is Zyxel 8825

share name is correct,
the same configuration worked flawlessy in moode 7;
no luck with the scan function.

It seems that ntlm is not supported anymore

So moOde is just building a mount command string to pass to the Raspberry Pi OS command interpreter. Here's the relevant option descriptions taken from the man page for mount.cifs on the moOde 8 image

Code:

      vers=arg
             SMB protocol version. Allowed values are:

             • 1.0 - The classic CIFS/SMBv1 protocol.

             • 2.0 - The SMBv2.002 protocol. This was initially introduced in Windows Vista Service Pack 1, and Windows Server 2008. Note that the ini‐
               tial release version of Windows Vista spoke a slightly different dialect (2.000) that is not supported.

             • 2.1 - The SMBv2.1 protocol that was introduced in Microsoft Windows 7 and Windows Server 2008R2.

             • 3.0 - The SMBv3.0 protocol that was introduced in Microsoft Windows 8 and Windows Server 2012.

             • 3.02 or 3.0.2 - The SMBv3.0.2 protocol that was introduced in Microsoft Windows 8.1 and Windows Server 2012R2.

             • 3.1.1 or 3.11 - The SMBv3.1.1 protocol that was introduced in Microsoft Windows 10 and Windows Server 2016.

             • 3 - The SMBv3.0 protocol version and above.

             • default - Tries to negotiate the highest SMB2+ version supported by both the client and server.

             If no dialect is specified on mount vers=default is used.  To check Dialect refer to /proc/fs/cifs/DebugData

             Note too that while this option governs the protocol version used, not all features of each version are available.

             The  default since v4.13.5 is for the client and server to negotiate the highest possible version greater than or equal to 2.1. In kernels
             prior to v4.13, the default was 1.0. For kernels between v4.13 and v4.13.5 the default is 3.0.

       sec=arg
              Security mode. Allowed values are:

              • none - attempt to connection as a null user (no name)

              • krb5 - Use Kerberos version 5 authentication

              • krb5i - Use Kerberos authentication and forcibly enable packet signing

              • ntlm - Use NTLM password hashing

              • ntlmi - Use NTLM password hashing and force packet signing

              • ntlmv2 - Use NTLMv2 password hashing

              • ntlmv2i - Use NTLMv2 password hashing and force packet signing

              • ntlmssp - Use NTLMv2 password hashing encapsulated in Raw NTLMSSP message

              • ntlmsspi - Use NTLMv2 password hashing encapsulated in Raw NTLMSSP message, and force packet signing

              The default in mainline kernel versions prior to v3.8 was sec=ntlm. In v3.8, the default was changed to sec=ntlmssp.

              If the server requires signing during protocol negotiation, then it may be enabled automatically. Packet signing may also be enabled auto‐
              matically if it's enabled in /proc/fs/cifs/SecurityFlags.

Since this is all vanilla Raspberry Pi OS stuff you might be better served asking over at the Raspberry Pi Forum.

If I force my OMV Samba server to use only SMBv1 (sec=NT1) then the scan function doesn't find it but manual mounting it in moOde works whether I explicitly set vers=1.0 in the flags or not. I'm not interested in exploring security protocols such as NTLM. Perhaps someone else is.

Regards,
Kent

It appears that support for sec=ntlm was removed in kernel 5.15.

https://bugzilla.kernel.org/show_bug.cgi?id=215375

Dmesg reports
[12896.209510] bad security option: ntlm
[12896.209526] CIFS: VFS: bad security option: ntlm

Regards,
Phil.

[url=https://bugzilla.kernel.org/show_bug.cgi?id=215375][/url]

[TheOldPresbyope]

The original NTLM was deprecated in 2010 and CIFS / SMBv1 in 2013. I can't say I miss either one.

[philrandal]

It appears that support for sec=ntlm was removed in kernel 5.15.

https://bugzilla.kernel.org/show_bug.cgi?id=215375

Dmesg reports
[12896.209510] bad security option: ntlm
[12896.209526] CIFS: VFS: bad security option: ntlm

Regards,
Phil.

[url=https://bugzilla.kernel.org/show_bug.cgi?id=215375][/url]

Well spotted. I gave up on using disk drives plugged into routers because of the manufacturers' refusal/inability to move beyond SMBv1. 

Phil