alvarezp

This is a quick note, documenting a quick successful test on Reverse VNC connections.

Unlike regular VNC connections, in which you connect to the controllable PC, in a Reverse VNC connection the controllable PC will connect to you. The control is in the same direction, but the connection is reversed.

What’s the benefit? Not having to worry about the network status and addresses of the remote PC. It is usually easier to initiate connections than to receive. This lets the guy with better network understanding to be the listener and the poor soul to be the initiator. This will put the network worries near to the tech support guy, where it should be for this particular scenario. Also, as with the current state of IPv4, full of the evil but necessary NAT, you will not have to worry about router NAT / port forwarding configuration in the remote router.

Test setup

The test setup consisted on my desktop workstation running Ubuntu and my laptop running Windows, both on the same Ethernet broadcast domain. No gateway was involved in the test.

The desktop workstation had the following characteristics:

• Operating System: Ubuntu Lucid Lynx (10.04).
• VNC package: xvnc4viewer 4.1.1+xorg4.3.0-37ubuntu2.
• Role: Controlling computer (VNC client). In real life here is where I would sit and control other computers.
• IP address: 192.0.2.10 (this is a fake, RFC 5735 documentation address).

The laptop had the following characteristics:

• Operating System: Microsoft Windows XP SP3.
• VNC package: TightVNC 1.3.10, installed from the OpenDisc software collection.
• Role: Controlled computer (VNC server). In real life this would be the PC receiving remote tech support from me.
• IP address: 192.0.2.20 (this is a fake, RFC 5735 documentation address).

Steps performed to establish the connection

On the desktop workstation (the VNC client, controlling computer):

• Opened a terminal
• Ran vncviewer -listen
• You should get a message like “main: Listening on port 5500″

On the laptop (the VNC server, controlled computer):

• Went to Start » All Programs » TightVNC and ran Launch TightVNC Server
• If the Properties window pops up, disable “Accept socket connections” and click OK (just for security reasons).
• Right click on the system tray TightVNC Server icon and choose Add New Client…
• Enter the IP address of the desktop workstation, in this example, 192.0.2.10 and click OK or hit Enter.

Sidenotes

• The test was done with the Windows Firewall enabled. You might get a message like To help protect your computer, Windows Firewall blocked some of this program features. | The computer administrator may unblock this program for: TightVNC Win32 Server when running the Tight VNC Server. You may safely click “OK” because you will initiate connections and not listen for a connection. This message gets inhibited by disabling Accept socket connections in the Properties window.
• The test was repeated using a restricted Windows account, with a successful result. This gives you a lot of flexibility. You might even try making a portable TightVNC server by following the Step 2 from the instructions on this VNC document from the TinyApps.Org blog
• Depending on the available bandwidth and latency, it might be necessary to tweak the server on the Properties window.
• I noticed a somewhat long delay on the first connection attempt, in one case even leading to a connection failing. On the second try it worked fine. I would guess this has to do with DNS resolving delays and caching, but it’s just speculation.

Comments welcome. If you have instructions for the same scenario on different platforms, post it on your blog and link it from a comment, or write it directly on a comment.

From XKCD

What a coincidence. I recently said the following over Tweeter (translated from Spanish):

To debate if “God” exists or not is like arguing if 0 is positive or negative. The thruth is both are the same number.

For me, +0 == -0 and I like the analogy. And yes, I have already been criticized… but, oh well.

In code I think it could be like this:

function dios_existe() {
	if (sign(0) == 1) return True;
	if (sign(0) == -1) return False;
	return dios_existe() /* haha, because that's just what happens with human beings */
}

As announced some days ago in the mailing list, Superkb 0.21 was released.

Please let me introduce it for those that don’t know the project yet.

Superkb is a shortcut-based launcher with on-screen graphical hints. It is written in C using Xlib, with the help of Cairo graphics, Pango, Imlib2, Xinerama, etc. and the source code is managed using Git.

Continue reading ‘Superkb 0.21 released’ »

So that’s the news: msn-pecan 0.1.0 is released! And I’m glad.

To directly quote from Felipec’s post in his blog:

After a bit more than two years of development we are proud to announce the first stable release of msn-pecan. The project started as a “fork” of libpurple’s msn protocol (read below why it’s not really a fork), but it has grown and soon will become a standalone library with support for Telepathy too.

Continue reading ‘felipec’s msn-pecan 0.1.0 released’ »

Justo cuando creí haberlo visto todo encuentro este video titulado Saturday Morning Science.

Es un video con los experimentos realizados por el Dr. Donald Pettit, astronauta, Ingeniero de Vuelo y Oficial de Ciencias de la expedición 6 a bordo de la Estación Espacial Internacional.

Según la página de Saturday Morning Science, “hasta en su tiempo libre, los astronautas a bordo de la ISS están descubriendo cosas nuevas y sorprendentes sobre la naturaleza”. Según Don Pettit, estos experimentos no se tenían programados como parte de la misión; no eran ciencia “programada” sino ciencia “de oportunidad”.

Este video es un video crudo y directo al grano; tal vez sea una versión compilada; pero hay otras versiones en YouTube y la galería de videos de la expedición donde están editadas a modo de entrevista con un poco más de explicación.

Espero que los disfruten tanto como yo y se sorprendan tanto como los astronautas.

Thanks to SourceForge and its MediaWiki implementation, the Superkb project now has its own Wiki.

For now, it is only in English. I’m really looking forward to adding a full Spanish equivalent.

I think this will make it a lot easier to keep the documentation up to date.

The SourceForge Wiki doesn’t allow anonymous contributions, so an SF account is needed to include the people in the editors group.

Suggestions and contributions are welcome.

/etc/network/interfaces:

auto br0
iface br0 net dhcp
   bridge_ports eth0 eth1
   bridge_stp off
   bridge_fd 3

Introduction and motivation

I have always felt the EIGRP metric as being really overwhelming. I see values like “2820096″ and instead of understanding it, I always end up asking what the hell does that number mean.

For example, in RIP:

R    192.168.0.0/24 [120/3] via 172.16.1.1, 00:00:15, FastEthernet0/0

Just by looking at the metric of “3″ I immediately know what is means: there are three steps between the announced network and the router receiving the advertisement. Easy, right? “Understanding the number” makes it easy for me to manage and diagnose it.

In OSPF, the metric (cost) is still not as cumbersome as EIGRP’s. However, in the following example, can you identify what does “66″ mean? For you, is it “just a number” that won over another because of its numerical value being lower? How do you know if the number is right or not?

O   192.168.0.0/24 [110/66] via 172.16.1.1, 00:00:82, FastEthernet0/0

Continue reading ‘Meaning of the default EIGRP metric’ »