SSID broadcast off

[bob]

I remember hearing this when I asked about turning SSID broadcast off
for a wireless router:

"You can usually turn off broadcasting the SSID at the router, but
there are plenty of reports that doing this can lead to connection
issues that are suddenly fixed by turning it back on."

I definitely think I'm seeing these "connection issues" with SSID
broadcast off, but I don't see a logical reason for it. Any ideas why
SSID broadcast off results in connection issues?

 

[Paul]

I remember hearing this when I asked about turning SSID broadcast off
for a wireless router:

"You can usually turn off broadcasting the SSID at the router, but
there are plenty of reports that doing this can lead to connection
issues that are suddenly fixed by turning it back on."

I definitely think I'm seeing these "connection issues" with SSID
broadcast off, but I don't see a logical reason for it. Any ideas why
SSID broadcast off results in connection issues?

Here they recommend turning off SSID broadcast, and using a non-obvious
SSID string.

http://www.depts.ttu.edu/helpcentral/safecomputing/secure/securewireless.php

The protocol is explained a bit here.
http://www.swiss.ai.mit.edu/6095/student-papers/spring02-papers/paranoia.htm

"When the wireless station is searching for an access point via its built-in
scanning function, it is in State 1, unauthenticated and unassociated.The
station finds an access point either via listening for an access point’s
beacon management frame or through knowing the access point’s uniquenetwork
name, otherwise named Service Set IDentifiers (SSID). Access points send
out beacon management frames periodically to allow a station waiting to
connect to find those access points within transmission range. A station
wishing to connect to a particular access point with known SSID sends out
a probe request management frame to locate the desired access point."

What that says is, the SSID is used in two kinds of packets. At least
as I understand it. The Access Point can broadcast the SSID, which is
an aid to roaming amongst multiple Access Points. But the client also
sends probe packets with the SSID in them, and it is also possible to
identify the SSID of a potential network, by listening to the probe
packets.

"Wireless Vulnerabilities & Exploits - Airjack tool"
http://www.wirelessve.org/entries/show/WVE-2005-0018

Page 5 here, walks through the protocol. It really depends on whether
the client is depending on an SSID broadcast, as a means to identify
an Access Point that is within range or not.

http://www.cs.umd.edu/~waa/wireless.pdf

Here are some examples of tools. Kismet is the one that can
identify your SSID, even when the beacon is disabled. It does
that by listening to the client sending probe packets.

http://www.netstumbler.com/downloads/netstumbler_v0.4.0_release_notes.pdf

http://www.kismetwireless.net/
http://www.kismetwireless.net/documentation.shtml

"Kismet identifies networks by passively collecting packets and detecting
standard named networks, detecting (and given time, decloaking) hidden
networks, and infering the presence of nonbeaconing networks via data
traffic."

So disabling the beacon, may prevent your SSID from showing
conveniently in a list of Access Points, but does not entirely
make your network invisible. As soon as your client sends
a probe packet, the game is up. A person running Linux on
a laptop, with a copy of Kismet, will get to know your SSID
eventually. The Airjack tool looks like its "essid_jack"
method may do something similar.

On this Cisco web page, you can see the things that a Cisco
"intrusion detection tool" is checking for.

http://www.cisco.com/en/US/tech/tk722/tk809/technologies_tech_note09186a008063e5d0.shtml

And this page has a recommendation for SSID:

http://www.cisco.com/en/US/products/hw/wireless/ps4570/products_white_paper09186a00800b469f.shtml

"In addition, disabling SSID broadcasts might have adverse effects
on Wi-Fi interoperability for mixed-client deployments."

In other words, if you mix different brands of wireless equipment,
disabling SSID broadcast may affect their ability to work together.
To me, that could only be the case, if a client refused to send
probe packets on its own. As usual, the problem is finding a
web page that addresses the protocol with greater precision.
(One of the reasons for going to the Cisco site in the first place.)

I think it would be fun to record the packets being sent by your
gear. As an example of the fun you can have, I got a copy of
Ethereal the other day, to find out what my computer was sending
when I wasn't doing anything. At first I feared the worst, but
once I captured a few packets with Ethereal, I could see the
OS was doing some uPNP. Disabling uPNP on my new router fixed that.
So a packet sniffer is great fun to have, as long as there is
no effort to setting it up. If you want to play with a wired
packet sniffer, try this one. (Presumably there is a tool
like this for the wireless world.)

http://freestuff.openxtra.co.uk/downloads/opensource/3_18_0/Ethereal_XTRA_3_18_0.exe

Paul

 

[Roby]

Here are some examples of tools. Kismet is the one that can
identify your SSID, even when the beacon is disabled. It does
that by listening to the client sending probe packets.

http://www.netstumbler.com/downloads/netstumbler_v0.4.0_release_notes.pdf

http://www.kismetwireless.net/
http://www.kismetwireless.net/documentation.shtml

"Kismet identifies networks by passively collecting packets and
detecting
standard named networks, detecting (and given time, decloaking) hidden
networks, and infering the presence of nonbeaconing networks via data
traffic."

So disabling the beacon, may prevent your SSID from showing
conveniently in a list of Access Points, but does not entirely
make your network invisible. As soon as your client sends
a probe packet, the game is up. A person running Linux on
a laptop, with a copy of Kismet, will get to know your SSID
eventually. The Airjack tool looks like its "essid_jack"
method may do something similar.

Paul:

Your response prompted me to experiment a bit with Kismet. My stuff is in
the basement ... wifi from the neighborhood doesn't get down here, and I
don't see either other access points or probes from scanning clients unless
I lug the gear upstairs.

I enabled the radio on my router with broadcast off. Kismet reported the
a/p immediately, including the SSID surrounded with "<>", meaning no
broadcast. Tried it several times, always with the same result. Tried
various router settings. Kismet was never fooled.

I guess my router (DI-624) doesn't do the "nonbeaconing network" dance.
Other than ad-hoc, how else do nonbeaconing networks arise?

Roby

 

[Mike Walsh]

On my home network a wireless desktop PC works with SSID broadcast off, but my Dell laptop will not connect unless SSID broadcast is on. I don't know why.

 

[Paul]

Paul:

Your response prompted me to experiment a bit with Kismet. My stuff is in
the basement ... wifi from the neighborhood doesn't get down here, and I
don't see either other access points or probes from scanning clients unless
I lug the gear upstairs.

I enabled the radio on my router with broadcast off. Kismet reported the
a/p immediately, including the SSID surrounded with "<>", meaning no
broadcast. Tried it several times, always with the same result. Tried
various router settings. Kismet was never fooled.

I guess my router (DI-624) doesn't do the "nonbeaconing network" dance.
Other than ad-hoc, how else do nonbeaconing networks arise?

Roby

This tutorial mentions that active/passive scanning are not controlled
by the standards as such. The tools are there (frame formats), but
how you use the tools are not.

http://www.sss-mag.com/pdf/802_11tut.pdf

I'm not sure you can really turn off the beacon function. Maybe the
SSID field can be filled with a reserved value, rather than a real
text field, and that is the only consequence of disabling SSID
broadcast. If you look at the physical protocol, there is some
mention of time keeping, and the need for nodes to synchronize
with one another. I'm not sure that can be accomplished with
just passive probes. The access to the air waves is CSMA
(collision sense multiple access), but with collision avoidance.
Short packets (RTS/CTS) collide in the classic sense, and the
protocol arranges to reserve the channel for a transmission. The
transmission is a longer packet, but not as long as a standard
Ethernet packet. The Ethernet packet would be fragmented into
smaller pieces.

One web site I visited, suggested there can be multipath in the
environment. They used an RF absorbing mat in the test room,
and got higher thruput than without it. It suggests there
is more than one way to screw up wireless - it can either be
a protocol problem (important piece missing, or two brands
of gear place more priority on one activity than another), or
a physical layer problem. I was reading a reviewer comment
on an 802.11n product (multiple antennas, perhaps multiple
channels, for higher thruput), and the user was commenting
on the need to change the relationship of the antennas to get
even part of the promised performance. So this stuff is tricky.

I have experienced the impact of enabling encryption on data
rate before. I used a VPN product, to connect to work, and
even though my physical channel (ADSL) is capable of good
rates, using Windows networking on top of the fragmentation
caused by the encryption method, resulted in a data rate of
4KB per second. With encryption enabled, I was basically
getting dialup modem performance, on an ADSL connection.
Using that ADSL modem today, I have no problem getting
300KB per second, when downloading from the Internet direcrly.
In that example, you cannot blame the physical channel, and
performance had something to do with the way packets were
chopped up into pieces (in that case, encryption caused the
normal packets to be fragmented), and how "acks" came back
from the other end of the link.

BTW - That tutorial is dated 1997, and a lot has changed since
then.

As for actual standards, there is this page. Just
about useless...

http://standards.ieee.org/getieee802/802.11.html

Paul