Wifi Siglent SDS1104X-E workaround SSID/PSK with Spaces and Special Characters

[1audio]

That's not just non-intuitive, it different from almost everything I can think of, except my very vintage NI GPIB-ENET ethernet adapter (which used RARP). Working that way can cause issues since the DHCP server won't see a renewal and could hand out that IP to something else later.

I'll do some more testing today. It seems to have trouble with Google's NTP server on boot. but on a manual access later it works. I can try others but Google's (216.239. 35.0) should be a good international target without the usage limits some of the others have.

This network stuff is pretty basic and old. Maybe the processor vendor's linux sources are (20 years) out of date?

Maybe Siglent needs a beta test group to catch some of this stuff before wide release.

Everything else seems to work pretty well.

[tv84]

A little trap is leaving DCHP ON whereas you should only use it to initially find your LAN IP and then set a unique IP for the scope, disable DCHP and Save the new IP.

I wouldn't call it a trap. It's a bad, bad implementation. I can't understand how this is not caught up by the betatester group! 

[tautech]

A little trap is leaving DCHP ON whereas you should only use it to initially find your LAN IP and then set a unique IP for the scope, disable DCHP and Save the new IP.

I wouldn't call it a trap. It's a bad, bad implementation. I can't understand how this is not caught up by the betatester group! 

Maybe but it has been like this for 8 years and a change in Siglent's philosophy and implement it in all their instruments will take a massive push from everyone whose input they value and respect.

First instrument that I discovered this was a 2013 SDS2304 which was maybe their first and certainly my first instrument with LAN so I've learned to live with it.

However just what is the industry standard if there is such a thing ? 
While DCHP is set to ON and the instrument is rebooted is negotiating a new IP a crime ?
Or if we press Save (a negotiated or user set IP) should DCHP be automatically disabled so not to be ON at boot ?

[Ringmodulator]

Using the DHCP assigned adress, store it and then turning DHCP on the scope off, can lead to a situation, where the DHCP reassigns this adress to another device when the scope is not active.

Then you have two devices trying to use the same ip adress as soon as the scope is active again.

[tautech]

Using the DHCP assigned adress, store it and then turning DHCP on the scope off, can lead to a situation, where the DHCP reassigns this adress to another device when the scope is not active.

Then you have two devices trying to use the same ip adress as soon as the scope is active again.

Quite so.

However for those that have little idea of IP stuff DCHP ON allows negotiation of a correct IP address which then they can assign a higher IP address to avoid conflict and turn DCHP OFF.
Not all of us can remember our IP address, subnet or gateway so for ease of use DCHP allows us to get it mostly right.

[2N3055]

DHCP is quite well standardized.

You use it  when you don't want to manage all IP addresses manually.

When enabled, it will contact DHCP server, that will give it IP address and other parameters to correctly setup TCP/IP stack.
Correct info has to  be previously setup in a DHCP server. DHCP server has pools of addresses that it can hand out to hosts.

Once server gives you one of the addresses from the Pool, that address comes with a lifetime period (lease period). Inside that lifetime  period, server remembers what address it has "leased" to you, and client will get that  same address all the time, as long as it keeps reconnecting to network regularly.  If a client, doesn't get connected to network for time longer that leased time, server "reclaims" lease and puts IP back to pool for others to use...

When deciding on addressing policy on your network, you need to set ranges to be used for static addresses and which ranges will be used for DHCP pools. They should never overlap.

On DHCP server (one that is fully featured) you can also create permanent leases. That way you practically have static addresses but they get centrally managed.

DHCP should never have any interaction with any other higher level network protocols. It happens early in TCP/IP stack initialization, when binding IP address to network interface.

NTP client running at startup should have triggered start by completion of TCP/IP initialization, otherwise timeouts are likely.

I'm seriously thinking of creating a whitepaper "TCP/IP simplified for T/M users: How to connect things in a lab  via TCP/IP networks without making a big deal out of it.."

[1audio]

DHCP has been standardized and common on pc's and phones for 20 years. It's pretty fundamental which is why most people never encounter issues. The default stack from the processor vendor should handle this all seamlessly. Turning off DHCP really should be a special exception for use when exposing the web server to the internet for example. (Probably not a good idea here).

[2N3055]

DHCP has been standardized and common on pc's and phones for 20 years. It's pretty fundamental which is why most people never encounter issues. The default stack from the processor vendor should handle this all seamlessly. Turning off DHCP really should be a special exception for use when exposing the web server to the internet for example. (Probably not a good idea here).

Yes exposing anything to Internet is not a good idea.

But there are many reasons to keep IP addresses fixed. How do you know which one is which today?
All you need is an text document to keep track which one is which and what addresses are used up.
Stick an IP to the front of the instrument and you are good..
And then you add them to DNS and you address your scope as "3104T" not 192.168.10.13. Or "thebeast"  for a 6GHz scope 

So there is a reason for static and there is a reason for DHCP...

[blurpy]

It sounds to me like this broke in the newest firmware. Works like expected on mine at 6.1.35R2. I can shut down the scope and start it again and it keeps the DHCP settings.

So 2 new bugs introduced:

1. Wifi is gone
2. DHCP forgets its settings

[tautech]

It sounds to me like this broke in the newest firmware. Works like expected on mine at 6.1.35R2. I can shut down the scope and start it again and it keeps the DHCP settings.

So 2 new bugs introduced:

1. Wifi is gone
2. DHCP forgets its settings

Yes WIFi is broken and reported as such.
DCHP is working correctly and will retain IP settings when DCHP = OFF.

[modoran]

What is wrong with DHCP ?  There is no issue for me, I keep DHCP ON and setup my dhcp server on my MikroTik router to always give the same IP address to the scope based on MAC. The IP cannot be assigned to anything else. I even assigned a static domain name to my scope "siglent.lan" to not forget it's IP

wifi is the only thing which does not work.

For NTP I also use ntp server hosted on my router, scope does not go to the internet at any time.

[blurpy]

DCHP is working correctly and will retain IP settings when DCHP = OFF.

You can't say DHCP is working correctly if you have to turn it off.
But it works for me in the old firmware with DHCP on, so I'm just basing this on what 1audio experienced after upgrading.

[Ringmodulator]

My take on this:

If the wifi router is under your control, create a permanent lease for the scope in the dhcp on the router, based on the mac adress.
Or use fixed a ip address, which is outside the dhcp range in the router.

Where the wifi router is not under your control, e.g. work enviroment, educational enviroment, service work at customer site, just use the dhcp service on the scope and leave it on.

Yes, the ip may change from time to time  and you have to update it for the http browser then.

Chris

[1audio]

The problem is that the "DHCP" only requests an IP address when manually prompted. As in not dynamic. Its more of a helper in setting a manual IP address than DHCP. However if you get an address from DHCP then it has a lease with an expiration and needs to be renewed. Usually you set a block for static IP addresses to prevent the DHCP server from issuing those addresses. not following these rules will cause problems.

[bingo600]

Usually you set a block for static IP addresses to prevent the DHCP server from issuing those addresses. not following these rules will cause problems.

Tehcnically you're right , but people that (mis)Uses/understand this: Are usually saved by the fact , that most (decent) dhcp  servers do a ping towards the address they're about to hand out as a new lease , and will not hand it out if there is an answer.

That "unfortunately" saves your butt , and will not get you to think about what is really happening.

Kinda' like proxy arp saved a lot of butt's when they forgot to set a default gateway.
Network ppl. had a hard time convincing users to remember to also set the def-gw... Why they said , it works wo. 
Luckily for security reasons , proxy arp was removed as default from ie. Cisco router interfaces , a while ago.
 
/Bingo

[2N3055]

Usually you set a block for static IP addresses to prevent the DHCP server from issuing those addresses. not following these rules will cause problems.

Tehcnically you're right , but people that (mis)Uses/understand this: Are usually saved by the fact , that most dhcp (decent) servers do a ping towards the address they're about to hand out as a new lease , and will not hand it out if there is an answer.

That "unfortunately" saves your butt , and will not get you to think about what is really happening.

/Bingo

Well that is not part of the DHCP standard. Windows DHCP does it (DHCP server side IP conflict detection) for instance.
But DHCP standard does not mandate it. And it is a bad practice to rely on it.
DHCP has a list of leases and if IP is not handed out and it is in a pool, it's available. That is only information that is sure.

IP conflict detection is responsibility of host itself, and ARP is used for it not ICMP...
It is done this way specifically to protect from badly configured DHCP server mass configuring many duplicate IP addresses to DHCP client (to prevent ARP storms).
So the host should refuse to configure with DHCP address if it detects IP is already in use with MAC different than his.
In which case it can default to internal autoconfigure IP, or leave IP unconfigured.
See RFC5227....

I agree that it is one of those "fixes" that only promote ignorance and misconfiguration. I prefer clear error messages that lead to fixing all problems and having network in perfect  shape.

But all this "let's make it easy for people that don't understand it" makes companies do all this "simplifying" that only promote confusion. But, it's a sign of times , I guess.

[bingo600]

IP conflict detection is responsibility of host itself, and ARP is used for it not ICMP...
It is done this way specifically to protect from badly configured DHCP server mass configuring many duplicate IP addresses to DHCP client (to prevent ARP storms).
So the host should refuse to configure with DHCP address if it detects IP is already in use with MAC different than his.
In which case it can default to internal autoconfigure IP, or leave IP unconfigured.
See RFC5227....

I know the above 
But you'd need to on the same L2 to "ARP" , lot's of Corp DHCP servers aren't.
So they "just send a ping".

But yes i've also seen a M$ come up w. the Duplicate IP detected - Based on  ARP.

I actually think the ISC-DHCP server might do the same (ping) , i haven't verified though.

/Bingo