Category Archives: Tech

RDP-ing to the console session

Posted on by
1

Microsoft’s Remote Desktop Protocol has a feature that gives it a huge advantage over most traditional remote desktop software such as VNC (UltraVNC, RealVNC etc.): the redirection of sound from the remote to the local machine. That is to say, I would be able to play a music file on the remote computer and have the sound playback from the local computer’s speakers, instead of it being outputted on the speakers of the remote computer.

Typically however, when a RDP connection is established, it creates a new session by default instead of showing what’s display on the remote desktop currently. So although you were logged into the remote computer, you weren’t able to carry on the work you left off previously remotely. This has been the main reason that previously made me use UltraVNC over Microsoft RDP. However, I was ignorant of the fact that Microsoft RDP is able to do the same, until I stumbled across this KB entry. The reason is that this feature is not obvious right out of the box, it’s not shown on the GUI of the client anywhere. It can only be accessed via a command line, with the following command:

mstsc -v:servername /F -console

That’s the best of both worlds in one. I don’t think I’ll ever look back to VNC again, at least not on a Windows system. Maybe when everyone is sporting 10 Gbps LAN connections, we’ll have enough bandwidth to redirect 3D graphics too.

File transfer rate: What's going on here?

Posted on by
1

I’m completely puzzled by this. Transferring a file across the network (GigE), a file that contains real data moves much slower (it’s almost a 10 MB/s difference!) than a test file created by fsutil. As far as I know, and I maybe wrong here, the content of a file shouldn’t matter when transferring across the network as the protocols involved (TCP and Samba) doesn’t do any compression on its own. Explanations anyone?

Transfer rate with a real file, in this case, an image of the Windows Vista WAIK

Transfer rate with a real file, in this case, an image of the Windows Vista WAIK


Test file created with fsutil

Test file created with fsutil


Transfer rate with a test file of the exact same size created by fsutil

The Path to x64

Posted on by
Reply

RAM prices are dirt cheap, and with the amount of work I’m doing on virtual machines lately, it would be silly to not get another stick of 2 GB to my existing 2 GB.

2 + 2 might make 5 if you were in the world of Big Brother, but in the 32-bit world, 2 + 2 is somewhere in the range of 3 ~ 3.5 GB. 32-bit systems are not always able to address up to the full 4 GB of available physical memory, the reason is a bit complicated and has to do with virtual addressing limits. I’ll save myself from rehashing what others have written on the topic and refer you to the excellent article here.

The transition from 32-bits to 64-bits was smoother than I expected. First of all, I’m running on an OEM version of Windows Vista Business 32-bit, and I needed a 64-bit copy of Windows. Luckily obtaining the installation media wasn’t an issue for me as I had a copy of Windows Ultimate lying around, which I won from a Microsoft talk last year. I admit I was a reluctant to open the shrink wrap at first, but I desperately needed the media.

It is worthwhile to note that serial keys for Windows Vista are tied to the edition (Home Premium, Business, Ultimate etc) but not to the bitness (32-bit or 64-bit). Therefore, using my old Business edition serial was perfectly fine and I can save my Ultimate edition license for another day.

There is no difference in the installation process between the two bitness. The only difference, and deal breaker for many is that 64-bit Vista requires 64-bit drivers, and the drivers have to be digitally signed. The only two drivers that I have trouble with were Sony Ericsson’s PC Suit, which was required to sync my phone and Adobe’s PDF printer. It seems that I’m out of luck for the former, but the latter got addressed with a patch.

The only issue I had was with poorly written applications which hardcode their installation paths. In Windows x64, program space is separated depending on if they’re 32 or 64 bit (with a few naming oddities I must say, but they’re all preserved for compatibility reasons). However, SOE’s launchpad absolutely insists on writing to C:\Program Files\Sony\Station\LaunchPad despite the fact that 32-bit applications are suppposed to be redirected to C:\Program Files (x86). The problem exists with only the launchpad itself though, it is able to patch EQ2 in its correct C:\Program Files (x86) path.

The other problem I have was with 64-bit Java; it didn’t provide a plugin for 32-bit Firefox. There exists a way to work around this on Linux, but as far as my Google skills go, I couldn’t find a solution on Windows. Therefore, I went back to 32-bit Java.

With a full 4 GB of addressable memory, there certainly has been some changes to my workflow. I’m gradually becoming a huge fan of keeping my system clean and moving my work onto virtual machines. I might be a terribly messy person in real life, but I almost have a certain OCD when it comes to organizing my system. I’d almost do all my work exclusively inside virtual machines if not for the fact that I’m a gamer, and that virtualized 3D hardware acceleration isn’t quite here yet, but it will be one day. Guaranteed its not much and it’ll take another year or two, or even longer, before the technology matures, but VMWare Fusion already has experimental Direct X 9 support, and its the road that we’re going to take.

There’s still a vacuum as far as 64-bit software is concerned. Let’s face it, there’s not that many applications that would benefit from a 32-bit to 64-bit transition. WoW64 does its job of running 32-bit applications on Windows x64 just fine without any performance degradation, despite all the rumors that fly around.

Lost in transition: ICMP Redirects

Posted on by
1

I configured and installed Ubuntu Server 8.04 with the typical LAMP setup with the intend of mirroring this blog locally so I could test out a few changes without affecting the live copy and placed the server virtualized, behind the Vyatta router.

icmp_network_diag

Back on my desktop, I was greeted with a previously unseen error as I navigated to the site.

interrupted

I verified that Apache was running with a ps aux | grep apache, and indeed it was. I checked that I was able to access the page from machine on the same subnet. At this point, I suspected it was an issue with the Vyatta router, although its rather puzzling since all traffic initiated from the 192.168.5.0 network, internet bound or otherwise seemed to be working fine.

ubuntu_tcpdump

Carrying out tcpdump on the Ubuntu server, it seems that the first SYN packet from 192.168.1.50 was received, and judging from the subsequent similar (they all have same sequence numbers) SYN-ACK packets that were sent out from the server, it was clear that server never heard from 192.168.1.50 any further. One of the following could’ve happened:

  1. The SYN-ACK bound for 192.168.1.50 never arrived at its destination.
  2. The SYN-ACK packets arrived at 192.168.1.50, but the ACK respond required to complete the handshake never made it back to the server.

Carrying out a tcpdump dump similarly on eth0 of Vyatta, I was able to verify that the packets were following both ways, which took the fault of the router of the question. All was well with it.

I don’t know why I didn’t look at this earlier, but when you install a sparkling new piece of equipment and it something doesn’t work, you would automatically lay blame to that equipment instead of examining the complete picture closely, exactly like the old rhetoric “it used to work until I <insert something that you recently just did here>”. I ran Wireshark, which is a GUI version of a packet capturing tool much like tcpdump on my desktop itself. What showed next was the reason behind all my problems.

Wireshark showed that my IPCop router was sending me an ICMP redirect for every packet I sent out destined for 192.168.5.3. It was then that it occurred to me that since the Vyatta router had an interface in the same network as my computer, IPCop was telling me that that shorter route to the 192.168.5.0 network was to send it directly to the gateway at 192.168.1.150 instead of sending it to the default gateway specified on the desktop of 192.168.1.1 aka IPCop and then have it rerouted.

It turns out that on Windows if the Windows Firewall is turned on, ICMP redirects are dropped by default. As a routing mechanism, ICMP redirects have no security built in and hence, are vulnerable to IP spoofing attacks. So although an ICMP redirect was sent to my computer, it was silently dropped and the message never got through.

To get around this problem, the firewall could simply be enabled to accept ICMP redirects. Despite the security issues with it, it is rather safe on a small LAN where every computer comes under my control and ICMP requests are not forwarded by the exterior facing router into the network. Alternatively, an entry could be added in the Windows routing table.

route -p add 192.168.5.0 mask 255.255.255.0 192.168.1.150

It turns out to be a simple and small issue, but it took the better part of an afternoon to solve. Its all about the learning experience I guess, that’s what the network was setup for in the first place.

Setting up the virtual network

Posted on by
Reply

Virtualization is a cool new buzzword, but it goes beyond that, it is actually going to help me solve a few problems. Before I go any further, here’s the network topology of my setup.

Network diagram

I’ve a few objectives I wish to attain with this setup. Mainly,

  • Learning Windows administration in depth.
  • Testing Vyatta and hope to eventually use it as my primary router.
  • Learning to implement more complex network setups with various routing protocols. I’ll eventually add more routers to my existing virtualized topology. Now I’m just getting the basics off the ground.
  • Learning some basic Linux administration. I’m adding Ubuntu 8.04 to the pile of virtualized OS soon, I currently have it installed on my desktop via Wubi.
  • Learning and deploying IPv6 as a minor objective after all the above has been satisfied.

My main home router is an old P3 450 MHz machine that’s finding new purpose in life and now runs IPCop. The router for my virtualized network runs Vyatta.

Taking advantage of Microsoft’s trial program for their server and developer products, I downloaded a copy of Windows Server 2008. The 60 day evaluation period can be extended to 240 days, and doing so is even blessed by Microsoft. One reinstallation every 240 days sound fair enough for me. This time I really really am going sit down and teach myself Active Directory. Yes, really.

In order for the newly added network to be recognized, an entry in IPCop’s routing table needed to be added. Being a SOHO router distribution, it doesn’t support any routing protocols so a static route had to be manually added. As a Linux newbie, the whole process took way longer because of a silly mistake that I made, missing out the gateway portion of the route add command. From my past experiences working on Cisco routers, adding a static path required you only to specify the destination network address, mask and either the next hop router address or outgoing interface. I hastily entered the same, specifying the outgoing interface without realizing that if a gateway is between the two networks, I’ve to use the next hop address syntax instead of just specifying the outgoing interface.

Correct:

route add -net 192.168.5.0 netmask 255.255.255.0 gw 192.168.1.150

Wrong:

route add -net 192.168.5.0 netmask 255.255.255.0 eth0

This resulted in a scenario of traffic being able to reach from 192.168.1.1 to 192.168.5.1, but not to the rest of the 192.168.5.0 network, which puzzled me greatly until I realized my folly.

Another silly was the result of cloning VMWare machines. The fact that cloned machines would have similar MAC addresses never crossed my mind, and that caused all kinds of havoc on its own. It was fixed by changing the MAC address in the machine configuration file (.vmx).

Aside from those issues, setting up the network was relatively easy. Vyatta took minimal configuration out of the box.

Setting up the interfaces:

set interfaces ethernet eth0 address 192.168.1.150/24
set interfaces ethernet eth1 address 192.168.5.1/24

Default routing to allow internet access:

set protocols static route 0.0.0.0/0 next-hop 192.168.1.1

Enable the ssh service:

set service ssh

In Vyatta, changes are not committed immediately after typing in every command until you explicitly tell it to, so:

commit

Done for now, more updates on this small project of mine as they come along. Oh, and I’m proud of the network diagram I drew, it’s the cleanest and neatest one I’ve ever done. Previously they were hand drawn or MS Paint jobs, this one’s done in Powerpoint.

Talking to myself

Posted on by
1

Jabber

On a normal day, I work with two computers: my primary PC and my laptop beside me. This allows for a whole much of handy multitasking, such as running an IM application while playing a game or watching a movie fullscreen, or maybe the roles would be reversed and I’m harvesting in EQ2 and watching the movie on my laptop instead. Either way, the need for copying chunks of text across to the other machine, such a URL or a code snippet is a scenario that often arises.

Previously, I had a text file on a folder shared across the network where I would paste the snippets of text to, but that wasn’t the most elegant solution. Then, I made a second MSN, or Windows Live Messenger as you would call it now, account and IMed myself on my other machine. It was a neat solution, but still, I didn’t like the idea that my message would have to endure a 300ms delay, traveling halfway across the world first to the MSN servers, and then bouncing all the way back.

My solution to that was an internal (available only within my LAN) IM system. After a bit of research, it seems that Jabber / XMPP was the way the go. XMPP is an open source IM protocol. I settled on Openfire as the server, and deployed Pandion to the rest my computers, which was to my messaging client of choice (much like Windows Live Messenger). After a simple 10 minute setup, which involved nothing more than running the respective installers and adding users to the friendly web interface of Openfire, I was up and running. Finally, an elegant internal messaging system. I couldn’t get the file transfer working thus far, but that’s not important, although I’ll want to try and solve just so the whole system would be error free.

What do you do with all that screenshots?

Posted on by
3

I’ve been trying to be a bit more organized recently, sorting out my the huge mess that is my digital storage, and clearing out a years worth of the stuff in the folder labeled ‘Incoming’. As the name suggests, is where every file coming in to my computer is stored, regardless of their source. This includes random stuff I copy from my laptop over to view temporarily, files downloaded from the Internet, more random bits of files I get sent over MSN and so on. If my mom could visualize my incoming folder as my room, she’ll go ape. It is that bad.

One thing I’ve always had problems sorting out is my screenshots folder from whatever game I’m playing. I’ve the tendency to take a lot of random screenshots, but never go through the process of sorting them. My question to you readers are: how do you organize them screenshots? Do you rename them? (not that my uncreative naming conventions for my L2 screenshots of “lol1v1.jpg”, “lolraped.jpg”, “omglololol.jpg” help me in anyway) Put them in different folders? Or do you make use of some photo album program to organize and tag them (Flickr comes to mind)?