Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
   Compare ISP   Rate your ISP
   Glossary   Glossary
Please login or register.

Login with username, password and session length
Advanced search  


Author Topic: Firebrick config processing tool: FB2700/2900 to 2500 prep  (Read 282 times)


  • Addicted Kitizen
  • *****
  • Posts: 7453
  • Retd sw dev; A&A; 4 ◊ 7km ADSL2; IPv6; Firebrick
Firebrick config processing tool: FB2700/2900 to 2500 prep
« on: December 25, 2018, 04:53:12 AM »

I have written a couple of tools which alter the XML config files used by Firebricks so that features unavailable on the FB2500 are removed and alternatives can be declared.

Itís a general preprocessor for the XML which offers conditional statement blocks, based on the #ifdef idea of the C preprocessor, although not with C syntax. It uses special XML comments which say either Ďsection is for FB2500í or Ďsection is for >FB2500í.

The first version of the tool is written in Awk, so will run on *nix or Windows.

The second version of the tool is written in iOS 12 Shortcuts for the iPad/iPhone.

If anyone would be interested in testing either version, or helping to document it, as there isnít any documentation yet, then I would be grateful for volunteers. A Firebrick is not needed, just need to knock up some test case XML files and see that they get preprocessed and come out correctly.

In fact, a load of test vectors and a shell script that automates testing through the whole lot would be handy. Would mean I might need to expand my knowledge of Bash and look up data structures in Bash variables, I suspect.

* Outstanding Bug.

I found a bug where a <usb></usb> element is used inside an if-condition block, so the marker for end of the conditional block, which is an Ďend ifí special comment, comes after the </usb>. Unfortunately the bug means that the </usb> terminates the conditional block. The conditional block should however continue to be in force down to the endif XML comment, as both should have to terminate before processing goes back to normal.

I can either fix this by one of two changes: the first would be to have more sophisticated proper  logic that keeps track of two states separately - inside <usb></usb> element being one flag, and an inside conditional block being the other. The second fix is to have two passes and deal with <usb></usb> completely independently, in a separate pass.

The bug is already fixed in the iOS version, by using the second method. I havenít worked out how to fix it in the ask program yet and the first method might be more easily achievable even though a bit tricky.

* Enhancement. v2.0

I rather want to add an enhancement. Currently nested conditional statements are not allowed, and in fact if this restriction is not removed then a fatal error should be reported as this weakness is a bug currently. Iím not sure if this would ever be of any practical value, but fixing it would, it seems to me, be fairly simple so I feel I ought to just do it. Adding a stack and pushing / popping the current state instead of simply setting it to fixed values at endif directives, that would seem to be about all thatís needed.

Making that enhancement would in any case fix the <usb></usb> bug, killing two birds with one stone. So all the more reason to do it.

I can see how to make the enhancement, adding stack usage, to the iOS version. Havenít looked into the Awk though, and havenít researched the subject of data structures and thus stacks in Awk yet.