[solved] Epson V30 (04b8:0131) v. V370 (04b8:0141a)

nb: 2022 - subbed "yay" for all "yaourt"

short version

Neither scanner will be detected in $ scanimage -L unless correct driver is used. Typically the V30 works well with only the driver, whereas the V370 needs the driver and may also need "epowka" adjustments described further down this page. Neither scanner requires CUPS.

V30 (04b8:0131) - $ yay -S iscan-plugin-gt-f720

V370 (04b8:014a) - $ yay -S iscan-plugin-perfection-v370

If still no proper V370 detection, check the "epowka" and "hpaio" notes further down. I've never been able to configure a box for both scanners so I could hook up either. I remove the driver for the scanner not being used.

---

prevention

• check the connection

  $ lsusb
  ID 04b8:0131 Seiko Epson Corp. GT-F720 [GT-S620/Perfection V30/V300 Photo]

• install and enable cups

  # pacman -S cups
  # systemctl list-unit-files |grep cups
  [if necesary....]
  # systemctl enable cups.service
  # systemctl restart cups.service

• can play with turning cups on and off or even uninstalling it later, but it's likely to be initially necessary for the scanner to successfully build against
• install the AUR driver

  $ yay -S iscan-plugin-gt-f720

• verify it's a detected scanner

  $ scanimage -L
  device `epkowa:interpreter:001:006' is a Epson Perfection V30 flatbed scanner

• try a test scan with, e.g. xsane

problem

Initiating the GUI xsane application with a USB-connected Epson V30 scanner results in a pause, then termination of the xsane application (without scanning). Connecting an Epson V370, the same actions result in normal xsane scanning operations. Using a known-good, functioning USB-connected Epson V370, let's run similar applications on both the V370 and the non-functioning V30, until we can find a difference, and hopefully solve the V30 non-operation.

---

CLI software

First, can we at least detect the V30 using the command-line? Two command line interface (CLI) scanner probes, scanimage and sane-find-scanner, verify slightly different features. Scanimage is the more thorough. Scanimage on the V30 pauses, but eventually goes to completion, describing the V30 as "unknown model".

$ scanimage -L
device `epkowa:usb:001:004' is a Epson (unknown model) flatbed scanner

... on the V370 there's no delay and the model name is identified.

$ scanimage -L
device `epkowa:interpreter:001:004' is a Epson Perfection V370 Photo flatbed scanner

Model name aside, the V30 and V370 are properly detected and trigger the kernel to create data files; we can rule-out hardware, firmware, or kernel problems. Since the USB device name for the V370 includes "interpreter", but the V30 device name remains "usb"; the kernel is not receiving additional information for the V30, beyond the simple usb connection. Let's locate the (operational) V370 driver on the hard drive, and see if the V30 is in the same folder and perhaps not working.
Attaching the USB V370, and stracing $ scanimage -T ($ strace scanimage -T 2>&1 |tee V370file.txt) and then searching inside the resulting text file, I noted (~line 1195)

open("/usr/lib/iscan/libiscan-plugin-perfection-v370.la", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/iscan/libiscan-plugin-perfection-v370.so", O_RDONLY|O_CLOEXEC) = 9

The V370 driver inside /usr/lib/iscan, however I could find no driver relevant to the V30 in that folder. It appears we're lacking a V30 driver. A V30 driver would give the kernel more information than "usb".

driver software

I lucked into a premade AUR version of the V30 driver -- one step with yaourt. A conversation about this driver exists on the forums. Apparently, the creator downloaded a DEB file from the Epson site and then converted the DEB into a pacman/yaourt package. It's probably also worth noting that DEB's can be directly installed on Arch with a couple of steps. In this case, I had the premade AUR version I could install more easily using yaourt.

$ yaourt Ss v30
aur/iscan-plugin-gt-f720 0.1.1-1 (8) (0.01)
EPSON Image Scan! plugin for Epson Perfection V30 scanner
$ yaourt -S iscan-plugin-gt-f720

After installation, the V30 should appear with its model information and "interpreter" instead of "usb"...

$ scanimage -L
device `epkowa:interpreter:001:004' is a Epson Perfection V30 flatbed scanner

...and scan images via xsane.

possible tweaks

If there are still problems, check the following.

• Uncomment "usb" inside /etc/sane.d/epowka.conf, but without adding any make or model information, just leave it as "usb". If you add make or model, scanimage may generate a second, conflicting, instance of the V30.
• Comment "epowka" in /etc/sane.d/dll.conf, or conflicts will occur.
• The scanner libs directory should include softlinks to the main lib, libesci-interpreter-gt-f720.so, eg

  $ ls /usr/lib/iscan/
  libesci-interpreter-gt-f720.so
  libesci-interpreter-gt-f720.so.0
  libesci-interpreter-gt-f720.so.0.0.0

• Run

  $ iscan-registry -a 0x04b8 0x0131 libesci-interpreter-gt-f720.so

See bottom of this page for more configuration file info.

---

Troubleshooting prior to yaourt

block hpaio

Sometimes hpaio loads when there's no HP scanner. Like many Linux apps, they either don't work at all or they can never be disabled. Hpaio won't stop the V30 or other scanners, but it's a hardcore annoyance since it's impossible to turn off via any interface, by disabling CUPS, etc. I got tired of this fast and blacklisted the sumb*tch. Find the names of the hp-related libsane files in /lib/sane.d/, because you can't find it and its dependencies the normal way...

# modinfo -F depends libsane-hp
modinfo: ERROR: Module libsane-hp not found.

... and then blacklist them via /etc/modprobe.d/blacklisted.conf (you can call the file anything).

# nano /etc/modprobe.d/blacklisted.conf
# stop hpaio annoyance when no hp scanner connected
install libsane-hpaio /bin/true
install libsane-hp /bin/true

xsane also loads hpaio

Any time xsane is initiated, xsane finds these hpaio drivers and loads them directly. Stracing xsane

open("./dll.d", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/etc/sane.d/dll.d", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 7
fstat64(7, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
getdents(7, /* 4 entries */, 32768) = 76
1572:stat64("/etc/sane.d/dll.d/hpaio", {st_mode=S_IFREG|0644, st_size=6, ...}) = 0
1573:open("./dll.d/hpaio", O_RDONLY) = -1 ENOENT (No such file or directory)
1574:open("/etc/sane.d/dll.d/hpaio", O_RDONLY) = 8
1576:read(8, "hpaio\n", 4096) = 6
4071:open("/usr/lib/sane/libsane-hpaio.so.1", O_RDONLY) = 19
4073:open("/usr/lib/sane/libsane-hpaio.so.1", O_RDONLY|O_CLOEXEC) = 19

so you will also have to disable xsane from activating hpaio.

# nano /etc/sane.d/dll.d/hpaio
# comment the following so hpaio doesn't load.
#hpaio

Note: don't forget that, if an HP scanner is ever connected, you'll need to undo these changes to both /etc/sane.d/dll.d/hpaio and to /etc/modprobe.d/blacklisted.conf.

---

But back to yaourt. Yaourt was the end-point, yet I had proceeded through several troubleshooting steps to determine the driver issue. A couple of workday's worth of effort were spent ruling-out any physical connection, firmware, kernel, or configuration files. Some of that is noted above, the remainder is below.

lsub -vv (v370)

Partial information from lsusb -vv:

idVendor 0x04b8 Seiko Epson Corp.
idProduct 0x014a
bcdDevice 1.00
iManufacturer 1 EPSON
iProduct 2 EPSON Perfection V37/V370
iSerial 0

lsub -vv (v30)

Partial information from lsusb -vv

idVendor 0x04b8 Seiko Epson Corp.
idProduct 0x0131 GT-F720 [GT-S620/Perfection V30/V300 Photo]
bcdDevice 1.00
iManufacturer 1 EPSON
iProduct 2 EPSON Scanner
iSerial 0

sane-find-scanner

Running sane-find-scanner (lsusb -vv also would have been fine) against both models, both scanners properly return hexadecimal model/product codes.

(vendor=0x04b8 [EPSON], product=0x014a [EPSON Perfection V37/V370])

... and for the V30, sane-find-scanner returns...

(vendor=0x04b8 [EPSON], product=0x0131 [EPSON Scanner])

I also attempted to get attributes and do tests on the V30, prior to yaourt.

$ scanimage -A -d 'epkowa:usb:001:004'
$ scanimage -T -d 'epkowa:usb:001:005'

Both of these time-out, returning nothing however, since we have the hexidecimal model code on both scanners (0131 for the V30 and 014a for the V370), firmware, hardware detection, and/or physical USB connection problems are ruled-out. There are three remaining categories of variables for this V30 problem. 1) Kernel software, application software, configuration files.

Kernel side

The kernel creates and destroys files inside the directory /run/udev/data/ whenever a USB device is connected or disconnected to a UNIX system. User-level applications, such as xsane, then read these files for operating parameters. So we'd like to check the /run/udev/data/ files for the V30. If they're good, we know xsane is malfunctioning. If they're bad, we know the kernel is malfunctioning (or not receiving enough V30 info).

/run/udev/data

How do we find the names of the files created when the V370 or the V30 are connected by USB? Sane-find-scanner is helpful, but we'll need to strace it to gather enough information. We'll send the two results to text files we can parse. First, the operating scanner, V370. Connect it to the USB port and, ($ strace sane-find-scanner 2>&1 |tee V370file.txt). At line 700 (YMMV) of V370file.txt, we find a call to the data file c189:5:

$ grep -rn "/run/udev/data"
open("/run/udev/data/c189:5", O_RDONLY|O_CLOEXEC) = 8

Next, the non-scanning V30. Connect it via USB and, $ strace sane-find-scanner 2>&1 |tee V30file.txt . At line 700 (again, YMMV) of V370file.txt, we find a call to the data file c189:4:

$ grep -rn "/run/udev/data"
open("/run/udev/data/c189:4", O_RDONLY|O_CLOEXEC) = 8

Now we have the names of the two data files the kernel creates, 189:5 for the V370, and 189:4 for the V30. Here's the content for the two files. The (functioning) V370

$ cat /run/udev/data/c189:5
I:97119577141
E:ID_VENDOR=EPSON
E:ID_VENDOR_ENC=EPSON
E:ID_VENDOR_ID=04b8
E:ID_MODEL=EPSON_Perfection_V37_V370
E:ID_MODEL_ENC=EPSON\x20Perfection\x20V37\x2fV370
E:ID_MODEL_ID=014a
E:ID_REVISION=0100
E:ID_SERIAL=EPSON_EPSON_Perfection_V37_V370
E:ID_BUS=usb
E:ID_USB_INTERFACES=:ffffff:
E:libsane_matched=yes
E:ID_VENDOR_FROM_DATABASE=Seiko Epson Corp.
E:ID_PATH=pci-0000:00:12.2-usb-0:2
E:ID_PATH_TAG=pci-0000_00_12_2-usb-0_2
E:ID_FOR_SEAT=usb-pci-0000_00_12_2-usb-0_2
G:uaccess
G:seat

...and, when the V30 is attached

$ cat /run/udev/data/c189:4
I:138131813751
E:ID_VENDOR=EPSON
E:ID_VENDOR_ENC=EPSON
E:ID_VENDOR_ID=04b8
E:ID_MODEL=EPSON_Scanner
E:ID_MODEL_ENC=EPSON\x20Scanner
E:ID_MODEL_ID=0131
E:ID_REVISION=0100
E:ID_SERIAL=EPSON_EPSON_Scanner
E:ID_BUS=usb
E:ID_USB_INTERFACES=:ffffff:
E:libsane_matched=yes
E:ID_VENDOR_FROM_DATABASE=Seiko Epson Corp.
E:ID_MODEL_FROM_DATABASE=GT-F720 [GT-S620/Perfection V30/V300 Photo]
E:ID_PATH=pci-0000:00:12.2-usb-0:2
E:ID_PATH_TAG=pci-0000_00_12_2-usb-0_2
E:ID_FOR_SEAT=usb-pci-0000_00_12_2-usb-0_2
G:uaccess
G:seat

Since both the V370 and the V30 files are properly created inside /run/udev/data/, the kernel is now ruled-out as a problem. Secondly, these presence of these data files also probably excludes the rules the kernel uses to write data files for /run/udev/data/. These rules for helping the kernel translate a physical USB connection into a data file are in /lib/udev/rules.d/. In the case of the scanner rules, the rules file is /lib/udev/rules.d/49-sane.rules. So far, everything has checked-out normally, and now we have ruled out the kernel's USB firmware detection and data propagation processes.

Unsolved

Our current unsolved clues related to the non-scanning are 1) the pause and eventual time-out when V30 is queried, 2) the unnamed model "Scanner", 3) the name "usb", instead of "interpreter" inside scanimage -L results.

# echo -1 >/sys/module/usbcore/parameters/autosuspend

Still, EAGAINs and the pauses did not stop, and this led me, finally, to a driver.

Other rule-outs: configuration files

• /etc/sane.d/epson.conf - possibly could add the make and model to identify the V30, however if a yaourt or pacman solution is available, remove it.
• /etc/sane.d/saned.conf - Should not be a problem, since V370 is operating
• /etc/sane.d/dll.conf - No problems since V370 is working
• /etc/sane.d/epkowa.conf - No problems since V370 operates
• /usr/share/iscan-data/usb - Neither the 014a or the 0131 models are in this file. This file is opened during scanimage tests however.

[solved] xinit: unable to connect to x server: Connection refused

This is a common, highly annoying, permission fail following any update. If your /etc/group and /etc/shadow files have customary arrangements, and you haven't created conflicting rules in /etc/udev/rules.d, then it's not your fault -- you did your normal user-level part. Defenestration of various programmers is the deserved solution because, since the advent of PAM, LDAP, NSS and the other ridiculous kludge of "security" since Sept 2001, which have mostly secured users out of their own systems, it's probably another feature requiring a permission adjustment. If so, you have days of work ahead. Try these below and don't get into security files unless these don't work.

If no programmers are handy to toss, here are some options

1. Log out entirely, then log back into your user and make a second attempt
2. Try rebooting entirely. If it's a large update, this solves it nearly every time.
3. You have two main configuration files for X, besides the regular stuff in .xinitrc (or .xsession if you're a dumbass who uses a DM):
   • /etc/X11/xorg.conf -- you should never have to fuck with this file but (ironically, as with everything else in Linux) you will nevertheless have to do so one day after a "helpful" "update" (although your system was running just fine before these) at which point you will have no experience at doing so, since you never were supposed to have to edit it, but now you suddenly have to and... (you guessed it) at a level assuming you have have a CS degree and years and years of experience with that file. Tada!
   • /usr/share/X11/xorg.conf.d -- this is the bullshit directory where 2 million conflicting configuration files live, files you cannot easily do anything but printout and lay side by side on the living room floor (which you don't have since you lost your job coming in late after all-nighters attempting to fix permission problems added since 2001) and desperately hope that you can identify some conflict between them or the aforementioned /etc/X11/xorg.conf file before losing another weekend or relationship with these printouts lying all over the house. Fun, right?

solutions

Reboot after large updates when this happens.

$ strace startx 2>&1 |tee bigfile.txt
This is obviously much better than a log file. Look for X authorities and see if they're not forthcoming.

$ xauth
Is there an ~/.Xauthority file? Two problems are possible. One, it's not being created, or two, it's being created with no content. It's a binary file, typically about 49 bytes in size, when functional. Zero bytes is not good, so then try....

$ xauth list

[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 www.websense.com
PING www.websense.com (204.15.67.11) 56(84) bytes of data.
64 bytes from www.websense.com (204.15.67.11): icmp_seq=1 ttl=49 time=27.9 ms
64 bytes from www.websense.com (204.15.67.11): icmp_seq=2 ttl=49 time=27.7 ms
^C
$ curl www.websense.com
curl: (6) Couldn't resolve host 'www.websense.com'

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.

tcpdump

Here are portions of dumps for the successful ping and struggling curl:

# tcpdump -nlieth0 -s0 udp port 53 -vvv
[during ping]
192.168.1.20.34097 > 192.168.1.254.53: [udp sum ok] 11891+ A? www.websense.com. (34)
192.168.1.254.53 > 192.168.1.20.34097: [udp sum ok] 11891 q: A? www.websense.com. 1/0/0 www.websense.com. [5s] A 204.15.67.11 (50)
192.168.1.20.58651 > 192.168.1.254.53: [udp sum ok] 51147+ PTR? 11.67.15.204.in-addr.arpa. (43)
192.168.1.254.53 > 192.168.1.20.58651: [udp sum ok] 51147 q: PTR? 11.67.15.204.in-addr.arpa. 1/0/0 11.67.15.204.in-addr.arpa. [9h53m39s] PTR www.websense.com. (73)

[during curl]
192.168.1.20.41050 > 192.168.1.254.53: [udp sum ok] 26082+ A? www.websense.com. (34)
192.168.1.20.41050 > 192.168.1.254.53: [udp sum ok] 54668+ AAAA? www.websense.com. (34)
192.168.1.254.53 > 192.168.1.20.41050: [udp sum ok] 26082 q: A? www.websense.com. 1/0/0 www.websense.com. [5s] A 204.15.67.11 (50)
192.168.1.254.53 > 192.168.1.20.41050: [udp sum ok] 54668- q: AAAA? www.websense.com. 0/0/0 (34)
192.168.1.20.58040 > 192.168.1.254.53: [udp sum ok] 47978+ A? www.websense.com.localdomain. (46)
192.168.1.20.58040 > 192.168.1.254.53: [udp sum ok] 42568+ AAAA? www.websense.com.localdomain. (46)
192.168.1.254.53 > 192.168.1.20.58040: [udp sum ok] 47978 NXDomain- q: A? www.websense.com.localdomain. 0/0/0 (46)
192.168.1.254.53 > 192.168.1.20.58040: [udp sum ok] 42568 NXDomain- q: AAAA? www.websense.com.localdomain. 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 (204.15.67.11) 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 www.websense.com 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
::ffff:cc0f:430b www.websense.com
204.15.67.11 www.websense.com

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

$ curl www.websense.com
[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
fuduntu-release-2013-3.noarch

$ 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 http://packages.fuduntu.org/repo/mirrors/fuduntu-stable-rpms-2013 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
fuduntu-release-2013-3.noarch

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

$ rpm -q fuduntu-release
fuduntu-release-2013-3.noarch

# 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
fuduntu-release-2013-3.noarch

$releasever

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
NETWORKING_IPV6=no

# 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 "192.168.1.254".

$ strace ping www.websense.com
socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.1.254")}, 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("192.168.1.254")}, [16]) = 50
close(3) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(1025), sin_addr=inet_addr("204.15.67.11")}, 16) = 0
getsockname(3, {sa_family=AF_INET, sin_port=htons(53553), sin_addr=inet_addr("192.168.1.20")}, [16]) = 0
close(3)

And for the failing curl :

$ strace curl www.websense.com
socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.1.254")}, 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("192.168.1.254")}, [16]) = 34
close(3) = 0
socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.1.254")}, 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.