June 2009 Archives

Recently I've bought and installed a Super Micro server (The usual raid-1 and IPMI configuration) but was puzzled by a rather odd problem: The IPMI card worked and I could control it via web interface. But neither ipmitools nor Supermicros own configuration system works.

After a quick talk with the support the problem was quite obvious: Turns out that the older IPMI firmware has a known bug that makes it impossible to use anything but the web interface. Unfortunately for me, the CD I got with the package had the old firmware.

As always, open the following ports:
 
UDP Port 623 for IPMI protocol
TCP Port 80 for Web User Interface
TCP Port 443 for KVM Over Lan
On the Client side you need to open UDP Port 6666 for Text Console Redirection

However, I must say I'm impressed by Supermicros internationall support. Quick replies, polity and accurate.

Recently my 3G mobile internet has begun to fail at an increasing rate. Basically, it doesn't fetch a IP and hangs at "Authenticating". I enabled verbose logging (OS X - System Preferences - Network - Huawei - Advanced - PPP - Settings: Configuration - Verbose logging)

And checked the logs (Application - Utilities - Console - /var/log/ppp.log) and found:

Mon Jun 29 19:06:22 2009 : sent [IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
Mon Jun 29 19:06:25 2009 : sent [IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
Mon Jun 29 19:06:28 2009 : sent [IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
Mon Jun 29 19:06:31 2009 : sent [IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
Mon Jun 29 19:06:34 2009 : sent [IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
Mon Jun 29 19:06:37 2009 : sent [IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
Mon Jun 29 19:06:40 2009 : sent [IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
Mon Jun 29 19:06:43 2009 : sent [IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
Mon Jun 29 19:06:46 2009 : sent [IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
Mon Jun 29 19:06:49 2009 : sent [IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
Mon Jun 29 19:06:52 2009 : IPCP: timeout sending Config-Requests
Mon Jun 29 19:06:52 2009 : sent [LCP TermReq id=0x2 "No network protocols running"]
Mon Jun 29 19:06:55 2009 : sent [LCP TermReq id=0x3 "No network protocols running"]

Basically, timed out. Talking to support they didn't see any problems. They thought it was a drivers related problem. But since I couldn't connect on Windows either (via parallels) I thought it might be a hardware problem.

Here's the tricky part: I have a spare Huawei E220, but locked on another provider. Thus I needed to unlock it to even try my hardware problem thesis. Turns out unlocking Huawei E220 was quite easy, a lot easier that up to date cellphones from Nokia or Sony Ericsson.

I won't go into the deails of unlocking here (not sure about the legality about describing the process) but it's pretty clear-cut and can be found on Google.

Turns out I was right, hardware indeed. And now I can connect again.  

For a client of mine we've been using mobile sync. To send the settings we use OTA OMA. Basically we make a XML file with settings, convert to WBXML. A good start guide can be found on http://mobiforge.com/developing/story/email-configuration-sms

I've found that sony ericsson phones (unlike Nokia) is more touchy on how to send username+password for sync (w5 type) application. This is a OK XML for SE+Nokia:

"<?xml version=\"1.0\"?>"
"<!DOCTYPE wap-provisioningdoc PUBLIC \"-//WAPFORUM//DTD PROV 1.0//EN\" \"http://www.wapforum.org/DTD/prov.dtd\">"
"<wap-provisioningdoc version=\"1.0\">"
"<characteristic type=\"APPLICATION\"> "
"    <parm name=\"APPID\" value=\"w5\"/> "
"    <parm name=\"NAME\" value=\"Radarspot LAB\"/> "
"    <characteristic type=\"APPADDR\"> "
"     <parm name=\"ADDR\" value=\"www.radarspotlab.com:8080/funambol/ds\"/> "
"    </characteristic> "
"    <characteristic type=\"APPAUTH\"> "
"     <parm name=\"AAUTHNAME\" value=\"%s\"/> "
"     <parm name=\"AAUTHSECRET\" value=\"%s\"/> "
"    </characteristic> "
"    <characteristic type=\"RESOURCE\"> "
      "<parm name=\"URI\" value=\"card\"/>"
      "<parm name=\"NAME\" value=\"Contacts DB\"/>"
"     <parm name=\"AACCEPT\" value=\"text/x-vcard;2.1,text/vcard;3.0\"/> "
"    </characteristic> "
"  </characteristic> "
"</wap-provisioningdoc>";

(Forgive me for the quotes, it's copy/past)

Google is writing about the Plausible Promise:

"When you start community-building, what you need to be able to present is a plausible promise. Your program doesn't have to work particularly well. It can be crude, buggy, incomplete, and poorly documented. What it must not fail to do is (a) run, and (b) convince potential co-developers that it can be evolved into something really neat in the foreseeable future."

It's a good read for any open source developer (or community builder for that matter) and is found here

This is a mental note to myself. Somethings using pre-installed VPS the PHP executed by Apache is lacking the necessary permissions to run binary files (shellscript and built-in commands works fine though). It doesn't generate errors, it simply doesn't work.

Those VPS often has the PHP-CGI version installed and thus you can:

1. Make your PHP script execute a shell script
2. Init the shell script with PHP-CGI
3. Execute

This is how the shell script in step 2 looks like:
#!/usr/bin/php
<?
exec('/home/user/www/mybinaryfiletoexecute');
?>

Note that the binary file must be in your www-dir.