<p dir="ltr">Your patch is functionally identical to mine. Mine just has the obligatory long comment detailing why it's there and what it does. </p>
<p dir="ltr">John Fraizer<br>
--Sent from my Android phone.<br>
Please excuse any typos.</p>
<div class="gmail_quote">On Jul 23, 2015 4:55 PM, "Hans van den Bogert" <<a href="mailto:hansbogert@gmail.com">hansbogert@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">reminds me of what I had to do, forgot the hardware. If needed, let me know and I’ll look it up (not arista IIRC). I patched it even more ugly probably:<br>
<a href="https://github.com/hansbogert/tacacs-plus/commit/88b4aac5ba53916bf78ea6ae0eaaf83e5221304c" rel="noreferrer" target="_blank">https://github.com/hansbogert/tacacs-plus/commit/88b4aac5ba53916bf78ea6ae0eaaf83e5221304c</a><br>
<br>
On 24 Jul 2015, at 00:51, John Fraizer <<a href="mailto:john@op-sec.us">john@op-sec.us</a>> wrote:<br>
<br>
> There is a bug in Arista EOS <=4.9.1 which causes it to flip it's lid when<br>
> it receives TAC_PLUS_AUTHOR_STATUS_PASS_REPL in an Authorization response.<br>
> The bug manifests itself as tac_plus and do_auth.py both agreeing that the<br>
> request was authorized but, the EOS device displaying "Authorization<br>
> denied:" and dropping the login.<br>
><br>
> After some troubleshooting to determine what was actually tickling this<br>
> bug, I found that when using an after authorization script with tac_plus,<br>
> it will return TAC_PLUS_AUTHOR_STATUS_PASS_REPL wherein when you don't use<br>
> an after authorization script, tac_plus will return<br>
> TAC_PLUS_AUTHOR_STATUS_PASS_ADD.<br>
><br>
> I write a quick and dirty patch that seems to work just fine in my<br>
> environment and I thought I would pass it along to the community in case<br>
> you have any vintage EOS devices in your stable and want to use after<br>
> authorization. (If you're not using do_auth.py, you don't know what you're<br>
> missing!)<br>
><br>
> This patch is against stock Shrubbery.net F4.0.4.28:<br>
><br>
> $ cat arista-bug-fix.diff<br>
> *** do_author.c.orig 2015-07-23 11:51:33.641510860 -0700<br>
> --- do_author.c 2015-07-23 12:13:11.667818482 -0700<br>
> ***************<br>
> *** 325,359 ****<br>
> --- 325,388 ----<br>
> case 2:<br>
> /* Use replacement AV pairs from program */<br>
> if (debug & DEBUG_AUTHOR_FLAG)<br>
> report(LOG_DEBUG, "cmd %s returns 2 (replace & continue)",<br>
> after);<br>
><br>
> /* Free any existing AV output pairs */<br>
> if (data->num_out_args) {<br>
> for (i = 0; i < data->num_out_args; i++) {<br>
> free(data->output_args[i]);<br>
> }<br>
> free(data->output_args);<br>
> data->output_args = NULL;<br>
> }<br>
><br>
> + /* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *<br>
> + * Arista EOS versions 4.9.1 and below do not support the *<br>
> + * TAC_AUTHOR_STATUS_PASS_REPL status. When they receive *<br>
> + * this status in an authorization reply, they flip their *<br>
> + * lidz and return "Authorization denied:" to the user *<br>
> + * and dump them out of the session. This presents a *<br>
> + * problem for organizations who desire to use after *<br>
> + * authorization scripts to change AV PAIRS, etc if they *<br>
> + * have equipment running older EOS code. *<br>
> + * *<br>
> + * After finally tracking down the root cause of this *<br>
> + * undesired behavior, the "fix" is very simple: "Lie to *<br>
> + * everybody and send TAC_AUTHOR_STATUS_PASS_ADD any time *<br>
> + * we would normally send TAC_AUTHOR_STATUS_PASS_REPL." *<br>
> + * *<br>
> + * This nasty hack was conceived and written by: *<br>
> + * John Fraizer <<a href="mailto:jfraizer@ebay.com">jfraizer@ebay.com</a>> *<br>
> + * 23 July 2015 *<br>
> + * *<br>
> + * No Warranty is Expressed or Implied! *<br>
> + * Individual mileage may vary with driving conditions and *<br>
> + * driving style. Always use the manufacturers *<br>
> + * recommended tire inflation! *<br>
> + * *<br>
> + * Semper Fi! *<br>
> + * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *<br>
> +<br>
> +<br>
> if (debug & DEBUG_AUTHOR_FLAG) {<br>
> report(LOG_DEBUG, "status is now AUTHOR_STATUS_PASS_REPL");<br>
> }<br>
><br>
> data->status = AUTHOR_STATUS_PASS_REPL;<br>
> + */<br>
> data->output_args = out_args;<br>
> data->num_out_args = out_cnt;<br>
> return;<br>
> }<br>
> }<br>
><br>
> /* Return a pointer to the value part of an attr=value string */<br>
> static char *<br>
> value(char *s)<br>
> {<br>
> while (*s != '\0' && *s != '=' && *s != '*')<br>
> s++;<br>
> if (*s != '\0')<br>
> return(++s);<br>
> return(NULL);<br>
><br>
><br>
><br>
><br>
><br>
><br>
> --<br>
> John Fraizer<br>
> LinkedIn profile: <a href="http://www.linkedin.com/in/johnfraizer/" rel="noreferrer" target="_blank">http://www.linkedin.com/in/johnfraizer/</a><br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <<a href="http://www.shrubbery.net/pipermail/tac_plus/attachments/20150723/2e4bb442/attachment.html" rel="noreferrer" target="_blank">http://www.shrubbery.net/pipermail/tac_plus/attachments/20150723/2e4bb442/attachment.html</a>><br>
> _______________________________________________<br>
> tac_plus mailing list<br>
> <a href="mailto:tac_plus@shrubbery.net">tac_plus@shrubbery.net</a><br>
> <a href="http://www.shrubbery.net/mailman/listinfo/tac_plus" rel="noreferrer" target="_blank">http://www.shrubbery.net/mailman/listinfo/tac_plus</a><br>
<br>
</blockquote></div>