Newly created VLAN/Interface is "down"

[phase5]

I noted a very similar issue #2 and I am sending (via bash client for testing currently) the full json document that was previously retrieved, with the sections added for the new VLAN/Interface (and also DHCP config) I wanted to send.

I will try to clearly lay out what I did here: -

First I set up a clean server and downloaded the config.xml using your API.

Then I added VLAN 75 on interface igb1.
I then added the interface (opt1), set an IP. (IPv4)
I then enabled DHCP Server on this interface and added a simple range.

At this point I re-downloaded config.xml and used diff to see the result of my changes above.

I then duplicated the newly added sections but changed (on the duplicate elements): -
VLAN ID from 75 to 76
IP Address to be a non-conflicting subnet.
opt1 to opt2
and the vlan interface from igb1_vlan75 to igb1_vlan76

I then set this new config and got an OK response.
{"callid":"593b30536e267","action":"config_set","message":"ok","data":{"do_backup":true,"do_reload":true}}

When looking in the GUI after posting the new config via the API, I can see that what I added has been created but the interface shows as down.

Going in with ssh and running ipconfig shows me that it did not actually create the vlan tagged interface "igb1_vlan76"

Any idea what I did wrong?
Any help you can offer would be very much appreciated.

config-cleaned.zip

[ndejong]

Thanks for the clear description, makes perfect sense what you are trying to achieve The issue is most likely coming from the fact that pfSense does not have a clear control layer making it quite hard to design fauxAPI to hook or call pfSense logic in an easy way without writing loads of new (probably duplicated) logic - it's why i called this thing fauxAPI, and for many pfSense configuration changes it works just fine That said, there is another request in the queue for functionality to take an interface up and down which may assist your particular requirement in a round about way Also - I'm curious what happens to your pfSense after you reboot, you might find those interfaces do correctly come to life On 10 Jun 2017, at 09:58, James Sefton <[email protected]> wrote: I noted a very similar issue #2 <#2> and I am sending (via bash client for testing currently) the full json document that was previously retrieved, with the sections added for the new VLAN/Interface (and also DHCP config) I wanted to send. I will try to clearly lay out what I did here: - First I set up a clean server and downloaded the config.xml using your API. Then I added VLAN 75 on interface igb1. I then added the interface (opt1), set an IP. (IPv4) I then enabled DHCP Server on this interface and added a simple range. At this point I re-downloaded config.xml and used diff to see the result of my changes above. I then duplicated the newly added sections but changed (on the duplicate elements): - VLAN ID from 75 to 76 IP Address to be a non-conflicting subnet. opt1 to opt2 and the vlan interface from igb1_vlan75 to igb1_vlan76 I then set this new config and got an OK response. {"callid":"593b30536e267","action":"config_set","message":"ok","data":{"do_backup":true,"do_reload":true}} When looking in the GUI after posting the new config via the API, I can see that what I added has been created but the interface shows as down. Going in with ssh and running ipconfig shows me that it did not actually create the vlan tagged interface "igb1_vlan76" Any idea what I did wrong? Any help you can offer would be very much appreciated. config-cleaned.zip <https://github.com/ndejong/pfsense_fauxapi/files/1065464/config-cleaned.zip> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#10>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAM2KgpeswurNG08esEEsOT1SBcfxFEYks5sCdwQgaJpZM4N18JR> .

[phase5]

Thank you for the prompt response.

I can confirm that the interfaces are present and correct after a reboot.
There is an easy work-around for me in this case where I can just have a batch of vlans created in advance.

I will certainly have a look at the extra functionality when you have it implemented though.

[phase5]

I spent a little more time on this over the past week and it seems the problem does indeed extend to interfaces as well as VLAN's.

If I pre-create my VLAN's in bulk as described earlier, that part is fine.
However, if I then create a new interface on one of those VLANs, assign it a static IP and explicitly mark it as enabled then I do get the adapter showing up but the IP on the summary page is missing and the new routes do not appear in the routing table. Going into the interface, unticking enabled, save, tick enabled again, save and then apply resolves the issue.

Something probably related is that if I do the above to make an interface work, but later remove the interface (via API) and then add another one (with a different IP but the same adapter name) the the interface shows up immediately but shows the old IP address. Routing table follows suit too.

If I remove a working adapter then the routes and actual interface appear to remain active behind the scenes.

The only way I have found to overcome this so far is to reboot, which is not really feasible to do on a regular basis.

Anyone got any idea's how I might work around this? I am not in a position to pre-create 500 interfaces like I am VLAN's. I did notice there were "modified by X person on X date" fields around the json and I wondered if anyone knew if they were in any way related to triggering pfSense to actually apply the changes.

[ndejong]

Hi James, I started taking a look further into this and noticed the functionality you need already seems to exist, however it might not be clear enough. Take a look at the "send_event" action? as documented here:- https://github.com/ndejong/pfsense_fauxapi#fauxapiv1actionsend_event This action is a call through to the pfSense core "send_event" functionality which you can see in the fauxapi code here:- https://github.com/ndejong/pfsense_fauxapi/blob/master/pfSense-pkg-FauxAPI/files/etc/inc/fauxapi/fauxapi_pfsense_interface.inc#L329 I expect you'll be able to do an "interface all reload" and everything should come up as expected without the reboot. Please do report back and let me know how it goes. N

…

On 11 July 2017 at 07:08, James Sefton ***@***.***> wrote: I spent a little more time on this over the past week and it seems the problem does indeed extend to interfaces as well as VLAN's. If I pre-create my VLAN's in bulk as described earlier, that part is fine. However, if I then create a new interface on one of those VLANs, assign it a static IP and explicitly mark it as enabled then I do get the adapter showing up but the IP on the summary page is missing and the new routes do not appear in the routing table. Going into the interface, unticking enabled, save, tick enabled again, save and then apply resolves the issue. Something probably related is that if I do the above to make an interface work, but later remove the interface (via API) and then add another one (with a different IP but the same adapter name) the the interface shows up immediately but shows the old IP address. Routing table follows suit too. If I remove a working adapter then the routes and actual interface appear to remain active behind the scenes. The only way I have found to overcome this so far is to reboot, which is not really feasible to do on a regular basis. Anyone got any idea's how I might work around this? I am not in a position to pre-create 500 interfaces like I am VLAN's. I did notice there were "modified by X person on X date" fields around the json and I wondered if anyone knew if they were in any way related to triggering pfSense to actually apply the changes. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#10 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAM2Kn0ZN4IqSWbPJ1UETHh8z1EDrrmJks5sMpLFgaJpZM4N18JR> .

[phase5]

Hi N,

Thanks very much. I have done quite a few tests with your suggestion and it appears to work perfectly.
I cannot confirm if it affects the previous vlan issue because I have them all pre-created now, but I suspect it may well sort that too. It has certainly sorted my issue above and 2 other related issues we found since.

I had seen the send event thing before but hadn't realized it supported reloading all interfaces like that. Maybe you could add a second example under the "filter reload" one for the "interface reload all", which would then make it really obviously.

I can't thank you enough for that pointer. We had resigned to living with having to go in the click SAVE APPLY all the time.