[Sysmonitor] sysmonitor screenlet fails to find the computer's IP address

Bug #618868 reported by Michel Leunen
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Individual Screenlets
Fix Released
Low
Unassigned
indiv-screenlets (Ubuntu)
Fix Released
Low
Julien Lavergne

Bug Description

Binary package hint: screenlets

Using Ubuntu 10.04.1 with screenlets 0.1.2-7ubuntu1
The screenlet sysmonitor doesn't return an IP address but an empty string. This is due to a bug in the function net_get_ip().
Here is the content of the function screenlets.sensors.net_get_ip().

def net_get_ip(): # by Whise
 442 """Returns ip if it can"""
 443 ip = commands.getoutput("ifconfig")
 444 x = 0
 445 while True:
 446 ip = ip[ip.find("inet addr:"):]
 447 ip = ip[10:]
 448 ipc = ip[:ip.find(chr(32))]
 449 if ipc != '127.0.0.1' and ipc != None and ipc !='1':
 450
 451 return ipc
 452
 453
 454 return _('Cannot get ip')

There is an error on line 446. The ifconfig command doesn't return a string "inet addr" but "inet adr" instead (only one 'd').
Because of this, the function doesn't return the ip address but an empty string.

To correct the problem, lines 446 and 447 must be changed to this:
446 ip = ip[ip.find("inet adr:"):]
447 ip = ip[9:]

This bug might or might not be related to this one:
bug #241557 - screenlets.sensors.net_get_ip() doesn't necessarily return the correct value

Tags: patch
Julien Lavergne (gilir)
Changed in screenlets (Ubuntu):
assignee: nobody → Julien Lavergne (gilir)
Revision history for this message
Julien Lavergne (gilir) wrote :

Thank you for your bug report and the proposed fix. Could you try with the screenlets package in my PPA : https://launchpad.net/~gilir/+archive/unstable and report back if the problem is fixed for you ?

Changed in screenlets (Ubuntu):
importance: Undecided → Low
assignee: Julien Lavergne (gilir) → nobody
status: New → Incomplete
Revision history for this message
Michel Leunen (michel-leunen) wrote : Re: [Bug 618868] Re: sysmonitor screenlet fails to find the computer's IP address

Yep, the problem is fixed with the package in your ppa.
Thanks for your fast response.

Le 20/08/10 00:05, Julien Lavergne a écrit :
> Thank you for your bug report and the proposed fix. Could you try with
> the screenlets package in my PPA :
> https://launchpad.net/~gilir/+archive/unstable and report back if the
> problem is fixed for you ?
>
> ** Changed in: screenlets (Ubuntu)
> Importance: Undecided => Low
>
> ** Changed in: screenlets (Ubuntu)
> Assignee: Julien Lavergne (gilir) => (unassigned)
>
> ** Changed in: screenlets (Ubuntu)
> Status: New => Incomplete
>

--
Michel Leunen
http://linux.leunen.com

Julien Lavergne (gilir)
Changed in screenlets (Ubuntu):
status: Incomplete → In Progress
assignee: nobody → Julien Lavergne (gilir)
Revision history for this message
Launchpad Janitor (janitor) wrote : Re: sysmonitor screenlet fails to find the computer's IP address

This bug was fixed in the package screenlets - 0.1.2-7ubuntu2

---------------
screenlets (0.1.2-7ubuntu2) maverick; urgency=low

  * debian/patches/21-return-ip-address.patch:
   - Fix screenlets.sensors.net_get_ip() to get the IP address. Thanks
     Michel Leunen for the patch. (LP: #618868)
 -- Julien Lavergne <email address hidden> Sat, 21 Aug 2010 18:01:52 +0200

Changed in screenlets (Ubuntu):
status: In Progress → Fix Released
Revision history for this message
Julien Lavergne (gilir) wrote :

Committed in revision 479 of screenlets trunk.

Changed in screenlets:
status: New → Fix Committed
importance: Undecided → Low
Revision history for this message
eitch (eitch) wrote :

Hello. On Maverick ifconfig returns "inet addr" with two 'd's and on a different machine with lucid I also see 'inet addr'. Thus this patch is a regression for me as the sysmonitor does not show the ip anymore.

Kind regards

Revision history for this message
Michel Leunen (michel-leunen) wrote :

My analysis of the problem was quite weak, sorry On MY machine, ifconfig still returns "inet adr" with only one "d".
Actually, the problem is a problem of locale. In your english ( I presume) version, it has two "d" but in mine which is a french version of Maverick, "inet adr" has only one "d".
What is the best way to test a string taking into account the user's locale ? Besides, what if you have two valid connections ? A wired one and a wireless one ? The function used only returns the first "inet addr" found in ifconfig. I suppose Julien will have to change the algorithm he used.

Revision history for this message
Julien Lavergne (gilir) wrote :

Maybe there is another way to find the IP adress, which doesn't change with the locale ?
Anyway, I'm re-open the bug, we need to find another fix.

Changed in screenlets (Ubuntu):
status: Fix Released → Triaged
Changed in screenlets:
status: Fix Committed → Triaged
Changed in screenlets (Ubuntu):
assignee: Julien Lavergne (gilir) → nobody
Revision history for this message
Michel Leunen (michel-leunen) wrote :

Yes, there is another way: using the command ip from the net-tools package instead of ifconfig. This package is installed by default in Ubuntu. Don't know for other distributions.
Use it like this:

$ ip addr show

On my machine, it prints this:

$ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
    link/ether 00:25:b3:c0:b6:86 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:21:6a:6c:de:18 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.8/24 brd 192.168.1.255 scope global wlan0
    inet6 fe80::221:6aff:fe6c:de18/64 scope link
       valid_lft forever preferred_lft forever
4: vboxnet0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 0a:00:27:00:00:00 brd ff:ff:ff:ff:ff:ff

You can narrow it to what is interresting with:

$ ip -o -4 addr show
1: lo inet 127.0.0.1/8 scope host lo
3: wlan0 inet 192.168.1.8/24 brd 192.168.1.255 scope global wlan0

So basically your function stays the same.

I've tried to use the python socket module directly but it gives an ip address even if the connection is lost for some reason:

>>> import socket
>>> socket.gethostbyname_ex(socket.gethostname())[2][0]
'192.168.1.8'

So I suppose your best bet is to go the 'ip addr show' way.

Revision history for this message
Michel Leunen (michel-leunen) wrote :

Something like this should work:

def net_get_ip(): # by Whise
 """Returns ip if it can"""
 ip = commands.getoutput("ip -o -4 addr show")
 x = 0
 while True:
  ip = ip[ip.find("inet "):]
  ip = ip[5:]
  ipc = ip[:ip.find("/")]
  if ipc != '127.0.0.1' and ipc != None and ipc !='1':

   return ipc

 return _('Cannot get ip')

tags: added: patch
Revision history for this message
Michel Leunen (michel-leunen) wrote :

Another possibility that directly gives the right result and uses ifconfig:

$ ifconfig | grep 'inet '| grep -v '127.0.0.1' | cut -d: -f2 | awk '{ print $1}'

That said, I don't know if the "inet" string stays the same in every locale, though.

Revision history for this message
Stefano Rivera (stefanor) wrote :

Easy solution: call ifconfig with an environment of LANG=C

Revision history for this message
Märt Põder (boamaod) wrote :

Copied an equivalent of Rivera's solution from U-A.

Changed in screenlets:
status: Triaged → Fix Committed
Papp Bence (sclegnrbs)
affects: screenlets → indiv-screenlets
Papp Bence (sclegnrbs)
summary: - sysmonitor screenlet fails to find the computer's IP address
+ [Sysmonitor] sysmonitor screenlet fails to find the computer's IP
+ address
Julien Lavergne (gilir)
Changed in screenlets (Ubuntu):
status: Triaged → In Progress
assignee: nobody → Julien Lavergne (gilir)
Julien Lavergne (gilir)
affects: screenlets (Ubuntu) → indiv-screenlets (Ubuntu)
Changed in indiv-screenlets (Ubuntu):
status: In Progress → Fix Released
Changed in indiv-screenlets:
status: Fix Committed → 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.