After almost 2 years of subtle hints from my wife and much less subtle nagging from my parents whenever they saw pictures or caught a glimpse on a video chat or just thought about it, I finally relented and with the assistance of my brother in law and father in law, ran the cables between the TiVo, bluray and wii through the fake wall instead of across the mantle piece. It’s not like I’d had the fake wall put in just for that purpose… Oh wait, that’s exactly why!

Any way… 2 HDMI, 1 composite and 1 component+audio (future) and I reran the cable coax through the conduit I’d also had put in for this purpose to the basement

1 month later, both HDMI ports magically stop working in the middle of the day.

TV was bought from Circuit City 2 years ago.
TiVo Series 3 was bought from Tweeter about 2 1/2 years ago.
Samsung Blu-Ray was bought from Circuit City last year.

As both Circuit City and Tweeter no longer exist, I’m out of luck for store support, so I go to Best Buy and buy an expensive HDMI cable (no other kind exist in the Best Buy universe…. newegg usually has good deals) and test the blu-ray with my upstairs TV with success. The TiVo has component output so I hook that up to the cable that I ran and that works, so I’m pretty sure the problem is with the TV.

After a little more procrastination, I finally call Hitachi customer support (shockingly, 1-800-HITACHI)… and this brings me to the point of this post.

WOAH. One ring and I get through to a real cheerful person who listens, asks if other inputs are working, and after checking the software version on my TV, recommends a software upgrade (I’m 10 versions behind). After suggesting that I call every 6 months or so and ask for an upgrade, she takes my name, address and we chat about the wonders of software upgrades on consumer devices and we’re done. “You should have the card by the end of the week, any problems just call back”. One support person, soup-to-nuts, no “I’ll just put you on hold” no hold music AT ALL. For a company with a product range of the size of Hitachi, I’m beyond speechless…. I’m moved to blog

Of course, I’m still waiting to find out if the software upgrade fixes my problem. I’m betting on expired certificates.

I don’t think I could even find the original email thread now, but the bug is pretty well documented in the CPAN page for Net::Patricia:

The match_string method ignores the mask bits/width, if specified, in its argument. So, if you add two prefixes with the same base address but different mask widths, this module will match the most-specific prefix even if that prefix doesn't wholly cotain the prefix specified by the match argument. For example:

   use Net::Patricia;
   my $pt = new Net::Patricia;
   $pt->add_string('192.168.0.0/25');
   $pt->add_string('192.168.0.0/16');
   print $pt->match_string('192.168.0.0/24'), "\n";

prints "192.168.0.0/25", just as if you had called:

   print $pt->match_string('192.168.0.0'), "\n";

This issue was reported to me by John Payne, who also provided a candidate patch, but I have not applied it since I hesitate to change this behavior which was inherited from MRT. Consequently, this module might seem to violate the principle of least surprise if you specific the mask bits when trying to find the best match.

The fix is not even one line. The patch is below.


*** libpatricia/patricia.c~     Wed Oct  4 16:41:35 2000
--- libpatricia/patricia.c      Tue Mar  5 11:42:23 2002
***************
*** 614,620 ****
 #endif /* PATRICIA_DEBUG */
       if (comp_with_mask (prefix_tochar (node->prefix),
                           prefix_tochar (prefix),
!                           node->prefix->bitlen)) {
 #ifdef PATRICIA_DEBUG
             fprintf (stderr, "patricia_search_best: found %s/%d\n",
                    prefix_toa (node->prefix), node->prefix->bitlen);
--- 614,620 ----
 #endif /* PATRICIA_DEBUG */
       if (comp_with_mask (prefix_tochar (node->prefix),
                           prefix_tochar (prefix),
!                           node->prefix->bitlen) && node->prefix->bitlen <= bitlen) {
 #ifdef PATRICIA_DEBUG
             fprintf (stderr, "patricia_search_best: found %s/%d\n",
                    prefix_toa (node->prefix), node->prefix->bitlen);

Plenty of security vendors will describe how to setup their solutions in a single-vendor environment, but that doesn’t match the real world.  I’ll start by listing out some components from a multi-platform environment.  Subsequent posts will describe issues with each of the various components and key configuration points.

Client environment: Windows XP, Mac OS/X (10.4 and 10.5), Linux (Ubuntu LTS).

IP phones: Avaya 96xx, Cisco 79xx

Switches: Cisco 6500, 3750 and 3650

Firewalls: Juniper SSG (relevant for future NAC deployments)

RADIUS: Microsoft IAS, Infoblox, Juniper Infranet Controller (for future NAC deployments)

Issues:  more machines than network drops at desks, authentication should be transparent to users, re-imaging machines, printers/scanners/etc, “stale” CRL from “root” CAs.

For instance, with Juniper’s screenos when they added TACACS+ support, they documented how to add the config to the firewall, but the details on having to create a new service and set priv levels were left to a KB entry after the fact.

tacacs.org is now available to collect server side snippets, hints and tricks.

Contact me for details on how to contribute.

This snippet is tested against “recent” Shrubbery tac_plus daemons as of the date of the post.

Searching for ACE and TACACS or similar gets confusing because of the RSA ACE server.  Good job Cisco

Cisco Application Control Engine modules are really separate devices from the “mother” switch, only suckling power and connectivity.  These devices need their own authentication schemes.  It’s pretty easy to turn on TACACS+ authentication and accounting (no authorization again.  Why do vendors insist on only doing 1 or 2 As and not 3?).

ACE modules needs a specific optional av-pair in the “exec” service in TACACS+ to authenticate. You can put this in a group or user stanza:

service = exec {
optional shell:Admin = "Admin default-domain"
}

The format is: shell:<Context> = “<Role> <domain>”

I’m not all that into ACE modules yet, so I’ll assume that the reader knows what each of those should be set to in their environment.  For us, we simply want the equivalent of priv-lvl = 15, and that’s what we get above.

Note that without that av-pair, the defaults come through as Admin context, default-domain and “Network-Monitoring” role.

Also note that excluding the “optional” keyword will render you unable to log in to any IOS devices that use your TACACS+ server for authorization.

ScreenOS 6.0+ users may have noticed that you can now configure TACACS+ servers to authenticate admin users. I’ll skip over the details, except to say that as of 6.1.0r3, failover isn’t working to either of the backup servers that you can configure, so use with care.
Also note that this is authentication only, no accounting or authorization (except for privilege levels).

ScreenOS needs a specific service in TACACS+ to authenticate. You can put this in a group or user stanza:

service = netscreen {
vsys = root
privilege = read-write
}

The vsys specifies which vsys that user is allowed to. If you only have one, it’s “root”.
privilege can be read-write, read-only or root. As far as I can tell, root allows you to manage local users and mess with nsrp. Otherwise read-write gets most things done. If you’re specifying a non-root vsys, you can also assign vsys-read-write or vsys-read-only as privileges.