This is scarce information on the Internet, so I'm reposting!
NetBIOS can be disabled now that it's fairly ancient networking. You're using TCP/IP and DNS right?
I don't use Microsoft DHCP or DNS servers, so finding the information to set this is hard to come by. To disable NetBIOS over TCP/IP in an ISC DHCP server, add the following to your dhcpd.conf:
option vendor-encapsulated-options 01:04:00:00:00:02;
It's that easy!
Thursday, May 27. 2010
disabling NetBIOS over TCP/IP in Windows via BIND DHCPD
Posted by Khanh Tran
in Internet/Networking, Linux, Windows
at
08:31
| Comments (0)
| Trackbacks (0)
Sunday, March 22. 2009
AT&T 3G Speed tests
I haven't been writing much lately due to a busy schedule!
Anyway, I recently borrowed one of those AT&T 3G LaptopConnect cards. It's a Sierra Wireless AirCard 881. Compared to the speeds I've been getting with my AT&T Tilt (tethered via USB), it didn't hold up as well as I expected:
AT&T Tilt (HTC) tethered via USB:
AT&T Sierra Wireless LaptopConnect Card (AirCard 881):
And although this isn't really for comparison to the AT&T test, it seems Cablevision (Optimum Online) has been steadily increasing my bandwidth at home, even out in the middle of nowhere!
Anyway, I recently borrowed one of those AT&T 3G LaptopConnect cards. It's a Sierra Wireless AirCard 881. Compared to the speeds I've been getting with my AT&T Tilt (tethered via USB), it didn't hold up as well as I expected:
AT&T Tilt (HTC) tethered via USB:
AT&T Sierra Wireless LaptopConnect Card (AirCard 881):
And although this isn't really for comparison to the AT&T test, it seems Cablevision (Optimum Online) has been steadily increasing my bandwidth at home, even out in the middle of nowhere!
Wednesday, February 4. 2009
eh, wordle...
Wordle generated and interesting graphic of the blog today...
If you look at it hard enough, it's slightly 3D!
Then there was this, more relaxed graphic:
If you look at it hard enough, it's slightly 3D!
Then there was this, more relaxed graphic:
Tuesday, November 18. 2008
using openSSH as a layer-2 ethernet bridge (VPN)
Consider the following network setup (which I live with by the way):
[main LAN] <-----------------------------------------------------> [remote datacenter LAN]
(192.168.0.0/16) <-------- leased point-to-point ------------> (192.168.0.0/16)
Both locations also have separate connections to the public Internet with different public IP subnets. However, for this discussion it's not necessary to have different public IP subnets. Under normal circumstances the local LAN and the remote LAN are the same logical LAN via the magic of the leased point to point line.
However, today that p2p connection broke (physically between the two locations, out of our control). This outage lasted several hours, but brought out an interesting use of SSH tunneling for ethernet bridging aka Layer-2 VPN or tunneling. For this to work, you'll need to have at least openSSH 4.3, a somewhat recent linux distro and the bridge-utils package for your distro. This also assumes you have a basic knowledge of IP and the linux command line. I use openSuSE 11.0, but this should work for almost any similar linux.
Let's say for example, the main location has a linux box (router1) with two NICs:
eth0: 1.1.1.1 (the public interface)
eth1: unassigned IP, but connected to your LAN (192.168.0.0/16 in my case)
On the other box, at the remote location (router2) we also have two NICs:
eth0: 2.2.2.2 (the public interface)
eth1: unassigned IP, but connected to your LAN (192.168.0.0/16 in my case)
Both routers should be set with it's public IP gateway as the default route, working DNS, etc. You'll want to enable IP forwarding (consult your specific distro) and in my case, I disabled the distro's firewall. On the remote side (consider it the "server"), you'll need to edit your sshd config to allow remote root logins and tunnels via SSH.
/etc/ssh/sshd_config:
PermitRootLogin yes
PermitTunnel yes
The root login is necessary to allow ssh to create the TAP devices for the bridge. Because of that, you'll also want to add your local side's IPs to /etc/hosts.allow for the sshd process. Now, on the local side (IP 1.1.1.1, which you might consider the client now) you'll want to "su root" and do the following:
ssh -o Tunnel=ethernet -f -w 0:0 2.2.2.2 true
The -o switch sets client options on the command line. We're specifying the tunnel type as ethernet (bridge) as opposed to point-to-point, which it'll do by default (for Layer-3 type VPN routing). The -f switch just forks ssh in the background so we're returned to our "client's" command line and not remote's. Since we've done that, ssh will expect a remote command of some kind, so we'll just run "true", effectively doing nothing. The -w 0:0 switch actually sets up our tap devices on either side as tap0. You can do -w 1:1 for tap1, -w 0:1 for tap0 on one side and tap1 on the other, etc.
On both sides now, you should be able to see via ifconfig -a your eth0, eth1 and tap0 devices. Make sure to call ifconfig with -a, or you'll only see interfaces with defined IPs. Now that the two boxes are connected via the public Internet to each other via SSH, you can finally start to establish the bridge interface. Now we'll use the bridge-utils binary to create a bridge interface called br0:
brctl addbr br0
brctl addif br0 eth1
brctl addif br0 tap0
Then you'll want to bring up all of your interfaces, if they aren't already:
ifconfig eth1 up
ifconfig tap0 up
ifconfig br0 up
Doing so will create the br0 interface, then bridge your eth1 and tap0 together and bring up the interfaces. Don't forget, YOU MUST RUN THE brctl and ifconfig COMANDS ON BOTH SIDES!!! Once you've done this, you can check the remote side to see if it knows about the MAC addresses (from Layer-2) on the local side:
brctl showmacs br0
This will report on the known MAC address from the ARP protocol. Depending on your network, you'll see a few or many. Depending on your setup, you can get a DHCP address on the "other side" of the tunnel now or configure an appropriate IP and ping across as if you were on the same physical broadcast domain!
As a final note, there's always a downside. TCP encapsulated TCP is bad and will put a STRAIN on your hardware. Make sure it's decent for the amount of anticipated traffic and use only as a quick and dirty solution or a temporary measure. The following is good reading for why this is not a long-term, permanent solution:
http://sites.inka.de/~W1011/devel/tcp-tcp.html
[main LAN] <-----------------------------------------------------> [remote datacenter LAN]
(192.168.0.0/16) <-------- leased point-to-point ------------> (192.168.0.0/16)
Both locations also have separate connections to the public Internet with different public IP subnets. However, for this discussion it's not necessary to have different public IP subnets. Under normal circumstances the local LAN and the remote LAN are the same logical LAN via the magic of the leased point to point line.
However, today that p2p connection broke (physically between the two locations, out of our control). This outage lasted several hours, but brought out an interesting use of SSH tunneling for ethernet bridging aka Layer-2 VPN or tunneling. For this to work, you'll need to have at least openSSH 4.3, a somewhat recent linux distro and the bridge-utils package for your distro. This also assumes you have a basic knowledge of IP and the linux command line. I use openSuSE 11.0, but this should work for almost any similar linux.
Let's say for example, the main location has a linux box (router1) with two NICs:
eth0: 1.1.1.1 (the public interface)
eth1: unassigned IP, but connected to your LAN (192.168.0.0/16 in my case)
On the other box, at the remote location (router2) we also have two NICs:
eth0: 2.2.2.2 (the public interface)
eth1: unassigned IP, but connected to your LAN (192.168.0.0/16 in my case)
Both routers should be set with it's public IP gateway as the default route, working DNS, etc. You'll want to enable IP forwarding (consult your specific distro) and in my case, I disabled the distro's firewall. On the remote side (consider it the "server"), you'll need to edit your sshd config to allow remote root logins and tunnels via SSH.
/etc/ssh/sshd_config:
PermitRootLogin yes
PermitTunnel yes
The root login is necessary to allow ssh to create the TAP devices for the bridge. Because of that, you'll also want to add your local side's IPs to /etc/hosts.allow for the sshd process. Now, on the local side (IP 1.1.1.1, which you might consider the client now) you'll want to "su root" and do the following:
ssh -o Tunnel=ethernet -f -w 0:0 2.2.2.2 true
The -o switch sets client options on the command line. We're specifying the tunnel type as ethernet (bridge) as opposed to point-to-point, which it'll do by default (for Layer-3 type VPN routing). The -f switch just forks ssh in the background so we're returned to our "client's" command line and not remote's. Since we've done that, ssh will expect a remote command of some kind, so we'll just run "true", effectively doing nothing. The -w 0:0 switch actually sets up our tap devices on either side as tap0. You can do -w 1:1 for tap1, -w 0:1 for tap0 on one side and tap1 on the other, etc.
On both sides now, you should be able to see via ifconfig -a your eth0, eth1 and tap0 devices. Make sure to call ifconfig with -a, or you'll only see interfaces with defined IPs. Now that the two boxes are connected via the public Internet to each other via SSH, you can finally start to establish the bridge interface. Now we'll use the bridge-utils binary to create a bridge interface called br0:
brctl addbr br0
brctl addif br0 eth1
brctl addif br0 tap0
Then you'll want to bring up all of your interfaces, if they aren't already:
ifconfig eth1 up
ifconfig tap0 up
ifconfig br0 up
Doing so will create the br0 interface, then bridge your eth1 and tap0 together and bring up the interfaces. Don't forget, YOU MUST RUN THE brctl and ifconfig COMANDS ON BOTH SIDES!!! Once you've done this, you can check the remote side to see if it knows about the MAC addresses (from Layer-2) on the local side:
brctl showmacs br0
This will report on the known MAC address from the ARP protocol. Depending on your network, you'll see a few or many. Depending on your setup, you can get a DHCP address on the "other side" of the tunnel now or configure an appropriate IP and ping across as if you were on the same physical broadcast domain!
As a final note, there's always a downside. TCP encapsulated TCP is bad and will put a STRAIN on your hardware. Make sure it's decent for the amount of anticipated traffic and use only as a quick and dirty solution or a temporary measure. The following is good reading for why this is not a long-term, permanent solution:
http://sites.inka.de/~W1011/devel/tcp-tcp.html
Saturday, May 17. 2008
monitoring latency and packet loss with mrtg and ping
I've been using MRTG for years to graph traffic on switch ports, but only recently started using it to graph other fun things.
Recently, I've started using it for latency.
/usr/local/bin/ping-host.sh:
Then in your mrtg.conf file:
You can also execute remote commands over SSH. I use that for load averages. You'll have to figure out how to set up authentication keys. Otherwise, the automated script will be prompted for a password on the console, which you won't be attached to. I might post later about setting up authentication keys for password-less login, but for now, here's my load average script, to be run on the remote host:
loadavg.sh:
Then on your MRTG host do something like:
Recently, I've started using it for latency.
/usr/local/bin/ping-host.sh:
#!/bin/sh
PING="/bin/ping"
ADDR="172.16.0.100"
DATA=`$PING -c10 -s500 $ADDR -q `
LOSS=`echo $DATA | awk '{print $18 }' | tr -d %`
echo $LOSS
if [ $LOSS = 100 ];
then echo 0
else
echo $DATA | awk -F/ '{print $5 }'
fi
Then in your mrtg.conf file:
Title[ping-host]: RTT to host
PageTop[ping-host]: <H1>Host Round Trip Time</H1>
Target[ping-host]: `/usr/local/bin/ping-host.sh`
MaxBytes[ping-host]: 2000
Options[ping-host]: growright,unknaszero,nopercent,gauge
LegendI[ping-host]: Pkt loss %
LegendO[ping-host]: Avg RTT
YLegend[ping-host]: RTT (ms)
ShortLegend[_]: p/s
You can also execute remote commands over SSH. I use that for load averages. You'll have to figure out how to set up authentication keys. Otherwise, the automated script will be prompted for a password on the console, which you won't be attached to. I might post later about setting up authentication keys for password-less login, but for now, here's my load average script, to be run on the remote host:
loadavg.sh:
#!/bin/bash
awk /proc/loadavg '{print (100*$1) "\n" (100*$2) }'
Then on your MRTG host do something like:
Target[Mail-LoadAvg]: `ssh -l mailnull mail.host.tld ./loadavg.sh`
Monday, May 12. 2008
iTunes and NFS... woahs and woes
A few months back I wrote about how I wanted to replace my iPod with my PocketPC. Alas, I've conceded to the mainstream. The iPod has won out for it's end-user experience. There's simply too much work involved in the PocketPC and the user interface is still stuck in its old roots. The stylus is still the primary form of "interface" and in the car, that just doesn't work. I'm sure it'd be fine for someone else, but I spend a lot of time in the car. I'll still use the PocketPC for phone, email, browsing, etc. Also, I actually really like iTunes. The interface is exactly how I like to manage my 40+GB of music and the podcasts just sync. The podcast client (Egress) I was using on the PocketPC was just too clumsy, never seemed to really "sync" the right way, and then of course there was that pesky ease-of-use issue. Once in Egress, there was little integration with Windows Media Player. Granted, it was functional, but it just wasn't easy to swith between podcasts and know which I've already listened to or not. Since my music library is also in iTunes already, I just didn't have the necessary investment in Windows Media Player. Back to iTunes for me for now.
On a similar note, I have iTunes running on a fairly new Mac Book. Since I have a large library, which I also like to access remotely, I put the whole thing on an NFS share from my MythTV box. The MythTV box is currently openSuSE 10.2. Everything was running great on Mac OS X 10.4, but I decided to upgrade to 10.5 this weekend and finally throw on Office 2008. Everything runs a bit slower than it used to, but I suppose that's to be expected with new OSes. OS X is probably suffering from Vista-style bloat. One thing that did improve was Quicken 2007 (PowerPC) stability, but that was a minor issue for me. At work, I've been running 10.5 and setting up a 10.5 server for ActiveDirectory integration and I've had nothing but issues with network mounts and network integration in general. So, when I found out last night that my iTunes library wouldn't open over NFS, it didn't surprise me. The issue was that the Mac had no problem mounting the NFS volume, but once you started clicking on files in Finder, they'd show up as zero length files and then they'd disappear. In the terminal, they showed as normal files, but of course, I was just doing directory listings, not actually opening the files.
Apparently, OS X 10.5 changes the NFS client behavior. However, there is a "fix" that I've implemented on the NFS server side, since I don't care enough to debug OS X in my personal life. I deal with it enough in the work environment. On the server side, I kept seeing these errors:
lockd/statd: failed to create /var/lib/nfs/sm/: err=-21
The problem there is that there's no hostname at the end of that path. For whatever reason, the OS X 10.5 is either not reporting the hostname, not the way openSuSE 10.2 expects it, or openSuSE 10.2 has an issue. Since I didn't have this problem under OS X 10.4, I'm guessing the first two options are the reason, not the third. Anyway, change the following value in /proc. I'm going to throw it in boot.local to survive reboots probably.
echo "0" >/proc/sys/fs/nfs/nsm_use_hostnames
On a similar note, I have iTunes running on a fairly new Mac Book. Since I have a large library, which I also like to access remotely, I put the whole thing on an NFS share from my MythTV box. The MythTV box is currently openSuSE 10.2. Everything was running great on Mac OS X 10.4, but I decided to upgrade to 10.5 this weekend and finally throw on Office 2008. Everything runs a bit slower than it used to, but I suppose that's to be expected with new OSes. OS X is probably suffering from Vista-style bloat. One thing that did improve was Quicken 2007 (PowerPC) stability, but that was a minor issue for me. At work, I've been running 10.5 and setting up a 10.5 server for ActiveDirectory integration and I've had nothing but issues with network mounts and network integration in general. So, when I found out last night that my iTunes library wouldn't open over NFS, it didn't surprise me. The issue was that the Mac had no problem mounting the NFS volume, but once you started clicking on files in Finder, they'd show up as zero length files and then they'd disappear. In the terminal, they showed as normal files, but of course, I was just doing directory listings, not actually opening the files.
Apparently, OS X 10.5 changes the NFS client behavior. However, there is a "fix" that I've implemented on the NFS server side, since I don't care enough to debug OS X in my personal life. I deal with it enough in the work environment. On the server side, I kept seeing these errors:
lockd/statd: failed to create /var/lib/nfs/sm/: err=-21
The problem there is that there's no hostname at the end of that path. For whatever reason, the OS X 10.5 is either not reporting the hostname, not the way openSuSE 10.2 expects it, or openSuSE 10.2 has an issue. Since I didn't have this problem under OS X 10.4, I'm guessing the first two options are the reason, not the third. Anyway, change the following value in /proc. I'm going to throw it in boot.local to survive reboots probably.
echo "0" >/proc/sys/fs/nfs/nsm_use_hostnames
Posted by Khanh Tran
in Apple/Mac, Internet/Networking, Linux
at
11:53
| Comment (1)
| Trackbacks (0)
Friday, February 29. 2008
ActiveSync Internet Passthrough not working...
I've got a few more software packages I've been playing with to make my new Tilt look more like an iPhone. These are some nice plugins/themes that make the AT&T (HTC) Tilt look and function much better. Stay tuned for that and my comments on using the Tilt to replace my iPod. I received my 8GB MicroSD card in the mail the other day, but I'm still waiting on the audio adapter for mini jack output. By the way, MicroSD cards are REALLY TINY. Amazing.
On a more functional note, I noticed Internet Passthrough wasn't working via ActiveSync. The default not for modern Windows Mobile and ActiveSync versions is to disable the wireless connectivity when connected to ActiveSync on a host PC. However, it wasn't working without the help of this tip about bypassing LSP (Layered Service Provider) and this AT&T Tilt forum post
On a more functional note, I noticed Internet Passthrough wasn't working via ActiveSync. The default not for modern Windows Mobile and ActiveSync versions is to disable the wireless connectivity when connected to ActiveSync on a host PC. However, it wasn't working without the help of this tip about bypassing LSP (Layered Service Provider) and this AT&T Tilt forum post
Posted by Khanh Tran
in Internet/Networking, Mobile, Windows
at
19:52
| Comments (0)
| Trackbacks (0)
Sunday, May 13. 2007
Living with an HP PSC 1350 on your network
I love the PSC 1350. It's low cost. It's multifunctional and has enough quality for my needs. If you have one on your network however, I feel your pain.
Making it work from Windows is a challenge to a network server. I've tried the Adobe PPD files mentioned in a previous post before and it works to a CUPS server, but not to a JetDirect, Airport Express, or other RAW print queue on port 9100. I read some others' posts about using the HP DeskJet 550C driver. That sounds great and is included everywhere, but it just wouldn't print. I finally found a post about using the DeskJet 3420 drivers and that worked.
FINALLY!
From Linux, the job was slightly easier due to PSC support via PPD files, mostly included with the various distributions. Mac OS X proved a bit harder. The old PPC version of OS X had sufficient support, but the updated driver package for the PSC just doesn't work "out-of-the-box". I suggest going to http://www.linux-foundation.org/en/OpenPrinting/MacOSX/hpijs, and getting the HPIJS driver packages for OS X.
Making it work from Windows is a challenge to a network server. I've tried the Adobe PPD files mentioned in a previous post before and it works to a CUPS server, but not to a JetDirect, Airport Express, or other RAW print queue on port 9100. I read some others' posts about using the HP DeskJet 550C driver. That sounds great and is included everywhere, but it just wouldn't print. I finally found a post about using the DeskJet 3420 drivers and that worked.
FINALLY!
From Linux, the job was slightly easier due to PSC support via PPD files, mostly included with the various distributions. Mac OS X proved a bit harder. The old PPC version of OS X had sufficient support, but the updated driver package for the PSC just doesn't work "out-of-the-box". I suggest going to http://www.linux-foundation.org/en/OpenPrinting/MacOSX/hpijs, and getting the HPIJS driver packages for OS X.
Sunday, December 3. 2006
How to make Windows print to a Linux CUPS IPP printer
Network printing is a daunting task. Network printing in Linux is tricky. I have a Linux server with a shared CUPS printer (one of those HP PSC printers). Making OS X print to it was somewhat simple because it's BSD under the hood, so it has CUPS/IPP support. Adding your server's hostname to your hosts file was the trick to making it work.
I set out to make Windows print to the Linux CUPS/IPP printer. You should add your hostname and IP to C:\WINDOWS\SYSTEM32\DRIVERS\ETC\HOSTS. This allows for name to IP resolution. Windows doesn't come with CUPS/IPP printing support out of the box. The key to making this work was found in a free Adobe PS driver found here. I chose Adobe Universal PostScript Windows Driver Installer 1.0.6 - English. Run the installer, select "Network Printer", and enter the URL of your printer queue. It will be something like http://hostname:631/printers/PrinterName. Select "yes" when prompted. You can use the Generic PostScript Printer option or you can use the PPD file created by CUPS for your printer with the Browse button. Your PPD file should be in /etc/cups/ppd on your Linux server.
I've only tested this under Windows XP, but other versions of Windows should work similarly.
I set out to make Windows print to the Linux CUPS/IPP printer. You should add your hostname and IP to C:\WINDOWS\SYSTEM32\DRIVERS\ETC\HOSTS. This allows for name to IP resolution. Windows doesn't come with CUPS/IPP printing support out of the box. The key to making this work was found in a free Adobe PS driver found here. I chose Adobe Universal PostScript Windows Driver Installer 1.0.6 - English. Run the installer, select "Network Printer", and enter the URL of your printer queue. It will be something like http://hostname:631/printers/PrinterName. Select "yes" when prompted. You can use the Generic PostScript Printer option or you can use the PPD file created by CUPS for your printer with the Browse button. Your PPD file should be in /etc/cups/ppd on your Linux server.
I've only tested this under Windows XP, but other versions of Windows should work similarly.
Posted by Khanh Tran
in Internet/Networking, Linux, Windows
at
12:07
| Comments (2)
| Trackbacks (0)
Monday, November 27. 2006
Update: iTunes sharing over WAN connections
A little while ago I posted an entry about sharing iTunes over a WAN with SSH tunnels. I also posted a little something about Hamachi networking. Well, apparently you can use Hamachi for WAN sharing of iTunes, without the need for Rendezvous Proxy or SSH tunnels. Get Hamachi working on your Windows or Mac OS X computer. For the OS X users, I HIGHLY recommend HamachiX. This is a graphical front-end to the currently console-only version of Hamachi. You could run through the console-based install of Hamachi from their website, but OS X is supposed to be easy, right? Anyway, once you get Hamachi working on both hosts, you just open up iTunes and share as if you were local on the LAN. No special tricks, but that's the point of Hamachi.
Monday, October 16. 2006
Optimum Voice findings...
It's been over two months with the new Optimum Voice service. So far so good, but I have a few not-quite-complaints about the service. First off, the price isn't bad if you have the other Cablevision/Optimum services. If you don't, you'll be paying a hefty price for service. Most of the features compare with the Vonage service I once had. One big problem I have is with the call log on the Optimum Voice website. It shows all the outgoing calls, but not the incoming ones. If anything, I'm more interested in the log of incoming calls. If I'm not home and I'm missing calls, it's the best way to know who called, even if they don't leave a message. The Caller ID is inconsistent, or at least it's going through some changes recently. Most of the time, I see the calling number's city, rather than the person calling. The distinctive ring or VIP ring is a nice touch over Vonage though. The voicemail, call waiting, and call forwarding services are also equivalent to Vonage. However, Vonage had one nice feature that Optimum Voice didn't quite get right. I live in an area that suffers from frequent blackouts. Vonage allows for a fall back number, in case the Vonage adapter is off due to power, or your ISP is out. Optimum Voice doesn't have this, but they do have "Follow Me". This rings multiple numbers simultaneously. This is great, but I don't want it to happen all of the time. International rates are similar, but I make few, if no, international calls. Optimum Voice does a weird thing where they expect you to buy Internation minutes in bulk. I think it's a minimum of $10. The minutes roll-over to the next month, but it's still somewhat annoying. Optimum Voice doesn't offer the different pricing plans as Vonage, has no second line option, no choice in are code/exchange, and no 1-800 number services. Finally, the Optimum Voice adapter is not portable, where the Vonage adapter is. The Optimum Voice adapter is integrated into the cable modem. This is great for setup, but you can't take it with you if you travel. Of course, from my last post, one of the reasons I changed was for customer service. With the "triple play" package of voice, data, and tv, I pay just about the same as I did with Vonage and if my adapter fails, I expect to bring it to any Cablevision center and get a new one right away.
Tuesday, August 1. 2006
VOIP ups and downs
I was a happy Vonage customer up until last week. Technically, I'm still a customer, but I'm in the middle of changing over to my local cable company's VOIP service. They claim my install date is next week, so I'll keep you posted. Here's what happened:
Vonage has been great up until it wasn't. The voice quality was perfect. You couldn't tell that I was on a VOIP line or not. Chances are that had much to do with my ISP (the local cable company). I was using the two port Linksys adapter, without issue for about 18 months. I originally had gone with Verizon's VoiceWing because I assumed they'd be able to port their own POTS line number easier than any other company. After a week on the phone with Verizon, I learned sadly that they can't even do something as basic as that. So, I ordered Vonage, got a new number and went with it.
Last week sometime, we had bad thunderstorms, lightning, brown-outs and all. The Linksys adapter went dead for dial tone, but the Internet router functions were still working. After 2 hours of on and off the cell phone with Vonage, I gave up. This was partially my fault that my cell phone dropped out, but the next call was not made any better by the next support person. Yes, it was a help desk in India, and no they were not even responsive to anything but their script. They wouldn't even admit to the fact that I had just been on the line with someone else and I had to restart from the beginning of their script. Needless to say that this was fruitless until I finally yelled at the last tech. It wasn't her fault, but after two hours, I didn't see the need to continue this on my cell phone charges for a $15/month phone service. Maybe that's why Vonage sucks for support. All I wanted was an answer on what to do about a dead router. They insisted I had a MAC address conflict on my network. I'm not sure how that was on my three computer network, but sure, whatever. I suppose it's even more proof of why I'm lucky to have passed on the stock offering...
Vonage has been great up until it wasn't. The voice quality was perfect. You couldn't tell that I was on a VOIP line or not. Chances are that had much to do with my ISP (the local cable company). I was using the two port Linksys adapter, without issue for about 18 months. I originally had gone with Verizon's VoiceWing because I assumed they'd be able to port their own POTS line number easier than any other company. After a week on the phone with Verizon, I learned sadly that they can't even do something as basic as that. So, I ordered Vonage, got a new number and went with it.
Last week sometime, we had bad thunderstorms, lightning, brown-outs and all. The Linksys adapter went dead for dial tone, but the Internet router functions were still working. After 2 hours of on and off the cell phone with Vonage, I gave up. This was partially my fault that my cell phone dropped out, but the next call was not made any better by the next support person. Yes, it was a help desk in India, and no they were not even responsive to anything but their script. They wouldn't even admit to the fact that I had just been on the line with someone else and I had to restart from the beginning of their script. Needless to say that this was fruitless until I finally yelled at the last tech. It wasn't her fault, but after two hours, I didn't see the need to continue this on my cell phone charges for a $15/month phone service. Maybe that's why Vonage sucks for support. All I wanted was an answer on what to do about a dead router. They insisted I had a MAC address conflict on my network. I'm not sure how that was on my three computer network, but sure, whatever. I suppose it's even more proof of why I'm lucky to have passed on the stock offering...
Saturday, March 25. 2006
Hamachi VPN
I finally got around to trying Hamachi. If you don't know what it is, check out http://www.hamachi.cc. Basically, it's a VPN solution. Not so basically, it allows you to create a LAN over the Internet, very simply, quickly, and efficiently. It uses UDP and has no issues with NAT based routers. In short, anyone with basic computer knowledge can set up a very secure private network over the Internet.
Hamachi is free and works with Linux and Windows. There is an OS X version, but it's console based. The Linux version is console based too, but I won't be looking to try the OS X version until they get a GUI around it. Hamachi works by establishing a connection from you to the Hamachi servers. Once your Hamachi clients come online, the Hamachi server steps out of the picture leaving you with a FAST, secure VPN. I generally don't like solutions that require a third party like this, but it really does work well. They assign you an IP in the 5.0.0.0/8 network, so they have lots of address space and you could even set up DNS entries to your assigned IP.
The setup is horribly simple, even on Linux. I won't get into all of that here, but the possibilities are endless and have re-opened many scenarios for me. Network games, file sharing and remote administration suddenly become much easier to implement with Hamachi. If you've ever struggled with port forwards, dynamic DNS, dynamic IPs and the like, you NEED hamachi.
Hamachi is free and works with Linux and Windows. There is an OS X version, but it's console based. The Linux version is console based too, but I won't be looking to try the OS X version until they get a GUI around it. Hamachi works by establishing a connection from you to the Hamachi servers. Once your Hamachi clients come online, the Hamachi server steps out of the picture leaving you with a FAST, secure VPN. I generally don't like solutions that require a third party like this, but it really does work well. They assign you an IP in the 5.0.0.0/8 network, so they have lots of address space and you could even set up DNS entries to your assigned IP.
The setup is horribly simple, even on Linux. I won't get into all of that here, but the possibilities are endless and have re-opened many scenarios for me. Network games, file sharing and remote administration suddenly become much easier to implement with Hamachi. If you've ever struggled with port forwards, dynamic DNS, dynamic IPs and the like, you NEED hamachi.
(Page 1 of 1, totaling 13 entries)
