09 June 2011

Happy IPv6 test day, part 2

In my first post in this small series, I closed without addressing matters of securing an IPv6 connection, and in matters of debugging where a connection failure is occurring. Thinking about it, the diagnostic post needs to come first, because tightening down a conneciton can cause hard to diagnose symptoms. So, on to diagnosis ...

We examined the interface results last time. Looking at just the routing related to ipv6 is straightfowrard as well:

Some familiar tools:

/sbin/ifconfig eth0
/sbin/ifconfig sit1
/sbin/route -A inet6

So using those tools:

[herrold@hostname ~]$ /sbin/ifconfig sit1
sit1 Link encap:IPv6-in-IPv4
inet6 addr: 2604:aa:bb:cc::2/64 Scope:Global
inet6 addr: fe80::4cf2:1c/128 Scope:Link
UP POINTOPOINT RUNNING NOARP MTU:1480 Metric:1
RX packets:1691 errors:0 dropped:0 overruns:0 frame:0
TX packets:1693 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:177195 (173.0 KiB) TX bytes:210468 (205.5 KiB)

[herrold@hostname ~]$ /sbin/route -n -A inet6 | grep 2604
2604:aa:bb:cc::/64 :: U 256 1658 0 sit1
2604:aa:bb:cc::/128 :: U 0 0 2 lo
2604:aa:bb:cc::2/128 :: U 0 1691 1 lo
[herrold@mailhub ~]$


That is a pretty ordinary routing table for a non-gateway endpoint. Off-box traffic (to the '/64' netmask) is handed to the sit interface, and local traffic (to the '/128') retained on the local lo interface

We use a unfamiliar tool: ping6 -- The common '127.0.0.1' localhost has a new form under ipv6:

ping6 ::1 -c 2

and testing

[root@hostname ~]# ping6 ::1 -c 2
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=0 ttl=64 time=0.157 ms
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.132 ms

--- ::1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.132/0.144/0.157/0.017 ms, pipe 2
[root@ostname ~]#

And we can ping by IP on the 'Global' link, both on the local end, and remotely with differing transit times for the packets:

Looking at the network connections, we examine the tunelling interface:

[root@hostname ~]# /sbin/ifconfig sit1
sit1 Link encap:IPv6-in-IPv4
inet6 addr: 2604:aa:bb:cc::2/64 Scope:Global
inet6 addr: fe80::4cf2:1c/128 Scope:Link
UP POINTOPOINT RUNNING NOARP MTU:1480 Metric:1
RX packets:1714 errors:0 dropped:0 overruns:0 frame:0
TX packets:1731 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:179587 (175.3 KiB) TX bytes:215180 (210.1 KiB)

[root@hostname ~]# ping6 2604:aa:bb:cc::2 -c 2
PING 2604:aa:bb:cc::2(2604:aa:bb:cc::2) 56 data bytes
64 bytes from 2604:aa:bb:cc::2: icmp_seq=0 ttl=64 time=0.135 ms
64 bytes from 2604:aa:bb:cc::2: icmp_seq=1 ttl=64 time=0.137 ms

--- 2604:aa:bb:cc::2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.135/0.136/0.137/0.001 ms, pipe 2
[root@hostname ~]# ping6 2604:aa:bb:cc::1 -c 2
PING 2604:aa:bb:cc::1(2604:aa:bb:cc::1) 56 data bytes
64 bytes from 2604:aa:bb:cc::1: icmp_seq=0 ttl=64 time=55.1 ms
64 bytes from 2604:aa:bb:cc::1: icmp_seq=1 ttl=64 time=53.7 ms

--- 2604:8800:100:bb::1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 53.781/54.473/55.165/0.692 ms, pipe 2
[root@hostname ~]#

Turning to DNS and name resoluton, it is quite familiar. One does not need an IPv6 link to query nameservers and receive back results, as they will answer questions _about_ ipv6 hostnames ('AAAA' records) to any authorized inquirant. Try these:

dig +trace www.ipv6.sixxs.net
dig www.kame.net aaaa

I get answers like this:

[herrold@centos-5 ~]$ dig www.kame.net aaaa

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5 <<>> www.kame.net aaaa
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45595
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 3

;; QUESTION SECTION:
;www.kame.net. IN AAAA

;; ANSWER SECTION:
www.kame.net. 85164 IN CNAME orange.kame.net.
orange.kame.net. 85164 IN AAAA 2001:200:dff:fff1:216:3eff:feb1:44d7

;; AUTHORITY SECTION:
kame.net. 85164 IN NS mango.itojun.org.
kame.net. 85164 IN NS orange.kame.net.

;; ADDITIONAL SECTION:
mango.itojun.org. 2364 IN A 210.155.141.200
mango.itojun.org. 2364 IN AAAA 2001:2f0:0:8800:206:5bff:fe8d:940
mango.itojun.org. 2364 IN AAAA 2001:2f0:0:8800::1:1

;; Query time: 1 msec
;; SERVER: 10.16.1.112#53(10.16.1.112)
;; WHEN: Thu Jun 9 17:17:20 2011
;; MSG SIZE rcvd: 195

[herrold@centos-5 ~]$

which is certainbly a mess to read -- let's trim out the interesting parts:

[herrold@centos-5 ~]$ dig www.kame.net aaaa
;; ANSWER SECTION:
www.kame.net. 85164 IN CNAME orange.kame.net.
orange.kame.net. 85164 IN AAAA 2001:200:dff:fff1:216:3eff:feb1:44d7

Which is the familiar information: a CNAME record is pointed in fact at a AAAA record at a ipv6 -type IP. We can ping (ping6) it by IP:

[root@hostname ~]# ping6 2001:200:dff:fff1:216:3eff:feb1:44d7 -c 2
PING 2001:200:dff:fff1:216:3eff:feb1:44d7(2001:200:dff:fff1:216:3eff:feb1:44d7) 56 data bytes
64 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7: icmp_seq=0 ttl=52 time=246 ms
64 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7: icmp_seq=1 ttl=52 time=256 ms

--- 2001:200:dff:fff1:216:3eff:feb1:44d7 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 246.833/251.705/256.577/4.872 ms, pipe 2
[root@hostname ~]#

or ping it by name, as DNS is working:

<[root@hostname ~]# ping6 www.kame.net -c 2
PING www.kame.net(2001:200:dff:fff1:216:3eff:feb1:44d7) 56 data bytes
64 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7: icmp_seq=0 ttl=52 time=227 ms
64 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7: icmp_seq=1 ttl=52 time=244 ms

--- www.kame.net ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1008ms
rtt min/avg/max/mdev = 227.291/235.678/244.066/8.401 ms, pipe 2
[root@hostname ~]#

Some other examples to try as 'beacons' might include:

ping6 2604:8800:100:9a::1 -c 2
ping6 2001:200:0:8002:203:47ff:fea5:3085 -c 2
ping6 ftp.ipv6.uni-muenster.de -c 2
ping6 -I eth0 ipv6.google.com -c 2


So the familiar diagnostic methods of examining interfaces, checking routing, testing connectivity by IP, and connectvity after resolution by name are all present

08 June 2011

Happy IPv6 test day

There is a 'ipv6 readiness testing day' today, April June 8, 2011, and so it seems appropriate to post my personal checklist for putting a CentOS box up on that network fabric

  • Apply for an account with SixXs. Their reply takes a couple of days, as it is a volunteer run organization
  • Have a deployed, updated, and hardened unit at a routable static IPv4 address
  • Amend /etc/sysconfig/iptables to include a line passing the tunnelling protocol. I place the entry after the IPSEC protocol entries in a stock setup. Restart iptables
    ... 
    -A RH-Firewall-1-INPUT -p 50 -j ACCEPT
    -A RH-Firewall-1-INPUT -p 51 -j ACCEPT
    # vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
    -A RH-Firewall-1-INPUT -p ipv6 -j ACCEPT
    # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...
  • Strip out any previous efforts at disabling the ipv6 / net-pf-10 kernel modules from loading in /etc/modules.conf, and in the files sourced in /etc/modprobe.d/ . Then rebuild the modules dependency table: /sbin/depmod -a
  • Amend /etc/sysconfig/network to carry the following lines:
    #
    NETWORKING_IPV6=yes
    IPV6INIT=yes
    IPV6FORWARDING=yes
    IPV6_DEFAULTDEV=sit1
    #
    Which anticipates that the configuration details for the ipv6 tunnel will live in a file: /etc/sysconfig/network-scripts/ifcfg-sit1
  • and add that mentioned file: /etc/sysconfig/network-scripts/ifcfg-sit1 -- I have elided site-specific details as to IP addresses with: aa.bb.cc and aa:bb:cc placeholders
    #
    DEVICE=sit1
    BOOTPROTO=none
    ONBOOT=yes
    IPV6INIT=yes
    IPV6_TUNNELNAME="SixXS"
    #
    IPV6_AUTOTUNNEL=yes
    PHYSDEV=eth0
    IPV6_ROUTER=yes
    #
    IPV6TUNNELIPV4="38.229.76.3"
    # 38.229.76.3 is the remote end of the tunnel at the tunnel broker
    IPV6TUNNELIPV4LOCAL="198.aa.bb.cc"
    # 198.aa.bb.cc is the local ipv4 static IP
    IPV6ADDR="2604:aa:bb:cc::2/64"
    # 2604:aa:bb:cc::2/64 shows both the local gateway IP, and netmask
    # the remote end gateway IP is by convention, the :1
    IPV6_MTU="1280"
    TYPE=sit
    #

At this point, simply restarting networking should bring up the ipv6 link, and properly route it -- so: /sbin/service network restart

The interfaces will look something like this:

[herrold@nostname ~]$ /sbin/ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:01:02:aa:bb:cc
inet addr:76.aa.bb.cc Bcast:76.aa.bb.dd Mask:255.255.255.248
inet6 addr: fe80::201:aaff:bb05:cc16/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:11088057 errors:0 dropped:0 overruns:1 frame:0
TX packets:10668738 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1726307345 (1.6 GiB) TX bytes:3178496052 (2.9 GiB)
Interrupt:3 Base address:0x6f80

[herrold@hostname ~]$ /sbin/ifconfig sit1
sit1 Link encap:IPv6-in-IPv4
inet6 addr: 2604:aa:bb:cc::2/64 Scope:Global
inet6 addr: fe80::bbf2:cc1c/128 Scope:Link
UP POINTOPOINT RUNNING NOARP MTU:1480 Metric:1
RX packets:500 errors:0 dropped:0 overruns:0 frame:0
TX packets:502 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:53331 (52.0 KiB) TX bytes:62784 (61.3 KiB)

[herrold@hostname ~]$

To wrap this up, ipv6 hardening, and connection debugging are worthy topics, and it may well be that a cautious sysadmin wants to lock down /etc/sysconfig/ip6tables and examine how one has hardened /etc/hosts.deny ... But rather than rush out content (I have a couple of mailing list posts I need to re-work), I'll leave these for later posts, while you, gentle reader, go apply for an account at a tunnel broker

22 May 2011

What not to buy: Dynex 1.3MP Webcam

I've spent the time across the weekend, tinkering with a USB webcam -- particularly a Dynex 1.3MP Webcam (USB ID: 0x19ff:0x0102 ). As I recall, Dynex is a BestBuy house brand. The Linux USB device driver support table indicates that the device is supported under _some_ Linux variant

The need was occasioned because some small animal, probably a groundsquirrel, has been digging in the garden of missus, and she wanted confirmation on what to go after. The local cat, Malaki, heard it and darted to the door, but I was too late letting him out to track down the intruder ... this time

My laptop at home has been my primary compute platform there, since I crushed my ankle late last December. I still need to post a page with all the gory x-ray details, to go along with the twitter pictures I sent along the way with recovery. The medical bill cost was staggering as well, and I'll sanitize and post details of that as well. Back to the laptop -- it runs a reasonably stock CentOS 5 most of the time, except when I've been trialling rebuilds of part of Red Hat's '6' series SRPM rebuilds

The seemingly needed 'uvcvideo' video driver was present, and I forced it to load, at the cost of the machine locking up in short order thereafter. I had to power cycle the unit to recover use of it. Hmmm ...

So I went looking for an application to pull content off of the newly present /dev/video0, and turned to the native 'ekiga' that CentOS 5 carries. It refused to acknowledge anything useful at that device, and so ... I had to power cycle the unit to recover use of it. Hmmm ...

Perhaps it was 'ekiga'. So I set out to solve the needed packaging to attain a current 'zoneminder' ... a bit more complex chain:

06:42:44 PM libgcrypt-devel-1.4.4-5.el5
06:42:44 PM libgpg-error-devel-1.4-2
06:42:46 PM gnutls-devel-1.4.1-3.el5_4.8
06:42:47 PM pcre-devel-6.6-6.el5_6.1
06:44:49 PM perl-MIME-Types-1.19-2orc
06:46:55 PM perl-TimeDate-1.16-5.el5
06:47:02 PM perl-MailTools-1.74-1orc
06:47:38 PM perl-DateManip-5.44-1.2.1
06:47:59 PM perl-DBD-MySQL-3.0007-2.el5
07:19:55 PM perl-PHP-Serialization-0.27-4orc
07:20:50 PM perl-MIME-Lite-3.01-5orc
07:23:33 PM perl-IO-Stringy-2.108-3.orc
07:23:54 PM perl-MIME-tools-5.411a-12orc
07:34:34 PM perl-IO-Zlib-1.10-1orc
07:43:10 PM perl-Compress-Raw-Zlib-2.027-1orc
07:47:54 PM perl-Archive-Zip-1.16-1.2.1
07:48:05 PM perl-Archive-Tar-1.39.1-1.el5_5.2
07:49:54 PM php-pdo-5.1.6-27.el5_5.3
07:49:55 PM php-mysql-5.1.6-27.el5_5.3
07:50:28 PM perl-Module-Load-0.10-3orc
07:51:38 PM perl-Device-SerialPort-1.002-3orc
07:51:49 PM zoneminder-1.23.3-2orc


and went through the very nicely done configuration. Oops -- it wants a mysql database server running to save state:


07:59:18 PM mysql-server-5.0.77-4.el5_6.6
08:03:20 PM mysql-test-5.0.77-4.el5_6.6


Zoneminder was willing to admit it could read /dev/video0 but all it returned was a black image. Grrr. ... and then after a few minutes, the laptop locked up again, and I had to power cycle the unit to recover use of it. Hmmm ..

So I spent a few minutes with Google doing some research, and found what looks like a ratehr nice little application for USB frame grabbing called: gideo -- see: A GTK video grabber designed with spca5xx components. Building it dragged in the Gnome / GTK development environment of thirty or so packages, and I only had to fix up a dependency's .spec file to handle Red Hat's multilib conventions


05:27:56 PM libtiff-devel-3.8.2-7.el5_6.7
05:29:52 PM gideo-0.1-1orc
05:43:18 PM SDL_image-1.2.10-2orc
05:43:18 PM SDL_image-devel-1.2.10-2orc


But now, 'gideo' is unwilling to admit, or loading the module is unwilling to produce a live /dev/video0, and ... you guessed it: The laptop locked up again, and I had to power cycle the unit to recover use of it

I think perhaps I'll try a different video camera