starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Add 802.11ay and "Other Wireless" interface types #6773

New Issue
Closed
opened 2025-12-29 19:45:15 +01:00 by adam · 4 comments
adam commented 2025-12-29 19:45:15 +01:00
Owner
Copy Link

Originally created by @ZPrimed on GitHub (Aug 5, 2022).

Originally assigned to: @arthanson on GitHub.

NetBox version

v3.2.7

Feature type

Data model extension

Proposed functionality

I am proposing the addition of two types to the Interface model.

IEEE 802.11ay is a defined standard (it's an evolution of 802.11ad, which already exists in the list).

I would also like to propose the addition of some sort of "Other (Wireless)" placeholder type, to enable users to document that an interface is some form of "Wireless" rather than just "Other" (which implies one of the cabled types, rather than an RF interface).

Use case

802.11ay will benefit anybody who has this kind of equpment.

"Other (Wireless)" will give a user a way to cover any other type of proprietary RF interface that isn't already covered by NetBox (e.g. Siklu 8010 P2P radios, which run in the 70-80GHz E-band spectrum at 10Gbps). Without an "Other (Wireless)" option for Interface Type, the "Other" interface must be used which is treated like a cabled interface rather than an RF one.

Database changes

Uncertain but suspect nothing major is required here - two new types that are both classified as RF/Wireless instead of Cabled.

External dependencies

n/a

Originally created by @ZPrimed on GitHub (Aug 5, 2022). Originally assigned to: @arthanson on GitHub. ### NetBox version v3.2.7 ### Feature type Data model extension ### Proposed functionality I am proposing the addition of two types to the Interface model. [IEEE 802.11ay](https://en.wikipedia.org/wiki/IEEE_802.11ay) is a defined standard (it's an evolution of 802.11ad, which already exists in the list). I would also like to propose the addition of some sort of "Other (Wireless)" placeholder type, to enable users to document that an interface is some form of "Wireless" rather than just "Other" (which implies one of the cabled types, rather than an RF interface). ### Use case 802.11ay will benefit anybody who has this kind of equpment. "Other (Wireless)" will give a user a way to cover any other type of proprietary RF interface that isn't already covered by NetBox (e.g. Siklu 8010 P2P radios, which run in the 70-80GHz E-band spectrum at 10Gbps). Without an "Other (Wireless)" option for Interface Type, the "Other" interface must be used which is treated like a cabled interface rather than an RF one. ### Database changes Uncertain but suspect nothing major is required here - two new types that are both classified as RF/Wireless instead of Cabled. ### External dependencies n/a
adam added the status: acceptedtype: feature labels 2025-12-29 19:45:15 +01:00
adam closed this issue 2025-12-29 19:45:15 +01:00
adam commented 2025-12-29 19:45:16 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 22, 2022):

Just a reminder: The "Other - wireless" type will need to be added to WIRELESS_IFACE_TYPES in constants.py.

@jeremystretch commented on GitHub (Aug 22, 2022): Just a reminder: The "Other - wireless" type will need to be added to `WIRELESS_IFACE_TYPES` in `constants.py`.
adam commented 2025-12-29 19:45:16 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 23, 2022):

Should "Other - wireless" be listed under "other" or "wireless"? 🙂

@jeremystretch commented on GitHub (Aug 23, 2022): Should "Other - wireless" be listed under "other" or "wireless"? :slightly_smiling_face:
adam commented 2025-12-29 19:45:16 +01:00
Author
Owner
Copy Link

@ZPrimed commented on GitHub (Aug 23, 2022):

Hmmm... That's a tricky one. Since there's only one "Wireless" section, and all of the rest of the RF types are there, I'd lean to putting it at the very bottom of the "Wireless" section (if you can put something in a non-alpha sort in that list)... But I can see the logic behind putting it under "Other" as well.

There are a bunch of non-standard RF protocols so trying to list everything can get to be ridiculous... It's too bad that there's no way to make the Wireless model extendable by the end-user somehow. 😛

@ZPrimed commented on GitHub (Aug 23, 2022): Hmmm... That's a tricky one. Since there's only one "Wireless" section, and all of the rest of the RF types are there, I'd lean to putting it at the very bottom of the "Wireless" section (if you can put something in a non-alpha sort in that list)... But I can see the logic behind putting it under "Other" as well. There are a bunch of non-standard RF protocols so trying to list everything can get to be ridiculous... It's too bad that there's no way to make the Wireless model extendable by the end-user somehow. 😛
adam commented 2025-12-29 19:45:16 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 23, 2022):

It's too bad that there's no way to make the Wireless model extendable by the end-user somehow.

If it's a real-world piece of hardware we'll happily add it to the list.

@jeremystretch commented on GitHub (Aug 23, 2022): > It's too bad that there's no way to make the Wireless model extendable by the end-user somehow. If it's a real-world piece of hardware we'll happily add it to the list.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label status: accepted type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#6773
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?