• Our parent company uses the same SSID located in Europe.

    When users come with their laptops to the U.S. They do not connect to our SSID automatically.

    Using windows 7 built-in wireless config. (SSID is hidden)

    SSID=logical name BSSID=MAC of AP or WLAN controller.

    Using group policy from AD both are WPA2/AES.

    Is it OK to use the same SSID?

    What issues will be seen by using this method?

  • It should work, unless one end or the other (usually the AP side) has MAC address filtering enabled.

    If you have a decent level of encryption, turn off Mac filtering. Hiding the SSID's doesn't buy you any real security, so if that is one of the reasons it's on then your company needs to re-evaluate their security methods.

    That being said, win7 does do somethings differently sometimes.

  • More specifically: Is the BSSID stored with the SSID on Windows wireless profiles?

    Clients sends packet to FF:FF:FF:FF:FF:FF to acquire the BSSID

    client has a profile for SSID=WLAN00 (in Europe MAC=00:11:22:33:66:77)
    (US MAC=11:22:33:88:99:77)

    BSSID of the SSID is returned?

    Does the client compare the MAC of the stored SSID?

  • the bssid dont play a role. the client sends out probe requests with the stored ssid to ffff.ffff.ffff and any aps configured with this ssid should respond with an probe response. than the client sends authentication + association requests to "best" AP.

    ssid should be exactly the same (case sensitive)

    both networks in europe an u.s. should use the same authentication: either PSK or 802.1x

    as stated from wlanman there can be trouble with some clients and the "hide ssid feature"

  • I have done installs in Europe and also in the US, to give you some areas to start you troubleshooting find out if the occurs in both spectrums. Ensure that they wlan client drivers that you have installed support the appropriate channels. In other words the channels impacted by 802.11h, the second issue that I would check is that the clients are configured to "connect automatically even if not in range" I believe is the correct terminology. Which should force the client to do an active probe. More than likely you issue will lie with one of those two issues.

  • I would be grabbing the WLAN (SSID) config from the WLCs or APs and comparing them side-by-side. From an SOE perspective, it would be nice if they were identical, but I would be aiming for 'as-close-as-possible'.

  • I have not seen it in PC's, but many mobile devices have what is often referred to as a Channel Mask. This mask controls what channels are allowed on the device. For example x'FFE0' [i]might[/i] allow US channels 1 through 11 and x'FFFC' allow channels 1 through 14 in the EU. This might or might not be configurable by the user. The PC's I have seen have a country code of some kind built into them which controls the same thing.

    Back to the mask example above, one set to x'8420' would allow channels 1, 6, and 11 and the clients would roam [u]much[/u] faster as they would not be scanning unused channels.

    If the original devices were from France, Israel, or some other country, they may also have other channel restrictions that could keep the devices off the network. Other countries have power limitations that we do not. So if they had problems with range, or connecting at range, I would expect limits imposed in the original purchasers Regulatory Domain.

  • Thanks for the replies!

  • Theg,

    Please let us know what you finally figure out !

Page 1 of 1
  • 1