Wireless Access

Deleting a rule from firewall policy, clicking done, then apply, at whcih point it is returning me to the User Roles screen.. If I then go back in, the rule is there again!

 

Ive tried various combinaitons of saving, applying etc.. but it always comes back...

 

Can I do this via cli as a workaround?

 

 

What version of code?  Before clicking "Apply" click on "show commands" to see what command it is trying to execute.  It might be a bug...

 

v5049

 

It seems to be showing the right command.. but obviously  not executing it!  Maybe ill try via ssh... 

 

Doesnt seem to work via ssh either....  I can see the access list session including the rule I want to delte, but when I try to do this I get "unknown policy"

 

Driving me nuts.. what a wast of a morning!!!

 

 

 

 

If you just upgraded your controller, try clearing the browser cache".

 

In addition, go to the commandline and type "show audit-trail" to see if the command was executed at all.

 

Had a look at audit trail, and it seems it isnt being executed!??

 

ip access-list session "captiveportal" no any host 17.0.0.0 "255.0.0.0" permit > -- command execution failed

 

If I look at the command section in gui.. its try to do:

no any host 17.0.0.0 255.0.0.0 any permit

 

Yet the "any" part of this doesnt seem to be an option when I view the help menu whilst manually entering the code... so I try permit, and get "unknown policy"

Then that is a bug.  What version of ArubaOS?

 

v5049  -  the latest we can upgrade to due to hardware limitaitons.

 

Thanks for you help!  

Did you try clearing the browser cache or using a different browser?

 

Tried both....

 

Seems that when I look at the commands lst in the gui it is also trying to execute commands I havent asked it to.. which is a little worrying.. and prob best it isnt actually doing them!

 

Think Ill be logging a call!

I have had this loads of time with the GUI. Personally, CLI is the only way to be sure. I think you are very wise up validate your config changes the way you have. It may sound overkill but checking in your configurations into a repository so you can diff the configs is a good 'workaround' for this behaviour.

---

@soapdish wrote:
I have had this loads of time with the GUI. Personally, CLI is the only way to be sure. I think you are very wise up validate your config changes the way you have. It may sound overkill but checking in your configurations into a repository so you can diff the configs is a good 'workaround' for this behaviour.

---

Soapdish,

 

I am not sure what you are referring to when you say "loads of time with the GUI", but if there is a bug, it should be reported so that it can be fixed.  Even if it seems to be a bug, it needs to be explained to the end user so that they know what to expect.

 

Frequently end-users have an idea that is different from how things work.  When they open a case, we either seek to explain the behavior, or in some cases, we change the behavior because it did not make sense in the first place.  We cannot do either unless it is reported.  Please report all anomalies to TAC so that they can be taken care of.

 

When I say loads of times within the GUI, I mean specifically that it is a frequent occurrence that I have simply gotten used to by now. Regarding reporting of this kind of issue to tac, the process itself I believe would be counter productive for me, although I can see the benefits for Aruba testing. Regarding upgrading as a means of fixing, frankly I'll stuck to the devil I know. Providing no changes are made the system has been very reliable.

Soapdish,

 

Either way, please let us know if we can help.

 

 

 

 

 

 

Thanks for your help.. is indeed a bug on the gui side.. shocking really! 

 

Although I have to admit to a syntax error on my behalf via the cli, but I was thrown off by looking at the comman syntax that the gui was trying to use.. well, thats may defence anyway :-p