SDS1104X-E Wifi needs router SSID broadcast all the time?

[pOM]

I set up WiFi on my SDS1104X-E and today received the TP Link dongle.  But when setting it up in the Utility I/O selections, during the "manual scan" it did not detect my wireless (wifi) network.  Ah, yes, the router SSID is turned off.  Switched the SSID back on, the scope eventually listed it, entered the password, connected, and confirmed that I could control the scope from my computer.  Great.  But when I then turned the SSID off again, during that same session, it lost the WiFi network connection.  (This was tested several times to confirm.)

EDIT:  I should add that when the scope is connected to the WiFi network, I can turn off the scope WiFi, and then back on, and it will automatically connect.  Similarly, if I turn off the scope altogether (power down), then start it up again, it reconnects.  All, of course, only if the router SSID is being broadcast. 

I know that laptops and tablets that have been connected to the network will automatically connect again even when the SSID is off (which is how I normally have it).

Should the scope not also be able to connect without the SSID being broadcast as long as the SSID and password are in the dialog box?

Should the scope lose the connection when the SSID is turned off during a session?

Am I doing something wrong, or missing a step or two. 

 

[tautech]

Am I doing something wrong, or missing a step or two.

Possibly.
Do you initially have DHCP set to ON, use the discovered IP or entered a unique IP and saved it ?

Within the I/O menu you can toggle between LAN and WLAN and each have their own IP Set which you can auto-discover with DHCP or use a previously saved IP.

I like to just plugnplay and let DHCP do its thing to initially get me on the correct subnet and then assign instruments to within a preferred IP range so while doing some checks for you DHCP found the previous IP that had been manually assigned to my 1104X-E and the router had remembered it.

Once saved and then DHCP turned to OFF the unique IP is set in both WLAN and LAN settings and while the WiFi Set SSID and PW are correct it should connect without issue although I did not disable SSID to check to know 100% this will work for you.

So I believe if you have the WLAN IP Set saved WIFI should not need SSID for WiFi to connect.
Interesting problem and interested if you can crack it.

[pOM]

Do you initially have DHCP set to ON, use the discovered IP or entered a unique IP and saved it ?

Yes.  In both LAN and WLAN, when the IP Address appeared in the box at the upper left, it was saved ("Save" button).

After connecting via WiFi and turning off DHCP, the same IP Address was displayed as when DHCP was on and the IP Address had been "Saved".  The DHCP status doesn't seem to have any effect on the connection afterwards.

. . . although I did not disable SSID to check to know 100% this will work for you.

Therein lies the issue, or so it seems; toggling the SSID affects the WLAN connection.  If the router SSID is turned off, the scope WLAN becomes disconnected and if the SSID is then turned back on, WLAN is automatically reconnected (after a short wait). 

EDIT: It's as if the scope is constantly checking that it's still linked to the same router (SSID), and if the SSID disappears it disconnects. (Not sure if this would be how the WiFi linking could work.)

[borjam]

I know that laptops and tablets that have been connected to the network will automatically connect again even when the SSID is off (which is how I normally have it).

That's not a good idea. It won't give any additional security and it can lead to more interference problems.

Let your neighbors know where your network is and give them the opportunity to select a different channel.

[pOM]

borjam

Yes, I appreciate the security and interference aspects of the SSID; however, the question is whether or not the SSID determines if the scope can connect to the WLAN.   Is this something built into the SDS1104X-E WiFi software, or is it something I'm missing in configuring the scope's WLAN settings?  As noted earlier, no other wifi-capable electronics I've tried requires the SSID to remain on after initially identifying the network and logging in.

[pOM]

Was hoping some members who are using wifi (WLAN) to link the scope to a computer could try turning off SSID and see if there's the same loss of connection.  I just want to know if this is indeed how the scope works.  Anyone. . . ?

In the meantime I've noticed what might be another extra step that's needed, in this case, to use the computer-based interface.

After starting up the scope this morning, I went to the WLAN I/O page, and initiated "Connect".  The link was established, and the NTP succeeded in syncing the time.  However, I could not open the computer user interface using the exact IP that I had used before, and that the I/O screen was still displaying.  The reason, it seems, was that DHCP was off.  I had to turn DHCP back on and save it, and then I was able to get the interface at the computer.  Looks as if the IP address, even though the same, has to be resaved each time to be able to use the web-based interface. 

[tubularnut]

Was hoping some members who are using wifi (WLAN) to link the scope to a computer could try turning off SSID and see if there's the same loss of connection.  I just want to know if this is indeed how the scope works.  Anyone. . . ?

In the meantime I've noticed what might be another extra step that's needed, in this case, to use the computer-based interface.

After starting up the scope this morning, I went to the WLAN I/O page, and initiated "Connect".  The link was established, and the NTP succeeded in syncing the time.  However, I could not open the computer user interface using the exact IP that I had used before, and that the I/O screen was still displaying.  The reason, it seems, was that DHCP was off.  I had to turn DHCP back on and save it, and then I was able to get the interface at the computer.  Looks as if the IP address, even though the same, has to be resaved each time to be able to use the web-based interface.

I can confirm that hiding the SSID does cause reconnection issues for the scope. However, I do not believe it is the scopes problem, but most likely the dongle itself. The dongle negotiates the connection purely under instruction from the scope, and the dongle will look for the SSID beacon from your router, if it can't see it, it won't connect. Dongles can be quite bad at this, as they will have minimal hardware/firmware inside to work. (Unfortunately I do not have another non-native WiFi device that I can try the dongle on)

Hiding the SSID was never part of the original 802.11 specification, is not compulsory for manufacturers to implement looking for a hidden ID, but it's just become commonplace over the years.

I also do not understand your obsession with hiding your SSID?  If you have mobile devices connected, like phones, laptops etc, when you take those away from that location, they will be constantly 'pinging' everything around them to see if that WiFi network is still there. This is not only an overhead for your device, but anyone out there scanning for networks, will pick that up, and think, "Oh, why is this person hiding their network, what are they hiding??" so you draw more attention to yourself.

As to your IP issue, have you reserved the IP address on your router? If you haven't and relying on just having it saved on your scope, you can have issues reconnecting once your original DHCP lease time expires (e.g. overnight) even if it by chance it just happens to come up with the same IP again.

[pOM]

I can confirm that hiding the SSID does cause reconnection issues for the scope. However, I do not believe it is the scopes problem, but most likely the dongle itself. The dongle negotiates the connection purely under instruction from the scope, and the dongle will look for the SSID beacon from your router, if it can't see it, it won't connect.

Thanks for the confirmation (exactly what I was seeking!) and for the clarification of the role of the dongle.  It makes sense; the dongle operates in response to the scope, and the scope feeds it the SSID and IP to use to make the connection.  As the dongle doesn't "see" the SSID, it doesn't know better and doesn't connect, or loses the existing connection.

I also do not understand your obsession with hiding your SSID?

Not at all; more of an old habit.  It was off for a long time, and I never had any issue with devices connecting, and maintaining connections with the SSID off, so the scope experience was new and I was wondering if it was abnormal.

As to your IP issue, have you reserved the IP address on your router? If you haven't and relying on just having it saved on your scope, you can have issues reconnecting once your original DHCP lease time expires (e.g. overnight) even if it by chance it just happens to come up with the same IP again.

That's probably what's happening.

I have not yet reserved the address.  I believe reserving the address was mentioned by tautech earlier. 

My use of the scope often involves long period of monitoring but it's not necessary for me to be watching the scope continuously.  Using the web connection, I can have the scope display on the computer while also doing other work with the computer.  Also, the scope is moved around somewhat, and being able to easily/automatically (re-)establish the WiFi connection, and access the scope from the computer location is a big advantage.

The responses have helped immensely.  I now have not only answers to my questions, but also a much better understanding of things like WiFi connections and the use of the dongle, as well as the concept of the "lease".  This is all very much appreciated. 

If I wasn't clear before, and gave the impression I was obsessed with "my way", I sincerely apologize. 

I've had the SSID on for a couple of days and the wifi connecting is working fine.  I'll have to see how to reserve the IP address on the router, but would imagine it can be done -- another learning experience.

Thanks again!

[tautech]

I have not yet reserved the address.  I believe reserving the address was mentioned by tautech earlier. 

FYI, neither did I. Our router apparently remembers a IP as its DHCP lease doesn't expire.
I imagine only when that IP is required for another device only then would the remembered IP be lost.

[Monkeh]

It makes sense; the dongle operates in response to the scope, and the scope feeds it the SSID and IP to use to make the connection.  As the dongle doesn't "see" the SSID, it doesn't know better and doesn't connect, or loses the existing connection.

It feeds it a BSSID, and the dongle has nothing to do with the IP. A bug or simple lazy implementation on the scope means it has no idea what the BSSID is. Perhaps they're waiting for beacons instead of actively sending probe requests.

[tubularnut]

I have not yet reserved the address.  I believe reserving the address was mentioned by tautech earlier. 

FYI, neither did I. Our router apparently remembers a IP as its DHCP lease doesn't expire.
I imagine only when that IP is required for another device only then would the remembered IP be lost.

I actually tried this out by setting my DHCP lease time to 1 minute. Then on the scope, I let it acquire an IP address by DHCP, saved it, then turned off DHCP, and shut down the scope,

After a few minutes, booted up the scope, it acquired the network, and synced with NTP, however, I could not reach the scope via the browser??

By pure chance, another device had grabbed the same IP address, and was responding to my attempts to get to it's web interface, which of course it didn't have!

So DHCP can often 'just work', sometimes it really screws things up 

[tautech]

I have not yet reserved the address.  I believe reserving the address was mentioned by tautech earlier. 

FYI, neither did I. Our router apparently remembers a IP as its DHCP lease doesn't expire.
I imagine only when that IP is required for another device only then would the remembered IP be lost.

I actually tried this out by setting my DHCP lease time to 1 minute. Then on the scope, I let it acquire an IP address by DHCP, saved it, then turned off DHCP, and shut down the scope,

After a few minutes, booted up the scope, it acquired the network, and synced with NTP, however, I could not reach the scope via the browser??

By pure chance, another device had grabbed the same IP address, and was responding to my attempts to get to it's web interface, which of course it didn't have!

So DHCP can often 'just work', sometimes it really screws things up 

Yes of course if the IP was a low value. For mine it was a value set a couple of years back, IIRC 192.168.0.142.
142, why, IDK it was just a # that came into my head at the time but purposely set high to reduce the likelihood it would be required by another device and obviously that DHCP lease has never been broken so it just found it again.
It's good practice to have all your instruments grouped together, say in the 150-200 IP range. Most routers allow for 254 unique address on the same subnet.

[tubularnut]

My DHCP range starts goes from 100 to 200, I assign static addresses below 100 to household items, and above 200 to lab equipment. Any adhoc or new stuff picks up DHCP

The assigned address I tested was 113, and only 102 was in use below that, so it wasn't just a case of next available address.

[Monkeh]

I have not yet reserved the address.  I believe reserving the address was mentioned by tautech earlier. 

FYI, neither did I. Our router apparently remembers a IP as its DHCP lease doesn't expire.
I imagine only when that IP is required for another device only then would the remembered IP be lost.

I actually tried this out by setting my DHCP lease time to 1 minute. Then on the scope, I let it acquire an IP address by DHCP, saved it, then turned off DHCP, and shut down the scope,

After a few minutes, booted up the scope, it acquired the network, and synced with NTP, however, I could not reach the scope via the browser??

By pure chance, another device had grabbed the same IP address, and was responding to my attempts to get to it's web interface, which of course it didn't have!

So DHCP can often 'just work', sometimes it really screws things up 

Presumably, if their DHCP stack isn't crap (.. which is a stretch), not only was that lease expired, but you actively released it. So DHCP working normally, user expectations at fault.

They invented this crazy system called DNS some time back in the 1980s which is intended to solve these problems.

[pOM]

tubularnut

That's interesting. If I understand correctly, after rebooting the scope it connected with the same IP, so the IP was okay for that; however, it wasn't good for connecting the browser.  That's similar to what I experienced.  When I turned DCHP back on, that enabled browser access (see below).

tautech

I am at a disadvantage, not being familiar with the wireless system, IP addresses, leases etc. 

Since I started with the dongle, the IP address has remained the same, based on the WLAN display on the scope.  I would imagine that's involved with the scope being able to reconnect when it's turned on.  I haven't had a problem with that aspect since leaving the SSID on. 

However, as mentioned, after the scope is "on-line", I cannot reach it from the computer (using the same IP address) to open the scope display on the monitor; I have to turn DCHP back on (if it was off, which has been the case).  When I do that, the IP doesn't change, but now I can connect the computer to the scope via that same IP address. 

I recall the suggestion was to keep the DCHP off after saving it; perhaps not in this case?  If I leave both the SSID and DCHP turned on, are there any downsides?

[tubularnut]

Presumably, if their DHCP stack isn't crap (.. which is a stretch), not only was that lease expired, but you actively released it. So DHCP working normally, user expectations at fault.

They invented this crazy system called DNS some time back in the 1980s which is intended to solve these problems.

Yes, I know I forced a release, that was my intention. It gets renegotiated after 50% of the lease time, so 30 seconds, and released after 1 minute for use by others.

I was simply demonstrating (quite fortunately) that having turned off DHCP on the device, so it is static, but not reserving that same address on the router, it can give you problems.

[tautech]

On ~ our 4th ISP supplier router and them all different. 
Some ISP suppliers PW protect them so users don't bork settings which is the case for our current router.

Everyone likes to have their own methods of assigning leases and I respect that but personally don't bother and just set instruments into a high range, disable the instruments DHCP and let DHCP sort out all the other stuff at low IP #'s.
Hasn't bitten us yet. 

I recall the suggestion was to keep the DCHP off after saving it; perhaps not in this case?  If I leave both the SSID and DCHP turned on, are there any downsides?

Yes, the router will assign the scope a new IP.
Instead set the scopes IP higher where it's unlikely to be used by another device and even if the DHCP lease expires the scope is telling the router 'this is my IP'. Then the scopes IP should be locked it stone where it can be accessed by your PC whenever you want and you should even be able to use a browser bookmark to access it quickly.

[Monkeh]

Instead set the scopes IP higher where it's unlikely to be used by another device and even if the DHCP lease expires the scope is telling the router 'this is my IP'.

By what mechanism do you suggest it's doing this? ARP does not count - DHCP does not rely on ARP tables to assign addresses, and most servers (and many clients) do not attempt to verify an address is free before using it.

Either assign an IP outside of the DHCP range, reserve an address with the DHCP server, or accept DHCP use and use DNS to address the device. The latter is probably not an option because 40 years later, people still don't use DNS..

[tautech]

Instead set the scopes IP higher where it's unlikely to be used by another device and even if the DHCP lease expires the scope is telling the router 'this is my IP'.

By what mechanism do you suggest it's doing this? ARP does not count - DHCP does not rely on ARP tables to assign addresses, and most servers (and many clients) do not attempt to verify an address is free before using it.

Either assign an IP outside of the DHCP range, reserve an address with the DHCP server, or accept DHCP use and use DNS to address the device. The latter is probably not an option because 40 years later, people still don't use DNS..

For the scope in question DHCP must be OFF. Then if the IP# is high enough not to be needed by another device the risk of the same IP being assigned to another device is low.
Now this is not the perfect solution as instead reserving that IP in the router would be however for those that either don't have the skill or can't access their router settings it serves as a satisfactory method for reliable connection at the same IP....well it has for us. YMMV

[Monkeh]

For the scope in question DHCP must be OFF.

And again I ask:

the scope is telling the router 'this is my IP'.

How?

Then if the IP# is high enough not to be needed by another device the risk of the same IP being assigned to another device is low.
Now this is not the perfect solution as instead reserving that IP in the router would be however for those that either don't have the skill or can't access their router settings it serves as a satisfactory method for reliable connection at the same IP....well it has for us. YMMV

Many implementations assign addresses randomly - hence why this is poor advice and indeed, YMMV. If you lack control over 'your' network, make one you actually control. And while you're at it, tell your ISP where they can stick it.

In this case, if one is going in and twiddling options like hiding their SSID, doing it properly is just a click or two away (assuming the router supports such, I never put it past consumer stuff to support useless options over useful).

[tautech]

For the scope in question DHCP must be OFF.

And again I ask:

the scope is telling the router 'this is my IP'.

How?

Then if the IP# is high enough not to be needed by another device the risk of the same IP being assigned to another device is low.
Now this is not the perfect solution as instead reserving that IP in the router would be however for those that either don't have the skill or can't access their router settings it serves as a satisfactory method for reliable connection at the same IP....well it has for us. YMMV

Many implementations assign addresses randomly - hence why this is poor advice and indeed, YMMV. If you lack control over 'your' network, make one you actually control. And while you're at it, tell your ISP where they can stick it.

In this case, if one is going in and twiddling options like hiding their SSID, doing it properly is just a click or two away (assuming the router supports such, I never put it past consumer stuff to support useless options over useful).

See all of reply #16.
I am fully aware it may not work for others however with our current router it's reliable and consistent.

Agreed, having your LAN fully configurable is by far the best solution however not all users have the skill or the access. For simplicity and WLAN connection with the TP Link dongle I only convey what has worked reliably for us with our current locked modem and scopes IP set and saved and scopes DHCP set to OFF.
Other modems may not offer permanent DHCP leases however our Ubiquity Cube seems to.

[Monkeh]

See all of reply #16.

I'm still looking for the answer as to how the scope is telling the router 'hey, I have this IP and you may not use it'.

FWIW, some particular language is used here:

  2.  Each server may respond with a DHCPOFFER message that includes an
      available network address in the 'yiaddr' field (and other
      configuration parameters in DHCP options).  Servers need not
      reserve the offered network address, although the protocol will
      work more efficiently if the server avoids allocating the offered
      network address to another client.  When allocating a new address,
      servers SHOULD check that the offered network address is not
      already in use; e.g., the server may probe the offered address
      with an ICMP Echo Request.  Servers SHOULD be implemented so that
      network administrators MAY choose to disable probes of newly
      allocated addresses.  The server transmits the DHCPOFFER message
      to the client, using the BOOTP relay agent if necessary.

  5. The client receives the DHCPACK message with configuration
     parameters.  The client SHOULD perform a final check on the
     parameters (e.g., ARP for allocated network address), and notes the
     duration of the lease specified in the DHCPACK message.  At this
     point, the client is configured.  If the client detects that the
     address is already in use (e.g., through the use of ARP), the
     client MUST send a DHCPDECLINE message to the server and restarts
     the configuration process.  The client SHOULD wait a minimum of ten
     seconds before restarting the configuration process to avoid
     excessive network traffic in case of looping.

As you're probably aware, almost everyone treats "SHOULD" as "DON'T BOTHER, SHE'LL BE RIGHT".

[pOM]

I don't have a lot of WiFi equipment, and of those I do have, it's rare that they are on at the same time, and that includes the scope as well. 

Maybe I can just leave the SSID and DHCP on, and deal with a changed IP address for the scope if/when it occurs.  As long as I know what's happening, and it doesn't become a problem, that's fine. 

[tautech]

I don't have a lot of WiFi equipment, and of those I do have, it's rare that they are on at the same time, and that includes the scope as well. 

Maybe I can just leave the SSID and DHCP on, and deal with a changed IP address for the scope if/when it occurs.  As long as I know what's happening, and it doesn't become a problem, that's fine.

The only problem is you will never know if/when the scopes IP changes whereas if you set it you can always access the scope at a known IP without needing to check the scope to see what it has become.
By just accepting what DHCP allocates without setting a unique address for the scope and saving it will amount to more work for you to find what the scopes IP has become. You may be able to live with that IDK.

Unfortunately we can't grab screenshots of the LAN or WLAN configurations to show typical setups as the scope's OS doesn't permit it presumably for security reasons. However photos can be taken. 

[pOM]

In that case, tomorrow, I'll try setting an IP address higher up in the range, save it (on the scope) and turn the DHCP off.  Main test will be after 24 hours (current lease time according to the router web page), to see if the connection and browser access can be resumed, when the scope is turned on again, without having to reset anything.  If that works for me, great.