Harrison Pham

I recently had AT&T Uverse installed. In order for Uverse to work, users must use a 2wire gateway that AT&T supplies. The gateway is great for most users, but unfortunately I use a complex network topology (VPN servers, etc) which requires that I have my own router.

Luckily the 2wire gateway has a feature called 'DMZPlus' which basically puts a host that you choose (in my case, a router running tomato) in DMZ. The 'Plus' part of the name means that the 2wire gateway will assign your public WAN address to your selected host via DHCP.

While this all sounds great, there is a known issue with the 2wire gateway refusing to save the DMZPlus setting. I spent a few hours debugging this issue and finally figured out the solution. It turns out that the 2wire gateway's method of doing DHCP isn't really compliant with any standards. This means that the super-secure iptables rules filtered out parts of the DHCP transaction, causing the 2wire gateway to get confused.

In order to fix this, simply add a rule to your iptables configuration to accept all incoming udp packets on port 68. Specifically, run this command: 'iptables -I INPUT -p udp --dport 68 -j ACCEPT'.

To keep this setting permanent (which is probably what you want to do), add this to your router's 'Firewall' script. This is available in most third-party firmwares including Tomato and dd-wrt. For Tomato, you can access this menu under Administration -> Scripts -> Firewall Tab. Paste 'iptables -I INPUT -p udp --dport 68 -j ACCEPT' in the firewall tab and click save.

DMZPlus should now work once you enable it in the 2wire router. Remember to perform a DHCP renew on your 'slave' router so it can grab the IP immediately.

A word of warning: The 2wire gateway will still be filtering certain ports. There is nothing end users can do about this, other than complain to AT&T about the issue. There is also a 1024 concurrent sessions limit, which is pretty low.

I'm starting a new project where I'll be making a standalone internet mp3 player. I listen to internet radio stations almost all the time and would love to have a way to enjoy those stations without my computer.

I've just ordered a VS1011 mp3 decoder breakout board from Sparkfun. I plan on connecting this up to a Propeller Chip running my custom TCP/IP stack, PropTCP. The Propeller will buffer the audio and feed the raw mp3 stream to the decoder chip.

The overall bandwidth required by this application is pretty low. A normal 96kbps Shoutcast stream only requires 12Kbytes/sec. A small 256kbit SPI SRAM chip should provide a nice 2.5 second buffer in case there is packet loss or severe network latency.

I also did a bit of research on the Shoutcast stream format and found out it isn't very well documented. Luckily it is quite simple and numerous people have 'reverse engineered' it. The stream itself runs on a HTTP-like protocol and uses embedded metadata sent every X bytes. More information about it can be found here.

I usually bash Comcast a lot because of their poor support and very weird package offerings. But today they formally announced an all-market speed increase for their two main packages. The 6000/384kbps package becomes 6000/1000kbps while the 8000/768kbps becomes 8000/2000kbps. This is an amazing increase, and probably took them a really long time to get ready for.

This brings them pretty much up to par with AT&T's DSL and Uverse offerings. I really felt that AT&T had the upper hand with their new VDSL deployments since it offered the fastest speeds for a really competitive price. They only held this status for a year before Comcast announced this speed increase.

I actually got this update on Monday when my modem rebooted as a result of the new config file push. I figured it was just one of Comcast's various random network updates and didn't check into it. I only noticed that they had increased the speeds when I read a news post on DSLReports. I got really excited and proceeded to test the supposed speed increase. Comcast disabled config file names in my modem log so I have to use a more scientific method of finding out my provisioned speed (speed testing).

I used WinSCP to upload a 3GB CentOS ISO to a server in Atlanta, GA and used SNMP to monitor my outbound connection speed. I was very pleased to see the speed stayed between 850 - 980kbps for the 1 hour I ran the test. In fact, I could upload at this speed without causing any delays to my other internet traffic. My gaming and VOIP packets had no added latency, which surprised me because I used to get +500ms latency in the past with my 384kbps upload provisioning.

I'm very pleased right now. I was very annoyed in the past about the lack of good upload speeds. Now I don't have anything else to complain about (that is, until I find a use for all this new found upload bandwidth). Maybe Comcast will push out a bump in the near future...

I have an old 1.8GHz Sony Vaio Desktop that uses a software controlled fan. Sony apparently thought it would be wise to just do everything in software, and would require you to install a Windows service to control the fans. The service was apparently a hack because it doesn't monitor the system temperatures. This lead to all sorts of system stability problems when the computer started getting older.

I've recently built a new computer to replace this aging desktop. I didn't want to waste good hardware so I decided to turn the old Vaio into a linux server.

I installed CentOS (which took ages because the dvd drive was all messed up). During the install, I noticed that the fan was insanely loud. The power supply fan combined with the cpu fan created a horrid noise that could be heard 2 rooms away. A quick search on google confirmed that old Vaios exhibited this fan problem. A few posts noted using something called pwmconfig. A little more research showed that this was a smart fan control configuration script that comes with lm_sensors.

I spent a while messing around with pwmconfig. The script had a flaw in it (it used tempfile instead of mktemp). A quick edit fixed that problem. I eventually gave up messing with smart fan control because I figured I could just use a fixed fan speed (like the method Sony decided to use).

So here is how I did it:

Install lmsensors:
yum install lm_sensors

Detect sensors:
sensors-detect

Run pwmconfig to get fan statistics (note which pwm channel controls which fan):
pwmconfig

Write a script to force fan speeds:

# Makes fan silentish
echo "Setting fan speeds...."
echo "125" > /sys/bus/i2c/devices/9191-0290/pwm1 # cpu fan
echo "75" > /sys/bus/i2c/devices/9191-0290/pwm2 # ps fan

Add the script to autostart on boot (I use console only, hence runlevel 3):
ln -s /root/fanquiet.sh /etc/rc3.d/S99fanquiet

A quick reboot of the system and everything should be working. If it doesn't work at all (no fans changing speeds), then you may need to check your i2c devices path, and make sure the lmsensors service is running.