Opened 9 years ago

Last modified 9 years ago

#6300 new defect

stop using ipv4 addresses for anything

Reported by: robot101 Owned by: Collabora
Priority: normal Milestone: 9.1.0-cancelled
Component: presence-service Version:
Keywords: Cc: jg, dwmw2
Blocked By: #4539 Blocking:
Deployments affected: Action Needed: code
Verified: no


Currently presence service detects whether we become connected by finding the IPv4 address of interfaces when network manager brings them up.

We also publish this IPv4 address as a buddy property in salut and gabble, so that theoretically activities which aren't using tubes can make direct connections to each other. To the best of my awareness, there are no such activities, and we should not rely on IPv4 connectivity for anything.

So, we should stop doing both of these things, and just use more general connectivity indications from network manager to decide when it's worth trying to connect in presence service (basically, do we try to connect with gabble or not).

Change History (6)

comment:1 Changed 9 years ago by bert

  • Blocked By 4539 added

Etoys still uses direct IPv4 connections obtained from buddy properties (#4539). The plan was to switch to tubes by update.1 but we did not quite finish it.

comment:2 Changed 9 years ago by gdesmott

  • Milestone changed from Never Assigned to Retriage, Please!

Would be a good goal for Update.2 IMHO.

comment:3 Changed 9 years ago by gdesmott

  • Action Needed set to never set
  • Milestone changed from Retriage, Please! to 9.1.0

comment:4 Changed 9 years ago by bert

Btw, etoys uses tubes now, #4539 is just not finalized.

comment:5 Changed 9 years ago by gdesmott

  • Action Needed changed from never set to code

Then we'll probably remove the ip4 buddy property during the 9.1.0 cycle.

comment:6 Changed 9 years ago by gdesmott

Note that the sugar-xos script from olpc-netutils uses the IP4 property when listing buddies.

Note: See TracTickets for help on using tickets.