Opened 11 years ago

Last modified 3 years ago

#6071 new plugin request

Pidgin VNC integration

Reported by: manishmahabir Owned by:
Milestone: Voice and Video Support Component: pidgin (gtk)
Version: 2.4.2 Keywords:
Cc: freechelmi, timofonic


It would be very useful if i could ask a person in my pidgin list to share screen via VNC!

If we are able to provide live help to our friends in such a simple and easy way, it would play crucial role in convincing our new friends to adopt something as wonderful as linux.

I have used VNC on my lan to connect to my friend's computer and it is pretty simple.But if we are behind a router with dynamic ip, things get complicated.Port forwarding is something which everybody can't do. Integrating vnc with pidgin with auto configuration of the router will make things simple and idiot-proof. It's importance and usability can never be overstated.

I am not asking for something new.Just a better integration of existing facilities can do wonders!

Change History (15)

comment:1 Changed 11 years ago by datallah

  • Type changed from enhancement to plugin request

This isn't something that belongs in Pidgin itself, but it sounds like a neat feature for a plugin.

comment:2 Changed 11 years ago by manishmahabir

This blueprint is taken from brainstorm:

The guy has planned to work on it and is looking for developers who would like to help and anyone who might know how to restrict SSH reverse tunnels.

The current problem: Vino is installed by default, but is usually inaccessible due to routers (NAT more specifically). Because these users are often behind a firewall, getting access would traditionally require opening a port in the firewall which presents a series of problems.

  • Many users will not choose a secure password for vino and someone can brute force the password and take over their computer.
  • Many users don't know how to open a port in their firewall because they've never done it/don't remember the password/don't know what a router is/etc.
  • This also leaves the connection unencrypted.

proposed solution:

I think the best solution would be to have a server that the person requesting help (referred to as User) and the person helping (referred to as Support) can both connect to that will bridge the connections.

Both sides will have a program that connects them in a chat room where there is a bot available, If they need remote desktop support they both tell the bot (maybe through a button in the applicatin) they need to bridge a connection between the two. Both of the programs generate public/private ssh key pairs (if they don't already have them) and send them to the bot. The bot then prepares a user account on the SSH server so that User can only listen on a specific port (reverse tunnel) and Support can only get to that same port (forward tunnel). Once the server is prepared User's program creates a reverse tunnel (ssh -R 5980:localhost:5900 help@…), then Support's program automaticly creates a forward tunnel (ssh -L 5999:localhost:5980 help@…), then runs "vnc localhost:99". At this point the SSH server has created a bridge between both user's firewalls.

*In the example above, the server decided that these users would use port 5980 on the SSH server to connect to each other, and user is running Ubuntu and is the first user logged in which listens on port 5900 *vnc displays listen on port numbers that are port+5900, so display 0 listens on 5900, display 80 listens on 5980

One user can be shared on the SSH server with different options per SSH key. The following line would be used for the support user in this example to make sure that they can't run any commands on the server, and can only create a forward connection to their assigned port (5980). command="/bin/sleep 20",no-X11-forwarding,no-port-forwarding,no-agent-forwarding,permitopen="localh ost:5980" ssh-rsa AAAA.... I can't seem to find a command to do the same thing in reverse to enforce the rule that user must listen on port 5980.

Does this help?

comment:3 Changed 11 years ago by chemistrydioxide

The official MSN client supports this.

If Pidgin gets support for this, it should interoperate with MSN's remote desktop integration.

comment:4 Changed 11 years ago by dave1g

microsofts technology is dif. than VNC they use rdp still, a similar feature could be made using both protocols

comment:5 Changed 11 years ago by datallah

Ticket #7137 has been marked as a duplicate of this ticket.

comment:6 Changed 11 years ago by lschiere

  • Owner lschiere deleted

comment:7 Changed 10 years ago by jlabrous

I'am trying to make one. Today, this is only a prototype but it works ! It is not protocol dependant: Invitation are send as normal text. Please have a look to and send me requirements

comment:8 Changed 9 years ago by phannent

Just to throw in my tuppence worth.

I think VNC should not be integrated in to Pidgin, what should happen is VNC be made more network aware. Once VNC can use UPnP/STUN/TURN to lookup the external address and open ports it could then send a system wide message (via pipes, Dbus, SendMessage?, etc ) to any application that cares that the user can perform a VNC connection.

Whilst XMPP could be used for sending VNC data it would add a layer to an already slow communication.

The work should be mainly with improving VNC, not working around it within another application.

comment:9 Changed 7 years ago by cheako

This 'looks' interesting, windows only though. They have source code.

Why is pidgin-vnc not part of pidgin?

A generic create DCC port forward using XMPP as a setup would be useful, particularity if both TCP and UDP port forwards could be created. Why is this still a vary troubling technical hurdle?

I see each end having a choice to make, independent of the other. If pidgin(or any XMPP client) creates a local socket as in a traditional SSH port forward or if the address/port to listen on or connect too is handed off.

The ability to run applications configured in each client would be ideal, something like MIME types... Who can handle this protocol?

Why so much talk about SSH, don't complicate a solution. It's true using SSH and VNC do go hand in hand, but using VNC should not depend on using SSH.

comment:10 Changed 7 years ago by cheako

Plus IPv6 DCC should be possible and deployed ASAP. At this stage, depending on both users having v6 addresses, even if the addresses are over tunnels or ip6to4, should be fine for any solution.

As for places with restrictive firewalls that block the UDP ports used for v6 tunnels, they would just be forced into supplying v6 connectivity... Once again not something that's too outrageous of a demand this late in the game.

comment:11 Changed 6 years ago by datallah

Ticket #15763 has been marked as a duplicate of this ticket.

comment:12 Changed 6 years ago by jlabrous

Take a look at and feel free to continue the job !

comment:13 Changed 4 years ago by salinasv

  • Component changed from unclassified to pidgin (gtk)

comment:14 Changed 4 years ago by salinasv

  • Milestone set to Voice and Video Support

comment:15 Changed 3 years ago by timofonic

Any mews about this? I think it should be part of libpurple core, so other clients would benefit from it.

There's RDP, NX, SPICE (for virtual machines) and others.

Integration would be very helpful for e-learning, sysadmins and personal administration of computers.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!