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

Treat cellular interface type as not connectable #11280

New Issue
Closed
opened 2025-12-29 21:42:49 +01:00 by adam · 11 comments
adam commented 2025-12-29 21:42:49 +01:00
Owner
Copy Link

Originally created by @Omripresent on GitHub (Jun 9, 2025).

Originally assigned to: @Omripresent on GitHub.

Deployment Type

Self-hosted

NetBox Version

v4.2.6

Python Version

3.12

Steps to Reproduce

  1. Create interface type LTE
  2. Via nbshell retrieve the interface
  3. call the is_wired property

Expected Behavior

is_wired should return False

Observed Behavior

is_wired returns True

Originally created by @Omripresent on GitHub (Jun 9, 2025). Originally assigned to: @Omripresent on GitHub. ### Deployment Type Self-hosted ### NetBox Version v4.2.6 ### Python Version 3.12 ### Steps to Reproduce 1. Create interface type LTE 2. Via nbshell retrieve the interface 3. call the is_wired property ### Expected Behavior is_wired should return False ### Observed Behavior is_wired returns True
adam added the type: bugstatus: acceptedseverity: low labels 2025-12-29 21:42:49 +01:00
adam closed this issue 2025-12-29 21:42:49 +01:00
adam commented 2025-12-29 21:42:50 +01:00
Author
Owner
Copy Link

@Omripresent commented on GitHub (Jun 9, 2025):

The following types cellular types should be added to constant.NONCONNECTABLE_IFACE_TYPES which Interface.is_wired should be referencing. As well as add a new Interface.is_cellular property and new WIRELESS_IFACE_TYPES constant.

# Cellular
TYPE_GSM = 'gsm'
TYPE_CDMA = 'cdma'
TYPE_LTE = 'lte'
TYPE_4G = '4g'
TYPE_5G = '5g'

I'm can to work on this one if it pleases the court.

@Omripresent commented on GitHub (Jun 9, 2025): The following types cellular types should be added to `constant.NONCONNECTABLE_IFACE_TYPES` which `Interface.is_wired` should be referencing. As well as add a new `Interface.is_cellular` property and new `WIRELESS_IFACE_TYPES` constant. ```python # Cellular TYPE_GSM = 'gsm' TYPE_CDMA = 'cdma' TYPE_LTE = 'lte' TYPE_4G = '4g' TYPE_5G = '5g' ``` I'm can to work on this one if it pleases the court.
adam commented 2025-12-29 21:42:50 +01:00
Author
Owner
Copy Link

@jnovinger commented on GitHub (Jun 9, 2025):

@Omripresent , thanks! Will assign to you.

For this one, let's just stick to fixing the original bug report by adding the cellular types to the existing dcim.constants.WIRELESS_IFACE_TYPES list and add a regression test for this. This should fix the original bug.

As for adding a new Interface.is_cellular property, can you please file a feature request for that?

@jnovinger commented on GitHub (Jun 9, 2025): @Omripresent , thanks! Will assign to you. For this one, let's just stick to fixing the original bug report by adding the cellular types to the existing `dcim.constants.WIRELESS_IFACE_TYPES` list and add a regression test for this. This should fix the original bug. As for adding a new `Interface.is_cellular` property, can you please file a feature request for that?
adam commented 2025-12-29 21:42:50 +01:00
Author
Owner
Copy Link

@Omripresent commented on GitHub (Jun 9, 2025):

@jnovinger, that makes sense. I'll stick with using the existing wireless types for now.

@Omripresent commented on GitHub (Jun 9, 2025): @jnovinger, that makes sense. I'll stick with using the existing wireless types for now.
adam commented 2025-12-29 21:42:51 +01:00
Author
Owner
Copy Link

@ross-cello commented on GitHub (Jun 26, 2025):

Hi Team,

This actually causes a quite large regression for us. We have thousands of cellular circuits "cabled".

While I know this is technically correct, in that they're not physically cabled connections... I don't see an appropriate equivalent representation via other available means.

Cheers

@ross-cello commented on GitHub (Jun 26, 2025): Hi Team, This actually causes a quite large regression for us. We have thousands of cellular circuits "cabled". While I know this is technically correct, in that they're not physically cabled connections... I don't see an appropriate equivalent representation via other available means. Cheers
adam commented 2025-12-29 21:42:51 +01:00
Author
Owner
Copy Link

@Omripresent commented on GitHub (Jun 27, 2025):

Hi @ross-cello,

Wouldn't using a wireless link be the appropriate alternative for your use case?

Image

@Omripresent commented on GitHub (Jun 27, 2025): Hi @ross-cello, Wouldn't using a wireless link be the appropriate alternative for your use case? ![Image](https://github.com/user-attachments/assets/1d0aacb3-af03-424d-87bd-df41e0eddb84)
adam commented 2025-12-29 21:42:52 +01:00
Author
Owner
Copy Link

@ross-cello commented on GitHub (Jun 27, 2025):

Hi @ross-cello,

Wouldn't using a wireless link be the appropriate alternative for your use case?

Image

Thanks for the response, but unfortunately not. As an ISP, our APN provider hands the service aggregate off to us physically to an edge router.
From a network design, our cellular topology is indistinguishable from something like FttH; it's just the last mile isn't a physical wire (copper/fibre), but "air".
We model these cellular as "circuits" because the procurement/billing/network are also identical to those of wired broadband.

Those wireless terminations only support interface-to-interface and seem tailored to WLAN. If it was perhaps extended to allow siimilar terminations as Cable/CircuitTermination, then maybe

@ross-cello commented on GitHub (Jun 27, 2025): > Hi [@ross-cello](https://github.com/ross-cello), > > Wouldn't using a wireless link be the appropriate alternative for your use case? > > ![Image](https://github.com/user-attachments/assets/1d0aacb3-af03-424d-87bd-df41e0eddb84) Thanks for the response, but unfortunately not. As an ISP, our APN provider hands the service aggregate off to us physically to an edge router. From a network design, our cellular topology is indistinguishable from something like FttH; it's just the last mile isn't a physical wire (copper/fibre), but "air". We model these cellular as "circuits" because the procurement/billing/network are also identical to those of wired broadband. Those wireless terminations only support interface-to-interface and seem tailored to WLAN. If it was perhaps extended to allow siimilar terminations as Cable/CircuitTermination, then maybe
adam commented 2025-12-29 21:42:52 +01:00
Author
Owner
Copy Link

@Omripresent commented on GitHub (Jun 27, 2025):

I think that makes sense but seems like a feature request to allow wireless connections to be used for circuit terminations.
It would make more sense to allow all wireless connections and not limit to cellular since it's just another form of transport.

@Omripresent commented on GitHub (Jun 27, 2025): I think that makes sense but seems like a feature request to allow wireless connections to be used for circuit terminations. It would make more sense to allow all wireless connections and not limit to cellular since it's just another form of transport.
adam commented 2025-12-29 21:42:52 +01:00
Author
Owner
Copy Link

@ross-cello commented on GitHub (Jun 27, 2025):

I think that makes sense but seems like a feature request to allow wireless connections to be used for circuit terminations. It would make more sense to allow all wireless connections and not limit to cellular since it's just another form of transport.

I agree. Being able to substitute CableTermination with something like WirelessTermination, attaching to CircuitTermination could conceivably satisfy the regression in capability.

Got caught off-guard by this, so will need to determine the approach.

@ross-cello commented on GitHub (Jun 27, 2025): > I think that makes sense but seems like a feature request to allow wireless connections to be used for circuit terminations. It would make more sense to allow all wireless connections and not limit to cellular since it's just another form of transport. I agree. Being able to substitute CableTermination with something like WirelessTermination, attaching to CircuitTermination could conceivably satisfy the regression in capability. Got caught off-guard by this, so will need to determine the approach.
adam commented 2025-12-29 21:42:53 +01:00
Author
Owner
Copy Link

@itskeoo commented on GitHub (Jul 8, 2025):

is there any news on this? I can't find a feature request. We structured our network the same way with "cabeled" cellular interfaces. since the wireless connection are supposedly for WLAN

@itskeoo commented on GitHub (Jul 8, 2025): is there any news on this? I can't find a feature request. We structured our network the same way with "cabeled" cellular interfaces. since the wireless connection are supposedly for WLAN
adam commented 2025-12-29 21:42:53 +01:00
Author
Owner
Copy Link

@Omripresent commented on GitHub (Jul 13, 2025):

I haven't seen a FR submitted for it either. @itskeoo do you mind submitting one with you use case in detail?

@Omripresent commented on GitHub (Jul 13, 2025): I haven't seen a FR submitted for it either. @itskeoo do you mind submitting one with you use case in detail?
adam commented 2025-12-29 21:42:54 +01:00
Author
Owner
Copy Link

@ross-cello commented on GitHub (Aug 8, 2025):

Sorry guys. I've not had the energy lately to make what I consider to be a satisfactory business case to propose.
For now we're parked on 4.3.2.

It might make sense to expand the WirelessLink model to bring it closer in function to CableTermination, but these things need a bit of time to analyse and understand.

Was initially tossing up between that and an entirely new WirelessTermination model with analogous capability to CableTermination, with a personal preference for the former.

@ross-cello commented on GitHub (Aug 8, 2025): Sorry guys. I've not had the energy lately to make what I consider to be a satisfactory business case to propose. For now we're parked on 4.3.2. It might make sense to expand the WirelessLink model to bring it closer in function to CableTermination, but these things need a bit of time to analyse and understand. Was initially tossing up between that and an entirely new WirelessTermination model with analogous capability to CableTermination, with a personal preference for the former.
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 severity: low status: accepted type: bug
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#11280
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?