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

Can't connect wifi interfaces of two devices, instead wired interfaces are shown #2375

New Issue
Closed
opened 2025-12-29 17:25:28 +01:00 by adam · 8 comments
adam commented 2025-12-29 17:25:28 +01:00
Owner
Copy Link

Originally created by @BarbarossaTM on GitHub (Feb 13, 2019).

Environment

  • Python version: 3.5.4
  • NetBox version: 2.5.5

Steps to Reproduce

  1. Create a device type with at least one Wifi interface (e.g. IEEE 802.11ac)
  2. Create two devices of this type
  3. Click on "connect" button on device A and try to connect wifi interface of device B

Expected Behavior

I expected the wifi interface of device B to be shown in the interfaces list on the cable page.

This is relevant for documenting point-to-point wifi backhaul links and automation of their configuration accordingly.

Observed Behavior

Only wired interfaces are shown in the drop-down on the cable page which doesn't make sense as those should be incompatible.

Best
Max

Originally created by @BarbarossaTM on GitHub (Feb 13, 2019). ### Environment * Python version: 3.5.4 * NetBox version: 2.5.5 ### Steps to Reproduce 1. Create a device type with at least one Wifi interface (e.g. IEEE 802.11ac) 2. Create two devices of this type 3. Click on "connect" button on device A and try to connect wifi interface of device B ### Expected Behavior I expected the wifi interface of device B to be shown in the interfaces list on the cable page. This is relevant for documenting point-to-point wifi backhaul links and automation of their configuration accordingly. ### Observed Behavior Only wired interfaces are shown in the drop-down on the cable page which doesn't make sense as those should be incompatible. Best Max
adam added the type: bugstatus: accepted labels 2025-12-29 17:25:28 +01:00
adam closed this issue 2025-12-29 17:25:28 +01:00
adam commented 2025-12-29 17:25:28 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Feb 14, 2019):

To clarify, the bug here isn't that you can't connect wifi interfaces, it is that the wifi interface shows a connection option.

Connecting wifi interfaces was proposed and rejected in #2067 as per @jeremystretch in #2730. I wouldn't mind if @jeremystretch revisited this as I would love to be able to connect my backhauls, however he is understandably busy with more pressing issues.

@DanSheps commented on GitHub (Feb 14, 2019): To clarify, the bug here isn't that you can't connect wifi interfaces, it is that the wifi interface shows a connection option. Connecting wifi interfaces was proposed and rejected in #2067 as per @jeremystretch in #2730. I wouldn't mind if @jeremystretch revisited this as I would love to be able to connect my backhauls, however he is understandably busy with more pressing issues.
adam commented 2025-12-29 17:25:29 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Feb 14, 2019):

It might be better to allow a "Circuit" to terminate on a wifi interface, than a "Cable"

@candlerb commented on GitHub (Feb 14, 2019): It might be better to allow a "Circuit" to terminate on a wifi interface, than a "Cable"
adam commented 2025-12-29 17:25:29 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Feb 14, 2019):

I don't disagree with that idea.

@DanSheps commented on GitHub (Feb 14, 2019): I don't disagree with that idea.
adam commented 2025-12-29 17:25:29 +01:00
Author
Owner
Copy Link

@jbakklund commented on GitHub (Feb 15, 2019):

Agree. A cable-in-the-air is a bit too abstract to fit the current list of physical cables, it is more like the pre 2.5 versions model of a logic connection. It could be represented as a separate type of "cable" where color, label, length, and connector is irrelevant - or maybe like a virtual hub?

@jbakklund commented on GitHub (Feb 15, 2019): Agree. A cable-in-the-air is a bit too abstract to fit the current list of physical cables, it is more like the pre 2.5 versions model of a logic connection. It could be represented as a separate type of "cable" where color, label, length, and connector is irrelevant - or maybe like a virtual hub?
adam commented 2025-12-29 17:25:29 +01:00
Author
Owner
Copy Link

@BarbarossaTM commented on GitHub (Feb 15, 2019):

Hi,

I see the point that with the current cable management (which is great, thanks for that <3) you can "only" PTP links but no PTMP. For me this wouldn't be a blocker to allow connecting two WIFI interfaces as a lot of people (as this thread and the comments in the other tickets show without a doubt) do.

If one would like to connect multiple device one could "hack" that by adding a "WIFI Cloud" device with lots of interfaces ;-)

So IMHO it would be REALLY great if connecting wifi interfaces would be possible.

Best
Max

@BarbarossaTM commented on GitHub (Feb 15, 2019): Hi, I see the point that with the current cable management (which is great, thanks for that <3) you can "only" PTP links but no PTMP. For me this wouldn't be a blocker to allow connecting two WIFI interfaces as a lot of people (as this thread and the comments in the other tickets show without a doubt) do. If one would like to connect multiple device one could "hack" that by adding a "WIFI Cloud" device with lots of interfaces ;-) So IMHO it would be REALLY great if connecting wifi interfaces would be possible. Best Max
adam commented 2025-12-29 17:25:29 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Feb 15, 2019):

or maybe like a virtual hub?

The nearest thing like that is a VLAN.

You can already associate a wireless interface with a VLAN, either directly (set 802.1Q mode "Access" then update then "Add VLANs"); or indirectly (via its IP address sitting within a prefix which in turn is associated to a VLAN). Either way models multipoint wireless connections reasonably well I think - any further would require modelling channels/frequencies.

There's still an argument that point-to-point wireless is different, and might be usefully modelled as a circuit.

@candlerb commented on GitHub (Feb 15, 2019): > or maybe like a virtual hub? The nearest thing like that is a VLAN. You can already associate a wireless interface with a VLAN, either directly (set 802.1Q mode "Access" then update then "Add VLANs"); or indirectly (via its IP address sitting within a prefix which in turn is associated to a VLAN). Either way models multipoint wireless connections reasonably well I think - any further would require modelling channels/frequencies. There's still an argument that point-to-point wireless is different, and might be usefully modelled as a circuit.
adam commented 2025-12-29 17:25:29 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Feb 15, 2019):

But it's not a "cable". If you were running a cable to anything, it would be an antenna.

The Netbox concept of "interface" combines a physical entity (a port), a layer 2 entity (some electronics with a MAC address) and a layer 3 interface (IP address(es)).

Suppose you have three PCs connected into a switch. All three PCs are "neighbours" in the sense that they are sharing the same VLAN and subnet. But Netbox doesn't show all three PC interfaces as connected to each other directly. Instead you have:

  1. the physical star cable topology into the switch
  2. the interfaces are optionally associated with VLANs. If you use this feature (i.e. configure each PC interface as "Access" port and add the VLAN), then the interfaces on the same VLAN form a group. You can see this if you browse to the VLAN and look at the "Members" tab.
  3. the layer3 interfaces have IP addresses, which are implicitly within a prefix, in which case all the IP interfaces within the same prefix form a group. You can browse to the Prefix, and under the "IP Addresses" tab you can see the list of addresses with "Parent" and "Interface" linking to the device/interface.

(2) and (3) are just as applicable to wireless as to wired. If you wanted to model (1) for wireless then it would be some sort of wifi domain, but it would be multipoint, unlike a cable or circuit. In that regard it would be similar to VLAN, although the same VLAN could be spread over both wired and wireless parts of the network.

Adding RF and SSID attributes to VLAN might be an idea, but you can already use Description for that, or Custom Fields.

@candlerb commented on GitHub (Feb 15, 2019): But it's not a "cable". If you were running a cable to anything, it would be an antenna. The Netbox concept of "interface" combines a physical entity (a port), a layer 2 entity (some electronics with a MAC address) and a layer 3 interface (IP address(es)). Suppose you have three PCs connected into a switch. All three PCs are "neighbours" in the sense that they are sharing the same VLAN and subnet. But Netbox doesn't show all three PC interfaces as connected to each other directly. Instead you have: 1. the physical star cable topology into the switch 2. the interfaces are optionally associated with VLANs. If you use this feature (i.e. configure each PC interface as "Access" port and add the VLAN), then the interfaces on the same VLAN form a group. You can see this if you browse to the VLAN and look at the "Members" tab. 3. the layer3 interfaces have IP addresses, which are implicitly within a prefix, in which case all the IP interfaces within the same prefix form a group. You can browse to the Prefix, and under the "IP Addresses" tab you can see the list of addresses with "Parent" and "Interface" linking to the device/interface. (2) and (3) are just as applicable to wireless as to wired. If you wanted to model (1) for wireless then it would be some sort of wifi domain, but it would be multipoint, unlike a cable or circuit. In that regard it would be similar to VLAN, although the same VLAN could be spread over both wired and wireless parts of the network. Adding RF and SSID attributes to VLAN might be an idea, but you can already use Description for that, or Custom Fields.
adam commented 2025-12-29 17:25:30 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 15, 2019):

Thanks everyone for the discussion here. Let me try to sum up:

  1. NetBox currently includes a "connect" button on wireless interfaces but does not allow for creating a connection between them. This is dumb, and is fixed in @DanSheps' PR #2896.
  2. The Cable model is ill-suited for representing wireless connections, and would be unintuitive at best.
  3. The Circuit model may be a good candidate for representing point-to-point wireless connections, however this (and any other discussion of new wireless mechanisms) would be out of scope for the current topic and need its own issue.
@jeremystretch commented on GitHub (Feb 15, 2019): Thanks everyone for the discussion here. Let me try to sum up: 1. NetBox currently includes a "connect" button on wireless interfaces but does not allow for creating a connection between them. This is dumb, and is fixed in @DanSheps' PR #2896. 2. The Cable model is ill-suited for representing wireless connections, and would be unintuitive at best. 3. The Circuit model may be a good candidate for representing point-to-point wireless connections, however this (and any other discussion of new wireless mechanisms) would be out of scope for the current topic and need its own issue.
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: 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#2375
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?