Add WLAN model for creating/connecting wireless PtP/PtMP links #3201

@tyler-8 commented on GitHub (Jan 22, 2020):

rssi is a measurement of the signal's environment rather than a setting attached to a device. IMO that would fall under monitoring data and be outside the scope of Netbox.

I do like this idea however, it could potentially function for LTE/5G connectivity modeling.

@tyler-8 commented on GitHub (Jan 22, 2020): `rssi` is a measurement of the signal's environment rather than a setting attached to a device. IMO that would fall under monitoring data and be outside the scope of Netbox. I do like this idea however, it could potentially function for LTE/5G connectivity modeling.

adam commented

@cbock-clairglobal commented on GitHub (Jan 29, 2020):

rssi is a measurement of the signal's environment rather than a setting attached to a device. IMO that would fall under monitoring data and be outside the scope of Netbox.

@tyler-8
True and fair enough. I only proposed it as RSSI is one of the key metrics useful to document and reference should issues pop up or the environment change. 👍

@cbock-clairglobal commented on GitHub (Jan 29, 2020): > > > `rssi` is a measurement of the signal's environment rather than a setting attached to a device. IMO that would fall under monitoring data and be outside the scope of Netbox. > @tyler-8 True and fair enough. I only proposed it as RSSI is one of the key metrics useful to document and reference should issues pop up or the environment change. 👍

adam commented

@millijuna commented on GitHub (Jan 30, 2020):

Except for the fact that Netbox deliberately seems to avoid having per-interface info other than IP and so froth, I think EIRP would be a better metric to record, rather than RSSI. That said, adding similar functionality for fiber links might also be good (record wavelength for CWDM/DWDM links, and Tx power for long-haul links). The latter is probably its own FR though.

@millijuna commented on GitHub (Jan 30, 2020): Except for the fact that Netbox deliberately seems to avoid having per-interface info other than IP and so froth, I think EIRP would be a better metric to record, rather than RSSI. That said, adding similar functionality for fiber links might also be good (record wavelength for CWDM/DWDM links, and Tx power for long-haul links). The latter is probably its own FR though.

adam commented

@mokas01 commented on GitHub (Feb 12, 2020):

wouldn't it be useful to know which config (PtP or PtMP) has been set on each AP antenna ? Could avoid some trouble on the field (at least some PtMP AP kick all connected clients if you try to connect to them with a PtP configured station)

@mokas01 commented on GitHub (Feb 12, 2020): wouldn't it be useful to know which config (PtP or PtMP) has been set on each AP antenna ? Could avoid some trouble on the field (at least some PtMP AP kick all connected clients if you try to connect to them with a PtP configured station)

adam commented

@MajesticFalcon commented on GitHub (Mar 14, 2020):

rssi is a measurement of the signal's environment rather than a setting attached to a device. IMO that would fall under monitoring data and be outside the scope of Netbox.

@tyler-8
True and fair enough. I only proposed it as RSSI is one of the key metrics useful to document and reference should issues pop up or the environment change. 👍

I agree. It it extremely useful to know what the "installed rssi" is. Same with fiber. "installed tx-power" and "installed rx-power." Your monitoring system "should" be able to maintain these values, but it having it documented as a custom field would also be helpful.

@MajesticFalcon commented on GitHub (Mar 14, 2020): > > `rssi` is a measurement of the signal's environment rather than a setting attached to a device. IMO that would fall under monitoring data and be outside the scope of Netbox. > > @tyler-8 > True and fair enough. I only proposed it as RSSI is one of the key metrics useful to document and reference should issues pop up or the environment change. 👍 I agree. It it extremely useful to know what the "installed rssi" is. Same with fiber. "installed tx-power" and "installed rx-power." Your monitoring system "should" be able to maintain these values, but it having it documented as a custom field would also be helpful.

adam commented

https://github.com/netbox-community/netbox/issues/722

@MajesticFalcon commented on GitHub (Apr 15, 2020):

As I am mid way through attempting to migrate different portions of our entire device management software over to netbox I have now encountered why it might not fit as well as originally hoped. We have just under 1000 radio links and there is specific information that needs to be coupled with the radio. I started using custom fields, but then quickly realized that you can't add a custom field to a specific device type. It definitely doesn't pertain to everybody, but we have the following fields for each radio. Freqency band, Service class (backhaul, repeater, access), SSID, Channel Width, Center Frequency, Azimuth, Beamwidth, Downtilt, height.

@MajesticFalcon commented on GitHub (Apr 15, 2020): As I am mid way through attempting to migrate different portions of our entire device management software over to netbox I have now encountered why it might not fit as well as originally hoped. We have just under 1000 radio links and there is specific information that needs to be coupled with the radio. I started using custom fields, but then quickly realized that you can't add a custom field to a specific device type. It definitely doesn't pertain to everybody, but we have the following fields for each radio. Freqency band, Service class (backhaul, repeater, access), SSID, Channel Width, Center Frequency, Azimuth, Beamwidth, Downtilt, height. https://github.com/netbox-community/netbox/issues/722

adam commented

@MajesticFalcon commented on GitHub (Aug 18, 2020):

I am a little unfamiliar with the process new features go through. Does "needs milestone" mean this has been accepted and will be implemented?

@MajesticFalcon commented on GitHub (Aug 18, 2020): I am a little unfamiliar with the process new features go through. Does "needs milestone" mean this has been accepted and will be implemented?

adam commented

@jeremystretch commented on GitHub (Aug 18, 2020):

@MajesticFalcon you can see the description of each issue label here. This FR has been shelved until it gets designated as part of a future NetBox release.

@jeremystretch commented on GitHub (Aug 18, 2020): @MajesticFalcon you can see the description of each issue label [here](https://github.com/netbox-community/netbox/labels). This FR has been shelved until it gets designated as part of a future NetBox release.

adam commented

@BarbarossaTM commented on GitHub (Oct 15, 2020):

I really like this idea/feature and am looking for something like this for a while <3

I would propose a little different approach than the original idea and allow to only link interfaces of a WIFI type as this describes the reality better. Linking bridges might be correct most of the times, but isn't what really happens over the air and wifi devices might even be configured as L3 devices.

What I'm wondering is how to denote the wifi mode (AP PTP, AP PTMP, Station) of a device/an interface/a SSID. Usually it probably will be a setting for the whole device but actually be a setting of the wifi interface/SSID. Maybe these could be attributes of the interface which "appear" like the untagged/tagged options of interfaces when you set a VLAN mode? And stuff like SSID, frequency, auth, etc. can become parameters of the "cable" equivalent?

@BarbarossaTM commented on GitHub (Oct 15, 2020): I really like this idea/feature and am looking for something like this for a while <3 I would propose a little different approach than the original idea and allow to only link interfaces of a WIFI type as this describes the reality better. Linking bridges might be correct most of the times, but isn't what really happens over the air and wifi devices might even be configured as L3 devices. What I'm wondering is how to denote the wifi mode (AP PTP, AP PTMP, Station) of a device/an interface/a SSID. Usually it probably will be a setting for the whole device but actually be a setting of the wifi interface/SSID. Maybe these could be attributes of the interface which "appear" like the untagged/tagged options of interfaces when you set a VLAN mode? And stuff like SSID, frequency, auth, etc. can become parameters of the "cable" equivalent?

adam commented

@MajesticFalcon commented on GitHub (Nov 23, 2020):

I am very excited to see this be accepted. This will allow me to finally move our entire equipment database off our custom solution to Netbox. Thank you.

@MajesticFalcon commented on GitHub (Nov 23, 2020): I am very excited to see this be accepted. This will allow me to finally move our entire equipment database off our custom solution to Netbox. Thank you.

adam commented

@jeremystretch commented on GitHub (Mar 4, 2021):

I'd like to work on fleshing out the proposed data model so that we can move forward with the feature. It's been a long time since I worked directly with wireless in a professional setting, so I'll be leaning on the more familiar folks for guidance here.

In its most basic form, we can consider a wireless LAN to be a "layer one" concept; essentially a bus network. However, in practice, we often employ WLANs in one of two specific topologies:

Point-to-point (a direct link between exactly two nodes)
Point-to-multipoint (a multiaccess link with all spokes communicating to a common node/access point)

If we care about differentiating these topologies, the data model needs to support that.

Additionally, I could use some help determining exactly which attributes of a WLAN we need to track, and what the potential values are for each. For example:

Type: 802.11a, 802,11g, 802.11n, ...
Channel: Frequency, number and/or width?
SSID
Authentication type: None, PSK, EAP, others?

As mentioned above, we want to stick to attributes that are administratively configurable; so not, for example, receive signal strength or noise ration. It's also important to distinguish between attributes of the WLAN and attributes of the interfaces which attach to it.

@jeremystretch commented on GitHub (Mar 4, 2021): I'd like to work on fleshing out the proposed data model so that we can move forward with the feature. It's been a _long_ time since I worked directly with wireless in a professional setting, so I'll be leaning on the more familiar folks for guidance here. In its most basic form, we can consider a wireless LAN to be a "layer one" concept; essentially a bus network. However, in practice, we often employ WLANs in one of two specific topologies: * Point-to-point (a direct link between exactly two nodes) * Point-to-multipoint (a multiaccess link with all spokes communicating to a common node/access point) If we care about differentiating these topologies, the data model needs to support that. Additionally, I could use some help determining exactly which attributes of a WLAN we need to track, and what the potential values are for each. For example: * Type: 802.11a, 802,11g, 802.11n, ... * Channel: Frequency, number and/or width? * SSID * Authentication type: None, PSK, EAP, others? As mentioned above, we want to stick to attributes that are _administratively configurable_; so not, for example, receive signal strength or noise ration. It's also important to distinguish between attributes of the WLAN and attributes of the _interfaces_ which attach to it.

adam commented

@MajesticFalcon commented on GitHub (Mar 4, 2021):

I wrote a plugin model for us. Some of the features include:
Antenna gain (in dBi)
Radio max power (in dBm)
Beamwidth
Channel width
Frequency
Licensed
Dynamic frequency selection
Lan mode (routed or bridged)
Type (siso, Mimo, mumimo)

There’s probably more, but those are off the top of my head. They may not fit into the core Netbox, but they are values I wrote in the Netbox plug-in for us. Let me know if you have any more questions!

On Mar 4, 2021, at 12:21 PM, Jeremy Stretch notifications@github.com wrote:

I'd like to work on fleshing out the proposed data model so that we can move forward with the feature. It's been a long time since I worked directly with wireless in a professional setting, so I'll be leaning on the more familiar folks for guidance here.

In its most basic form, we can consider a wireless LAN to be a "layer one" concept; essentially a bus network. However, in practice, we often employ WLANs in one of two specific topologies:

Point-to-point (a direct link between exactly two nodes)
Point-to-multipoint (a multiaccess link with all spokes communicating to a common node/access point)

If we care about differentiating these topologies, the data model needs to support that.

Additionally, I could use some help determining exactly which attributes of a WLAN we need to track, and what the potential values are for each. For example:

Type: 802.11a, 802,11g, 802.11n, ...
Channel: Frequency, number and/or width?
SSID
Authentication type: None, PSK, EAP, others?

As mentioned above, we want to stick to attributes that are administratively configurable; so not, for example, receive signal strength or noise ration. It's also important to distinguish between attributes of the WLAN and attributes of the interfaces which attach to it.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/netbox-community/netbox/issues/3979#issuecomment-790826338, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACBR6OKOL3KEJWX7XPRR7E3TB7FQ7ANCNFSM4KJZFL3Q.

@MajesticFalcon commented on GitHub (Mar 4, 2021): I wrote a plugin model for us. Some of the features include: Antenna gain (in dBi) Radio max power (in dBm) Beamwidth Channel width Frequency Licensed Dynamic frequency selection Lan mode (routed or bridged) Type (siso, Mimo, mumimo) There’s probably more, but those are off the top of my head. They may not fit into the core Netbox, but they are values I wrote in the Netbox plug-in for us. Let me know if you have any more questions! On Mar 4, 2021, at 12:21 PM, Jeremy Stretch <notifications@github.com> wrote: I'd like to work on fleshing out the proposed data model so that we can move forward with the feature. It's been a long time since I worked directly with wireless in a professional setting, so I'll be leaning on the more familiar folks for guidance here. In its most basic form, we can consider a wireless LAN to be a "layer one" concept; essentially a bus network. However, in practice, we often employ WLANs in one of two specific topologies: * Point-to-point (a direct link between exactly two nodes) * Point-to-multipoint (a multiaccess link with all spokes communicating to a common node/access point) If we care about differentiating these topologies, the data model needs to support that. Additionally, I could use some help determining exactly which attributes of a WLAN we need to track, and what the potential values are for each. For example: * Type: 802.11a, 802,11g, 802.11n, ... * Channel: Frequency, number and/or width? * SSID * Authentication type: None, PSK, EAP, others? As mentioned above, we want to stick to attributes that are administratively configurable; so not, for example, receive signal strength or noise ration. It's also important to distinguish between attributes of the WLAN and attributes of the interfaces which attach to it. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://github.com/netbox-community/netbox/issues/3979#issuecomment-790826338>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACBR6OKOL3KEJWX7XPRR7E3TB7FQ7ANCNFSM4KJZFL3Q>.

adam commented

@BarbarossaTM commented on GitHub (Mar 4, 2021):

Hi Jeremy,

In its most basic form, we can consider a wireless LAN to be a "layer one" concept; essentially a bus network. However, in practice, we often employ WLANs in one of two specific topologies:

Point-to-point (a direct link between exactly two nodes)
Point-to-multipoint (a multiaccess link with all spokes communicating to a common node/access point)
If we care about differentiating these topologies, the data model needs to support that.

Indeed. I propose a new type (let's say) Wifi Connection which is similar to a Circuit. Ideally this object has a boolean parameter for PTP vs. PTMP and depending on this setting two or more endpoints can be connected if they are compatible (see below). This way it would be possible to later "just" switch from PTP to PTMP and not having to remove and recreate the Wifi Connection. I think this way would be preferable over two different object types even if one would have to distinguish between PTP and PTMP. On first glance it looks to me like this would only be relevant when connecting endpoint.

Additionally, I could use some help determining exactly which attributes of a WLAN we need to track, and what the potential values are for each. For example:

Type: 802.11a, 802,11g, 802.11n, ...

One could argue that this could be defined through the endpoints being connected to the Wifi Connection by leveraging the type of the interfaces being connected, using the first one connected as the type for the Wifi Connection and checking that the 2nd one (and possibly others) are compatible (or strictly the same?).

Channel: Frequency, number and/or width?
SSID
Authentication type: None, PSK, EAP, others?

Yes, those are required.

I propose:

SSID
Frequency (MHz)
Channel width (MHz) (drop down with 10/20/30/40/../160?)

Maybe a distinction between a Control Frequency and a Center Frequency might be useful. I propose both fields being string and not Integer so people can supply lists when working in 5 GHz bands which require DFS.

Auth is harder, the obvious choices are None, WPA2-PSK and then it's getting complicated as there are a number of options for WPA2 Enterprise stuff (EAP with PAP, CHAP, TLS, TTLS, ...) and WPA3 as well as iPSK (different keys can be mapped to different networks). I'm unsure how to model this. It might be worth having something like "auth type" being one of { None, WPA2-PSK, WPA2-Enterprise, WPA3, iPSK } and having different fields for details of those.

It would be required to denote which device is in AP mode and which in station mode. This might be something that is part of the endpoint (or maybe even interface) configuration. I'm thinking of something similar to the Circuits model where endpoints can be connected and the endpoint connection has attributes on it's own. This would include a check that only one endpoint can be in AP mode.

It would be cool if the interface or endpoint had attributes for the output power (dBm) which might best be modelled using a signed integer or string.

Best
Max

@BarbarossaTM commented on GitHub (Mar 4, 2021): Hi Jeremy, > In its most basic form, we can consider a wireless LAN to be a "layer one" concept; essentially a bus network. However, in practice, we often employ WLANs in one of two specific topologies: > > Point-to-point (a direct link between exactly two nodes) > Point-to-multipoint (a multiaccess link with all spokes communicating to a common node/access point) > If we care about differentiating these topologies, the data model needs to support that. Indeed. I propose a new type (let's say) _Wifi Connection_ which is similar to a Circuit. Ideally this object has a boolean parameter for PTP vs. PTMP and depending on this setting two or more endpoints can be connected if they are compatible (see below). This way it would be possible to later "just" switch from PTP to PTMP and not having to remove and recreate the _Wifi Connection_. I think this way would be preferable over two different object types even if one would have to distinguish between PTP and PTMP. On first glance it looks to me like this would only be relevant when connecting endpoint. > Additionally, I could use some help determining exactly which attributes of a WLAN we need to track, and what the potential values are for each. For example: > > Type: 802.11a, 802,11g, 802.11n, ... One could argue that this could be defined through the endpoints being connected to the _Wifi Connection_ by leveraging the type of the interfaces being connected, using the first one connected as the type for the _Wifi Connection_ and checking that the 2nd one (and possibly others) are compatible (or strictly the same?). > Channel: Frequency, number and/or width? > SSID > Authentication type: None, PSK, EAP, others? Yes, those are required. I propose: - SSID - Frequency (MHz) - Channel width (MHz) (drop down with 10/20/30/40/../160?) Maybe a distinction between a Control Frequency and a Center Frequency might be useful. I propose both fields being string and not Integer so people can supply lists when working in 5 GHz bands which require DFS. Auth is harder, the obvious choices are None, WPA2-PSK and then it's getting complicated as there are a number of options for WPA2 Enterprise stuff (EAP with PAP, CHAP, TLS, TTLS, ...) and WPA3 as well as iPSK (different keys can be mapped to different networks). I'm unsure how to model this. It might be worth having something like "auth type" being one of { None, WPA2-PSK, WPA2-Enterprise, WPA3, iPSK } and having different fields for details of those. It would be required to denote which device is in AP mode and which in station mode. This might be something that is part of the endpoint (or maybe even interface) configuration. I'm thinking of something similar to the Circuits model where endpoints can be connected and the endpoint connection has attributes on it's own. This would include a check that only one endpoint can be in AP mode. It would be cool if the interface or endpoint had attributes for the output power (dBm) which might best be modelled using a signed integer or string. Best Max

adam commented

@cbock-clairglobal commented on GitHub (Mar 4, 2021):

I think most of the comments here are right on regarding common settings/fields. To add to what’s already been said, see this screenshot taken from the wireless settings page of a newer Ubiquiti LTU Rocket. The settings circled in red are found on pretty much all PTP/PTMP wireless bridge radios. Those settings are:

- SSID / LINK NAME
- Key / Password
- Channel Frequency
- Channel Bandwidth
- Radio Mode (Access Point or Station)
- Access Point Mode (PTP or PtMP)
- Radio Gain / Output Power / Tx Power (dBm)
- Antenna Gain (dBm)
- Antenna Type (maybe this is just an inventory item?)

Couple notes:

Channel Frequency: For a PTP/PTMP wireless bridge this is often represented as either a common channel number or the “center frequency” (depending on how wide the channel is). While the channel numbers do reference particular center frequencies (see here), it seems like most wireless bridge radios explicitly list the center frequency in the settings pages. Having said that, WiFi WAPs --like the kind found in buildings to connect end users to the wired network-- typically reference the operating frequency by the channel number instead (e.g. 2.4GHz channels are set to 1, 6 or 11).

Additionally, some folks might be interested in tracking 5GHz radios that are operating on DFS frequencies. DFS overlaps a large part of the 5GHz spectrum and most radios simply let you know when you've selected a frequency in the DFS range.

One thing to keep in mind is that most wireless devices now have numerous radios-- 3x3 MIMO has 1x 2.4GHz and 2x 5GHz radios, while some PTP radios use a primary (60GHz) and failover (5GHz) radio for redundancy. In these situations one of the device radios might mesh with another device for an uplink, while the remaining radios service clients. That’s the case with Meraki WAPs where the 2.4GHz radios can be used to bridge/mesh a WAP while the 5GHz radios broadcast SSIDs for end user connectivity. In those cases I could see each radio being a type of ‘interface’ with certain trackable fields being associated (SSID/VLAN, Password, Freq/Chan, Chan Width).

Radio Mode / Access Point Mode: Wireless bridges are either an AP or a station, and APs are typically set to either PTP or PTMP mode.

Type: As you mentioned, WiFi has numerous versions of 802.11 that could be referenced. As opposed to a PTP/PTMP radios which use a variety of protocols (for instance, Ubiquiti’s proprietary AirMAX which don't use 802.11 at all. Not sure how that would be modeled or if it is even necessary. Typically I’ve tracked/inferred that information by the model number of the devices themselves (Cisco Catalyst 9130AX = 802.11ax/WiFi6).

@cbock-clairglobal commented on GitHub (Mar 4, 2021): I think most of the comments here are right on regarding common settings/fields. To add to what’s already been said, see [this screenshot](https://i.imgur.com/OgeBJCH.png) taken from the wireless settings page of a newer Ubiquiti LTU Rocket. The settings circled in red are found on pretty much all PTP/PTMP wireless bridge radios. Those settings are: **- SSID / LINK NAME** **- Key / Password** **- Channel Frequency** **- Channel Bandwidth** **- Radio Mode** (Access Point or Station) **- Access Point Mode** (PTP or PtMP) **- Radio Gain / Output Power / Tx Power** (dBm) **- Antenna Gain** (dBm) **- Antenna Type** (maybe this is just an inventory item?) **Couple notes:** **Channel Frequency:** For a PTP/PTMP wireless bridge this is often represented as either a common channel number or the “center frequency” (depending on how wide the channel is). While the channel numbers do reference particular center frequencies ([see here](https://en.wikipedia.org/wiki/List_of_WLAN_channels#5_GHz_(802.11a/h/j/n/ac/ax))), it seems like most wireless bridge radios explicitly list the center frequency in the settings pages. Having said that, WiFi WAPs --like the kind found in buildings to connect end users to the wired network-- typically reference the operating frequency by the channel number instead (e.g. 2.4GHz channels are set to 1, 6 or 11). Additionally, some folks might be interested in tracking 5GHz radios that are operating on [DFS](https://www.wi-fi.org/knowledge-center/faq/what-is-dynamic-frequency-selection-dfs) frequencies. DFS overlaps a large part of the [5GHz spectrum](https://twimgs.com/networkcomputing/news/2013/10/graphic-80211-acChannels-all.png) and most radios simply let you know when you've selected a frequency in the DFS range. One thing to keep in mind is that most wireless devices now have numerous radios-- 3x3 MIMO has 1x 2.4GHz and 2x 5GHz radios, while [some PTP radios](https://store.ui.com/collections/operator-airmax-and-ltu/products/gbe) use a primary (60GHz) and failover (5GHz) radio for redundancy. In these situations one of the device radios might mesh with another device for an uplink, while the remaining radios service clients. That’s the case with Meraki WAPs where the 2.4GHz radios can be used to bridge/mesh a WAP while the 5GHz radios broadcast SSIDs for end user connectivity. In those cases I could see each radio being a type of ‘interface’ with certain trackable fields being associated (SSID/VLAN, Password, Freq/Chan, Chan Width). **Radio Mode / Access Point Mode**: Wireless bridges are either an AP or a station, and APs are typically set to either PTP or PTMP mode. **Type:** As you mentioned, WiFi has numerous versions of 802.11 that could be referenced. As opposed to a PTP/PTMP radios which use a variety of protocols (for instance, Ubiquiti’s proprietary [AirMAX](https://dl.ubnt.com/datasheets/airmax/UBNT_DS_airMAX_TDMA.pdf) which don't use 802.11 at all. Not sure how that would be modeled or if it is even necessary. Typically I’ve tracked/inferred that information by the model number of the devices themselves (Cisco Catalyst 9130AX = 802.11ax/WiFi6).

adam commented

@ghost commented on GitHub (Mar 6, 2021):

More vendor agnostic interface labeling would help in cases where a Cambium or Siklu radio is used vs. Ubiquiti. Cambium does not use SSID but color codes (CC) and MAC addresses for interface referencing.

@ghost commented on GitHub (Mar 6, 2021): More vendor agnostic interface labeling would help in cases where a Cambium or Siklu radio is used vs. Ubiquiti. Cambium does not use SSID but color codes (CC) and MAC addresses for interface referencing.

adam commented

@mjducharme commented on GitHub (Mar 6, 2021):

I think "Estimated Capacity" would probably be a useful metric to have as well, as the estimated maximum rate that the wireless link will be able to handle. The reason is for planning purposes - if a customer says they want a 100Mbps circuit from point A to point Z with dedicated bandwidth, you need to be able to easily make sure that you have the bandwidth available before agreeing to sell the service. Looking at live traffic for that information is not necessarily a good metric because there may be an outage that is temporarily removing some of the traffic that would normally be travelling across those links, and also the need to make sure enough bandwidth is left over for retail customers to use.

@mjducharme commented on GitHub (Mar 6, 2021): I think "Estimated Capacity" would probably be a useful metric to have as well, as the estimated maximum rate that the wireless link will be able to handle. The reason is for planning purposes - if a customer says they want a 100Mbps circuit from point A to point Z with dedicated bandwidth, you need to be able to easily make sure that you have the bandwidth available before agreeing to sell the service. Looking at live traffic for that information is not necessarily a good metric because there may be an outage that is temporarily removing some of the traffic that would normally be travelling across those links, and also the need to make sure enough bandwidth is left over for retail customers to use.

adam commented

@mattguthmiller commented on GitHub (Mar 6, 2021):

In an enterprise/carrier setting, microwave links do not transmit and receive on the same frequency, so it would be helpful to have separate fields for each.

@mattguthmiller commented on GitHub (Mar 6, 2021): In an enterprise/carrier setting, microwave links do not transmit and receive on the same frequency, so it would be helpful to have separate fields for each.

adam commented

@1da1a172 commented on GitHub (Mar 10, 2021):

Can I get some clarification on the scope of this? Most of the comments seem centered around wireless connections between managed devices (e.g., mesh), but some of the conversation seems to also relate to APs for end users to connect to (e.g., AP to STA). Is the second one in scope here?

Auth is harder, the obvious choices are None, WPA2-PSK and then it's getting complicated as there are a number of options for WPA2 Enterprise stuff (EAP with PAP, CHAP, TLS, TTLS, ...) and WPA3 as well as iPSK (different keys can be mapped to different networks). I'm unsure how to model this. It might be worth having something like "auth type" being one of { None, WPA2-PSK, WPA2-Enterprise, WPA3, iPSK } and having different fields for details of those.

Technically, the different authentication methods within WPA2 (non psk) is a a function of the authentication server, not the AP. Of course, if you are also configuring the STA (e.g., the remote end of a bridge), then these things still need to be configured.

Radio max power

This can mean several different things:

max power that can be configured (a hardware limit of the radio/antenna)
max power allowed by the regulatory domain (what the FCC will allow for this radio/antenna)
upper end of the range the admin set to allow the AP to choose within (note, this also implies a min power)

@1da1a172 commented on GitHub (Mar 10, 2021): Can I get some clarification on the scope of this? Most of the comments seem centered around wireless connections between managed devices (e.g., mesh), but some of the conversation seems to also relate to APs for end users to connect to (e.g., AP to STA). Is the second one in scope here? > Auth is harder, the obvious choices are None, WPA2-PSK and then it's getting complicated as there are a number of options for WPA2 Enterprise stuff (EAP with PAP, CHAP, TLS, TTLS, ...) and WPA3 as well as iPSK (different keys can be mapped to different networks). I'm unsure how to model this. It might be worth having something like "auth type" being one of { None, WPA2-PSK, WPA2-Enterprise, WPA3, iPSK } and having different fields for details of those. Technically, the different authentication methods within WPA2 (non psk) is a a function of the authentication server, not the AP. Of course, if you are also configuring the STA (e.g., the remote end of a bridge), then these things still need to be configured. > Radio max power This can mean several different things: - max power that can be configured (a hardware limit of the radio/antenna) - max power allowed by the regulatory domain (what the FCC will allow for this radio/antenna) - upper end of the range the admin set to allow the AP to choose within (note, this also implies a min power)

adam commented

@jeremystretch commented on GitHub (Mar 10, 2021):

Can I get some clarification on the scope of this?

I find myself asking the same question. 😆

As we've seen, there's certainly a lot involved in modeling wireless connections. I think my biggest hurdle at this point is properly decoupling the physical layer (channel frequency and bandwidth) from the data layer (SSID, AP mode, etc.). It's also evident from the discussion that some distinction needs to be made between traditional WLAN point-to-point links and those which utilize microwave transponders.

As we're currently targeting early April for the first v2.11 beta release, I'm not sure we'll have sufficient time to form and flesh out a suitable model. IMO it would be best at this point to punt this implementation to v2.12 and dedicate more time to ensuring we our modeling approach is correct. It would be ideal to form a sort of working group with several wireless experts to help guide this initiative.

@jeremystretch commented on GitHub (Mar 10, 2021): > Can I get some clarification on the scope of this? I find myself asking the same question. :laughing: As we've seen, there's certainly a lot involved in modeling wireless connections. I think my biggest hurdle at this point is properly decoupling the physical layer (channel frequency and bandwidth) from the data layer (SSID, AP mode, etc.). It's also evident from the discussion that some distinction needs to be made between traditional WLAN point-to-point links and those which utilize microwave transponders. As we're currently targeting early April for the first v2.11 beta release, I'm not sure we'll have sufficient time to form and flesh out a suitable model. IMO it would be best at this point to punt this implementation to v2.12 and dedicate more time to ensuring we our modeling approach is correct. It would be ideal to form a sort of working group with several wireless experts to help guide this initiative.

adam commented

@jeremystretch commented on GitHub (Mar 15, 2021):

We're going to have to punt this from v2.11 unfortunately, to provide time to identify and draft a sufficiently robust implementation of the wireless model.

@jeremystretch commented on GitHub (Mar 15, 2021): We're going to have to punt this from v2.11 unfortunately, to provide time to identify and draft a sufficiently robust implementation of the wireless model.

adam commented

@jeremystretch commented on GitHub (Mar 17, 2021):

Tentatively tagging this for v2.12, though we clearly still need a game plan.

@jeremystretch commented on GitHub (Mar 17, 2021): Tentatively tagging this for v2.12, though we clearly still need a game plan.

adam commented

@BarbarossaTM commented on GitHub (Mar 17, 2021):

I really like seeing this feature in the future. What can I do to help? Is it worth building a plugin and trying to generically model the part I can think of as a PoC?

@BarbarossaTM commented on GitHub (Mar 17, 2021): I really like seeing this feature in the future. What can I do to help? Is it worth building a plugin and trying to generically model the part I can think of as a PoC?

adam commented

@millijuna commented on GitHub (Mar 18, 2021):

IMHO, the KISS principle should be followed as much as possible. The critical info for wireless links seems to be frequency, wireless type, and unit role. My biggest concern is that adding wireless type as an enumerated type would lead to the same situation that's with cable interface types, which becomes a maintenance problem for maintainers. Could not the other functions mentioned (max power, antenna gain, etc... ) be handled through custom fields or similar?

@millijuna commented on GitHub (Mar 18, 2021): IMHO, the KISS principle should be followed as much as possible. The critical info for wireless links seems to be frequency, wireless type, and unit role. My biggest concern is that adding wireless type as an enumerated type would lead to the same situation that's with cable interface types, which becomes a maintenance problem for maintainers. Could not the other functions mentioned (max power, antenna gain, etc... ) be handled through custom fields or similar?

adam commented

@martinum4 commented on GitHub (Apr 23, 2021):

Maybe separate Wireless networks and the interface stuff from each other, kind of similar to the Provider Networks feature.
E.g. Model the wireless network first, then add a connection between interface and network.

Preferably we would have the options for antennas too and have them integrated in a trace feature.

Example-Trace:
Device A;Interface A <-> Cable-A1 <-> Patchpanel A <-> Cable-A2<-> Antenna-A <-> Wireless-network <-> Antenna-B <-> Cable-B <-> Device B; Interface B

Location of the Antennas can be done conventionally over the locations (e.g. Location Mast A, sublocation 20 Meters, sublocation 40 Meters)

Also, why stop at WLAN? In the basic this feature could be useful for cellular or WiMAX network operators too.

@martinum4 commented on GitHub (Apr 23, 2021): Maybe separate Wireless networks and the interface stuff from each other, kind of similar to the Provider Networks feature. E.g. Model the wireless network first, then add a connection between interface and network. Preferably we would have the options for antennas too and have them integrated in a trace feature. Example-Trace: Device A;Interface A <-> Cable-A1 <-> Patchpanel A <-> Cable-A2<-> Antenna-A <-> Wireless-network <-> Antenna-B <-> Cable-B <-> Device B; Interface B Location of the Antennas can be done conventionally over the locations (e.g. Location Mast A, sublocation 20 Meters, sublocation 40 Meters) Also, why stop at WLAN? In the basic this feature could be useful for cellular or WiMAX network operators too.

adam commented

@jeremystretch commented on GitHub (May 4, 2021):

Bumping this from v2.12 as we've decided to focus primarily on the UI overhaul for this release. Will revisit soon. I'd actually like to put together a working group of wireless experts in the meantime to help inform the modeling.

@jeremystretch commented on GitHub (May 4, 2021): Bumping this from v2.12 as we've decided to focus primarily on the UI overhaul for this release. Will revisit soon. I'd actually like to put together a working group of wireless experts in the meantime to help inform the modeling.

adam commented