Windows 10 won't connect to WiFi on my Draytek router - why?

[Chris Green]

I have a (mostly Linux) home network with a Draytek 2860n connecting
to the internet using VDSL. It all works well and much as expected.

Mostly visitors using MS Windows and Android seem to connect to my
WiFi OK too.

However it would seem that Windows 10 (and possibly some iPhones) are
failing to connect and I really can't see why.

I have a Windows 10 partition on my (normally Linux) laptop so I
booted that and tried, sure enough it fails to connect to the WiFi
saying 'incorrect password' or something like that. The password is
most definitely *not* incorrect, it's quite a simple one and thus easy
to enter without errors and I have tried more than once. I've also
checked that the password is what I think it is by looking in (linux)
Network Manager.

So, what might be the problem, I can't think of many possibilites, but
might it be one of the following:-

Win10 *is* connecting to the WiFi but not getting DHCP/DNS or
whatever and reports that as 'incorrect password'.

The password is too short and simple for Win10 to believe it
(seems a bit unlikely).

Something else.

Can anyone suggest how I might diagnose this? I'm very unfamiliar
with W10 and don't have a clue how to dig down and find what the
actual issue is.

--
Chris Green
·

[Graham J]

Chris Green wrote:
> I have a (mostly Linux) home network with a Draytek 2860n connecting
> to the internet using VDSL. It all works well and much as expected.
>
> Mostly visitors using MS Windows and Android seem to connect to my
> WiFi OK too.
>
> However it would seem that Windows 10 (and possibly some iPhones) are
> failing to connect and I really can't see why.
>
> I have a Windows 10 partition on my (normally Linux) laptop so I
> booted that and tried, sure enough it fails to connect to the WiFi
> saying 'incorrect password' or something like that. The password is
> most definitely *not* incorrect, it's quite a simple one and thus easy
> to enter without errors and I have tried more than once. I've also
> checked that the password is what I think it is by looking in (linux)
> Network Manager.
>
> So, what might be the problem, I can't think of many possibilites, but
> might it be one of the following:-
>
> Win10 *is* connecting to the WiFi but not getting DHCP/DNS or
> whatever and reports that as 'incorrect password'.

Typical MS illogical error reporting

>
> The password is too short and simple for Win10 to believe it
> (seems a bit unlikely).
>
> Something else.
>
> Can anyone suggest how I might diagnose this? I'm very unfamiliar
> with W10 and don't have a clue how to dig down and find what the
> actual issue is.
>

1. Reboot the Draytek router. I've known this help with many Windows
clients when other clients do connect OK.

2. Is the Draytek router fully up to date with the latest firmware? If
not, resolve this before proceeding.

3. Is the Draytek router at Factory configuration apart from the
settings necessary to achieve the internet connection? Specifically
have you set the correct VLAN parameters for VDSL? Has anybody changed
the firewall settings away from the default? If you are uncertain about
any of these things, factory reset the router and apply only the minimum
settings necessary to bring up the internet connection.

4. Using any browser and any other computer look at what the router
reports about the wireless clients (look at the station list). It
should show more about how the connection is failing. If you're not
familiar with managing the Draktek router from a browser, please learn.
We can help.

5. Temporarily disable the WiFi on the W10 machine and connect it to the
router via an Ethernet cable, making sure there are no other networking
components along this connection to confuse the issue. (I've seen
problems with Engenius wireless bridges used to extend a LAN to a
distant building, for example.) Does the W10 machine connect OK? If
not, report back and tell us more about what is failing.

6. Note that the command line on W10 is essentially the same as for
previous Windows. Ask if you need help getting to it ...

--
Graham J

[Graham J]

Graham J wrote:

[snip]

Add to item 5 - leave the W10 machine connected to the internet long
enough to get itself fully updated, this may take many hours if it's not
been updated before ...

--
Graham J

[Java Jive]

Further addition: not only, as mentioned by Graham above, do some
routers, even DV ones, behave strangely when given unusual settings, but
also some DV models have a firmware bug where the WiFi functionality is
lost on a reboot; to get it back, you have to power cycle instead of or
after rebooting it. A visible symptom of this is the disappearance of
the WiFi settings section from the menu on the left-hand-side of the
configuration pages.

As you say that other clients are connecting, that cannot be the whole
story here, but it may be a factor adding complexity or even downright
confusion to your attempts to troubleshoot an existing other problem.

[Chris Green]

Well that *seems* to have fixed it, my W10 computer now connects
successfully, I have yet to check whether my daughter's does too
(that's the one that started the rot!).

> 2. Is the Draytek router fully up to date with the latest firmware? If
> not, resolve this before proceeding.
>

Yes.

> 3. Is the Draytek router at Factory configuration apart from the
> settings necessary to achieve the internet connection? Specifically
> have you set the correct VLAN parameters for VDSL? Has anybody changed
> the firewall settings away from the default? If you are uncertain about
> any of these things, factory reset the router and apply only the minimum
> settings necessary to bring up the internet connection.
>

My set-up is a bit too complicated to want to do a factory reset of
the router. Two incoming ports are open to allow connections (for
SMTP and SSH) so the firewall is non-standard. In addition the router
doesn't provide DNS/DHCP on my network, I use dnsmasq in a Raspberry
Pi to do that as I then get names for everything on my network.

Things are also complicated slightly by there being two Draytek
routers, the 2860n as noted above and an old 2820n with its WANs
turned off providing extra WiFi coverage. I guess the two routers
*might* be complicating things so if/when the problem occurs again I
will try turning the 2820n off.

> 4. Using any browser and any other computer look at what the router
> reports about the wireless clients (look at the station list). It
> should show more about how the connection is failing. If you're not
> familiar with managing the Draktek router from a browser, please learn.
> We can help.
>

If the problem recurs I will do this, it would confirm (or not) at
least whether MS Windows was *really* not connecting or (as suggested
above) its error reporting was misleading.

> 5. Temporarily disable the WiFi on the W10 machine and connect it to the
> router via an Ethernet cable, making sure there are no other networking
> components along this connection to confuse the issue. (I've seen
> problems with Engenius wireless bridges used to extend a LAN to a
> distant building, for example.) Does the W10 machine connect OK? If
> not, report back and tell us more about what is failing.
>

If I get desperate I will try this! :-)

> 6. Note that the command line on W10 is essentially the same as for
> previous Windows. Ask if you need help getting to it ...
>

Yes, OK, but what could I do that's useful when I got there? :-)
I guess there's ifconfig and such still.


Thanks for all the ideas, I will report anything interesting when I
try my daughter's computer again.

--
Chris Green
·

[Andy Burns]

Chris Green wrote:

> I have a Windows 10 partition on my (normally Linux) laptop so I
> booted that and tried, sure enough it fails to connect to the WiFi

You could quickly eliminate (or not) DHCP by giving the laptop's wifi
interface a static IP address ... but mainly it was Vista that could be
picky about DHCP

[Graham J]

I suspect that the Draytek "learns" that a client is in some way
invalid, and rebooting makes it forget that. It may be that the ARP
cache contains incorrect values, particularly if you have been switching
other things off and on to try to debug the system.

>> 2. Is the Draytek router fully up to date with the latest firmware? If
>> not, resolve this before proceeding.
>>
> Yes.
>
>
>> 3. Is the Draytek router at Factory configuration apart from the
>> settings necessary to achieve the internet connection? Specifically
>> have you set the correct VLAN parameters for VDSL? Has anybody changed
>> the firewall settings away from the default? If you are uncertain about
>> any of these things, factory reset the router and apply only the minimum
>> settings necessary to bring up the internet connection.
>>
> My set-up is a bit too complicated to want to do a factory reset of
> the router. Two incoming ports are open to allow connections (for
> SMTP and SSH) so the firewall is non-standard. In addition the router
> doesn't provide DNS/DHCP on my network, I use dnsmasq in a Raspberry
> Pi to do that as I then get names for everything on my network.

That's a cop-out. You can back up the settings, factory restore and
test, then restore the clever config.

> Things are also complicated slightly by there being two Draytek
> routers, the 2860n as noted above and an old 2820n with its WANs
> turned off providing extra WiFi coverage. I guess the two routers
> *might* be complicating things so if/when the problem occurs again I
> will try turning the 2820n off.

The important point here will be that the 2820n should not have DHCP
running. Provided that it has an IP address which is unique on the
network all should be well. But you should know all about that since
with the Raspberry Pi providing DHCP and DNS the 2860n should also have
its DHCP service disabled (note there is a DHCP relay setting - have you
configured that correctly? - this may be vital for WiFi clients).

However configuration of multiple wireless access points is always
contentious. I set the same SSID but use different channels; that way
clients are supposed to be able to roam from one WLAN to another - but
in my experience this is only guaranteed if there is a completely dead
region between each wireless service area ensuring that the connection
will drop and restart as the client is moved from one service area to
the other. I suspect the only reliable method is to use a central
controller managing multiple access points - but I've no experience with
this.

>> 4. Using any browser and any other computer look at what the router
>> reports about the wireless clients (look at the station list). It
>> should show more about how the connection is failing. If you're not
>> familiar with managing the Draktek router from a browser, please learn.
>> We can help.
>>
> If the problem recurs I will do this, it would confirm (or not) at
> least whether MS Windows was *really* not connecting or (as suggested
> above) its error reporting was misleading.

Given your specific configuration the WiFi connection may well be OK
while the DHCP/DNS is broken, because the DHCP request packets from W10
don't reach the Raspberry Pi, or their replies don't make it back. So
do get yourself familiar with the Vigor settings ASAP.

Temporarily setting the DHCP and DNS parameters in W10 manually may
allow further diagnostics, such as proving you can ping the Rasberry Pi.

>> 5. Temporarily disable the WiFi on the W10 machine and connect it to the
>> router via an Ethernet cable, making sure there are no other networking
>> components along this connection to confuse the issue. (I've seen
>> problems with Engenius wireless bridges used to extend a LAN to a
>> distant building, for example.) Does the W10 machine connect OK? If
>> not, report back and tell us more about what is failing.
>>
> If I get desperate I will try this! :-)

Probably this is the first thing to try with any WiFi failure. It
should also give much better performance since the 2860 offers Gigabit
on its LAN ports.

>> 6. Note that the command line on W10 is essentially the same as for
>> previous Windows. Ask if you need help getting to it ...
>>
> Yes, OK, but what could I do that's useful when I got there? :-)
> I guess there's ifconfig and such still.

There's a wealth of useful commands, many of which look quite similar to
those you would find in UNIX or Linux - just sufficiently different to
be very annoying !!!!!! Google will help you. Alternatively a
<space>/? at the end of a command will usually give cryptic help.

> Thanks for all the ideas, I will report anything interesting when I
> try my daughter's computer again.

Good luck.

--
Graham J

[Chris Green]

While I could do this without (much) reference to the documentation
using the Linux command line and editing the configuration files
directly I'm completely lost on MS Windows so - how do you set up a
static IP on W10?

--
Chris Green
·

[Andy Burns]

Chris Green wrote:

> how do you set up a static IP on W10?

left-click the wifi icon in the taskbar, network & internet settings,
change adapter options, right-click the relevant NIC, properties, select
TCP/IPv4, properties, then fill in suitable addr/mask/dns values.

[NY]

"Andy Burns" <use...@andyburns.uk> wrote in message
news:fqp8oq...@mid.individual.net...

I have come across some routers - I think it was the ones that were supplied
by TalkTalk - that will not assign an IP address by DHCP if a Windows 10 PC
has both IPv4 and IPv6 protocols enabled for the wifi adaptor. I *think* the
same problem also affected Ethernet, but I'm not certain of that. Disabling
IPv6 or setting a static IPv4 address allowed communication; the former is
the better workaround because it avoids potential IP address clashes with
other PCs which use DHCP. (*)


The symptom of it failing was that the PC's IP address was reported by
ipconfig as being 169.x.x.x


(*) If a PC needs a perpetual IP address, it is better to configure the
MAC-to-IP mapping at the router if it has a static-IP setting, rather than
setting the PC to a static address. DHCP is still used to give the PC an
address, but the router always gives that PC (identified by MAC) the *same*
address. This is useful if NetBIOS hostname-to-IP lookup isn't working
properly and you want to access a web server that's running on a PC - where
you have to use the URL http://192.168.1.5/folder/filename instead of
http://hostname/folder/filename. I have NextPVR running on my TV-recording
PC and whereas other Windows PCs can address this with a URL that uses the
"server's" hostname, Android devices can't do this, so the IP address must
be used instead - so the router must be set to give "server" a
static-by-DHCP address. SMB file-sharing software in Android also needs a
UNC address \\192.168.1.5\folder\filename rather than
\\hostname\folder\filename - though I've yet to fine any Android software
that will allow true file access to a network share: something that makes a
network share look like another storage area on the phone, so any apps can
access it in the same way; instead it's necessary to copy the file from the
share to the local storage and then access it from there, which is little
better than FTP: very poor :-(

[NY]

"Andy Burns" <use...@andyburns.uk> wrote in message

news:fqpad9...@mid.individual.net...

Further to my earlier suggestion about disabling IPv6, "left-click the wifi

icon in the taskbar, network & internet settings, change adapter options,

right-click the relevant NIC, properties" is also the way to turn off IPv6
by unticking it.

[Andy Burns]

NY wrote:

> Further to my earlier suggestion about disabling IPv6, "left-click the
> wifi icon in the taskbar, network & internet settings, change adapter
> options, right-click the relevant NIC, properties" is also the way to
> turn off IPv6 by unticking it.

I did used to disable IPv6 in earlier versions of windows, but now some
features rely on it, I've got IPv6 configured just as a link-local
prefix at home. I know other ISPs offer native IPv6, I wish Plusnet
would show some enthusiasm towards it ...

[Graham J]

NY wrote:
> "Andy Burns" <use...@andyburns.uk> wrote in message
> news:fqp8oq...@mid.individual.net...
>> Chris Green wrote:
>>
>>> I have a Windows 10 partition on my (normally Linux) laptop so I
>>> booted that and tried, sure enough it fails to connect to the WiFi
>>
>> You could quickly eliminate (or not) DHCP by giving the laptop's wifi
>> interface a static IP address ... but mainly it was Vista that could
>> be picky about DHCP
>
> I have come across some routers - I think it was the ones that were
> supplied by TalkTalk - that will not assign an IP address by DHCP if a
> Windows 10 PC has both IPv4 and IPv6 protocols enabled for the wifi
> adaptor. I *think* the same problem also affected Ethernet, but I'm not
> certain of that. Disabling IPv6 or setting a static IPv4 address allowed
> communication; the former is the better workaround because it avoids
> potential IP address clashes with other PCs which use DHCP. (*)
>
>
> The symptom of it failing was that the PC's IP address was reported by
> ipconfig as being 169.x.x.x
>
>
> (*) If a PC needs a perpetual IP address, it is better to configure the
> MAC-to-IP mapping at the router if it has a static-IP setting, rather
> than setting the PC to a static address. DHCP is still used to give the
> PC an address, but the router always gives that PC (identified by MAC)
> the *same* address.

[snip]

Generally, both a static setting in the device and the same IP address
being issued by Binding in the DHCP server will guarantee it all works.
This is because on power up some devices will self-assign a confusing
address if the DHCP server isn't running. Typically this is where you
have a Windows Server which takes a significant time to boot - longer
than a printer or NAS device on the LAN. So if nothing works after a
power cut rebooting the client device might help.

--
Graham J

[Andy Burns]

NY wrote:

> The symptom of it failing was that the PC's IP address was reported by
> ipconfig as being 169.x.x.x

Windows (or Linux using zeroconf) will assign an APIPA address like that
whenever DHCP is enabled but there is no DHCP server (or the client
doesn't get along with the server).

[Graham J]

If you're going to support Windows machines you're going to have to
learn this stuff. But mostly Google will find it for you.

You can of course use the command line to achieve such settings, see:

<https://helpdeskgeek.com/networking/change-ip-address-and-dns-servers-using-the-command-prompt/>

Macs also have a GUI for setting network parameters, but again a command
line option is available, see:

<https://helpdeskgeek.com/networking/change-ip-address-and-dns-servers-using-the-command-prompt/>

Might not work for versions earlier than OS10. I certainly don't
remember a command line in OS7 or OS8.

--
Graham J

[Chris Green]

OK, thanks.

--
Chris Green
·

[Chris Green]

Well, maybe. But I need to minimse downtime to avoid bouncing mail
(SMTP receive), it's OK for a few hours but I prefer not to if I can
avoid it.

>
> > Things are also complicated slightly by there being two Draytek
> > routers, the 2860n as noted above and an old 2820n with its WANs
> > turned off providing extra WiFi coverage. I guess the two routers
> > *might* be complicating things so if/when the problem occurs again I
> > will try turning the 2820n off.
>
> The important point here will be that the 2820n should not have DHCP
> running.

It doesn't.

> Provided that it has an IP address which is unique on the
> network all should be well. But you should know all about that since
> with the Raspberry Pi providing DHCP and DNS the 2860n should also have
> its DHCP service disabled (note there is a DHCP relay setting - have you
> configured that correctly? - this may be vital for WiFi clients).
>

Yes, that's right, no DHCP on the 2860n. I have wondered about the
DHCP relay setting as I couldn't find any good documentation about it.
Until now it hasn't beem configured, i.e. I just have DHCP off and no
DHCP relay. It all works like this (well, apart from the W10 thing)
so I've not bothered with it. Presumably if I set it I tell it that
the DHCP server is the Pi's IP address.

> However configuration of multiple wireless access points is always
> contentious. I set the same SSID but use different channels; that way
> clients are supposed to be able to roam from one WLAN to another - but
> in my experience this is only guaranteed if there is a completely dead
> region between each wireless service area ensuring that the connection
> will drop and restart as the client is moved from one service area to
> the other. I suspect the only reliable method is to use a central
> controller managing multiple access points - but I've no experience with
> this.
>

Yes, quite, I've got them both the the same SSIDs but as you say it's
not very well defined what clients do if you move them around. In the
main systems are either close to one or the other and don't move
around to much so it's not a *big* issue.

>
> >> 4. Using any browser and any other computer look at what the router
> >> reports about the wireless clients (look at the station list). It
> >> should show more about how the connection is failing. If you're not
> >> familiar with managing the Draktek router from a browser, please learn.
> >> We can help.
> >>
> > If the problem recurs I will do this, it would confirm (or not) at
> > least whether MS Windows was *really* not connecting or (as suggested
> > above) its error reporting was misleading.
>
> Given your specific configuration the WiFi connection may well be OK
> while the DHCP/DNS is broken, because the DHCP request packets from W10
> don't reach the Raspberry Pi, or their replies don't make it back. So
> do get yourself familiar with the Vigor settings ASAP.
>
> Temporarily setting the DHCP and DNS parameters in W10 manually may
> allow further diagnostics, such as proving you can ping the Rasberry Pi.
>
>
> >> 5. Temporarily disable the WiFi on the W10 machine and connect it to the
> >> router via an Ethernet cable, making sure there are no other networking
> >> components along this connection to confuse the issue. (I've seen
> >> problems with Engenius wireless bridges used to extend a LAN to a
> >> distant building, for example.) Does the W10 machine connect OK? If
> >> not, report back and tell us more about what is failing.
> >>
> > If I get desperate I will try this! :-)
>
> Probably this is the first thing to try with any WiFi failure. It
> should also give much better performance since the 2860 offers Gigabit
> on its LAN ports.
>

Yes, much of my network is hard-wired, it's only laptops (and
smartphones) that aren't really. I've never seen a problem with the
laptop when I hard-wire it but I didn't try that when the W10 issue
cropped up.

> >> 6. Note that the command line on W10 is essentially the same as for
> >> previous Windows. Ask if you need help getting to it ...
> >>
> > Yes, OK, but what could I do that's useful when I got there? :-)
> > I guess there's ifconfig and such still.
>
> There's a wealth of useful commands, many of which look quite similar to
> those you would find in UNIX or Linux - just sufficiently different to
> be very annoying !!!!!! Google will help you. Alternatively a
> <space>/? at the end of a command will usually give cryptic help.
>
> > Thanks for all the ideas, I will report anything interesting when I
> > try my daughter's computer again.
>
> Good luck.
>

Thanks again/more.

--
Chris Green
·

[Andy Burns]

Chris Green wrote:

> I have wondered about the
> DHCP relay setting as I couldn't find any good documentation about it.

Would only be required if the DHCP server is on a different IP subnet to
the clients ...

[Chris Green]

Yes, I *think* I came to that conclusion in the end which is why I
left it unconfigured.

--
Chris Green
·

[Graham J]

Fair comment. But the issue in Chris's configuraton may be that the
DHCP request packets which are broadcast do not reach the DHCP server,
so setting the relay IP might help. So understandung why the broadcast
fails may be important.

Does the Rasberry Pi provide any sort of DHCP logging or monitoring so
you can see whether it receives any requests from the W10 laptop?

--
Graham J

[Andy Burns]

Graham J wrote:

> Does the Rasberry Pi provide any sort of DHCP logging or monitoring s

I should expect dhcpdump is available, if not just use
tcpdump -e port 67 or port 68

[Stephen]

On Thu, 12 Jul 2018 17:38:46 +0100, Andy Burns <use...@andyburns.uk>
wrote:

DHCP doesnt really kick in until you have a LAN link - if the WiFi
isnt finding the router and negotiating the passwrd then it may not
matter.
- worth checking if it works at a hotspot etc - some PCs have a
"disable WiFi" switch, or the card aerial cound be disconnected within
the case.....

What windows doesnt seem to do is notice when the DHCP server comes
back upm initiate DHCP and sort out a valid IP adr.
- you can force it using the command line CMD
try
ipconfig /release
ipconfig /renew

renew on its own doesnt consistently work for me (but the same
happened all the way back to Win2000)

--
Stephen

[Chris Green]

I'm pretty sure that dnsmasq logs most things in syslog so I can
certainly take a look (if/when the problem occurs again).

--
Chris Green
·

[Graham J]

In my experience it pays to be very familiar with such diagnostic tools
well before any problem occurs. That way you know how to run the tools,
and have some experience of what is normal behaviour - so recognising
the signature of a fault becomes easier.

--
Graham J

[Dick]

On 12/07/2018 18:19, Chris Green wrote:

> Yes, quite, I've got them both the the same SSIDs but as you say it's
> not very well defined what clients do if you move them around. In the
> main systems are either close to one or the other and don't move
> around to much so it's not a *big* issue.

Its a very bad idea to use the same SSID for multiple wifi access
points. You have no idea which device you are connecting to. There seems
to be a misconception that having the same SSID will somehow magically
allow seamless roaming between access points, it won't, that is only
achievable with true mesh systems with the necessary software.

[Java Jive]

IME, not so. I've set up a client with multiple access points all
broadcasting the same SSID, and proved that I can walk from one end of
the site to the other, visiting every room in every building along the
way, while streaming a Radio 4 program on my phone, and never lose the
programme let alone the connection.

[NY]

"Java Jive" <ja...@evij.com.invalid> wrote in message
news:pifdhg$1623$1...@gioia.aioe.org...

I would tend to give the two wireless networks different SSIDs if they were
connected together either by Ethernet from router to remote access point or
by a wifi repeater. Indeed when you put an access point into repeated mode,
it often automatically uses an SSID which is the parent one with a suffix:
eg SPIDER and SPIDER_EXT.

I've never known what the best advice is about wireless channels. Is it good
idea to make the extension network a different non-overlapping channel (eg 6
or 11 if the parent is 1) or is it better to make the extension the same
channel as the parent?

[Dick]

Probably because the stream is being buffered you won't notice the drop
and re-connection. Try it using different SSIDs, it will give the same
experience.

[Dick]

Definitely a different channel to avoid interference.

[Woody]

"Java Jive" <ja...@evij.com.invalid> wrote in message
news:pifdhg$1623$1...@gioia.aioe.org...

With the same SSID and on the same channel?



--
Woody

harrogate3 at ntlworld dot com

[Chris Green]

Some sites agree with you, other sites don't. I read around this
issue quite a lot and I'm sort of more convinced by the 'same SSID'
enthusiasts but there's certainly no totally reliable way to mave
from one WiFi source to another.

--
Chris Green
·

[NY]

"Dick" <inv...@invalid.com> wrote in message
news:pifl5g$844$2...@dont-email.me...

>> I've never known what the best advice is about wireless channels. Is it
>> good idea to make the extension network a different non-overlapping
>> channel (eg 6 or 11 if the parent is 1) or is it better to make the
>> extension the same channel as the parent?
> Definitely a different channel to avoid interference.

Yes. I would go for different channels, but I've seen some sites or
newsgroup postings which suggest that a range-extended network should be on
the *same* channel as the parent. Likewise with SSID - some say make it
different (the default action of range-extenders) and some say make it the
same.

I notice that BT's own routers put the real SSID (eg BTHomeHub2-WXYZ) and
the piggyback SSIDs for public hotspots (BTWiFi-with-FON, BTWiFi-X) all on
the same channel.

[+++ATH0]

On 2018-07-15 03:55, Dick wrote:
> Its a very bad idea to use the same SSID for multiple wifi access
> points. You have no idea which device you are connecting to. There seems
> to be a misconception that having the same SSID will somehow magically
> allow seamless roaming between access points, it won't, that is only
> achievable with true mesh systems with the necessary software.

What a load of old tripe.

[Dick]

I don't think so, please explain how you can tell which AP you are
connected to if all have the same SSID. Please explain how having the
same SSID allows seamless roaming without mesh capability.

[Java Jive]

On 15/07/2018 15:18, Dick wrote:
>
> Probably because the stream is being buffered you won't notice the drop
> and re-connection. Try it using different SSIDs, it will give the same
> experience.

Of course it won't, I'd lose the connection the moment I was out of
range of the first access point.

[Java Jive]

On 15/07/2018 16:21, Woody wrote:
>
> "Java Jive" <ja...@evij.com.invalid> wrote in message
>>

>> IME, not so. I've set up a client with multiple access points all
>> broadcasting the same SSID, and proved that I can walk from one end
>> of the site to the other, visiting every room in every building
>> along the way, while streaming a Radio 4 program on my phone, and
>> never lose the programme let alone the connection.
>
> With the same SSID and on the same channel?

Yes.

[Java Jive]

On 15/07/2018 19:27, Dick wrote:
>
> On 15/07/2018 18:26, +++ATH0 wrote:
>>
>> On 2018-07-15 03:55, Dick wrote:
>>>
>>> Its a very bad idea to use the same SSID for multiple wifi access
>>> points. You have no idea which device you are connecting to. There seems
>>> to be a misconception that having the same SSID will somehow magically
>>> allow seamless roaming between access points, it won't, that is only
>>> achievable with true mesh systems with the necessary software.
>>
>> What a load of old tripe.

+1

> I don't think so, please explain how you can tell which AP you are
> connected to if all have the same SSID. Please explain how having the
> same SSID allows seamless roaming without mesh capability.

It just works with a DrayTek Vigor 2860 series router and their AP910C
access points. No special mesh software required.

[Chris Green]

I don't need to "explain how you can tell which AP you are connected
to .....", I just want to be connected.

What's *supposed* to happen when you move around is that there is a
signal threshold below which the connection will get re-negotiated.
There is a specific setting for this but not all routers/clients know
about it and thus it sometimes works OK and sometimes doesn't.
(I'd have to do some serious searching to find the details again)

--
Chris Green
·

[NY]

"Chris Green" <c...@isbd.net> wrote in message
news:b43u1f-...@esprimo.zbmc.eu...

The one problem that could arise, and maybe this is solved by mesh networks,
is routing of data. If you have an extension access point connected by
Ethernet to the router which has the same SSID, the router will know that
initially you are connected by wifi so it won't send the data by any of the
Ethernet ports. Then your computer disconnects from that LAN and connects to
the extension AP. Now the router needs to know that it needs to send traffic
out of the relevant LAN port instead of the router's own wifi.

I'd have thought that the process of establishing a connection and being
given an IP address (maybe the same one as before) would tell the router how
the computer connected and therefore route the traffic correctly.

My experience is that it all seems to work OK. My parents have two wifi
networks because their hot water cylinder blocks the wifi from the router to
the kitchen and conservatory, so I've set up a repeater AP in the kitchen,
connected by Ethernet. I've never had problems with a portable device
switching from one network to the other as I walk around the house. And
that's just with a normal TP Link router and a bog-standard AP.

[Dick]

Ergo, if the AP's have different SSIDs you can force a re-connection to
a stronger signal manually rather than the device hanging on to a weak
signal.

[Nick Leverton]

The problem is that session handover when roaming between APs is
not seamless, even on the same SSID. I recently experienced this at
$WORKPLACE. Any time my Wifi device saw a minor interruption with the
local AP it would switch to another one, meaning that any TCP session
(browsing, remote login, etc) just hung, sometimes recoverably, sometimes
not. I had to turn the roaming aggressiveness down to minimum in the
driver settings to minimise the trouble arising from unwanted changovers.

As far as I know, this is a general AP roaming problem and not to do
with using the same SSID. Some more recent APs and devices may support
seamless handover but I've not worked with one so can't say more.

Nick
--
"The Internet, a sort of ersatz counterfeit of real life"
-- Janet Street-Porter, BBC2, 19th March 1996

[NY]

"Nick Leverton" <ni...@leverton.org> wrote in message
news:pii0fb$7kp$1...@leverton.org...

> The problem is that session handover when roaming between APs is
> not seamless, even on the same SSID. I recently experienced this at
> $WORKPLACE. Any time my Wifi device saw a minor interruption with the
> local AP it would switch to another one, meaning that any TCP session
> (browsing, remote login, etc) just hung, sometimes recoverably, sometimes
> not. I had to turn the roaming aggressiveness down to minimum in the
> driver settings to minimise the trouble arising from unwanted changovers.
>
> As far as I know, this is a general AP roaming problem and not to do
> with using the same SSID. Some more recent APs and devices may support
> seamless handover but I've not worked with one so can't say more.

So if you had a client-server session open in Teamviewer, or had been
browsing web pages or checking emails by downloading over POP (though not at
the precise moment of handover), you'd expect that sometimes things would
hang? I've never seen that, either on my phone or my laptop.

On my phone, I have even switched between wifi and mobile internet, and not
seen any problems. Teamserver sessions stay connected, and I can browse to a
site that I had been browsing to before the handover, or can check for new
POP emails. The only time I've had problems is if I was downloading data
(web page, EXE file, POP emails) at the moment of handover.

[Java Jive]

On 16/07/2018 12:27, Dick wrote:
>
> Ergo, if the AP's have different SSIDs you can force a re-connection to
> a stronger signal manually rather than the device hanging on to a weak
> signal.

Ergo bollocks (latin for spherical objects). If you set up everything
correctly in the first place with the right sort of SOHo equipment and
the same setting on each AP, it just works seemlessly, as I and others
have described. Having to manually force a reconnection is a sign that
the WiFi network was not installed or configured correctly, in other
words it's a sign of failure.

[Graham J]

[snip]

As you move about, your client will try to connect to the strongest
signal. If it knows about the SSID and provides the necessary security
key it should connect; but many laptop clients will fail this and have
to be told to connect to the chosen signal manually.

Mesh networks overcome this to an extent by managing the connection
betwen the client and the most relevant access point (which might not be
the nearest, it could be one that is carrying less traffic, or one
specified by how the system was set up).

The above is the connection between the client device and the wireless
access point (either stand-alone or integrated within a router).

The issue of moving the client device from one wireless network point to
another is quite separate, and is equivalent to unplugging a cable from
one network switch port and plugging it into another port, possibly in a
different network switch. This is handled by ARP (Address Resolution
Protocol) and network switches contain a cache of the resolved port
details. The cache normally retains data for no more than a few
seconds, so unplugging a cable from one place and plugging it into
another usually works as expected. Some older network switches may
retain the ARP cache for many tens of seconds - leading to a degree of
confusion and black magic solutions such as powering everything off, and
applying power in a specified sequence. See:

https://en.wikipedia.org/wiki/Address_Resolution_Protocol

Once the pathway to a specific device is established (i.e. the
particular port or access point in use), the client may then use DHCP to
request an IP address. Conventionally this will be the same as the one
it most recently released; but this depends on both router and client
design. Usually you will see the same IP address allocated as a client
moves from on access point to another.

--
Graham J

[Chris Green]

Yes, but getting naive users to do that is non-trivial in my experience!

--
Chris Green
·

[Dick]

It may appear to work seamlessly, but it doesn't. It drops and
re-connects. A lot of devices refuse to give up a weak signal in
preference for a stronger signal.

[Java Jive]

On 16/07/2018 13:47, Dick wrote:
> On 16/07/2018 13:18, Java Jive wrote:
>> On 16/07/2018 12:27, Dick wrote:
>>>
>>> Ergo, if the AP's have different SSIDs you can force a re-connection
>>> to a stronger signal manually rather than the device hanging on to a
>>> weak signal.
>>
>> Ergo bollocks (latin for spherical objects).  If you set up everything
>> correctly in the first place with the right sort of SOHo equipment and
>> the same setting on each AP, it just works seemlessly, as I and others
>> have described.  Having to manually force a reconnection is a sign
>> that the WiFi network was not installed or configured correctly, in
>> other words it's a sign of failure.
>
> It may appear to work seamlessly, but it doesn't. It drops and
> re-connects.

So the client's user isn't aware of it - that in my parlance is seamless.

A lot of devices refuse to give up a weak signal in
> preference for a stronger signal.

Then that's a problem with the client device, and that's where the
problem should be solved. You can't make the rest of the world work
less well, just to accommodate a handful of bad devices.

[Stephen]

On Sun, 15 Jul 2018 17:24:48 +0100, "NY" <m...@privacy.net> wrote:

>"Dick" <inv...@invalid.com> wrote in message
>news:pifl5g$844$2...@dont-email.me...
>>> I've never known what the best advice is about wireless channels. Is it
>>> good idea to make the extension network a different non-overlapping
>>> channel (eg 6 or 11 if the parent is 1) or is it better to make the
>>> extension the same channel as the parent?
>> Definitely a different channel to avoid interference.

Channels need to have ideally minimal overlap.
On 2.4 GHz there are 3 channels for the original bandwidth use
signals, on 1, 6, 11.

Since the UK allows operation up to ch 13, you can trade slightly
higher interference and get 4 channels with tighter spacing.

But then wider channels came along to get better performance by
spraying a single signal across 11 channels.....

5 GHz was intended to improve on that and defined 8 non overlapping
channels originally - but then got hit by the wider channel fix to
higher speeds.

1 of the tuning options in commercial rollouts is to reduce power on
APs to balance coverage of an individual AP with interference, since
if you have more than a few AP you have to re-use the channels.....

>
>Yes. I would go for different channels, but I've seen some sites or
>newsgroup postings which suggest that a range-extended network should be on
>the *same* channel as the parent. Likewise with SSID - some say make it
>different (the default action of range-extenders) and some say make it the
>same.
>

It depends what you want it to do.
A lot of the advice about using different SSIDs is because clients
trigger migration, and some clients didnt pick when and how to do it
all that well, so multiple SSIDs lets the user pick 1 - which sort of
works when they know which is going to be a good choice......

SSID per AP doesnt scale for anything more than a few AP which
confines it to a relatively small building.

eg. in an office with 10s of access points per floor (and a company
with lots of offices) would you want to set up 100s of SSIDs on all
devices?

So commercial APs are designed to gracefully hand off client devices
between themselves as users walk around a building, or as "hot spots"
develop to distribute the load across muliple AP.

The same thing is starting to occur within individual APs, what with
dual frequency, multi radio, multi antenna support being built into
chipsets.

>I notice that BT's own routers put the real SSID (eg BTHomeHub2-WXYZ) and
>the piggyback SSIDs for public hotspots (BTWiFi-with-FON, BTWiFi-X) all on
>the same channel.

--
Stephen

[Stephen]

<snip>

if you have multiple AP and want roaming to work then the alterations
to parameters need to react at layer 2.
- if your APs are not in the same subnet and DHCP range with a common
default gateway then anything that relies on an unchanging IP during a
session such as VoIP or iplayer will disconnect at roam time.

Multiple AP connected to 1 or more layer2 switches in a common VLAN +
subnet will work if they are set up correctly (and the kit reacts
correctly to the side effects)
- the WiFi will move based on client roaming
- when the client roams the switch network connecting the AP needs to
pick up the "move" of the MAC address and update devices to match
- otherwise return traffic goes to the wrong AP and gets thrown into
the bit bucket.

Some switches dont update correctly / consistently and that will have
exactly the same effect on the user as broken roaming.....

Controller based "cloud of WiFi AP" systems fix this by having all AP
scattered across different subnets act as a single overlay & send
traffic to a central device
- roaming doesnt alter the controller central location to send
traffic.

--
Stephen

[Nick Leverton]

In article <aeSdnWW99ZrVFdHG...@brightview.co.uk>,

NY <m...@privacy.net> wrote:
>"Nick Leverton" <ni...@leverton.org> wrote in message
>news:pii0fb$7kp$1...@leverton.org...
>> The problem is that session handover when roaming between APs is
>> not seamless, even on the same SSID. I recently experienced this at
>> $WORKPLACE. Any time my Wifi device saw a minor interruption with the
>> local AP it would switch to another one, meaning that any TCP session
>> (browsing, remote login, etc) just hung, sometimes recoverably, sometimes
>> not. I had to turn the roaming aggressiveness down to minimum in the
>> driver settings to minimise the trouble arising from unwanted changovers.
>>
>> As far as I know, this is a general AP roaming problem and not to do
>> with using the same SSID. Some more recent APs and devices may support
>> seamless handover but I've not worked with one so can't say more.
>
>So if you had a client-server session open in Teamviewer, or had been
>browsing web pages or checking emails by downloading over POP (though not at
>the precise moment of handover), you'd expect that sometimes things would
>hang? I've never seen that, either on my phone or my laptop.

Exactly Teamviewer, yes. I believe the underlying problem was that
summarised by Stephen Hope in an adjacent posting. Following a roam
between APs, other devices on the network do not know which AP is supposed
to be handling the Layer 2 packets for the destination device.

[Andy Burns]

Nick Leverton wrote:

> Following a roam
> between APs, other devices on the network do not know which AP is supposed
> to be handling the Layer 2 packets for the destination device.

In most cases they don't need to know, the AP is only acting as a
bridge, not a router.

As soon as the device has associated with a new AP, any IP packet that's
sent (including from TCP retransmissions) will associate the client's
MAC address with the port on the switch(es) that the AP is connected
to/through, and that's it, no ARP flush necessary as the same client
ought to keep the same IP/MAC combination (assuming the roaming is
within a single subnet and anyway your TCP connections will be hosed if
not).

IME the thing that causes roaming clients to go wrong is they tend to
cling to a poor signal too long rather than roaming to a stronger signal
that is available, if only they would look.

Yes mesh systems have their place e.g they can kick the clients off a
weak signal and therefore force them to hop to a stronger one, and they
offer centralised management.