can not find hardware address

Bug #1328285 reported by Brian Murray
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
whoopsie (Ubuntu)
Fix Released
High
John Lenton

Bug Description

Working with popey, trying to figure out why his crashes weren't reported.

Jun 9 22:24:28 ubuntu-phablet whoopsie[1934]: whoopsie 0.2.30 starting up.
Jun 9 22:24:28 ubuntu-phablet whoopsie[1934]: Unable to find a hardware address
Jun 9 22:24:28 ubuntu-phablet whoopsie[1934]: Using lock path: /var/lock/whoopsie/lock
Jun 9 22:24:29 ubuntu-phablet whoopsie[1953]: offline
Jun 9 22:24:33 ubuntu-phablet whoopsie[1953]: message repeated 3 times: [ offline]
Jun 9 22:24:33 ubuntu-phablet whoopsie[1953]: online
Jun 9 22:24:34 ubuntu-phablet whoopsie[1953]: online
Jun 9 22:25:10 ubuntu-phablet whoopsie[1953]: offline
Jun 9 22:25:13 ubuntu-phablet whoopsie[1953]: message repeated 2 times: [ offline]
Jun 9 22:25:13 ubuntu-phablet whoopsie[1953]: online

Notice the "unable to find a hardware address". Ted suggests:

14:51 < tedg> bdmurray, I imagine that is because it can't
              find oFono. Perhaps the upstart jobs need to
              be adjusted so it doesn't start until after
              oFono is up.

Related branches

tags: added: utopic
Revision history for this message
Brian Murray (brian-murray) wrote :

I tested a fix using the following change:

=== modified file 'data/whoopsie.conf'
--- data/whoopsie.conf 2013-02-20 18:26:14 +0000
+++ data/whoopsie.conf 2014-06-09 22:15:18 +0000
@@ -2,7 +2,7 @@

 description "crash report submission daemon"

-start on runlevel [2345]
+start on runlevel [2345] and ofono
 stop on runlevel [!2345]

 env CRASH_DB_URL=https://daisy.ubuntu.com

Changed in whoopsie (Ubuntu):
importance: Undecided → High
status: New → Triaged
Revision history for this message
Brian Murray (brian-murray) wrote :

I'm not convinced this (the message in the log file) is actually an issue as I quickly ran the following command after booting up and did have a system identifier.

root@ubuntu-phablet:~# /home/phablet/system-id.sh
('79493b50adc9aac91c09a65a7a5c145b5c4de51a33c5c63bd6ebfd9859d2f16792300ee3c95db77306b8a5368ef7e4bd9ebdaee81db6862876bfb4556b5bb960',)

Even though this appeared in syslog:

Jun 10 00:30:01 ubuntu-phablet whoopsie[1871]: whoopsie 0.2.30 starting up.
Jun 10 00:30:01 ubuntu-phablet whoopsie[1871]: Unable to find a hardware address
Jun 10 00:30:01 ubuntu-phablet whoopsie[1871]: Using lock path: /var/lock/whoopsie/lock

Revision history for this message
Steve Langasek (vorlon) wrote :

<slangasek> stgraber: do you know a proper way to programmatically get a list of all network interfaces on a system, including those that are currently down? http://linux.die.net/man/7/netdevice documents that SIOCGIFCONF doesn't include down interfaces, and recommends /proc/net/dev instead
<stgraber> slangasek: I usually iterate through /sys/class/net which works fine if you just want a list or want physical interface related kind of information. If you need to query the interface configuration, then you need getifaddrs and it's a whole other kind of worm (also, some most IPv6 info is also in /proc, but ipv4 isn't... yay for consistency)
<slangasek> stgraber: context is whoopsie trying to get a mac address to use as a system identifier; this shouldn't be dependent on network interfaces being up
<stgraber> slangasek: /sys/class/net/*/address will get you that
<stgraber> slangasek: if you want to make sure you've got an ethernet device (and therefore a MAC), check that /type == 1 too

Revision history for this message
Steve Langasek (vorlon) wrote :

The above more directly addresses the root cause here, which is that whoopsie is starting up and trying to find a mac address before the interface is up, and SIOCGIFCONF only returns the list of interfaces that are up and have ipv4 addresses associated with them. The system identifier generation should not give different results depending on whether the network is up, especially as whoopsie will run quite early in boot relative to network configuration (when using NM). Probing via /sys/class/net will more reliably get us an answer based on the ethernet (incl. wifi) interfaces, which is evidently the first choice anyway - so for most devices, no need to fall back to IMEI at all.

Also, note that even with this change, it's very possible for boot-time races to cause different system identifiers to be chosen at each boot. Whatever identifier whoopsie chooses, I think it should really be recorded on the filesystem, so that it persists across boots rather than bouncing back and forth between interfaces.

John Lenton (chipaca)
Changed in whoopsie (Ubuntu):
assignee: nobody → John Lenton (chipaca)
status: Triaged → In Progress
tags: added: rls-u-incoming
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package whoopsie - 0.2.34

---------------
whoopsie (0.2.34) utopic; urgency=medium

  [ John Lenton ]
  * Obtain a MAC address for system identifier generation even if the network
    is not up. (LP: #1328285)
 -- Brian Murray <email address hidden> Mon, 07 Jul 2014 11:44:26 -0700

Changed in whoopsie (Ubuntu):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.