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.