Monday, July 22, 2013

more ipv6 / ipv4 fun

Links: ipv6 over adsl :: Linksys E1000 knowledge base :: Linksys list of IPv6 enabled is a useful site for checking IPv6 functionality. YouTube, probably due its fallback capacities (PPAP, HTML 5) is much more tolerant. So it was of interest to recently that I could access South Park at the gf's place, but not at home.

home setup

At home, we have ATT ADSL split between roommates. Service was initiated during the years when ATT provided Linksys E1000 routers in tandem with Motorola 2210-02 modems. This equipment is questionable; the Motorola overheats if it's breathed on, and the Linksys has no IPv6 support. This post is about the latter.

To set-up IPv6, we only want one IPv6 choke-point, so we want the modem to pass everything (bridge mode) and do the PPoE inside the router. But can we get the E1000 to do IPv6? Appears not easily.

Step 1 - ISP

Contact with ATT today noted that their DNS servers are resolving in IPv6.

Step 2 - Modem and Router

Modem is not in bridge mode; it's providing DHCP downstream to the LAN (E1000 Router). Unclear whether that's already degraded or filtered to IPv4-only coming from modem. Also it appears that the modem cannot be set to bridge mode without physical modification.

The router itself is not inherently IPv6 capable, so it may be worthwhile to start there. ATT sells the IPv6 Motorola NVG510 modem/router combo for $100. That one's not been getting good reviews. Another option is say, the less expensive D-Link G604T ($60). Outdated, but OpenWRT or DD-WRT should handle things.

E3000 v.2.1 (dd-wrt)

In an attempt to enable IPv6, installed dd-wrt software. Apparently the E3000 has a small (4MB) memory capacity so we're only looking for K2.6 builds, which run about 3.3MB. It was also suggested to keep Tx power down around 45mW for best throughput. I'll probably set my MTU filter at 1500 or 1400. We'll see.

Couple of useful links:
  • page 4 describes 16964 as first build supporting the router, then the 16968 build as stable, then 16994 (nokaid) having ipv6. 19519 may be most recent, but appears best to start with 16968 and then flash up to 19519 (nokaid).

  • firewall code

  • Friday, July 19, 2013

    [solved] slackware media march - july 2013

    Links: slackerboy install notes :: :: adobe flash 11 :: ibm bash shell tutorial

    "It's rarely if ever necessary to update a good Linux installation -- the odd security update being the exception". This should and would be a true statement if it weren't for the parade of media player and media codec changes perpetrated by media providers. Over the long run, media-related updates cost us months of wasted time and effort.

    An site sensitive to anything less than perfect Flash configuration is, ironically. If it indicates Flash or some other similar Flash error, where do I begin?


    Running Firefox 17 ESR inside a Slackware KDE desktop, look into /usr/lib64/mozilla/plugins
    $ ls /usr/lib64/mozilla/plugins
    Nope, no flashplayer installed. And if I look into "about:plugins" in my browser, I also see no flash player installed.

    KDE directory gobbledy-gook

    The final version of Adobe is 11.2, due to be entirely retired Jan 2014. Linux users may be forced into Chromium at that time. Lack of information is typical in the media-player realm. Meanwhile, we're supposed to install into a bunch of sub-directories and make soft links and so on without KDE documentation. No thanks. [SUCCESS]

    Point the browser to adobe flash 11, and download.
    $ tar -xzvf install_flash_player_11_linux.x86_64.tar.gz
    Download the tarball and unpack it. A file named is created. In a separate file named "usr" a lot of KDE bologna (see below) is also created. Ignore the entire "usr" folder and focus upon .
    # cp /usr/lib64/mozilla/plugins/
    Verify the Flash Player is active in Firefox via about:plugins. If it's not in there, create a plugins folder: /usr/lib64/firefox[version]/plugins; try that kind of thing. Done in five minutes. Go to YouTube and enjoy your bass fishing videos.

    Chromium in Arch

    This works, for those running Arch. Follow the instructions for installing "chromium-pepperflash-stable". [FAIL]

    Same as with libflashplayer.soabove, head to adobe flash 11, and download.
    $ tar -xzvf install_flash_player_11_linux.x86_64.tar.gz
    The unpacked folder will be a /usr folder, with subfolders, /bin, /lib, /share, and so on. Sudo-up and waste an hour transfering files into the real versions of these directories in the file system. For example
    $ cd [install directory]
    $ cd usr/lib64/kde4
    # mkdir /usr/lib64/kde4; mkdir /usr/lib/kde4
    # cp /usr/lib64/kde4/
    # cp /usr/lib/kde4/
    $ cd ..; cd .. ; cd bin
    # cp flash-player-properties /usr/bin/
    $ cd ..; cd share/applications
    # cp flash-player-properties.desktop /usr/share/applications/
    And so on through each directory. After these were complete:
    # update-desktop-database
    # update-desktop-database -q /usr/share/applications >/dev/null 2>&1
    # gtk-update-icon-cache
    # gtk-update-icon cache /usr/share/icons/hicolor >/dev/null 2>&1

    None of this KDE sh*t worked. Suggest the easy way with or, if runninig Arch, get the pepperflash prior to Jan 2014.

    FAIL: cooling/acpi in a 2008 trashiba

    Links: fan speed control :: cooling and acpi :: fancontrol :: Satellite L305D-S5869 :: One user's solution - v.2.0
    I have a disposable Satellite L305D-S5869 or, more specifically, a PSLC8U-00Y010, for trips and low priority activities. It has the older Toshiba BIOS (Insyde H20 Rev 3.5 v. 1.8) with flakey DSDT code; it's hit or miss with ACPI or kernel module fan speed control. This appears to apply mostly to Slackware and Slackware hybrids; the laptop's fans do occasionally work with Fedora-based OS's. Another challenge for this crappy BIOS is hibernation, but that's another post.

    $ lsmod |grep thermal
    thermal 8082 0
    thermal_sys 13862 4 thermal,processor,video,fan
    hwmon 1473 3 radeon,thermal_sys,k10temp

    $ sensors
    Adapter: PCI adapter
    temp1: +56.9°C (high = +70.0°C)

    Adapter: Virtual device
    temp1: +56.0°C (crit = +105.0°C)
    Not bad, except I had never heard the fan on even at over 70C. Taking a trip into the BIOS, there were no ACPI settings, but I added append="acpi=force"into LILO. Still over 70C with no fans. (On the BIOS tip, you can read further down that I also updated the BIOS to the latest version to no avail).


    We can set thresholds to whatever we'd like, using the program to increase or decrease fan use. I don't yet have a configuration file in place.
    # fancontrol
    Loading configuration from /etc/fancontrol ...
    Error: Can't read configuration file

    # ls /etc/fancontrol
    ls: cannot access /etc/fancontrol: No such file or directory
    A larger problems; it may be that fancontrol cannot detect my fans -- its configuration editor is unable to detect them.
    # pwmconfig
    pwmconfig revision 5770 (2009-09-16)
    /usr/sbin/pwmconfig: There are no pwm-capable sensor modules installed
    At first cut, it appears no Pulse Width Modification controllable fans are in the laptop, but it may be the system fan is controllable via some other method(s). It's also of note that KDE is the WM running, and that Kinfocenter does not indicate hardware has been properly detected. Fedora-based distros have had no such problems. Accordingly, although this post began about cooling, detection is the first order of business, and it has been added to the title in parentheses.

    Notably, Kinfocenter provides identical results as lshal, where it might have looked for its information:
    # lshal
    udi = '/org/freedesktop/Hal/devices/acpi_CPU0'
    info.category = 'processor' (string)
    info.product = 'Unknown Processor' (string)

    So instead of hal or other OS detection, let's directly access fan information.
    # ls /sys/class/thermal
    cooling_device0 cooling_device1 cooling_device2 cooling_device3 thermal_zone0

    # cat /sys/class/thermal/cooling_device0/device/hid

    # cat /sys/class/thermal/cooling_device0/device/modalias

    So this fan's ACPI identifier is PNP0C0B. The fan is currently off; what are its range of possible values when running?
    # cat /sys/class/thermal/cooling_device0/device/thermal_cooling/cur_state

    # cat /sys/class/thermal/cooling_device0/device/thermal_cooling/max_state

    # cat /sys/class/thermal/cooling_device0/device/thermal_cooling/power/control
    Now it's clear why no PWM functionality was detected by pwmconfig: the fan's options are apparently either "on" or "off". Power is controlled "auto"-matically. But similarly to these commands for a backlight, let's attempt to turn on "cooling_device0".
    # echo 1 > /sys/class/thermal/cooling_device0/device/thermal_cooling/power/wakeup_active
    bash: /sys/class/thermal/cooling_device0/device/thermal_cooling/power/wakeup_active: Permission denied
    This sort of problem continued with other attempts "invalid parameters" and so forth. The next step seemed to be query the device for legal settings. Assistance via a specialized program to add to efficiency seemed sensible.


    Links: acpitool :: acpitool GUI
    I'm running a Toshiba laptop, so let's try
    # acpitool -F 1
    Forcing the fan of/off is only supported on Toshiba laptops.
    No Toshiba ACPI extensions were found.
    Hah! OK, so "No Toshiba ACPI extensions" on a Toshiba laptop means that either specific kernel modules are not loading for Toshiba, or playing with the BIOS and LILO until this changes. Probably the former, toshiba_acpi.ko.
    # find -name toshiba_acpi.ko

    # lsmod |grep toshiba

    # grep -n toshiba /etc/rc.d/rc.modules
    178:#/sbin/modprobe toshiba_acpi

    # nano /etc/rc.d/rc.modules
    Hopefully this is not too many modules and hogs memory. Following this I rebooted.
    # lsmod |grep toshiba
    Huh. Okay then...
    # modprobe toshiba_acpi
    FATAL: Error inserting toshiba_acpi (/lib/modules/ No such device
    Not good. Per this site, I checked the BIOS and note that the BIOS is not Toshiba. Appears I will have to recompile the kernel and enable (menuconfig) Device Drivers / x86 Platform Specific Device Drivers / Toshiba Laptop Extras . I'm dubious since, if it can't load an external module, how is it likely to work as a built-in option. Still, have to try everything for cooling...

    post kernel - BIOS

    As feared, the kernel was unable to detect the Toshiba-ness of the laptop, even after building in the Toshiba-specific features above, in addition to some other switches which I hoped would allow the kernel to grasp it was in a Toshiba.
    # acpitool -F 1
    Forcing the fan of/off is only supported on Toshiba laptops.
    No Toshiba ACPI extensions were found.
    Next stop is the BIOS. The BIOS, Insyde H20 v.1.2 rev.3.5, appears rudimentary and has no ACPI settings. Perhaps we can flash it to something better/more recent. At the Toshiba website, the most recent (April 2009) BIOS for the L305D. Sort of old and the file is Windows specific - slc8v180.exe. I ran strings against it see if it was just an archive.
    $ strings slc8v180.exe
    [snip] processorArchitecture="X86" name="Roshal.WinRAR.WinRAR" type="win32" /> WinRAR archiver
    I was able to unpack this. I found a bootable ISO in the files with a README to reboot with it. Thereafter, I burned the ISO to a CD, and rebooted the system. Voila, the Insyde BIOS updated from 1.2 to 1.8. However, looking inside it, no ACPI functions were added, and I still get the following:
    # modprobe toshiba_acpi
    FATAL: Error inserting toshiba_acpi (/lib/modules/ No such device

    Arch installation

    Let's see if we can find better interaction with a different OS, with a newer kernel. Installed Arch and then compiled acpitool.
    # acpitool -F 1
    Could not open file : /proc/acpi/toshiba/fan
    You must have write access to /proc/acpi/toshiba/fan to stop or start the fan.
    Or ensure yourself you are running a kernel with Toshiba ACPI support enabled.
    Fails, but more information. Acpitool apparently only points at /proc/acpi/toshiba/fan, but the fan directory for this this system is /sys/bus/acpi/drivers/fan. Let's attempt a softlink, first being sure there is a /proc/acpi/toshiba directory into which we can link a "fans" directory.
    # ls /proc/acpi/toshiba
    keys version

    # ln -s /sys/bus/acpi/drivers/fan /proc/acpi/toshiba
    ln: failed to create symbolic link '/proc/acpi/toshiba/fan': No such
    file or directory
    Let me get this straight, ln fails to create a directory, because the directory it's supposed to create doesn't exist before it creates it? Brilliant program. But at any rate, the device in the "fan" directory, PNP0C0B:00, is a symlink to another directory.
    $ ls -an /sys/devices/LNXSYSTM:00/device:44/PNP0C0B:00
    total 0
    drwxr-xr-x 4 0 0 0 Aug 1 12:06 .
    drwxr-xr-x 6 0 0 0 Aug 1 12:06 ..
    lrwxrwxrwx 1 0 0 0 Aug 1 18:42 driver -> ../../../../bus/acpi/drivers/fan
    -r--r--r-- 1 0 0 4096 Aug 1 18:41 hid
    -r--r--r-- 1 0 0 4096 Aug 1 18:41 modalias
    -r--r--r-- 1 0 0 4096 Aug 1 18:41 path
    drwxr-xr-x 2 0 0 0 Aug 1 18:41 power
    drwxr-xr-x 2 0 0 0 Aug 1 18:41 power_resources_D0
    -r--r--r-- 1 0 0 4096 Aug 1 18:41 power_state
    -r--r--r-- 1 0 0 4096 Aug 1 18:41 real_power_state
    lrwxrwxrwx 1 0 0 0 Aug 1 18:42 subsystem -> ../../../../bus/acpi
    lrwxrwxrwx 1 0 0 0 Aug 1 18:42 thermal_cooling -> ../../../virtual/thermal/cooling_device3
    -rw-r--r-- 1 0 0 4096 Aug 1 12:06 uevent
    -r--r--r-- 1 0 0 4096 Aug 1 18:41 uid
    Yep, acpi "proc" is being replaced by the newer "sys", which also effects "suspend", and other acpi activity. Which is the power state we need to change for the fan? Here are the "cats" for various of these entries:
    driver directory
    hid PNP0C0B
    modalias acpi:PNP0C0B:
    path \_TZ_.FAN1
    power directory
    power_resources_D0 directory
    power_state D3cold
    real_power_state D3cold
    uevent DRIVER=fan
    uid 2
    Now in each of these three sub-directories "driver", "power", and "power_resources_D0"
    drwxr-xr-x 2 0 0 0 Aug 1 12:07 .
    drwxr-xr-x 14 0 0 0 Aug 1 12:06 ..
    lrwxrwxrwx 1 0 0 0 Aug 1 18:39 PNP0C0B:00 -> ../../../../devices/LNXSYSTM:00/device:44/PNP0C0B:00
    --w------- 1 0 0 4096 Aug 1 18:37 bind
    --w------- 1 0 0 4096 Aug 1 12:07 uevent
    --w------- 1 0 0 4096 Aug 1 18:37 unbind

    drwxr-xr-x 2 0 0 0 Aug 1 18:41 .
    drwxr-xr-x 4 0 0 0 Aug 1 12:06 ..
    -rw-r--r-- 1 0 0 4096 Aug 1 19:17 async
    -rw-r--r-- 1 0 0 4096 Aug 1 19:17 autosuspend_delay_ms
    -rw-r--r-- 1 0 0 4096 Aug 1 19:17 control
    -r--r--r-- 1 0 0 4096 Aug 1 19:17 runtime_active_kids
    -r--r--r-- 1 0 0 4096 Aug 1 19:17 runtime_active_time
    -r--r--r-- 1 0 0 4096 Aug 1 19:17 runtime_enabled
    -r--r--r-- 1 0 0 4096 Aug 1 19:17 runtime_status
    -r--r--r-- 1 0 0 4096 Aug 1 19:17 runtime_suspended_time
    -r--r--r-- 1 0 0 4096 Aug 1 19:17 runtime_usage

    drwxr-xr-x 2 0 0 0 Aug 1 18:41 .
    drwxr-xr-x 4 0 0 0 Aug 1 12:06 ..
    lrwxrwxrwx 1 0 0 0 Aug 1 19:19 LNXPOWER:00 -> ../../LNXPOWER:00
    The two symlinks are problematic infinite loops, but "power" appears to contain a useful writeable file named "control". According to this site, which is about USB, but has the appropriate power information, we should be able to use /power/control to change the fan's state from "auto" to "on".
    $ cat /sys/devices/LNXSYSTM:00/device:44/PNP0C0B:00/power/control

    # echo on > /sys/devices/LNXSYSTM:00/device:44/PNP0C0B:00/power/control

    $ cat /sys/devices/LNXSYSTM:00/device:44/PNP0C0B:00/power/control

    $ cat /sys/devices/LNXSYSTM:00/device:44/PNP0C0B:00/power_state
    In other words, although the device seems to accept the power change, the fan does not power-up. And though we can see it in sys/devices, it's not detected by the kernel. Yeah, we see it in dmesg during boot, but it never is seen by the kernel -- we can tell because it never forms an entry in /proc/acpi. During boot, it's called "FAN1", but after that...gone.

    $ dmesg |grep ACPI
    PnP ACPI: found 10 devices
    ACPI: bus type PNP unregistered
    ACPI: bus type USB registered
    ACPI: Battery Slot [BAT0] (battery present)
    ACPI: AC Adapter [ADP0] (on-line)
    ACPI: Power Button [PWRB]
    ACPI: Lid Switch [LID]
    ACPI: Power Button [PWRF]
    ACPI: Video Device [VGA] (multi-head: yes rom: no post: no)
    ACPI: Thermal Zone [THZN] (50 C)
    ACPI: Fan [FAN1] (off)

    # cd /proc/acpi

    # grep -rn LID *
    wakeup:2:LID S4 *enabled

    # grep -rn FAN *
    # grep -rni fan *

    $ acpi -V
    Battery 0: Unknown, 100%
    Battery 0: design capacity 4000 mAh, last full capacity 2541 mAh = 63%
    Adapter 0: on-line
    Thermal 0: ok, 48.0 degrees C
    Thermal 0: trip point 0 switches to mode critical at temperature 105.0 degrees C
    Cooling 0: Fan 0 of 1
    Cooling 1: LCD 3 of 7
    Cooling 2: Processor 0 of 3
    Cooling 3: Processor 0 of 10
    Seems to be there, but nothing....

    How about in /sys/bus/acpi/drivers/fan?
    $ ls /sys/bus/acpi/drivers/fan
    PNP0C0B:00 bind uevent unbind

    $ ls /sys/bus/acpi/drivers/fan/PNP0C0B:00/
    driver hid modalias path power power_resources_D0 power_state real_power_state subsystem thermal_cooling uevent uid
    These are the same settings (and same problems) as earlier above in the former configuration: /sys/devices/LNXSYSTM:00/device:44/PNP0C0B:00/. A Gordian knot with no apparent commands to reach inside it -- so close but so far.

    Wednesday, July 10, 2013

    [solved] curl rabbit hole

    Links: DNS server list Note: the workaround described here is probably only necessary during this temporary era of IPv4 -> IPv6 transition. I have little doubt this curl bug will eventually be resolved.

    Currently (7/2013), when we enter a URL via curl at the command line, curl's first action is a DNS resolution query to resolve the address. By default, curl queries in both IPv4 and IPv6 formats. The rub is that, unless the DNS server responds in both formats, A and AAAA, curl spawns an error (see below) and exits. Most major sites are returned in both formats but many sites, including repositories needed by rpm/yum, are not resolved in IPv6.
    $ curl
    curl: (6) Could not resolve host:; Cannot allocate memory

    We can overcome the problem with the "--ipv4" switch.
    $ curl --ipv4
    [page loads normally]

    The more substantial problem is rpm/yum reliance upon curl for network repository access. Calls to curl from within rpm/yum are made without any switches available to the user. Accordingly, curl makes such DNS queries in a default IPv4 + IPv6 format. This means rpm/yum fail and exit unless curl receives both A and AAAA responses.
    # rpm -ivh
    curl: (6) Could not resolve host:; Cannot allocate memory

    troubleshoot - tcpdump

    Tcpdump information confirms that it is curl's insistence on both IPv4 and IPv6 information that causes the failure:
    # rpm -ivh
    curl: (6) Could not resolve host:; Cannot allocate memory
    [tcpdump information] > 41495+ A? (36) > 25356+ AAAA? (36) > 41495 1/0/0 A (52) > 25356- 0/0/0 (36)
    Curl has received valid DNS resolution (emboldened), but only to the IPv4 query. Curl's failure inside of an rpm request thereby causes rpm to also fail. Although we know so far that curl has a design flaw requiring it receive A and AAAA query responses (instead of either), and although we know we can't control curl inside of rpm, we need more information about why no AAAA (IPv6) data is being returned. We might be able to control that.

    troubleshoot - nslookup, dig

    $ nslookup

    Non-authoritative answer:

    $ nslookup type=AAAA
    nslookup -type=aaaa
    Non-authoritative answer:
    *** Can't find No answer

    $ dig +short A

    $ dig +short AAAA
    Perhaps an AAAA record (PTR or zone) was never created for the sourceforge repository (consider eg.this article). It's also possible ATT does not update its DNS files often, or there is an incorrect AAAA record in their zone. Too many upstream variables to determine reliably. At this point, unless we work for the NSA, we're stuck with the information we have. What is a feasible solution?

    strategy 1

    Write a patch and recompile curl (or pfsense) to succeed with either IPv4 or IPv6 information. The most reliable solution --- except that I'm not a programmer.

    strategy 2 (inelegant but successful)

    Provide BIND with an AAAA /etc/hosts entry for Some good /etc/hosts IPv6 information is available here. The excellent site provided a set of conversion options for 78.46.17. The IPv6 address which appeared best for tricky operations such as the current curl release (operating in IPv4 mode, but needing IPv6 info!) appeared to be "IPv4-mapped address". This is 0:0:0:0:0:ffff:4e2e:11e4, written as ::ffff:4e2e:11e4.
    # nano /etc/hosts

    # nano /etc/host.conf
    order hosts,bind
    (Other helpful links were this article and this IPv4-6 translator). Before the successful curl run, I tried the URL successfully in Chromium, entering http://[::ffff:4e2e:11e4] in the URLbar.

    strategy 3

    Try other DNS servers, ones likely to have the most up-to-date zones. Google provides solid instructions in this document describing how to point to their DNS servers. There is also this DNS list. Alternatively, I could simply add "nameserver" entries in /etc/resolv.conf using "supersede" to prevent overwriting by dhcpcd as described in comments here.

    strategy 4

    A common way to manage IPv4 vs IPv6 confusion in the past has been locking-out IPv6. I even showed how to do this in a prior post. However, since curl now requires requires A and AAAA records to be returned, shutting out IPv6 is no longer a sensible confusion-stopper. Unless a person has no need to contact software repositories.

    xsane rabbit hole

    Links: scanimage man page :: clear overview of network and usb scanners, groups

    I recently connected a mothballed Epson that scans on every system, but found that it didn't work in Fedora. The sane-find-scanner utility detected the scanner, but scanimage -L did not (as root or user). This is apparently a common problem, sometimes associated with permissions, sometimes random bugs.

    I did get it to scan by manually entering the USB address detected by sane-find-scanner, and add the library suffix for Epsons* from /usr/lib/sane/. This looks like, eg...
    $ scanimage -d epson2:libusb:001:005 --resolution 75 --mode Gray > star.jpeg
    $ convert star.jpeg -normalize out.jpg
    Conversion (ImageMagick) is required because the output image caused errors "not jpeg starts 0x50 0x34". The Start of File (SOF) was not the correct header for a JPEG. This is because it's really a PGM file. Anyway, scanning in this way would be prohibitively time intensive.

    *attempted both /usr/lib/sane/libsane-epson and /usr/lib/sane/libsane-epson2

    $ scanimage --help --device-name epson:libusb:001:005

    Options specific to device `epson:libusb:001:005':
    Scan Mode:
    --mode Lineart|Gray|Color [Lineart]
    Selects the scan mode (e.g., lineart, monochrome, or color).
    --dropout None|Red|Green|Blue [None]
    Selects the dropout.

    --gamma-correction User defined (Gamma=1.0)|User defined (Gamma=1.8) [User defined (Gamma=1.8)]
    Selects the gamma correction value from a list of pre-defined devices
    or the user defined table, which can be downloaded to the scanner
    --resolution 75|150|300|600dpi [75]
    Sets the resolution of the scanned image.
    --speed[=(yes|no)] [no]
    Determines the speed at which the scan proceeds.

    --short-resolution[=(yes|no)] [no]
    Display short resolution list
    --red-gamma-table 0..255,...
    Gamma-correction table for the red band.
    --green-gamma-table 0..255,...
    Gamma-correction table for the green band.
    --blue-gamma-table 0..255,...
    Gamma-correction table for the blue band.

    --wait-for-button[=(yes|no)] [no]
    After sending the scan command, wait until the button on the scanner
    is pressed to actually start the scan process.
    --preview[=(yes|no)] [no]
    Request a preview-quality scan.
    --preview-speed[=(yes|no)] [no]

    -l 0..215.9mm [0]
    Top-left x position of scan area.
    -t 0..297.857mm [0]
    Top-left y position of scan area.
    -x 0..215.9mm [215.9]
    Width of scan-area.
    -y 0..297.857mm [297.857]
    Height of scan-area.
    --quick-format CD|A5 portrait|A5 landscape|Letter|A4|Max [Max]


    Stracing scanimage revealed that the appropriate was consulted, but nothing was returned. I also moved all .conf files in /etc/sane.d/ except the epsons, in case the client was could not locate the appropriate .conf file from the 30 or so in that folder. No luck.


    One article (link is also at top of page), seemed to imply that saned was necessary to run the scanner. I considered saned (configured via /etc/sane.d/saned.conf) only necessary for network access to scanners, and so looked more closely.

    Saned and CUPS appear similar, at least in concept. Since I could find no clear guideline for the syntax for adding USB printers into saned, it's possible they are added to /etc/sane.d/saned.conf in a similar USB URL format as in CUPS, eg usb:/dev/usb/lp0. But it appears we may have to more specific about which USB and so include each:


    The Fedora installation had no group for scanning. It might be necessary to add a "scanner" group and create user access. If there is an underlying permissions issue, this might resolve it.

    Tuesday, July 9, 2013

    [solved] dns, yum, rpm, curl, ping

    Links: yum variables :: IPv4 address conversion :: yum commands
    NB: This is complicated post. It first addresses IPv6 (mostly successfully), but a second problem is revealed specific to Fuduntu, that I could not circumvent. Since Fuduntu is defunct, I'm disregarding and posting "solved" above. Hopefully, there's plenty of info below for others working on what might be a similar Fedora flavor of the Fuduntu release problem.
    Consider the following problem -- if I can ping, I should be equally able to curl, but I'm not:
    $ ping
    PING ( 56(84) bytes of data.
    64 bytes from ( icmp_seq=1 ttl=49 time=27.9 ms
    64 bytes from ( icmp_seq=2 ttl=49 time=27.7 ms
    $ curl
    curl: (6) Couldn't resolve host ''
    This did more than just raise my curiosity; rpm/yum relies on curl during access to repositories. First I checked for proxy and IPv6 settings. All looked normal: no proxy, IPv6 set to ignore, but not to block or forced resolution. Let's look under the hood.


    Here are portions of dumps for the successful ping and struggling curl:
    # tcpdump -nlieth0 -s0 udp port 53 -vvv
    [during ping] > [udp sum ok] 11891+ A? (34) > [udp sum ok] 11891 q: A? 1/0/0 [5s] A (50) > [udp sum ok] 51147+ PTR? (43) > [udp sum ok] 51147 q: PTR? 1/0/0 [9h53m39s] PTR (73)

    [during curl] > [udp sum ok] 26082+ A? (34) > [udp sum ok] 54668+ AAAA? (34) > [udp sum ok] 26082 q: A? 1/0/0 [5s] A (50) > [udp sum ok] 54668- q: AAAA? 0/0/0 (34) > [udp sum ok] 47978+ A? (46) > [udp sum ok] 42568+ AAAA? (46) > [udp sum ok] 47978 NXDomain- q: A? 0/0/0 (46) > [udp sum ok] 42568 NXDomain- q: AAAA? 0/0/0 (46)
    Ping only queries the DNS server in IPv4 (A?) and has success. Curl initially requests in both IPv4(A?) and IPv6 (AAAA?). Although curl receives a proper response ( to its IPv4 request, nothing is returned for IPv6 request. Apparently due to some bug, curl ignores the IPv4 resolution and requests a second time in both formats. It also mysteriously appends "localdomain" onto its query(!).

    solution - /etc/hosts + release awareness

    Links: IPv4 address conversion :: yum concerns :: cleaning old yum info

    We should write a patch for curl and recompile it, but that's for programmers. I only know how to supply curl with the IPv6 information it wants. The site may not have an AAAA record in its DNS zone file, but I can still manually enter IPv6 info into /etc/hosts and force curl to use that.
    # nano /etc/hosts

    # nano /etc/host.conf
    order hosts,bind

    $ curl
    [page loads normally]
    Problem 1 solved. However, there is a second problem, one specific to Fuduntu, not curl. Fuduntu is a hybrid. It accordingly doesn't have typical Fedora values in its rpm variables, eg $releasever.
    $ rpm - q fedora-release
    package fedora-release is not installed

    $ rpm -q fuduntu-release

    $ ls /etc/*release
    ls: cannot access /etc/release*: No such file or directory

    $ yum list fedora-release
    Loaded plugins: fastestmirror, langpacks, presto, refresh-packagekit
    Adding en_US to language list
    Determining fastest mirrors
    Could not retrieve mirrorlist error was
    14: PYCURL ERROR 6 - ""
    Error: Cannot find a valid baseurl for repo: fuduntu
    Glitches also cause this with Fedora users when version conflicts arise. In the case of Fuduntu however, the repos no longer exist -- one strategy might be to spoof Fuduntu version checking as if were being upgraded when it accesses third-party repos. If we eliminate the locally-stored repo files and the rpm release file, we might be able to override with third party information. First let's do a debug dump with the current info (in case we need it later), then remove local information.
    $ yum-debug-dump
    Output written to: /home/~/yum_debug_dump-local-2013-07-12_20:50:30.txt.gz

    $ rpm -q fuduntu-release

    # yum remove fuduntu-release-2013-3.noarch
    [screens and screens of removal]

    $ rpm -q fuduntu-release

    # ls /etc/yum.repos.d
    dropbox.repo fuduntu.repo
    # rm /etc/yum.repos.d/fuduntu.repo
    # ls /etc/pki/rpm-gpg/
    RPM-GPG-KEY-fuduntu RPM-GPG-KEY-fuduntu-i386
    RPM-GPG-KEY-fuduntu-2013-primary RPM-GPG-KEY-fuduntu-x86_64
    # rm /etc/pki/rpm-gpg/*

    # yum clean all

    $ rpm -q fuduntu-release


    Links:replace $releasever using sed :: yum variables
    The orphaned Fuduntu release has no access to Fuduntu repositories because they no longer exist. Fuduntu must rely on third-party repos to move forward. Fedora-related repositories are arranged with "f[$releasever]-[$basearch]". In Fuduntu this variable was "2013-i386". This special variable worked in Fuduntu repos, but fails in 3rd party repos -- $releasever, needs to be changed to something standard, such as "17", to create a more Fedora-standard "f17-i386" variable.

    But nothing worked. Not exporting the variable $releasever=17 to the kernel, not changing /etc/yum.conf, not swapping out the value of "2013" for "17" in each /etc/*release. Nothing I could find globally changed this variable. Eventually, after a couple of lost days on the project, I gave up and brute forced the repo files individually. Before modifying, I eliminated the old cache and backed-up all the unmodified repos into a new directory I called "default". Then I modified the repos, exchanging "$releasever" for "17" in each file.
    # rm -r /var/tmp/*

    # mkdir /etc/yum.repos.d/default
    # cp /etc/yum.repos.d/* /etc/yum.repos.d/default/

    # sed -i 's/$releasever/17/g' ./etc/yum.repos.d/*
    The repos finally loaded.

    (non)solution - remove IPv6 functionality

    Link: Disabling IPv6

    This is not a solution, because curl/rpm/yum needs IPv6 and IPv4 information and does not get what it needs with the process below. I'm including this info however, because it provides insight into how other TCP clients (ie, not strictly curl/rpm) can be assisted in a mixed A/AAAA environment. Some readers are interested in a Chromium,etc.
    # nano /etc/sysconfig/network

    # nano /etc/modprobe.d/blacklist.conf
    blacklist nf_conntrack_ipv6
    blacklist nf_defrag_ipv6

    Appendix 1 - wireshark

    A good link for using wireshark to check DNS problems. The wireshark GUI is more elegant than my CLI approach above, and arguably more user-friendly for those working on IPv4 /IPv6 solutions.

    Appendix 2 - strace

    Straces are too long to regurgitate here; let's look at the 14 relevant lines where ping succeeds and curl is unsuccessful. Of possible interest here is that, from inside the LAN, the DNS server, via DHCP, is simply the gateway at "".
    $ strace ping
    connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("")}, 16) = 0
    gettimeofday({1373430779, 7870}, NULL) = 0
    poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
    send(3, "\346\f\1\0\0\1\0\0\0\0\0\0\3www\10websense\3com\0\0\1"..., 34, MSG_NOSIGNAL) = 34
    poll([{fd=3, events=POLLIN}], 1, 5000) = 1 ([{fd=3, revents=POLLIN}])
    ioctl(3, FIONREAD, [50]) = 0
    recvfrom(3, "\346\f\201\200\0\1\0\1\0\0\0\0\3www\10websense\3com\0\0\1"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("")}, [16]) = 50
    close(3) = 0
    connect(3, {sa_family=AF_INET, sin_port=htons(1025), sin_addr=inet_addr("")}, 16) = 0
    getsockname(3, {sa_family=AF_INET, sin_port=htons(53553), sin_addr=inet_addr("")}, [16]) = 0

    And for the failing curl :
    $ strace curl
    connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("")}, 16) = 0
    gettimeofday({1373429425, 713068}, NULL) = 0
    poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
    sendmmsg(3, {{{msg_name(0)=NULL, msg_iov(1)=[{"\215s\1\0\0\1\0\0\0\0\0\0\3www\10websense\3com\0\0\1"..., 34}], msg_controllen=0, msg_flags=0}, 34}, {{msg_name(0)=NULL, msg_iov(1)=[{"\34\305\1\0\0\1\0\0\0\0\0\0\3www\10websense\3com\0\0\34"..., 34}], msg_controllen=0, msg_flags=0}, 34}}, 2, MSG_NOSIGNAL) = 2
    poll([{fd=3, events=POLLIN}], 1, 5000) = 1 ([{fd=3, revents=POLLIN}])
    ioctl(3, FIONREAD, [34]) = 0
    recvfrom(3, "\34\305\200\0\0\1\0\0\0\0\0\0\3www\10websense\3com\0\0\34"..., 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("")}, [16]) = 34
    close(3) = 0
    connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("")}, 16) = 0

    Curl never seems to leave port 53, and it also appears curl may have actually received the IP of the DNS server in response to its query to that selfsame DNS server. Perhaps this is due to curl embedding its request inside a more complex sendmmsg routine, as opposed to ping's simpler send routine. Additionally, ping uses a getsockname process not used by curl.

    More information: while Epiphany is running, we check to see what calls are creating errors. Get its PID, open a terminal, and let strace run for several seconds while attempting to surf to an address in Epiphany. Then CTRL-C out and examine the data,eg....
    $ strace -c -p 13881
    Process 3811 attached
    ^CProcess 3811 detached
    % time seconds usecs/call calls errors syscall
    ------ ----------- ----------- --------- --------- ----------------
    54.08 0.000384 0 2167 writev
    14.79 0.000105 5 20 munmap
    13.24 0.000094 0 1526 clock_gettime
    13.24 0.000094 0 6690 4567 recv
    4.65 0.000033 0 4583 poll
    0.00 0.000000 0 1 restart_syscall
    0.00 0.000000 0 80 9 read
    0.00 0.000000 0 31 write
    0.00 0.000000 0 36 open
    0.00 0.000000 0 36 close
    0.00 0.000000 0 4 unlink
    0.00 0.000000 0 18 access
    0.00 0.000000 0 8 rename
    0.00 0.000000 0 262 gettimeofday
    0.00 0.000000 0 1 clone
    0.00 0.000000 0 14 _llseek
    0.00 0.000000 0 21 mmap2
    0.00 0.000000 0 58 46 stat64
    0.00 0.000000 0 84 8 lstat64
    0.00 0.000000 0 36 fstat64
    0.00 0.000000 0 2 1 madvise
    0.00 0.000000 0 70 6 futex
    0.00 0.000000 0 1 statfs64
    ------ ----------- ----------- --------- --------- ----------------
    100.00 0.000710 15749 4637 total
    Blog formatting squishes the data a little, but we see significant errors(4567 of them) on "recv" calls, as well as some on "stat64" and a few others.

    Wish I could write in C and recompile curl.

    Saturday, July 6, 2013

    fuduntu - yum/rpm stuff

    links: yum setup :: yum command examples

    why yum/rpm?

    In the previous post, I noted an install of Fuduntu, a recently orphaned distro. The idea was to establish a simple system which might retain its stability against the tide of media player updates. An expected side benefit was the opportunity to learn yum. Specifically, it's necessary to modify Fuduntu's default yum files because Fuduntu's yum URL's are now invalid. Note: the final Fuduntu release appears to be based on Fedora 17 (or roughly Enterprise Linux 6), plus some Ubuntu features.


    No notable differences between Fedora and Fuduntu in the global /etc/yum.conf file. Standard.

    repos to remove - /etc/yum.repos.d/

    The helpful System > Administration > Software Sources window:

    We can see the Fuduntu repository entries are there, though they no longer point anywhere. To follow good housekeeping, toggle enable to "enable=0" inside each undesired repo entry in /etc/yum.repos.d/. To be more thorough, we could delete unwanted repo files(in /etc/yum.repos.d/) and gpg keys (in /etc/pki/gpg-keys/). In my simple world, I renamed all the repos with a .bak extension and kept them -- I might want to look inside one later. This also allows me to change the extension back to ".repo" if I wanted to reactivate one for some reason.
    # cd /etc/yum.repos.d/
    # rename .repo .bak *.repo

    repos to add

    As noted at the top, I assumed Fuduntu's nearest releases were F17 and EL6.
    (1) REPOFORGE (formerly RPM Forge)
    # rpm -ivh
    However, rpm for some reason could not resolve the host and was providing the following error
    curl: (6) Could not resolve host:; Cannot allocate memory
    error: skipping - transfer failed
    This is not a small problem, and requires a separate post on IPv4 and IPv6 addressing, which will be my next post. Essentially, curl does the DNS and downloading for rpm/yum actions. Users can specify "--ipv4" in direct CLI curl requests, but there are no such switches when rpm calls curl as a subroutine, out of sight of the user. If it doesn't receive IPv6 information, curl fails, causing rpm to fail.

    So, for now, downloaded the rpm repo file directly via my browser, and then...
    # yum --nogpgcheck localinstall rpmforge-release-0.5.3-1.el6.rf.i686.rpm
    ...and finally
    # yum install --enablerepo=rpmforge-extras
    Looking at its file, it performs a gpg check on the downloaded packages. There are many settings available, a simple example is the one above -- to toggle a repo in a file on or off, change the state in the "enabled" line.

    (2) ATRPMS Below is the repair for curl IPv6 finickiness. Then one can directly download and install the file using rpm.
    # nano /etc/host.conf
    order hosts,bind

    # nano /etc/hosts

    # curl --ipv6

    [install key]
    # rpm --import

    # rpm -ivh
    Preparing... ########################################### [100%]
    1:atrpms-repo ########################################### [100%]

    # ldconfig

    # yum clean all

    # nano /etc/host.conf
    order hosts,bind

    # nano /etc/hosts

    # curl --ipv6

    # rpm -ivh
    warning: /var/tmp/rpm-tmp.QSSeST: Header V3 RSA/SHA256 Signature, key ID 8296fa0f: NOKEY
    Preparing... ########################################### [100%]
    1:rpmfusion-free-release ########################################### [100%]

    # ldconfig

    # yum clean all

    manual repo pointing

    Let's create a new repo file, fedora1.repo. Permissions of the file should be 644...
    # chown 644 /etc/yum.repos.d/fedora1.repo should appear in System > Administration > Software Sources:

    quick test - yum repolist

    Fast way to check if everything is operating correctly

    NOTES: gpg keys

    On first cut, the new repository did not work. Note that in the above repo listing, we requested a gpg check and provided the folder to find it...
    ... but then of course we only had Fuduntu keys in that folder, no Fedora keys. Further, the Fedora project has moved on, it's no longer operating repos for Fedora 17. So we could use rpm to import the keys and automatically create softlinks... /etc/pki/rpm-gpg/...
    # rpm --import RPM-GPG-KEY-fedora-17-primary
    # rpm --import RPM-GPG-KEY-fedora-17-secondary
    ...but Fedora does not maintain older packages, so we'd have the keys to nothing. We could even add the old F17 keys manually...
    # gedit /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-17-primary the key block from the link into that file, then made a softlink for housekeeping...
    # ln -s /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-17-primary /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora
    ...but again this would be pointless since no F17 software is available at Fedora.

    There are also these sorts of possible yum problems.