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

API cables endpoint does not fail when connecting virtual or wireless links #2888

New Issue
Closed
opened 2025-12-29 18:23:07 +01:00 by adam · 12 comments
adam commented 2025-12-29 18:23:07 +01:00
Owner
Copy Link

Originally created by @davidc on GitHub (Sep 19, 2019).

Environment

  • Python version: 3.7.3
  • NetBox version: 2.5.2

Steps to Reproduce

  1. Create a point to point 802.11ad interface.
  2. Connect it to something via web - fails (because of #2067).
  3. Connect it to something via API - works.
  4. Edit the interface via web or API - fails with error "Virtual and wireless interfaces cannot be connected to another interface or circuit. Disconnect the interface or choose a suitable type".

Expected Behavior

I would expect to be able to create a connection between two wireless point to point interfaces. However as this has already been bizarrely rejected (#2067), I am not asking for that behaviour here. Instead the API should have also rejected me making this connection in the first place, rather than letting it get into what it considers an "illegal" state and becoming unsaveable in the future.

  1. Preferred solution: Continue to allow creation of point to point connections, at least via the API, as I know what my network topology is and wish to model it as is. But fix saving the interface to allow it to be saved.

  2. Alternative solution: Prevent creation of point to point links via the API entirely to conform to developer's view of how networks should look.

Observed Behavior

An error when saving the interface in the web or API.

ipdb> x = nb.dcim.interfaces.get(213)
ipdb> x
wlan60-1
ipdb> x.name = "wlan60-station-1"
ipdb> x.save()
*** pynetbox.core.query.RequestError: The request failed with code 400 Bad Request: {'type': ['Virtual and wireless interfaces cannot be connected to another interface or circuit. Disconnect the interface or choose a suitable type.']}
Originally created by @davidc on GitHub (Sep 19, 2019). ### Environment * Python version: 3.7.3 * NetBox version: 2.5.2 ### Steps to Reproduce 1. Create a point to point 802.11ad interface. 2. Connect it to something via web - fails (because of #2067). 3. Connect it to something via API - works. 4. Edit the interface via web or API - fails with error "Virtual and wireless interfaces cannot be connected to another interface or circuit. Disconnect the interface or choose a suitable type". ### Expected Behavior I would expect to be able to create a connection between two wireless point to point interfaces. However as this has already been bizarrely rejected (#2067), I am not asking for that behaviour here. Instead the API should have also rejected me making this connection in the first place, rather than letting it get into what it considers an "illegal" state and becoming unsaveable in the future. 1. Preferred solution: Continue to allow creation of point to point connections, at least via the API, as I know what my network topology is and wish to model it as is. But fix saving the interface to allow it to be saved. 2. Alternative solution: Prevent creation of point to point links via the API entirely to conform to developer's view of how networks should look. ### Observed Behavior An error when saving the interface in the web or API. ``` ipdb> x = nb.dcim.interfaces.get(213) ipdb> x wlan60-1 ipdb> x.name = "wlan60-station-1" ipdb> x.save() *** pynetbox.core.query.RequestError: The request failed with code 400 Bad Request: {'type': ['Virtual and wireless interfaces cannot be connected to another interface or circuit. Disconnect the interface or choose a suitable type.']} ```
adam closed this issue 2025-12-29 18:23:07 +01:00
adam commented 2025-12-29 18:23:08 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 20, 2019):

Please post the exact API request you are making (without using pynetbox).

@jeremystretch commented on GitHub (Sep 20, 2019): Please post the exact API request you are making (without using pynetbox).
adam commented 2025-12-29 18:23:08 +01:00
Author
Owner
Copy Link

@davidc commented on GitHub (Sep 24, 2019):

Please find below:

PATCH /api/dcim/interfaces/213/ HTTP/1.1
Host: netbox
User-Agent: python-requests/2.21.0
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
Content-Type: application/json;
authorization: Token XXXXXXXXXXXXXXX
X-Session-Key: XXXXXXXXXXXXXXX
Content-Length: 28

{"name": "wlan60-station-2"}

HTTP/1.1 400 Bad Request
Date: Tue, 24 Sep 2019 13:57:09 GMT
Server: gunicorn/19.9.0
Cache-Control: private, max-age=0, must-revalidate
Content-Type: application/json
Vary: Accept,Cookie,Origin
Allow: GET, PUT, PATCH, DELETE, HEAD, OPTIONS, TRACE
API-Version: 2.6
X-Frame-Options: SAMEORIGIN
Content-Length: 149
Connection: close

{"type":["Virtual and wireless interfaces cannot be connected to another interface or circuit. Disconnect the interface or choose a suitable type."]}
@davidc commented on GitHub (Sep 24, 2019): Please find below: ``` PATCH /api/dcim/interfaces/213/ HTTP/1.1 Host: netbox User-Agent: python-requests/2.21.0 Accept-Encoding: gzip, deflate Accept: */* Connection: keep-alive Content-Type: application/json; authorization: Token XXXXXXXXXXXXXXX X-Session-Key: XXXXXXXXXXXXXXX Content-Length: 28 {"name": "wlan60-station-2"} HTTP/1.1 400 Bad Request Date: Tue, 24 Sep 2019 13:57:09 GMT Server: gunicorn/19.9.0 Cache-Control: private, max-age=0, must-revalidate Content-Type: application/json Vary: Accept,Cookie,Origin Allow: GET, PUT, PATCH, DELETE, HEAD, OPTIONS, TRACE API-Version: 2.6 X-Frame-Options: SAMEORIGIN Content-Length: 149 Connection: close {"type":["Virtual and wireless interfaces cannot be connected to another interface or circuit. Disconnect the interface or choose a suitable type."]} ```
adam commented 2025-12-29 18:23:08 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 24, 2019):

NetBox version: 2.5.2

The current stable release is v2.6.4. Please upgrade and ask to reopen this if you can replicate the issue on the current release.

This isn't a bug. Wireless interfaces cannot be connected, as indicated by the error message.

@jeremystretch commented on GitHub (Sep 24, 2019): > NetBox version: 2.5.2 ~The current stable release is v2.6.4. Please upgrade and ask to reopen this if you can replicate the issue on the current release.~ This isn't a bug. Wireless interfaces cannot be connected, as indicated by the error message.
adam commented 2025-12-29 18:23:08 +01:00
Author
Owner
Copy Link

@davidc commented on GitHub (Sep 24, 2019):

Apologies for the typo, this should have read 2.6.2. I will try 2.6.4 now.

Please read the description. If they can't be connected, even in a point-to-point one-to-one manner, why does it let me connect them in the first place and put the system into an unusable state.

@davidc commented on GitHub (Sep 24, 2019): Apologies for the typo, this should have read 2.6.2. I will try 2.6.4 now. Please read the description. If they can't be connected, even in a point-to-point one-to-one manner, why does it let me connect them in the first place and put the system into an unusable state.
adam commented 2025-12-29 18:23:08 +01:00
Author
Owner
Copy Link

@davidc commented on GitHub (Sep 24, 2019):

The problem persists with 2.6.4

PATCH /api/dcim/interfaces/213/ HTTP/1.1
Host: netbox
User-Agent: python-requests/2.21.0
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
Content-Type: application/json;
authorization: Token XXXXX
X-Session-Key: XXXXX
Content-Length: 28

{"name": "wlan60-station-2"}

HTTP/1.1 400 Bad Request
Date: Tue, 24 Sep 2019 14:30:27 GMT
Server: gunicorn/19.9.0
Cache-Control: private, max-age=0, must-revalidate
Content-Type: application/json
Vary: Accept,Cookie,Origin
Allow: GET, PUT, PATCH, DELETE, HEAD, OPTIONS, TRACE
API-Version: 2.6
X-Frame-Options: SAMEORIGIN
Content-Length: 149
Connection: close

{"type":["Virtual and wireless interfaces cannot be connected to another interface or circuit. Disconnect the interface or choose a suitable type."]}
@davidc commented on GitHub (Sep 24, 2019): The problem persists with 2.6.4 ``` PATCH /api/dcim/interfaces/213/ HTTP/1.1 Host: netbox User-Agent: python-requests/2.21.0 Accept-Encoding: gzip, deflate Accept: */* Connection: keep-alive Content-Type: application/json; authorization: Token XXXXX X-Session-Key: XXXXX Content-Length: 28 {"name": "wlan60-station-2"} HTTP/1.1 400 Bad Request Date: Tue, 24 Sep 2019 14:30:27 GMT Server: gunicorn/19.9.0 Cache-Control: private, max-age=0, must-revalidate Content-Type: application/json Vary: Accept,Cookie,Origin Allow: GET, PUT, PATCH, DELETE, HEAD, OPTIONS, TRACE API-Version: 2.6 X-Frame-Options: SAMEORIGIN Content-Length: 149 Connection: close {"type":["Virtual and wireless interfaces cannot be connected to another interface or circuit. Disconnect the interface or choose a suitable type."]} ```
adam commented 2025-12-29 18:23:09 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Sep 24, 2019):

This isn't a bug. Wireless interfaces cannot be connected, as indicated by the error message.

As per Jeremy's comment, wireless interfaces cannot be connected. You need to disconnect the interface before you attempt to save, as the message states.

@DanSheps commented on GitHub (Sep 24, 2019): > This isn't a bug. Wireless interfaces cannot be connected, as indicated by the error message. As per Jeremy's comment, wireless interfaces cannot be connected. You need to disconnect the interface before you attempt to save, as the message states.
adam commented 2025-12-29 18:23:09 +01:00
Author
Owner
Copy Link

@davidc commented on GitHub (Sep 24, 2019):

I understand this. The point is that it should not be LETTING it get into this illegal state and making the interface unsaveable.

If you won't let wireless interfaces be connected, then do so consistently, and don't allow the user to enter a state where he has to go edit the database to fix it.

@davidc commented on GitHub (Sep 24, 2019): I understand this. The point is that it should not be LETTING it get into this illegal state and making the interface unsaveable. If you won't let wireless interfaces be connected, then do so consistently, and don't allow the user to enter a state where he has to go edit the database to fix it.
adam commented 2025-12-29 18:23:09 +01:00
Author
Owner
Copy Link

@davidc commented on GitHub (Sep 24, 2019):

Hi. This has already been rejected by the developers in #2067. Please do not pollute this bug report and dilute the fix I am trying to establish here.

@davidc commented on GitHub (Sep 24, 2019): Hi. This has already been rejected by the developers in #2067. Please do not pollute this bug report and dilute the fix I am trying to establish here.
adam commented 2025-12-29 18:23:09 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Sep 24, 2019):

Thanks davidc, I think for now the best would be option 2. If in the future, wireless P2P links are in the cards, then we can roll that fix back.

@DanSheps commented on GitHub (Sep 24, 2019): Thanks davidc, I think for now the best would be option 2. If in the future, wireless P2P links are in the cards, then we can roll that fix back.
adam commented 2025-12-29 18:23:09 +01:00
Author
Owner
Copy Link

@BarbarossaTM commented on GitHub (Sep 24, 2019):

Wow, censorship of comments is hard. I'm dissapointed. So I try this again in the hope this message doesn't get censored again.

Hi. This has already been rejected by the developers in #2067. Please do not pollute this bug report and dilute the fix I am trying to establish here.

In #2884 @jeremystretch wrote the following, so "the developers" theirselfs came up to fix it that way nearly a year after #2067.

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.

Best
Max

@BarbarossaTM commented on GitHub (Sep 24, 2019): Wow, censorship of comments is hard. I'm dissapointed. So I try this again in the hope this message doesn't get censored again. > Hi. This has already been rejected by the developers in #2067. Please do not pollute this bug report and dilute the fix I am trying to establish here. In #2884 @jeremystretch wrote the following, so "the developers" theirselfs came up to fix it that way nearly a year after #2067. > 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. Best Max
adam commented 2025-12-29 18:23:09 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Sep 24, 2019):

@BarbarossaTM Your comment was deleted because you pinged a bunch of people not involved in the bug fix in an attempt to garner support for changing the cable model in a bug fix. This is not the place to do this.

This is not the place to request a change to the model, as suggested it needs it's own issue.

@davidc I have a fix, I want to run this one by the other maintainers to see if they have any comments, it should show up as a PR shortly.

@DanSheps commented on GitHub (Sep 24, 2019): @BarbarossaTM Your comment was deleted because you pinged a bunch of people not involved in the bug fix in an attempt to garner support for changing the cable model in a bug fix. This is not the place to do this. This is not the place to request a change to the model, as suggested it needs it's own issue. @davidc I have a fix, I want to run this one by the other maintainers to see if they have any comments, it should show up as a PR shortly.
adam commented 2025-12-29 18:23:09 +01:00
Author
Owner
Copy Link

@davidc commented on GitHub (Sep 24, 2019):

Again, this is of no relevance to the issue I am reporting. I happen to agree with the need for it, but this bug report is about something completely different. Please make your own issue report and stop distracting from the actual, singular bug I am reporting in this one. As clearly stated in the text you are quoting. You cannot really think that "defect in API allows database to get into illegal state" is the same thing as "I want a new feature"?

@davidc commented on GitHub (Sep 24, 2019): Again, this is of no relevance to the issue I am reporting. I happen to agree with the need for it, but this bug report is about something completely different. Please make your own issue report and stop distracting from the actual, singular bug I am reporting in this one. As clearly stated in the text you are quoting. You cannot really think that "defect in API allows database to get into illegal state" is the same thing as "I want a new feature"?
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
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#2888
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?