@Hank21 

Hank21 wrote

  @UKJim 

One SSID can have up to 128 passphrases. This is a performance restriction of the OC200. If you create two SSIDs, you can specify two profiles with the same VLAN ID. The router's ability to allocate VLANs allows them to be on the same VLAN.

However, I recomend you try setting up PPSK with an external radius, which will allow you to employ more passphrases. The external radius server determines the number of passphrases and the authentication process.

Here's how to configure PPSK with different RADIUS servers:PPSK Function with Different RADIUS Servers Configuration Guide

 

Hi Hank and thank you for your swift response.

I had considered whether setting up a Radius server was necessary, but its yet more expense and work for this project, which is essentially just wifi access (we have no internal business servers) for the traders for a 2-day event every year. The showground is a "greenfield" site, i.e. no buildings or structures, just open space which must be reverted back to empty fields when the show ends.

We obtained quotes from event wifi solution specialists, but these were going to be 4 or 5 times the cost (every year!) of us buying the network gear ourselves and reusing it on consecutive years. TP-Link Omada seems right for our event.

Another question about the PPSK without Radius (built-in Radius) please.

When creating the profiles using the auto-generate method, it asks for a PPSK Name Prefix, which it then appends underscore + a number to make each record unique, e.g. I created "HS-ts000" as the prefix which resulted in "HS-ts000_1", "HS-ts000_2", "HS-ts000_3", etc.

I thought this name would be shown somewhere in the Clients connection lists (perhaps in Insights->Known Clients or Past Connections) to help identify which PPSK the client connection relates to.

Can you tell me where the generated name is used/displayed? As this would be useful to understand which PPSK's are being used.

Thank you.

Jim

WiFiGuy01 wrote

I'm slightly confused. What are your reasons for wantiing to use individual PSK's for every stand if you're just going to have them all on the same VLAN?

 

Thinking this setup will work purely as a mesh setup is also very unwise and is a disaster waiting to happen. You should be using dedicated PtP backhaul links to each of the AP locations. 

Hi  @WiFiGuy01 

Reasons for wanting to use individual PSK's:-

As with any PPSK, security. Particularly in a situation where we want to be seen as doing our best to be PCI Compliant (Payment Card Industry).

Also you might see from my response to Hank above that I'm interested in being able to identify which clients (trade stands) are logging in. Either for support purposes, problems with logging on, or too many different logins against a single trade stand, for example the trader has shared their PSK with other people.

Disaster waiting to happen?

A bit more background on this project.....

Purpose:
To enable 250 businesses in trade stands site-wide around the showground to get reliable internet for taking payments using their own point-of-sale card payment systems.

Reason:
The traders normally use their mobile phones for internet connections but the show gets about 30,000 members of public over the weekend and the rural 4G service on our local telecoms masts becomes overwhelmed, so causing payment connection problems for the traders, and the show staff/employees who also suffer poor phone communication.

We would allow low-bandwidth (Rate Limited) connections for the traders to be able to run their business and sell their products. It's not really intended for video streaming(!), Facebook, voice/video calls, eg WhatsApp, but would probably get used for that to some extent. They are there to sell their wares, not play games or watch videos.

The payment transactions are very low bandwidth (2-3kb per transaction), plus emails and similar minimal business work so should be easy work for the network.

The show is a registered charity and needs to work to a tight budget. The Omada EAP Outdoor AP range (we've decided on EAP650's) look like they will provide what we need. However the network topology is what we welcome help and advice with.

The showground site is long and thin located in 2 large fields approx 150m wide and 660m long. There are some trees/hedges dotted around the site, but mostly open space. Access points would be put up on masts, marquee poles, lighting stands, and towers, and similar structures to gain some height for better coverage and avoiding obstacles like tall parked vehicles.

We envisage 2 mesh sets, each with a central Uplink AP, and 1 or 2 hop APs each side. Hopefully Mesh 1 would provide coverage for the bottom half of the site and the second mesh (Mesh 2 connected via a long-range bridge) covers the top half of the site.

Numerous diesel electricity generators supply mains power for the site, lighting, etc.

Laying ethernet cables is to be minimal due to cost and limitations of long PoE/ethernet runs and the size of the site and avoiding areas of most movement of public on foot and lots of show vehicles. There are no permanent buildings/structures since it is a "greenfield" site and all equipment has to be removed at the end of the show. Therefore we want to utilise a wireless backhaul mesh system. PoE would follow mains cables where laid to various (non-vehicle) areas of the showground, and Ethernet backhaul only where necessary to root AP's, wirelessly connected to the mesh APs.

Due to the length of the site a point-to-point bridge will be used, 2x CPE710 each one on tall masts, with a distance of approx 350m apart, to feed Mesh 2.

We have Gigabit fibre (1GB up/down) by a local provider into the site, into a cabinet where the main ONT, router, switch and controller will be sited.

Note the wifi network is NOT for public use! It will be a PCI Compliant secure authenticated (WPA2/3) private WLAN used only by the trade stands and show staff, therefore we don't consider it a High Density environment.

We understand that careful planning of Channels, Bandwidths, Tx power and frequencies are important for an optimised mesh solution. We have performed in-field testing to ascertain distances and speeds and mesh connectivity. We will use additional wired backhaul where possible.

Please feel free to offer any additional advice or concerns - we are not experts, but we are quick learners and we certainly don't want a disaster!

  @UKJim 

You can just run the external radius server on your computer.Currently, the controller client list does not include the ppsk name. We've already given feedback to our related department. It is used to determine which client connects to the password. However, it did not display.

  @WiFiGuy01 

OK, understood.

So ideally I should cable for wired backhaul from the switch located at each mesh to each AP?

I take it you have practical experience of Omada in this respect? Do you work with other brands of mesh devices?

Why would Omada offer wireless backhaul as a feature if it won't work?

Can you offer any advice for AP radio settings to provide best stability?

WiFiGuy01 wrote

  @UKJim 

 

...and especially one outdoors at an event where the noise floor will be impacted by thousands of mobile phones.

 

Every single one of your AP's should be backhauled to one or more central locations using PtP or PtMP connections.

 

  @WiFiGuy01 

Aha! That's the spanner in the works then. I hadn't appreciated that.

So not only do the thousands of mobile phones hammer the local phone network to the point its unusable.

They can also cause too much interference for the wireless backhaul to work properly.

Seriously, Thank you for firing a warning shot across our bow!

I hope you'll forgive me for wanting to ascertain you weren't just some doomsaying troll

So will the CPE710's likewise suffer as PtP, or are they less affected because they use a focused beam and if we use appropriate channel selection?

Should we use something else like 60Ghz PtP to get away from 5GHz ac/ax entirely?

Thank you for your valued input.

Much appreciated

Jim

  @Hank21 

Thanks, that's interesting

Hank21 wrote

Currently, the controller client list does not include the ppsk name. We've already given feedback to our related department. It is used to determine which client connects to the password. However, it did not display.

Any idea when this will be done?