Brian Candler
2015-12-14 15:01:11 UTC
Rancid wasn't working with HP Procurve switches - a problem which I have
found mentioned by other people, e.g.
http://www.shrubbery.net/pipermail/rancid-discuss/2012-April/006317.html
http://louwrentius.com/creating-configuration-backups-of-hp-procurve-switches.html
I believe I have found and fixed the underlying cause of this problem.
It's in hpuifilter. In the case where tbuf contains both a complete
escape sequence and a partial escape sequence, the function expectmore()
was returning zero to say "complete" when in fact there could have been
a partial sequence following it. As a result, some escape sequences were
getting mangled.
The attached patch changes this so only a complete escape sequence is
accepted, and now hrancid/hlogin appear to work happily, at least with
the J9775A (2530-48G) that I'm using here.
I'm sure this could be done in a cleaner way, and also it could amortise
several escape sequences into a single call, although I didn't do this
as the existing code currently stops after a newline sequence and this
appears to be intentional.
I also took the liberty of changing memcpy() calls to memmove(), since
the former has undefined behaviour when the destination and source
memory areas overlap.
Regards,
Brian Candler.
found mentioned by other people, e.g.
http://www.shrubbery.net/pipermail/rancid-discuss/2012-April/006317.html
http://louwrentius.com/creating-configuration-backups-of-hp-procurve-switches.html
I believe I have found and fixed the underlying cause of this problem.
It's in hpuifilter. In the case where tbuf contains both a complete
escape sequence and a partial escape sequence, the function expectmore()
was returning zero to say "complete" when in fact there could have been
a partial sequence following it. As a result, some escape sequences were
getting mangled.
The attached patch changes this so only a complete escape sequence is
accepted, and now hrancid/hlogin appear to work happily, at least with
the J9775A (2530-48G) that I'm using here.
I'm sure this could be done in a cleaner way, and also it could amortise
several escape sequences into a single call, although I didn't do this
as the existing code currently stops after a newline sequence and this
appears to be intentional.
I also took the liberty of changing memcpy() calls to memmove(), since
the former has undefined behaviour when the destination and source
memory areas overlap.
Regards,
Brian Candler.