[tac_plus] Work around for BUG in Arista EOS <=4.9.1

[John Fraizer]

There is a bug in Arista EOS <=4.9.1 which causes it to flip it's lid when
it receives TAC_PLUS_AUTHOR_STATUS_PASS_REPL in an Authorization response.
The bug manifests itself as tac_plus and do_auth.py both agreeing that the
request was authorized but, the EOS device displaying "Authorization
denied:" and dropping the login.

After some troubleshooting to determine what was actually tickling this
bug, I found that when using an after authorization script with tac_plus,
it will return TAC_PLUS_AUTHOR_STATUS_PASS_REPL wherein when you don't use
an after authorization script, tac_plus will return
TAC_PLUS_AUTHOR_STATUS_PASS_ADD.

I write a quick and dirty patch that seems to work just fine in my
environment and I thought I would pass it along to the community in case
you have any vintage EOS devices in your stable and want to use after
authorization.  (If you're not using do_auth.py, you don't know what you're
missing!)

This patch is against stock Shrubbery.net F4.0.4.28:

$ cat arista-bug-fix.diff
*** do_author.c.orig    2015-07-23 11:51:33.641510860 -0700
--- do_author.c 2015-07-23 12:13:11.667818482 -0700
***************
*** 325,359 ****
--- 325,388 ----
      case 2:
        /* Use replacement AV pairs from program */
        if (debug & DEBUG_AUTHOR_FLAG)
            report(LOG_DEBUG, "cmd %s returns 2 (replace & continue)",
                   after);

        /* Free any existing AV output pairs */
        if (data->num_out_args) {
            for (i = 0; i < data->num_out_args; i++) {
                free(data->output_args[i]);
            }
            free(data->output_args);
            data->output_args = NULL;
        }

+ /* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
+  * Arista EOS versions 4.9.1 and below do not support the  *
+  * TAC_AUTHOR_STATUS_PASS_REPL status.  When they receive  *
+  * this status in an authorization reply, they flip their  *
+  * lidz and return "Authorization denied:" to the user     *
+  * and dump them out of the session.  This presents a      *
+  * problem for organizations who desire to use after       *
+  * authorization scripts to change AV PAIRS, etc if they   *
+  * have equipment running older EOS code.                  *
+  *                                                         *
+  * After finally tracking down the root cause of this      *
+  * undesired behavior, the "fix" is very simple: "Lie to   *
+  * everybody and send TAC_AUTHOR_STATUS_PASS_ADD any time  *
+  * we would normally send TAC_AUTHOR_STATUS_PASS_REPL."    *
+  *                                                         *
+  * This nasty hack was conceived and written by:           *
+  * John Fraizer <jfraizer at ebay.com>                        *
+  * 23 July 2015                                            *
+  *                                                         *
+  * No Warranty is Expressed or Implied!                     *
+  * Individual mileage may vary with driving conditions and  *
+  * driving style.  Always use the manufacturers            *
+  * recommended tire inflation!                             *
+  *                                                         *
+  * Semper Fi!                                              *
+  * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
+
+
        if (debug & DEBUG_AUTHOR_FLAG) {
            report(LOG_DEBUG, "status is now AUTHOR_STATUS_PASS_REPL");
        }

        data->status = AUTHOR_STATUS_PASS_REPL;
+ */
        data->output_args = out_args;
        data->num_out_args = out_cnt;
        return;
      }
  }

  /* Return a pointer to the value part of an attr=value string */
  static char *
  value(char *s)
  {
      while (*s != '\0' && *s != '=' && *s != '*')
        s++;
      if (*s != '\0')
        return(++s);
      return(NULL);






--
John Fraizer
LinkedIn profile: http://www.linkedin.com/in/johnfraizer/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20150723/2e4bb442/attachment.html>