Siglent SDS2000X Plus - Bugs / Missing Features / Feature Requests

[Faranight]

Hey,

I've skimmed over this thread, but didn't find anything related (sorry, if I missed it). Anyway, I've recently been moving stuff around in my lab, and I noticed that whenever I unplug my Siglent SDS2140X+ from mains power (while it's powered off of course) and then plug it back in after a while it will automatically turn itself on. I'm not sure, if this is a bug or not, but I would prefer that it stayed off until I manually power it back on by pressing the power button. Sometimes there's a thunderstorm, and I have a habit of unplugging my stuff prior. But when I re-apply power to the lab, the machine will turn on. We can also get power cuts here which means the machine will likely power itself on automatically, if that happens. Sometimes (i.e. in the winter during heavy snowfall) we can even get multiple cuts in a row and power is like on/off/on/off/on/off. I worry this will negatively affect my scope, if it keeps turning on and off like that.

Is there a setting I can change to prevent it from automatically powering on when the mains power is applied? I'm on firmware version 1.3.9R4.

EDIT: Thanks, Martin72.

[Martin72]

A look at the manual, page 29:

Power on Line
When the “Power on Line” option is enabled, once the oscilloscope is
connected to the AC power supply through the power cord, the
oscilloscope boots automatically.

 

[blurpy]

I asked about this in the main thread, but didn't get any replies, so I assume this is not possible in the current firmware. Consider these as feature requests.

...

2. Would be nice to be able to display watts, and perhaps the formula editor could be the way to go. I can't see any way of using measurements in the editor however. Is it possible to enter something like this? RMS(C1) * RMS(C1) / 8
Ideally it would be a custom "measurement" since it doesn't need a trace, but I can't see a way of doing that.

Well, to quote myself again here, it seems #2 is sort of possible:



Wish it was possible to base it on the RMS measurement instead, but better than nothing.

This is what it looks like:



The Pk-Pk(F2) measurement is watts into 8 ohm.

Now for some feedback on the formula editor.

1. Bug - the formula editor is blank after booting the scope, which is quite annoying when you want to edit a long formula:



The formula is remembered, as can be seen by the function shown in the menu, except it's not possible to edit it. It should be pre-filled in the editor when you open it.

2. Request - a way of storing and selecting favorite formulas. It gets old fast entering these formulas.

3. Request - support longer formulas. The one I used is almost max length. If I try to use the ERES function I only get the first character:



There is obviously lots of room to write there, but it's not possible to enter any more characters.

4. Request - support hiding the math trace, like the channel traces can. The trace is in the way for my use case. I only need the measurement.

[umgfoin]

Good morning,
we have a new firmware available:
SDS2000X Plus Firmware-V1.3.9R6 (Release Date 10.24.21)

SMB1-only connectivity-flaw still unchanged.
'Asking myself, if this is really *that* hard to fix?

Code: [Select]

10/21/2021 1.3.9R6
1. Fixed several bugs
a) When selecting the option screen the scope hangs
b) Wrong FFT frequency when memory depth > 10 Mpts
c) Incorrect network storage path leads the scope to hang
++umgfoin

[Martin72]

Hi,

SMB1-only connectivity-flaw still unchanged.
'Asking myself, if this is really *that* hard to fix?

This is a very quick "emergency" update, not a full one as you can see it on the few fixes in the list.
Apart from this, maybe "yours" is indeed hard to fix or the internal priority for this is low.

Martin

[oz2cpu]

wow blurby fantastic,
I have been looking for a way to use the RMS read out value, for a little bit math, and make it watts into 8 ohms,

[umgfoin]

Hi Martin,

Apart from this, maybe "yours" is indeed hard to fix or the internal priority for this is low.

No, it isn't:

Code: [Select]

umount /usr/bin/siglent/usr/mass_storage/net_storage
mount -t cifs -o vers=3.0,username=foo,password=bar,rw,soft //HostIP/Share /usr/bin/siglent/usr/mass_storage/net_share
++umgfoin.

[2N3055]

Hi Martin,

Apart from this, maybe "yours" is indeed hard to fix or the internal priority for this is low.

No, it isn't:

Code: [Select]

umount /usr/bin/siglent/usr/mass_storage/net_storage
mount -t cifs -o vers=3.0,username=foo,password=bar,rw,soft //HostIP/Share /usr/bin/siglent/usr/mass_storage/net_share
++umgfoin.

It is always easy to say other peoples job is easy....

Mapping is NOT being done from command line. It is being done from GUI, and with code.. So that has to be changed and checked. Which is a bit more involved than what you say.
Mind you, it is not huge job, but it is a job and a test and a...
They literally have better (as in more important) things to do.
FFT fix was important and done very quickly. Priorities...

Complexity of these machines is astonishing. No matter how many developers you put on it you will always have to have priorities.

Most important thing is that this scope is a part of platform that is going to be with us for some time. And will develop and be made better and better.
It takes time to do this. That is all.

Only 4-5 years ago, scope with these kind of capability for this price was unheard of.

My very expensive Keysight 3000T doesn't have any LAN mapping capability. It runs Windows CE, it would be trivial to add it... right...?
I would be happy if it would map any level of SMB, but it doesn't. And they don't care.

People asked Siglent for LAN mapping, and they did it... Not perfect, but hey, that can be fixed. But they listen, apparently.
Unlike others..

[kcbrown]

It is always easy to say other peoples job is easy....

Yep.  How often have any of us said "how hard can it be?" when contemplating doing something, and then we actually go try it, and find that it's far more difficult than we originally anticipated?

I dare say that many of us have been through that.

It's something to always keep in mind when looking at something.  You have to have a pretty deep understanding of how something works to be able to say with legitimate confidence that a change to it would be easy.


You'd think that the change here shouldn't be hard.  And compared with some other things, it might not be.  But remember that they have to do this right.

It turns out that I have direct experience with the problem seen here, in a product I maintain at work.  To do this right, you have to attempt the mount using various option combinations until you succeed or until all of them fail.  Worse, mount failures can occur for all sorts of reasons, which means that unless you want to try all of the option combinations one by one (which, if the issue is that the remote server is off the air, means the total time before you accept defeat could easily be longer than the user would normally tolerate), you have to examine the actual error returned, parse it (I don't see anything in the mount.cifs manpage that describes exit codes), and figure out what it implies.

So, yes, if all you're interested in doing is mounting a version 3.0 CIFS share, then that is straightforward.  But what Siglent is really interested in doing here is mounting any CIFS share of any version, because they cannot know in advance what version of CIFS is in use on the target server.

Now, I don't know what version of the Linux kernel they're using here, but this is what the mount.cifs manpage says about the version argument:

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.

So if the kernel version in use by Siglent is 4.13.5 or higher, then the failures seen here are likely due to something other than the version itself, and Siglent would have to explicitly specify 1.0 or 2.0 to attempt mounts against those versions.  Conversely, if they're using something earlier then the protocol version used by default will depend on the kernel version they're using.


And that's just the version argument.  There's also the question of what password hashing mechanism the mount attempt should use, something that also differs by target server.  Now the number of option combinations you need to try has increased severalfold. 

There may be additional options that could make the difference between success and failure, and each of those would increase the number of option combinations to try by at least twofold.

With all that, you can see why Siglent likely chose to use the defaults when attempting the mount (without knowing the specific command line arguments they're using, I can't say anything definitive).

Mapping is NOT being done from command line. It is being done from GUI, and with code.. So that has to be changed and checked. Which is a bit more involved than what you say.
Mind you, it is not huge job, but it is a job and a test and a...
They literally have better (as in more important) things to do.

Yep, exactly.  Meanwhile, unless you're using this feature in a work setting, you might well be able to change the server settings to also support an SMB 1.x mount.

People asked Siglent for LAN mapping, and they did it... Not perfect, but hey, that can be fixed. But they listen, apparently.
Unlike others..

I wonder how long it'll be before nctnico changes his mind about Siglent ... 

[blurpy]

Now, I don't know what version of the Linux kernel they're using here, but this is what the mount.cifs manpage says about the version argument:

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.

/ # uname -a
Linux (none) 3.19.0-01-svn165603 #192 SMP PREEMPT Tue Aug 6 23:16:29 CST 2019 armv7l GNU/Linux

1.0 then

[SebastianH]

Hey guys,

I just received my SDS2104X Plus and am generally impressed with it (especially considering the price point). The only thing that immediately started to annoy me is the fan noise.

I saw the fan noise mentioned as something that could be improved (in this thread actually once), but I'm not sure whether my fan noise is even normal. I would highly appreciate if someone had a look at my short youtube video () to compare it with your own unit. I can clearly hear a sound that I would describe almost more like a rattle than a hum. Otherwise the fan noise is totally acceptable imho. When playing the video on my laptop I kind of don't hear it as clearly as in real life, so please keep this in mind). If this sound is normal it is definitively something that should be addressed by Siglent and is hence somewhat a "bug" (by all means: increase the price by $5 and use a different fan ).

If it wasn't for the warranty, I'd probably try to use some rubber to dampen the fan noise and possibly use a different fan altogether. But I'm not too keen on opening a still fairly expensive new piece of gear with warranty if I don't absolutely have to.

Thanks,
Sebastian

[tubularnut]

Yep, mine sounds like that, but I normally have a radio on, so don’t really notice it.

[Deichgraf]

Hi Martin,

Apart from this, maybe "yours" is indeed hard to fix or the internal priority for this is low.

No, it isn't:

Code: [Select]

umount /usr/bin/siglent/usr/mass_storage/net_storage
mount -t cifs -o vers=3.0,username=foo,password=bar,rw,soft //HostIP/Share /usr/bin/siglent/usr/mass_storage/net_share
++umgfoin.

Here comes a possible workaround to mount a SMB3 share of a Windows 10 computer with the SDS2000X+.

The scope has the nice feature to execute the siglent_device_startup.sh shell script, located on an inserted USB stick, on startup.
So here we can place something to mount a Windows 10 share with the right options as shown by umgfoin 

Here is a short step by step procedure:

1) Copy the code below into a text editor and modify it to your needs and setup:  IP-Address of the intended Win10 machine, the username and password (Windows) and the shared folder which should be mounted by the scope.

Code: [Select]

mount -t cifs -o vers=3.0,user=Winuser,password=Winpass,dir_mode=0777,file_mode=0777  //Win-IP/shared_folder  /usr/bin/siglent/usr/mass_storage/net_storage
2) Save the file as siglent_device_startup.sh.

3) On the Windows computer, the intended shared folder should have full access rights for Everyone (Full control, Write, Read - permission).

4) Copy the prepared siglent_device_startup.sh on a USB stick, insert it into the scope and power it up or reboot.

5) After boot up, remove the USB stick and press [Print] on the front panel. You should see a white notice string/message that a file/picture was stored on the net_storage ...

6) You can also check the mounted network share via [Save/Recall] and using the builtin File Manager to check the mounted windows folder =>  new SIGLENT folder.

Credits to umgfoin and wgoeo!

Have fun,
Deichgraf

[blurpy]

Hey guys,

I just received my SDS2104X Plus and am generally impressed with it (especially considering the price point). The only thing that immediately started to annoy me is the fan noise.

I saw the fan noise mentioned as something that could be improved (in this thread actually once), but I'm not sure whether my fan noise is even normal. I would highly appreciate if someone had a look at my short youtube video to compare it with your own unit. I can clearly hear a sound that I would describe almost more like a rattle than a hum.

That sound is very familiar. We had a discussion not long ago in the main thread:

One question - is the fan supposed to tick? I've read some complaints about noise, but mine ticks very fast, like a clock on speed.

It's nothing wrong with the fan it seems, they just chose one that ticks.

[SebastianH]

Good to know, thanks for the confirmation. I already know what will happen once the warranty is over (or -- more likely -- I don't care about the warranty anymore)

[kcbrown]

Bug report: when the scope is under significant load, it is largely unresponsive to the front panel controls, particularly the timebase and/or vertical sensitivity controls. 

To reproduce this, feed a 1 MHz signal into the scope on one channel.  Turn off all other channels.  Configure acquisition for a 200M buffer, and the trigger for rising edge and normal mode.  Set your timebase to 10 ms/div (so that the entire buffer is used -- these settings will result in a screen time coverage of 100ms).  Then enable zoom mode.

Now play with the timebase and vertical sensitivity controls on the front panel.  Notice how it will fail to recognize some of the movement of the controls when you move them even moderately quickly.

This is with the latest firmware (1.3.9R6), but seems to be the case with earlier firmware versions as well.

--

This shouldn't happen.  It's clear from the mouse handling that the scope is perfectly capable of dealing with input events in a timely fashion.  Movement of the mouse under the above conditions is smooth, so it's clear the scope is capable of recognizing a large number of input events in a relatively small amount of time.  Handling of the front panel should be the same way.  Now, I realize that some of the effects of the front panel may take some time to process and display, but events from the front panel should be buffered and those events merged together when possible.   For instance, if I move the timebase knob 6 clicks counterclockwise, I expect to see the time per division increase by a factor of 100 no matter how heavily loaded the scope is, no matter how quickly I moved the knob, and no matter how quickly it's able to update the display: it should buffer the events and merge them into a single change, and then apply that change.   This kind of predictability of the effects of knob movement is exactly why the timebase and vertical sensitivity knobs have detents in the first place!  By ignoring events from the front panel, the scope eliminates the predictability that one otherwise expects.

Now, I'm not expecting Keysight-like responsiveness or anything (nice as that would be).  Responsiveness is the speed with which changes become apparent on the screen.  But I am expecting the scope to at least put every front panel input event into a queue for processing, and to merge the effects together when possible so that it can present as smooth an experience as possible (so if I quickly turn the timebase knob counterclockwise by 6 detents, it might go straight from where it is to a time per division that's 100 times larger, without showing the intervening steps, depending on how often it's able to update the screen).  I don't know if the front panel generates interrupts when you use it, but if it doesn't then the scope should have a very high priority thread dedicated to reading the front panel and putting events from it into a queue.   And if it does, then obviously the interrupt handler should be queuing the events.  Save for when the scope is doing fast segment acquisition, which blocks all other operations, under no conditions should the scope miss events from the front panel.

[Deichgraf]

Bug report: when the scope is under significant load, it is largely unresponsive to the front panel controls, particularly the timebase and/or vertical sensitivity controls. 

To reproduce this, feed a 1 MHz signal into the scope on one channel.  Turn off all other channels.  Configure acquisition for a 200M buffer, and the trigger for rising edge and normal mode.  Set your timebase to 10 ms/div (so that the entire buffer is used -- these settings will result in a screen time coverage of 100ms).  Then enable zoom mode.

Now play with the timebase and vertical sensitivity controls on the front panel.  Notice how it will fail to recognize some of the movement of the controls when you move them even moderately quickly.

This is with the latest firmware (1.3.9R6), but seems to be the case with earlier firmware versions as well.

--

This shouldn't happen.  It's clear from the mouse handling that the scope is perfectly capable of dealing with input events in a timely fashion.  Movement of the mouse under the above conditions is smooth, so it's clear the scope is capable of recognizing a large number of input events in a relatively small amount of time.  Handling of the front panel should be the same way.  Now, I realize that some of the effects of the front panel may take some time to process and display, but events from the front panel should be buffered and those events merged together when possible.   For instance, if I move the timebase knob 6 clicks counterclockwise, I expect to see the time per division increase by a factor of 100 no matter how heavily loaded the scope is, no matter how quickly I moved the knob, and no matter how quickly it's able to update the display: it should buffer the events and merge them into a single change, and then apply that change.   This kind of predictability of the effects of knob movement is exactly why the timebase and vertical sensitivity knobs have detents in the first place!  By ignoring events from the front panel, the scope eliminates the predictability that one otherwise expects.

Now, I'm not expecting Keysight-like responsiveness or anything (nice as that would be).  Responsiveness is the speed with which changes become apparent on the screen.  But I am expecting the scope to at least put every front panel input event into a queue for processing, and to merge the effects together when possible so that it can present as smooth an experience as possible (so if I quickly turn the timebase knob counterclockwise by 6 detents, it might go straight from where it is to a time per division that's 100 times larger, without showing the intervening steps, depending on how often it's able to update the screen).  I don't know if the front panel generates interrupts when you use it, but if it doesn't then the scope should have a very high priority thread dedicated to reading the front panel and putting events from it into a queue.   And if it does, then obviously the interrupt handler should be queuing the events.  Save for when the scope is doing fast segment acquisition, which blocks all other operations, under no conditions should the scope miss events from the front panel.

It's running linux and the top command is available in the compiled busybox ... so telnet'ing into the scope and checking the kernel / main.app usage is possible.

I checked it a week ago ... normal trace display (1 - 4) will show ~15% load, and with FFT enabled I could see ~63%

[oz2cpu]

is there a general: SIGLENT Bugs / Missing Features / Feature Requests
thread ?
or at least one for their Power supplies ?
i spend quite along time searching this forum, but dont find it,
this thread is for the SCOPE SDS2000 only..
I got a few ideas for the SPD3303 and even for a brand new model, I would love to purchase from them, if available,
and i am sure many other users would feel the same way. it could be interesting to ask the users what they feel / need / wish for

[umgfoin]

Here comes a possible workaround to mount a SMB3 share of a Windows 10 computer with the SDS2000X+.

The scope has the nice feature to execute the siglent_device_startup.sh shell script, located on an inserted USB stick, on startup.
So here we can place something to mount a Windows 10 share with the right options as shown by umgfoin 

/SNIP

Hi Deichgraf,
there's a simpler approach:
While looking into the instrument's main.app, I recognized, not much sanitizing effort is applied, while parsing Net-storage-dlg's user-input:
This opens an effective way for parameter-injection to the subsequent mount-calls:

So, basically, it's sufficient to add

Code: [Select]

,vers=3.0 directly after username (or password) in the respective input controls...

++umgfoin.

[umgfoin]

Yep, exactly.  Meanwhile, unless you're using this feature in a work setting, you might well be able to change the server settings to also support an SMB 1.x mount.

It is always easy to say other peoples job is easy....

Good afternoon gentlemen,
I didn't expect my comment to lead into a philosophical discussion.  :-)

Sure your points of concern are legitmate as an engineer's general attitude.
In this specific case, I'm having sufficently deep insight:
The discussion SMB1 compatibility vs. security has been lead time ago and the reason why current implementations should refrain from using SMB1 are convincing.
However, here it is not about disabling CIFS/SMB1-support, but enabling higher versioned dialects for those that support or rely on it (e.g. any recent  (>=1803) std. WIN10 box uninstalls SMB1-support silently, if no SMB1 traffic is detected within 14d). NT LM 0.12 & POSIX2 aka CIFS will still be available in my shell-example shown above.

This instrument currently builds upon Linux kernel 3.19.0, thus it defaults to "negotiate up to SMB1.0"-behaviour unless you allow it to offer higher versioned dialects.
From a developer's point of view and under the given situation it is all about one single additional const char* option-flag, regardless of the implementation method chosen (Linux API, shell-call).
@2N3055: Linux Programmer's Manual: MOUNT(2).
This fact was the reason for my laconic comment.

Sure, you still won't satisfy all possible client/server combinations out there, but you cover the most common combinations at the time being.
Imho, it is not desirable to limit a contempory network-client to a deprecated protocol-revision.
 
I greatly honour Siglent's effort to add features after product-release, especially as the decision to add a SMB-client to a rolled out emb. device is something many manufacturers would consider to be possibly painful and thus refrain from doing it. I clearly prefer Siglent's approach.

Just my two cts.
++umgfoin.

[2N3055]

Here comes a possible workaround to mount a SMB3 share of a Windows 10 computer with the SDS2000X+.

The scope has the nice feature to execute the siglent_device_startup.sh shell script, located on an inserted USB stick, on startup.
So here we can place something to mount a Windows 10 share with the right options as shown by umgfoin 

/SNIP

Hi Deichgraf,
there's a simpler approach:
While looking into the instrument's main.app, I recognized, not much sanitizing effort is applied, while parsing Net-storage-dlg's user-input:
This opens an effective way for parameter-injection to the subsequent mount-calls:

So, basically, it's sufficient to add

Code: [Select]

,vers=3.0 directly after username (or password) in the respective input controls...

++umgfoin.

Briliant!

[2N3055]

Yep, exactly.  Meanwhile, unless you're using this feature in a work setting, you might well be able to change the server settings to also support an SMB 1.x mount.

It is always easy to say other peoples job is easy....

Good afternoon gentlemen,
I didn't expect my comment to lead into a philosophical discussion.  :-)

Sure your points of concern are legitmate as an engineer's general attitude.
In this specific case, I'm having sufficently deep insight:
The discussion SMB1 compatibility vs. security has been lead time ago and the reason why current implementations should refrain from using SMB1 are convincing.
However, here it is not about disabling CIFS/SMB1-support, but enabling higher versioned dialects for those that support or rely on it (e.g. any recent  (>=1803) std. WIN10 box uninstalls SMB1-support silently, if no SMB1 traffic is detected within 14d). NT LM 0.12 & POSIX2 aka CIFS will still be available in my shell-example shown above.

This instrument currently builds upon Linux kernel 3.19.0, thus it defaults to "negotiate up to SMB1.0"-behaviour unless you allow it to offer higher versioned dialects.
From a developer's point of view and under the given situation it is all about one single additional const char* option-flag, regardless of the implementation method chosen (Linux API, shell-call).
@2N3055: Linux Programmer's Manual: MOUNT(2).
This fact was the reason for my laconic comment.

Sure, you still won't satisfy all possible client/server combinations out there, but you cover the most common combinations at the time being.
Imho, it is not desirable to limit a contempory network-client to a deprecated protocol-revision.
 
I greatly honour Siglent's effort to add features after product-release, especially as the decision to add a SMB-client to a rolled out emb. device is something many manufacturers would consider to be possibly painful and thus refrain from doing it. I clearly prefer Siglent's approach.

Just my two cts.
++umgfoin.

I know how API works. That is not a problem, catching all the errors from all combinations and testing that is the actual work.

I do want to apologize for knee jerk reaction, I'm highly allergic to the "that is easy" statement (being the old fart that was on the receiving side one too many times   ), so I might have been a bit more abrasive than i should have been. Sorry if I was. I do understand you act from a good place.
And I do not say it is not an issue and that it shouldn't be made better. It should. Siglent is making great effort to play in the big league and they should strive for the best.
But priorities exists for a reason, and this scope is not something that would (should) be facing hostile network so from risk triad calculated, risk is rather small. I do like that this is openly discussed. So users know not to do something naive..
AFAIK Siglent is aware..

And in meantime, your little trick works like charm..

[tautech]

is there a general: SIGLENT Bugs / Missing Features / Feature Requests
thread ?
or at least one for their Power supplies ?
i spend quite along time searching this forum, but dont find it,
this thread is for the SCOPE SDS2000 only..
I got a few ideas for the SPD3303 and even for a brand new model, I would love to purchase from them, if available,
and i am sure many other users would feel the same way. it could be interesting to ask the users what they feel / need / wish for

Yes:
https://www.eevblog.com/forum/testgear/siglent-technical-support-join-in-eevblog/

Some of their product threads are listed in the OP however none for any of the 3ch PSU's of which there's been 3 series over the years. SDP3303X-E has been their most popular.

[Deichgraf]

Here comes a possible workaround to mount a SMB3 share of a Windows 10 computer with the SDS2000X+.

The scope has the nice feature to execute the siglent_device_startup.sh shell script, located on an inserted USB stick, on startup.
So here we can place something to mount a Windows 10 share with the right options as shown by umgfoin 

/SNIP

Hi Deichgraf,
there's a simpler approach:
While looking into the instrument's main.app, I recognized, not much sanitizing effort is applied, while parsing Net-storage-dlg's user-input:
This opens an effective way for parameter-injection to the subsequent mount-calls:

So, basically, it's sufficient to add

Code: [Select]

,vers=3.0 directly after username (or password) in the respective input controls...

++umgfoin.

Hi umgfoin, (bavarian?)

thanks for sharing your research results on sniffing through the main.app and the nice outcome / side effect
So they put the dialog input directly into a (shell) system call with mount but without any encapsulation / quotes on these strings!?

meanwhile ... copying main.app for inspection 

[2N3055]

Here comes a possible workaround to mount a SMB3 share of a Windows 10 computer with the SDS2000X+.

The scope has the nice feature to execute the siglent_device_startup.sh shell script, located on an inserted USB stick, on startup.
So here we can place something to mount a Windows 10 share with the right options as shown by umgfoin 

/SNIP

Hi Deichgraf,
there's a simpler approach:
While looking into the instrument's main.app, I recognized, not much sanitizing effort is applied, while parsing Net-storage-dlg's user-input:
This opens an effective way for parameter-injection to the subsequent mount-calls:

So, basically, it's sufficient to add

Code: [Select]

,vers=3.0 directly after username (or password) in the respective input controls...

++umgfoin.

Hi umgfoin, (bavarian?)

thanks for sharing your research results on sniffing through the main.app and the nice outcome / side effect
So they put the dialog input directly into a (shell) system call with mount but without any encapsulation / quotes on these strings!?

meanwhile ... copying main.app for inspection 

No they did not "put the dialog input directly into a (shell) system call ".. That is Linux filesystem API, same one that shell calls... But it accepts pretty much same mount flags as you would pass as a options on a command line when calling mount from the shell.