I thought I’d let everyone know that I upgraded my iPhone 3G to iPhone OS 3.0 yesterday and tethering Just Works™ over both Bluetooth PAN and USB. In fact, it’s much simpler to use than I expected.
I have an original 6G data plan with Rogers and according to their FAQ, this is a supported feature and I am not going to get a multi-thousand dollar bill next month. 
Since I will eventually be implementing OpenID in a commercial project, I thought I would go ahead and set myself up properly.
There are now a few free OpenID providers and I have setup my own account with VeriSign Labs Personal Identity Provider beta. Of course, I do not wish to expose the actual provider as my OpenID: what if I lose trust in them or they simply stop offering the service one day?
The solution to this is actually quite simple and allows you to use your own domain as your personal OpenID, exactly what I needed. The technical term is delegation and is fully documented. To implement this trick using WordPress, simply edit your themes header.php and add two meta tags. Of course you can do this with your software of choice, or even plain vanilla HTML. This is what I added to my blog:
<link rel="openid.server" href="https://pip.verisignlabs.com/server"> <link rel="openid.delegate" href="https://adam.sherman.pip.verisignlabs.com">
The above indicates that my personal OpenID is being delegated to https://adam.sherman.pip.verisignlabs.com which is hosted by the server https://pip.verisignlabs.com/server. Since the page at http://sherman.ca/ contains the above tags, I can now go to any site supporting OpenID (look for the logo: 
) and simply use sherman.ca as my identifier.
I believe that OpenID’s time has come and I look forward to implementing it for some of my clients in order to give their users the ability to consume services without a registration page.
Since I have run into problems similar this fellow, I thought I would link to the original page and reproduce the instructions here:
# dscacheutil -flushcache
Very useful tip.
This afternoon I quickly setup enough infrastructure on my test server to enable it to use Multicast DNS to resolve local names and answer local queries. Multicast DNS is part of the Zeroconf specification, which Apple has implemented and refers to as Rendezvous.
In order for this to work, your system needs to both answer and perform multicast DNS queries. The two pieces you need for this are:
As of 0.3, nss-mdns is already Debian-ready, simply build a package executing fakeroot dpkg-buildpackage from the unpacked tarball. There is an mDNSResponder package in Sarge which is rumored to be removed shortly due to license problems with APSL, so grab a copy soon.
Once these are installed, simply add mdns to the hosts line of /etc/nsswitch.conf and you’re done.
You will now be able to resolve “.local” hosts from your Debian system and also resolve this system’s hostname on other local hosts. By editing /etc/mdnsresponder/mDNSResponder.conf, you can advertise any service you want.
Some days I wish I had way more energy in order to explore all the technology I’m interested in.
How does JXTA figure in relation to JINI?
Dan Creswell’s post about JINI not being RMI brought JINI back to the forefront of my technology todo list. This stuff is cool.
I just read Debian on Soekris HOWTO and was wondering if there are any additional steps one should take to ensure proper functioning of a Debian system running from a CompactFlash card. For example, would logging and other hammering reduce the life of the card in any significant fashion? Is it worth the hassle of going to a read-only root filesystem on the card?
Since my previous posts (1 & 2) about using IPsec in tunnel mode to securely connect multiple networks (I’m up to 17 on the same gateway.), I have needed to add support for “road warriors”.
While IPsec has low overhead, even in tunnel mode, it requires a lot of effort to configure for use by mobile clients. First, we must now assume NATs in the field; whether they are behind the now omnipresent home gateways or on public wireless networks. Secondly, it is my experience that using a VPN system based around bridging has many advantages:
I will elaborate on the routing issues. In our setup, our main gateway connects to 17 remote networks via IPsec. In order for a remote client to access a remote network, both the client and the remote gateway must have the correct routing table.
In light of the above, I decided to use OpenVPN. It fulfills my main objectives: simplicity and security. Correctly setup, OpenVPN will perform verification against both the client and server certificates and uses very strong crypto. To set this up you will need a PKI (Public Key Infrastructure).
My server-side configuration:
ca /etc/ssl/certs/ca.crt
ccd-exclusive
cert /etc/ssl/certs/gw.domain.ca.crt
client-config-dir ccd
client-to-client
dev tap0
dh /etc/ssl/dh2048.pem
float
group nogroup
keepalive 10 120
key /etc/ssl/private/gw.domain.ca.key # This file should be kept secret
local 66.46.199.130
passtos
persist-key
persist-tun
port 1194
proto udp
push "route 10.100.0.0 255.255.0.0"
server-bridge 10.100.0.1 255.255.255.0 10.100.0.90 10.100.0.100
status openvpn-status.log
user nobody
verb 4
My client-side configuration:
dev tap0
remote gw.domain.ca
tls-remote gw.domain.ca
pull
nobind
passtos
float
tls-client
ca ts-ca.crt
cert adam.crt
key adam.key
keepalive 15 45
persist-tun
persist-key
verb 2
Note the tls-remote directive. This is critical to ensuring that the client verifies the identity of the server.
My previous post promised some information about how firewall rules interact with IPsec under Linux 2.6, well here it is.
The Shoreline Firewall has full support for declaratively defining IPsec tunnels and hosts under the new IPsec support. To do this however, you will need the policy match netfilter extension from the Patch-o-Matic NG and also 4 other patches:
While these patches are in the POM-NG, they will not cleanly apply to linux 2.6.9. Ronald Moesbergen was nice enough to port the patches are are available from the list archive.
To apply the patches, simply run patch -p1 < ipsec-* from the top of our kernel source tree. Also copy the policy match extension’s files from the POM-NG directory into your kernel tree and insert the contents of the two .ladd files into the relevant Makefile and Kconfig file. Then reconfigure, enabling the policy match, and rebuild. Then follow the documentation.
If I have time, I’ll try and add some more information here.
Update: Howtoforge has a good tutorial about setting up “roadwarrior” VPNs using IPsec & KAME.
Since I was unable to find a clear description of setting up an IPSec-based VPN using the native IPSec stack from USAGI and KAME userland tools that are part of Linux 2.6.x, I thought I would post a short explanation.
Software
Network Topology
I am going to explain a very straightforward topology often found in the field. You have two networks, network A (10.0.0.0/24) and network B (10.0.1.0/24). Each network has router/gateway/firewall system, gateway A (10.0.0.1) and gateway B (10.0.1.1). Each of these gateway systems as an external, public, IP address: 3.3.3.3 & 2.2.2.2.
In this topology, our end goal is to allow a hosts on network A, say 10.0.0.123, to securely contact a host on network B, say 10.0.1.158, via an IPSec tunnel.
Note: In many cases, I will provide only a single example. You must ensure the other gateway is configured similarly, often by reversing the configuration. This is left as an exercise to the reader.
IPSec
Setting up IPSec involves two steps: keying and policy. Normally, you use racoon to provide keying and setkey to establish policy. I will instead use racoon-tool as convenient shortcut. This tool was written by the Debian Maintainer of the racoon package in order to emulate some of the nice configuration syntaxt of the FreeS/WAN, an older IPSec implementation for Linux. It dynamically generates a racoon.conf (/var/lib/racoon/racoon.con) and also sets up the policy based on a single configuration file.
First, we simply state that racoon should use the notify priority when sending messages to syslogd:
global:
log: notify
It is helpful to create a %default peer and connection in order to avoid duplication of configuration directives:
peer(%default):
verify_identifier: on
hash_algorithm[0]: sha1
encryption_algorithm[0]: aes
connection(%default):
src_ip: 3.3.3.3
The above src_ip directive simply says that our connections will be using our public IP.
Next, we define our peer, gatewayB, identifying it by address:
peer(2.2.2.2):
peers_identifier: address
Finally, we define a policy so that packets from networkA to networkB are encrypted via gatewayB:
connection(to-gatewayB):
dst_ip: 2.2.2.2
src_range: 10.0.0.0/24
dst_range: 10.0.1.0/24
admin_status: enabled
Unfortunately, I have no idea what the admin_status: enabled directive does, or even whether it is required.
You must also add a key to /etc/racoon/psk.txt for the remote gateway:
# Entry for gatewayB
2.2.2.2 0x2eba016ffc2314869ae9f9a3b8901a173242f0c8
A randomly generated key is best, and can be created with the following command:
$ dd if=/dev/random count=20 bs=1 | xxd -ps
(The xxd command is part of the vim package.)
Make sure that you can the racoon package configured to use racoon-tool by either editing /etc/defaults/racoon or reconfiguring the package. Also, you should probably reload the tool by executing /etc/init.d/racoon reload. You can then check that your policy is in effect by running setkey -DP. You should get something like the following, followed by a bunch of default policies:
10.0.1.0/24[any] 10.0.0.0/24[any] any
in ipsec
esp/tunnel/2.2.2.2-3.3.3.3/unique#16385
created: Nov 18 23:01:24 2004 lastused:
lifetime: 0(s) validtime: 0(s)
spid=1512 seq=9 pid=9800
refcnt=1
10.0.0.0/24[any] 10.0.1.0/24[any] any
out ipsec
esp/tunnel/3.3.3.3-2.2.2.2/unique#16384
created: Nov 18 23:01:24 2004 lastused: Nov 18 23:05:31 2004
lifetime: 0(s) validtime: 0(s)
spid=1505 seq=8 pid=9800
refcnt=1
Now that the policy is in effect, the kernel will ask the racoon daemon for a security association (SA), when it needs to deal with a packet matching the policy. Racoon will negotiate an SA with the remote gateway on the fly. (This will not happen until after we’ve setup the routing, below, but you can see it by using the setkey -D command.)
Routing
In order for a packet to match the policy we have setup, and also be forwarded to the remove gateway, we must adjust the routing table using the ip command (Provided by the Debian iproute2 package.).
The policy we have setup, says that packets coming from 10.0.0.0/24 and going to 10.0.1.0/24 must be encrypted and authenticated. This is achieved by adding a slightly weird entry to the routing table on gatewayA:
$ ip route add 10.0.1.0/24 via 2.2.2.2 src 10.0.0.1
And on gatewayB:
$ ip route add 10.0.0.0/24 via 3.3.3.3 src 10.0.1.1
Once you have added the new entries to the routing tables on both gateways, we test the tunnel. If you ping 10.0.1.0 from gatewayA, and then execute setkey -D, you will see the new SA that has been automatically created.
This is the routing table you should have on gateway “A”:
root@gatewayA:/tmp# ip route show
3.3.3.0/24 dev eth1 proto kernel scope link src 3.3.3.3
10.0.1.0/24 via 3.3.3.1 dev eth1 src 10.0.0.1
10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.1
default via 3.3.3.3 dev eth1
Followed by the routing table present on gateway “B”:
root@gatewayB:/tmp# ip route show
2.2.2.0/24 dev eth1 proto kernel scope link src 2.2.2.2
10.0.1.0/24 dev eth0 proto kernel scope link src 10.0.1.1
10.0.0.0/24 via 2.2.2.1 dev eth1 src 10.0.0.1.1
default via 2.2.2.1 dev eth1
In the above examples, 2.2.2.1 & 3.3.3.1 are the default gateways that connect your public networks. (The routers usually provided by your ISP.)
Note: if you have any firewall rules enabled, you are going to have hassles. Notice that the IPSec tunnel doesn’t have it’s own device: the encrypted packets are going through a public interface. This will confuse any firewall rules that expect to be able to categorize packets by interface. I intend to figure out a good solution and post it at a later date.
Update: I now have a fully working IPsec gateway/router/firewall. See this other post.
Update: It seems that when the external addresses of the gateways on are different subnets, which was not the case during my testing, you must add a route like ip route add OTHER_NETWORK via LOCAL_DEFAULT_GW src INTERNAL_IP. Otherwise, you will get an error: RTNETLINK answers: Network is unreachable. Please leave a comment if you can clarify this.
Corporate and personal communications is undergoing an obvious revolution right before our eyes. I won’t comment on this aspect of VoIP since there are so many doing so, particularly in the large news publications. However, we’re missing something: presence.
Instant messaging has boomed and become an almost integral part of our society, with youth leading this integration. Have we not noticed that this form of communication is almost entirely controlled by a select few corporations? To name a few:
This is all a Bad Thing™! Lets reminisce for a moment about good, old fashioned, email service. This technology is completely decentralized and relies on each entity having their own SMTP system. If I want to send you mail, I simply do a DNS lookup to find your mail server and off I go. This server can either be provided by your ISP, out-sourced to another provider or you may have set it up internally.
Contrast this with IM, where your messages are being routed by a third-party who:
To actually start discussing VoIP now, the above prevents good presence for VoIP applications.
Thankfully, the defacto VoIP protocol, SIP, has full support for an SMTP-like distrbuted model using SRV records in DNS. This allows the DNS system to be queries for the correct SIP server for a domain and therefore gives us nice, convenient addresses for voice communications using the familiar “user@domain” form.
Built on top of SIP, there is SIMPLE or the S I M P L E. This upgrades your SIP infrastructure to support full presence and instant messaging capabilities. So far, I know of very few clients that have full SIMPLE support:
Also, I believe that Microsoft‘s Windows Messenger is available in a SIP edition.
A major open instant messaging protocol, Jabber, also has the above mentioned SRV capability. It seems to be under implemented in practice, however, with many people not even bothering. Jabber uses the XMPP protocol and bridges exist to allow SIMPLE to interoperate with it.
I’m rambling here. To get to the point, it seems that integrating SIP hardware devices : Analog Telephone Adapters (ATAs), like those from Sipura, and desk phones like those from Polycom; with presence provided either by SIMPLE or XMPP, is a problem. See, when you are using a great hardware phone for actual calling, you can’t do decent presence. How will my Jabber client know that I’m on the phone in order to set my status to “On the phone”?
My conclusion is that we should really be using softphones. Why not? Don’t we all have laptops and Bluetooth headsets? Well, I intend to get myself fully setup this way. To heck with all the other ways of getting voice service. Also, Jabber isn’t a great candidate unless you use something like the myJabber Instant Messaging Client for XMPP and myJabber AE Soft Phone combination, which is non-standard.
More to come on this topic once I get a copy of eyeBeam for Mac OS X to play with.
The Polycom SoundPoint IP are a line of very nice VoIP phones for business use. The current model line-up includes:
I setup five IP500s last week and hooked them up to an Asterisk system. Since Polycom doesn’t offer support to anyone not certified by them, more on that later, I relied on VoIP-Info and #asterisk to figure things out. The IP phones are extremely configurable, allowing you to change everything from the sampled sounds they make to very low-level adjustments to the units handling of RTP packets.
The sound quality of the IP500 units that we have is terrific. The built-in full duplex speakerphone is also very good, though not quite as perfect as the purpose built conference phone, also from Polycom, that is used in the boardroom.
The look and feel of these units is very professional, much more so than many of the other competing products we looked at. Paul thinks that this is an important aspect when selling to business clients. The units are also well-priced.
Something I am disappointed is the lack of LDAP directory support. While the phones have the ability to load an XML formatted directory from their boot server, they will not periodically update from it. It would be far more integrated to simply use an LDAP tree for this purpose as Cisco does, I believe.
More information on these great IP phones is available on the wiki and at PolycomEmergencyDialplan.
Last week I successfully setup a tunnel from my local network to Freenet6 Hexago I now have a /64 prefix of IPv6 addresses and am advertising them on my network using radvd This works great!
The next step is to get DNS working properly for IPv6 addresses.
Can a Customer take their IP’s with them?
Exerpt:
There has been a Temporary Restraining Order (TRO) issued by state court that customers may take non-portable IP space with them when they leave their provider. Important to realize: THIS TEMPORARY RESTRAINING ORDER HAS BEEN GRANTED, AND IS CURRENTLY IN EFFECT. THIS IS NOT SOMETHING THAT COULD HAPPEN, THIS IS SOMETHING THAT HAS HAPPENED. THERE IS AN ABILITY TO DISSOLVE IT, AND THAT IS WHAT WE ARE TRYING TO DO.
This is a complicated issue and is not as straightforward as the above message seems to insinuate. A colleague comments:
I am following this. It is not as simple as it seems, and in fact two things have not been pointed out yet. a) NAC is being compensated for this. b) As the court affidavit points out, NAC has previous history of blackmailing the client.
Some related information is here
Some protocols/routing daemons:
These people have a product that is MIPS based and very flexible, might be more interesting for than Soekris:
OLSR: