Cannot get IDs of "Read Routing Gateway"

[edenzv]

Hi,

I want to delete routing gateway but I cannot find the ID in the request of "Read Routing Gateway".

Thanks Eden

[jaredhendrickson13]

Hey!

This is because pfSense doesn't store object IDs, rather they use the configuration array index value of the object. This is outlined in the documentation here. Or you can refer to #90 for some examples and info on future plans for obtaining object IDs.

Let me know if you have any troubles.

Thanks!

[edenzv]

Hey,

Thanks o the quick response, I also did your recommend before and tried it again, but I tried to remove by the ID and it remove other that I didn't meant to remove:

This is the gateways list in pfSense webgui:

This is the output of GET https://pfSense/api/v1/routing/gateway in postman:

I need to removed "WANCP1" and from the documentation this ID is 1 but it removed a different gateway (LANGW):

And after check the gateway list I found that it removed different gateway (WAN11):

I hope that you understood this use case.

Thanks Eden

[jaredhendrickson13]

Thanks for these details. Looking further into the code, I do see there is a discrepancy on this endpoint between the GET and DELETE requests. Typically, GET requests read the pfSense configuration directly but in this case the function it calls seems to return some detailed backend values for gateways that are not expected.

In the short term, I do see a workaround you can use today. Making a GET request to /api/v1/routing/gateway does seem to return the ID within the response data itself, more specifically the attribute field of the object is the ID. If the object does not contain a numeric value in the attribute field, it cannot be deleted as it's a system-defined gateway.

For example, GET requests to /api/v1/routing/gateway currently return this:

{
  "status": "ok",
  "code": 200,
  "return": 0,
  "message": "Success",
  "data": {
    "EXAMPLE_GW_1": {
      "interface": "em0",
      "gateway": "172.16.209.2",
      "name": "EXAMPLE_GW_1",
      "weight": "1",
      "ipprotocol": "inet",
      "descr": "",
      "monitor": "172.16.209.2",
      "friendlyiface": "wan",
      "friendlyifdescr": "WAN",
      "attribute": 0,    # <----- This object uses ID 0
      "tiername": ""
    },
    "EXAMPLE_GW_2": {
      "interface": "em0",
      "gateway": "172.16.209.12",
      "name": "EXAMPLE_GW_2",
      "weight": "1",
      "ipprotocol": "inet",
      "descr": "",
      "monitor": "172.16.209.12",
      "friendlyiface": "wan",
      "friendlyifdescr": "WAN",
      "attribute": 1,    # <----- This object uses ID 1
      "tiername": ""
    },
    "Null4": {
      "name": "Null4",
      "interface": "lo0",
      "ipprotocol": "inet",
      "gateway": "127.0.0.1",
      "attribute": "system",    # <----- This object cannot be deleted as it is a system gateway
      "tiername": ""
    }
  }
}

In the long term, this does express the need to move the current GET response to a different endpoint that can be used to retrieve these more detailed/non-configuration gateway values. Then in it's place, the GET response for this endpoint should be refactored to only return gateways as they appear in the configuration. Since this requires a breaking change, I will include the code change in the v1.3.0 workflow. For now, I will add a snippet to the documentation that details this discrepancy in the next release (v1.2.0). I'll keep this issue updated as these changes are implemented.

Thanks again for pointing this out. I appreciate it.

[edenzv]

Hey,

I'm very appreciate your advices.
I tried the workaround of remove the attribute, and I got response that it removed the right gateway but it removed a different gateway:

Need to removed "WANCP_Internet", and the attribute is 5:

Send delete request and got response that it removed:

I see the list of the existing gateways and see that "WANCP_Internet" is existing and "WANGW_2" has been removed:

I hope that you understood this use case.

Thanks Eden

[jaredhendrickson13]

Thanks for your patience.I spent some time yesterday looking deeper into this and I did find that in some scenarios the IDs become misaligned from the configuration, which seems to be what is causing this. I found I was able to reproduce this when either:

1. the gateway order has been re-arranged within the UI
2. gateways exist for multiple interfaces and were added out of order, or a gateway was deleted

I can actually reproduce the mismatched ID in the pfSense UI as well, however, it seems to work some magic to somehow map this magic ID back to it's actual ID which is something the API endpoint is missing. I'll work on a fix for this and have it included in the next patch. I'll update this issue when I have a pull request for the patch, which will include a test build so you can verify it fixes this issue for you.

Thanks again!