No free VTYs

So, was working on a Nagios event handler to issue a NAT clear command to a Cisco router (half-baked IPSec VPN box issues, fail) and even though I had configured all of the rcmd stuff properly in IOS and locked it down to just the Nagios server for access it still didn't work. On the server side, when I issued the command I would get a single line of output:

No free VTYs.

So, I went back to the router and turned on 'debug ip tcp rcmd' and noticed that the rsh authentication (if you can call it that) was working but after accepting the command from the rsh client (router sends 'OK' to client), the router followed by immediately sending '' to the client. Ok, so let's look at the VTY line config.

All of my default VTYs are setup with 'transport input ssh' because I don't use telnet where I have the choice to use SSH. I changed that to 'transport input rlogin ssh' and no luck. Finally, I changed it to 'transport input ssh telnet' and bingo, the rcmd was working like a champ. I removed the telnet option for my main access lines and defined a new line, telnet only, with a much more restrictive access-class limited to the server running Nagios.

Migrating IPPlan from 4.92a to 6.00BETA2

I performed this for two IP network repositories that I manage and it worked out ok. The paths and such are relative to the FreeBSD platform from which this runs, therefore you may have to tweak if you've made the mistake of using something other than FreeBSD. Some steps, such as step 1, may not be necessary for you, so check your extensions.ini beforehand as you may already have support for gmp.

1. rebuild php extensions with GNU MP support and enable it in /usr/local/etc/php/extensions.ini
2. unpack source
3. cp config.php config.php.orig
4. patch config.php from patch file in /usr/ports/net-mgmt/ipplan/files/
5. fix user name, password, db type, and db name in config.php
6. fix user name, password, db type, and db name in contrib/db-migrate.php
7. create new ipplanv6 db via phpMyAdmin with same permissions as ipplan db
8. visit http://site/ipplanv6/admin/install.php, choosing "new installation" and "run the sql now"
   
   

   #zlib support compiled into php
   #output to webrowser will be compressed for quicker loading of pages if web browser supports compression
   The database schema was created - you can now create users and groups after loggin in with the admin user specified in the config.php file
   Click here to access the administration page

9. visit http://site/ipplanv6/contrib/db-migrate.php which will import all data from the ipplan db into the new ipplanv6 db
   
   

   Migrating table grp Migrating table users [snip] Migrating table fwdzonerec

10. via phpMyAdmin, check the ipplanv6.version table and you should see version (or schema) '23'

That's about it. Other than the fiasco with building the GNU MP extension for PHP, which I won't go into here, it was pretty painless and doing it twice helped me clean up these notes which will hopefully help you.

This is a big step forward for IPPlan and I am stoked to see IPv6 support. It's been on my wish list for a *very* long time and while I have contributed patches to the project in the past, I simply didn't have the spare time to do the IPv6 integration. I had been planning to resurrect the old Perl code for FreeIPdb that I worked on with a couple guys from Global Crossing, but now that IPPlan supports IPv6, I think that FreeIPdb will really die (at least for me).

Finally, if you are using IPPlan and it's useful to you and/or your business then *PLEASE* contribute to the project. Thank you!

tcpdump can't find /dev/bpf

Setting up new router/firewall and during testing had this issue:

# tcpdump -n -e -tttt -vv -i pflog0 tcpdump: (cannot open device) /dev/bpf: No such file or directory # ls /dev/bp* crw------- 1 root wheel - 0, 84 Sep 9 20:54 /dev/bpf0 crw------- 1 root wheel - 0, 86 Sep 9 20:54 /dev/bpf1 crw------- 1 root wheel - 0, 87 Sep 9 20:54 /dev/bpf2

Turns out that the tcpdump package for FreeBSD 7.2 that I had installed, version 3.9.7, was the cause of the problem. Weird part is that the base tcpdump is 3.9.8 -- newer than the packaged port! Weird indeed.

Anyway, deinstalled the package and now the base tcpdump has no problem connecting to the pflog0 interface for real-time pflog examination.

# which tcpdump /usr/local/sbin/tcpdump # pkg_deinstall tcpdump ---> Deinstalling 'tcpdump-3.9.7' [Updating the pkgdb ... (...) done] # which tcpdump /usr/sbin/tcpdump # tcpdump -V tcpdump version 3.9.8 libpcap version 0.9.8 Usage: tcpdump ... # /usr/sbin/tcpdump -n -e -tttt -vv -i pflog0 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 96 bytes

Live and learn...

Modifying a FreeBSD release ISO for headless booting

Ok, here are the commands. I will come back later to add context, too many irons in the fire right this minute...

# mkdir /bigdisk/iso # mkdir /bigdisk/iso_headless # cd /bigdisk # fetch ftp://ftp7.us.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/7.2/7.2-RELEASE-i386-disc1.iso # mdconfig -a -t vnode -f /bigdisk/7.2-RELEASE-i386-disc1.iso -u 0 # mount -t cd9660 /dev/md0 /bigdisk/iso

No trailing slash on the rsync destination is significant. The following two commands are equivalent:

   rsync -av /bigdisk/iso/ /bigdisk/iso_headless
   rsync -av /bigdisk/iso/* /bigdisk/iso_headless/

# rsync -av /bigdisk/iso/ /bigdisk/iso_headless # umount /bigdisk/iso # mdconfig -d -u 0

Note that I did attempt the following, which failed:

   echo "/boot/loader -h" > /bigdisk/iso_headless/boot.config

# echo 'console="comconsole"' >> /bigdisk/iso_headless/boot/loader.conf # mkisofs -no-emul-boot -U -R -b boot/cdboot -o /bigdisk/7.2-RELEASE-i386-disc1_HEADLESS.iso /bigdisk/iso_headless # cdrecord -scanbus

Set whatever speed you want here. I had some cheap, old CDRs and they needed burn slowly. I have plenty to keep me busy while it's burning...

# cdrecord speed=2 dev=1,0,0 /bigdisk/7.2-RELEASE-i386-disc1_HEADLESS.iso

That's all for now, please enjoy responsibly.

Retrieve ARP table from Cisco router, parse, spew

I had a colleague in need of an automated way to retrieve the ARP table from a lot of Cisco routers and format the output in a spreadsheet. Another colleague suggested using an Expect script, which is definitely cool because I love using Expect (seriously, it's a Swiss Army knife), but I wanted to take it a different direction. I looked up the SNMP MIB to retrieve the ARP table and then parsed the input to provide a two-column output consisting of the IP address and MAC address, one pair per line.

Here is the script:

snmpwalk -t 60 -v 1 -c MYCOMMSTRING routerhostname .1.3.6.1.2.1.4.22.1.2 | \ while read line; do \ IP_ADDR=`echo ${line} | \ awk '{print $1;}' | \ sed -e 's/^IP-MIB::ipNetToMediaPhysAddress.[0-9]*\.//'`; \ MAC_ADDR=`echo ${line} | \ awk '{print $4;}' | \ sed -e 's/^\([0-9a-f]\)/0\1/' \ -e 's/:\([0-9a-f]\):/:0\1:/g' \ -e 's/:\([0-9a-f]\):/:0\1:/g' \ -e 's/:\([0-9a-f]\)$/:0\1/' | \ tr '[:lower:]' '[:upper:]'`; \ echo "${IP_ADDR} ${MAC_ADDR}"; \ done

Notice that there are two mid-string sed matches, each with a 'g' matching command. The reason that this command needs to be listed twice is that a single iteration of 'g' doesn't mean global, it means to match up to two addresses within the stream. Since some of the MAC addresses I was dealing with were beyond that, such as "0:d:ed:c:7:5e", just using a single mid-string pattern with 'g' left me with "00:0d:ed:0c:7:5e" (note the :7: instead of the desired :07:). Adding the second iteration of mid-string matching fixed this issue by enabling matching of a third and fourth mid-string single-digit. I learned something new about sed, and learning something new is a good thing.

FreeBSD 7.2 on my Samsung NC10-14GB

Everything working well so far. To get X working I read a lot of forums and ML archives. To get the 915resolution tool, from ports, working with the 945GME chipset in this netbook, I had to patch a couple of files...

# diff -ruN 915resolution.c.orig 915resolution.c --- 915resolution.c.orig 2009-08-08 22:51:00.000000000 +0000 +++ 915resolution.c 2009-08-08 22:53:44.000000000 +0000 @@ -57,12 +57,12 @@ typedef unsigned int cardinal; typedef enum { - CT_UNKWN, CT_830, CT_845G, CT_855GM, CT_865G, CT_915G, CT_915GM, CT_945G, CT_945GM, + CT_UNKWN, CT_830, CT_845G, CT_855GM, CT_865G, CT_915G, CT_915GM, CT_945G, CT_945GM, CT_945GME, CT_946GZ, CT_G965, CT_Q965 } chipset_type; char * chipset_type_names[] = { - "UNKNOWN", "830", "845G", "855GM", "865G", "915G", "915GM", "945G", "945GM", + "UNKNOWN", "830", "845G", "855GM", "865G", "915G", "915GM", "945G", "945GM", "945GME", "946GZ", "G965", "Q965" }; @@ -216,6 +216,10 @@ type = CT_945GM; break; + case 0x27ac8086: + type = CT_945GME; + break; + case 0x29708086: type = CT_946GZ; break; @@ -511,6 +515,7 @@ case CT_915GM: case CT_945G: case CT_945GM: + case CT_945GME: case CT_946GZ: case CT_G965: case CT_Q965: @@ -551,6 +556,7 @@ case CT_915GM: case CT_945G: case CT_945GM: + case CT_945GME: case CT_946GZ: case CT_G965: case CT_Q965: @@ -806,6 +812,9 @@ else if (!strcmp(argv[index], "945GM")) { *forced_chipset = CT_945GM; } + else if (!strcmp(argv[index], "945GME")) { + *forced_chipset = CT_945GME; + } else if (!strcmp(argv[index], "946GZ")) { *forced_chipset = CT_946GZ; }

...and this one...

# diff -ruN chipset_info.txt.orig chipset_info.txt --- chipset_info.txt.orig 2007-04-15 07:31:29.000000000 +0000 +++ chipset_info.txt 2009-08-08 22:53:59.000000000 +0000 @@ -7,3 +7,4 @@ 915PM, 915GM, 915GMS, 910GML $2590_8086 $91 - $92 945G $2770_8086 $91 - $92 945GM $27A0_8086 $91 - $92 +945GME $27AC_8086 $91 - $92

More to come later, but I will leave you with this:

# kldstat Id Refs Address Size Name 1 22 0xc0400000 9fab28 kernel 2 2 0xc0dfb000 4a64c sound.ko 3 1 0xc0e46000 1ae38 snd_hda.ko 4 1 0xc0e61000 802c ng_ubt.ko 5 6 0xc0e6a000 da08 netgraph.ko 6 1 0xc0e78000 6a45c acpi.ko 7 4 0xc5a80000 2000 ng_bluetooth.ko 8 1 0xc5a82000 d000 ng_hci.ko 9 1 0xc5aba000 f000 ng_l2cap.ko 10 1 0xc5acb000 1a000 ng_btsocket.ko 11 1 0xc5aed000 4000 ng_socket.ko 12 1 0xc5b39000 22000 linux.ko 13 1 0xc5e27000 9000 i915.ko 14 1 0xc5e30000 13000 drm.ko

Have fun!

Rant: There, fixed that for ya...

I am so sick and tired of people who think they are so clever to reply to someone else on a mailing list, EDITING SOMEONE ELSE'S WORDS, and then covering with the oh-so-bright "There, fixed that for you." comment. Hello jackass, why don't you form an intelligent reply and submit that to the list and refrain from editing quoted text from someone else. If I happen to jump straight into a message in some archive via a Google search or such and I see a quoted message then I don't REALLY know what the quoted message was if some super-smart guy decides to "fix" someone else's quote, do I?

Please, if you have taken up this bad habit, give some thought to quitting. It isn't nearly as witty as you believe it is.