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

New interface types for IP radio / wireless networking. #10077

New Issue
Closed
opened 2025-12-29 21:26:34 +01:00 by adam · 6 comments
adam commented 2025-12-29 21:26:34 +01:00
Owner
Copy Link

Originally created by @dallenk on GitHub (Aug 12, 2024).

NetBox version

4.06

Feature type

Data model extension

Proposed functionality

NetBox version
4.06

Feature type
New functionality

Proposed functionality
adding a new interface type for radio systems, which use N-type, TNC, or BNC connectors on the hardware. such as the Codan MT-4E transmitter/receiver cards (using N-type)

Use case
hardware used in radio systems, especially uhf/vhf are hybrid, and can combine IP interfaces with standard ethernet, and legacy connections to the field and antennas.

Database changes
i don't' believe this will need a new field.. but I'm not a coder.

External dependencies
No response

update

Apologies for the delay. I was on VA without internet access.

I am proposing 4 new connector types be included for device interfaces to accommodate a wide range of IP Radio rack mounted hardware currently in use by communications carriers and network providers. below are the most common types I used in the field, most often the "plug/male" is the cable connector, and the "jack/female" is the equipment side.

N-Type: (both plug and jack)
https://www.amphenolrf.com/rf-connectors/n-type-connectors.html
https://en.wikipedia.org/wiki/N_connector

TNC: (both plug and jack)
https://www.amphenolrf.com/rf-connectors/tnc-connectors.html
https://en.wikipedia.org/wiki/TNC_connector

BNC: (both plug and jack)
https://www.amphenolrf.com/rf-connectors/bnc-connectors.html
https://en.wikipedia.org/wiki/BNC_connector

SMA: (both plug and jack)
https://www.amphenolrf.com/rf-connectors/sma-connectors.html
https://en.wikipedia.org/wiki/SMA_connector

I hope this is enough for technical references you were looking for. If not let me know and I'll do what I can to provide you the right information.

some come in a "mini" size but for the purposes of netbox perhaps it doesn't need that much granularity?

Thank you!

Use case

These additions include interface types available in many carrier grade IP wireless and radio systems available to communications provider networsk.

Database changes

no database changes needed.. just additional interface types

External dependencies

No response

Originally created by @dallenk on GitHub (Aug 12, 2024). ### NetBox version 4.06 ### Feature type Data model extension ### Proposed functionality NetBox version 4.06 Feature type New functionality Proposed functionality adding a new interface type for radio systems, which use N-type, TNC, or BNC connectors on the hardware. such as the Codan MT-4E transmitter/receiver cards (using N-type) Use case hardware used in radio systems, especially uhf/vhf are hybrid, and can combine IP interfaces with standard ethernet, and legacy connections to the field and antennas. Database changes i don't' believe this will need a new field.. but I'm not a coder. External dependencies No response update Apologies for the delay. I was on VA without internet access. I am proposing 4 new connector types be included for device interfaces to accommodate a wide range of IP Radio rack mounted hardware currently in use by communications carriers and network providers. below are the most common types I used in the field, most often the "plug/male" is the cable connector, and the "jack/female" is the equipment side. N-Type: (both plug and jack) https://www.amphenolrf.com/rf-connectors/n-type-connectors.html https://en.wikipedia.org/wiki/N_connector TNC: (both plug and jack) https://www.amphenolrf.com/rf-connectors/tnc-connectors.html https://en.wikipedia.org/wiki/TNC_connector BNC: (both plug and jack) https://www.amphenolrf.com/rf-connectors/bnc-connectors.html https://en.wikipedia.org/wiki/BNC_connector SMA: (both plug and jack) https://www.amphenolrf.com/rf-connectors/sma-connectors.html https://en.wikipedia.org/wiki/SMA_connector I hope this is enough for technical references you were looking for. If not let me know and I'll do what I can to provide you the right information. some come in a "mini" size but for the purposes of netbox perhaps it doesn't need that much granularity? Thank you! ### Use case These additions include interface types available in many carrier grade IP wireless and radio systems available to communications provider networsk. ### Database changes no database changes needed.. just additional interface types ### External dependencies _No response_
adam added the type: feature label 2025-12-29 21:26:34 +01:00
adam closed this issue 2025-12-29 21:26:34 +01:00
adam commented 2025-12-29 21:26:34 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 15, 2024):

What you've listed are physical connector types for attaching an external antenna; they don't govern the transmission or receipt of data. The network interface type would likely be one of the IEEE 802.11 variants NetBox supports.

@jeremystretch commented on GitHub (Aug 15, 2024): What you've listed are physical connector types for attaching an external antenna; they don't govern the transmission or receipt of data. The network interface type would likely be one of the IEEE 802.11 variants NetBox supports.
adam commented 2025-12-29 21:26:34 +01:00
Author
Owner
Copy Link

@dallenk commented on GitHub (Aug 17, 2024):

hi @jeremystretch I'm not sure what you mean here?? how can I specify the correct interface for the module/device/port for a piece of radio equipment that uses these physical interface types? Physically, the antenna is not connected to this device, a patch cable is connected to a ground bar with lighting arrestors, the lighting arrestors are connected to another cable, which in turn is connected to the antenna.. the actual antenna does not connect to the back of these devices. These are absolutely not "WiFi" devices, they are UHF/VHF/Microwave radio systems powering carrier level communications networks.

image

Rx and Tx are for transmitting and receiving data over the air.. how is the medium, which is LMR-400 or RG-142 copper cable any different than an ethernet patch cable in terms of physical connectivity? Is there a different place i should put this request?

@dallenk commented on GitHub (Aug 17, 2024): hi @jeremystretch I'm not sure what you mean here?? how can I specify the correct interface for the module/device/port for a piece of radio equipment that uses these physical interface types? Physically, the antenna is not connected to this device, a patch cable is connected to a ground bar with lighting arrestors, the lighting arrestors are connected to another cable, which in turn is connected to the antenna.. the actual antenna does not connect to the back of these devices. These are absolutely not "WiFi" devices, they are UHF/VHF/Microwave radio systems powering carrier level communications networks. ![image](https://github.com/user-attachments/assets/0bbf6afb-13e1-4539-8662-dbe2191b75e2) Rx and Tx are for transmitting and receiving data over the air.. how is the medium, which is LMR-400 or RG-142 copper cable any different than an ethernet patch cable in terms of physical connectivity? Is there a different place i should put this request?
adam commented 2025-12-29 21:26:35 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Aug 18, 2024):

Rx and Tx are for transmitting and receiving data over the air.. how is the medium, which is LMR-400 or RG-142 copper cable any different than an ethernet patch cable in terms of physical connectivity? Is there a different place i should put this request?

For wireless, we model the 802.11## variants, the physical infrastructure between the access point and the end of the antenna is not modelled.

If you wanted to model this, you would model your antenna as a separate device and then the stuff in between would be front/rear ports, but I don't think it would translate well IMO.

@DanSheps commented on GitHub (Aug 18, 2024): > Rx and Tx are for transmitting and receiving data over the air.. how is the medium, which is LMR-400 or RG-142 copper cable any different than an ethernet patch cable in terms of physical connectivity? Is there a different place i should put this request? For wireless, we model the 802.11## variants, the physical infrastructure between the access point and the end of the antenna is not modelled. If you wanted to model this, you would model your antenna as a separate device and then the stuff in between would be front/rear ports, but I don't think it would translate well IMO.
adam commented 2025-12-29 21:26:35 +01:00
Author
Owner
Copy Link

@dallenk commented on GitHub (Aug 18, 2024):

Ok, so what about modeling different wireless technologies?   802.11 varients are wifi, but that is not the only wireless in use, especially for carrier systems and point2point networks.   I do see a coaxial section, could these technologies not be put there instead?   "Other" is just very generic, while these are specific.On Aug 18, 2024 09:56, Daniel Sheppard @.***> wrote:

Rx and Tx are for transmitting and receiving data over the air.. how is the medium, which is LMR-400 or RG-142 copper cable any different than an ethernet patch cable in terms of physical connectivity? Is there a different place i should put this request?

For wireless, we model the 802.11## variants, the physical infrastructure between the access point and the end of the antenna is not modelled

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

@dallenk commented on GitHub (Aug 18, 2024): Ok, so what about modeling different wireless technologies?   802.11 varients are wifi, but that is not the only wireless in use, especially for carrier systems and point2point networks.   I do see a coaxial section, could these technologies not be put there instead?   "Other" is just very generic, while these are specific.On Aug 18, 2024 09:56, Daniel Sheppard ***@***.***> wrote: Rx and Tx are for transmitting and receiving data over the air.. how is the medium, which is LMR-400 or RG-142 copper cable any different than an ethernet patch cable in terms of physical connectivity? Is there a different place i should put this request? For wireless, we model the 802.11## variants, the physical infrastructure between the access point and the end of the antenna is not modelled —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
adam commented 2025-12-29 21:26:35 +01:00
Author
Owner
Copy Link

@dallenk commented on GitHub (Aug 19, 2024):

perhaps this will help me explain better

If you wanted to model this, you would model your antenna as a separate device and then the stuff in between would be front/rear ports, but I don't think it would translate well IMO.

if I add a rear port, I can use BNC / N-type / SMA ect.. however, that doesn't really work as there wouldn't be a "front port" like it would be in a patch panel or 1:1 device such as a media converter, it does work with the lightning arrestors however, they are non-racked devices with N connectors. Not ideal, but it works
image

Here are the Interfaces used, which at this point is electrical, no different than an RJ-45 10/100 "interface" which really is just electrical voltage across copper pairs.. the UHF/VHF radio frequency is also just a modulated AC voltage using a copper medium such as coaxial (LMR-400, RG-58, RG-142)
image

But, there are no options for this other than "WiFi". There is a coaxial section, but only DOCSIS for what is usually a Cable ISP
image

It seems like the "device interface" is a technology, while a device front or rear "port" is a physical connection and not a technology. IMO the physical connection would be perfectly suited in the interface "type" dropdown. Or a new dropdown added for "physical connection type" where these could be selected for the technology/protocol ?

hope that helps describe a little better?

@dallenk commented on GitHub (Aug 19, 2024): perhaps this will help me explain better `If you wanted to model this, you would model your antenna as a separate device and then the stuff in between would be front/rear ports, but I don't think it would translate well IMO.` if I add a rear port, I can use BNC / N-type / SMA ect.. however, that doesn't really work as there wouldn't be a "front port" like it would be in a patch panel or 1:1 device such as a media converter, it does work with the lightning arrestors however, they are non-racked devices with N connectors. Not ideal, but it works ![image](https://github.com/user-attachments/assets/7ca932f0-6adb-40c5-a192-1eca377e783b) Here are the Interfaces used, which at this point is electrical, no different than an RJ-45 10/100 "interface" which really is just electrical voltage across copper pairs.. the UHF/VHF radio frequency is also just a modulated AC voltage using a copper medium such as coaxial (LMR-400, RG-58, RG-142) ![image](https://github.com/user-attachments/assets/28ab85d0-c991-4c78-8ccc-12395456b3d6) But, there are no options for this other than "WiFi". There is a coaxial section, but only DOCSIS for what is usually a Cable ISP ![image](https://github.com/user-attachments/assets/6e5b2141-99c3-42fa-ba88-cc21df4b4be4) It seems like the "device interface" is a technology, while a device front or rear "port" is a physical connection and not a technology. IMO the physical connection would be perfectly suited in the interface "type" dropdown. Or a new dropdown added for "physical connection type" where these could be selected for the technology/protocol ? hope that helps describe a little better?
adam commented 2025-12-29 21:26:36 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Aug 19, 2024):

You need to think of the rear port as internal to the device

@DanSheps commented on GitHub (Aug 19, 2024): You need to think of the rear port as internal to the device
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 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#10077
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?