I finally got myself an iPhone - and am loving it. It's great how I can now sync my calendars, and address book to my phone without having to worry at all about having six clones of each event on my calendar (which of course, makes it rather difficult to tell what I'm actually meant to be doing that day). However, a topic that has come up a couple of times in discussion with a few friends is that of the iPhone SDK. I feel that the big question here is, "Do Apple have enough incentive to make a fully featured iPhone SDK?".
With a friend moving to work at a VoIP start-up that deals with having a client on mobiles that allows SIP calls to be made, the big discussion we have been having is whether the iPhone SDK will allow a VoIP client to be implemented on it. My initial feeling on this is, no - not initially. It's been documented in a number of places that Apple are taking call revenue from the networks on each iPhone that is sold. If this is true, then it would be against Apple's interest to actually allow a functional SIP implementation make it onto non-hacked iPhones - since they're going to lose money if users start making their calls via SIP rather than via the cell networks (this assumes that Apple get revenue based on all calls - not just based on the actual contract worth).
However, I can't say that I'm sure of this - Apple may only be taking their cut from the revenue that is generated from the subscription fee on each iPhone - rather than the additional calls, and in this case, they might feel that allowing users to utilise VoIP when they're in a hotspot area would be another cool feature that the iPhone can offer. They might also feel that a lot of the iPhone users aren't savvy enough to be using SIP very often - I guess something like Skype from hotspots (or iChat for voice, or Google Talk...) might be more popular with the less tech-savvy userbase. It's hard to call really.
Alternatively, Apple might just wait until the networks stop paying them revenue, and roll the SDK with better network support then, increasing sales on a device that they're no longer making such revenue on.
Either way, the iPhone really just slots in where a phone should, it works with wireless and a mobile-data mechanism without having to think about it at all (although I'd like an 802.1X implementation). Calendar data syncs, Mail accounts sync, my Music syncs, my contacts sync - it integrates with my (primarily Apple based) digital life very well.
I'm impressed with my iPhone - roll on the SDK so that I can start making it do even funkier things!
Last time I tried to run Asterisk on OS X it was on Panther (10.3), and it really failed to work. It seems since I last looked, things have come a long way. When rearranging how my personal VoIP was configured, I was looking for a simple SIP proxy - however, the only one I could find immediately was Java based, and lacking on a few features that I wanted. Hence, I decided to check out if there were any better Asterisk packages available. I found the packages over at mezzo.net, and wow. Not only does their Asterisk build work properly (Voicemail, IAX2, and SIP-wise at least), it comes with some really nice modules. For example, the res_bonjour module announces your Asterisk server out over your local LAN as a Bonjour service - definitely useful if you're trying to work out whether there's a facility for VoIP outgoing calls for something like calling out straight from Address Book. However, the best thing here is app_notify.
Now, when I receive an inbound call - app_notify is invoked on the Asterisk server, which sends a message to my Mac Pro. The listener on the desktop then pops up a Growl notification that I'm receiving a call. However, there's also a script interface to the notify app on OS X, one of the included scripts is to add an event to a calendar in iCal when you receive a call - great for being able to check when you received a call without having to dig out the Asterisk logs, or the recent calls list on your deskphone.
Even more awesome, is the fact that if your phone numbers are correct (i.e. domestic, rather than having the international prefix), the application looks up the number in the local address book, and puts this information in the calendar too!
Now, this is why we need VoIP. Integration between my phone and my computer SHOULD be this easy, it's great!
So, at the moment, I'm writing a presentation about the operation and the security implications of RFID. During the course of the random searches around the internet, I've found that there's a lot of really, really cool work going with respect to RFID. Even more great than the output on the subject is who is studying it. Lots of really cool observations are coming out of the open source friendly community - some of the best presentations on the subject are from presentations at CCC. Along with projects like OpenPCD, this output is pretty cool!
However, that's not really the point of this post. During the course of reading around, I've found that whilst there's a lot of information around - there's also a lot of FUD that surrounds that information. My presentation is trying to give people (with some physics background) a simple idea of what RFID is, and particularly how it works. Given that I've already done a quick summary of how RFID works, I figured I'd blog about it, so that I can add to the mush of material that you just can't reference online.
I'll discuss a high frequency system - since cards such as MIFARE (which e.g. Oyster uses) work at around 13.56MHz. The RFID system consists of two elements - the reader, and the tag. Tags come in a number shapes - active, passive, and semi-passive. Really, it's the passive tags that I'm interested in. The image below shows the anatomy of a (simple) passive tag. It's composed of an antenna - running around the card, an IC, and a substrate that they're both attached to.
The reader consists of a dipole-antenna, a transceiver, and some controlling electronics (this is hugely simplified, check OpenPCD for much more detail). Obviously, the consideration of the conversation between the reader, and the tag is the interesting part.
The reader emits a signal from a dipole antenna at a fixed radio frequency. The magnetic field of the signal induces a current in the dipole antenna loop of the tag - hence powering it on.
The tag is now powered up, and a capacitor in the tag is charged, the current is trapped using a diode. The resulting voltage across the capacitor powers up the IC within the tag. In the really simple case that we're considering - we'll assume that this tag just has a unique ID, and isn't doing anything interesting. The IC replays the unique tag ID (as a digital binary signal). The signal is fed into a transistor, causing the antenna to reflect/absorb more of the signal - hence modulating it.
The modulated signal shows variations in the frequency which are dependent on the way in which the transistor responded to the input from the IC within the tag. This results in a load-modulated signal - the trace below shows the frequency distribution of the reflected signal from the tag.
The RFID tag information is contained completely in the sidebands of the signal, and the figure above shows that compared to the reader-generated centre frequency - these are extremely weak. The 90dB difference accounts for some of the reason why RFID transmission range is so limited.
The modulated signal is received by the reader, where it is resolved into a tag ID.
This isn't exactly the most exciting part of RFID, but its the basics of how the technology works, in a fairly friendly format I hope, and without a spin that's trying to present any kind of agenda about RFID. There's a lot more interesting things to look at, and blog about on this subject, so I'll probably discuss those at some other time. But for the time being - I'm interested in this, and hope that this helps someone one day - questions/comments/corrections are welcomed to my mail address.
Since I've got a few moments, and I've decided to actually write down some rants rather than deciding that I can't be bothered to - I'm going to use some space to single the praises of Django.
I've been using Django for a couple of years now - since around the autumn of 2005, and as such, feel that I've got a pretty good grasp of how the framework works. I haven't really hacked around that much with the innards of Django (although I did propose a patch), however, what I really like about this framework isn't particularly the internals, but just the whole philosophy that there seems to be in terms of building a web application.
Let's face it, when you sit down to write a web application, especially as a sysadmin or a network engineer - your primary motivation isn't to write a web application, your motivation is to get some data out in a very easily readable format to some audience. So, you start looking at how your database should be designed (or retrofitting your code around an existing database), and you start writing code for updating one table, or grabbing data from another. Stop. This is where Django comes in. With Django, you just rapidly develop your data into a set of models, which can be related in a number of different ways - almost everything that you want to do (for generic data handling) can then be done straight from a generic Django view - without you having to go around writing a lot of code for really generic things. It really speeds up web application development.
I love the fact that Django has things like overloadable save(), and delete() methods for each model - it sounds fairly trivial, but it's great to be able to have the application create the ports on a switch when it saves it into the database the first time - and remove them when the user removes the switch. I've found myself able to work on really quite complicated model layouts without getting too tied up in it, because it's just a case of breaking it down simply into models.
I've got a couple of Django based projects that I'm maintaining (hint: you're reading one of them). The other is a portal system for Catalyst2. I've been working on this system for almost 2 years now - it started out as a PHP application, and then morphed into Django when I discovered it. As a PHP app it was just unmanageable, because of the amount of code that I was having to write. Django's inbuilt admin application has let me just worry about actually presenting data to users - and keeping the boring stuff (like adding data to simple database tables) out of the way of the application. It's become a pretty complicated application.
The system tracks ISP assets, things like racks, servers, switches, routers, cabling...the list goes on. For servers it can control APC MasterSwitches via SNMP, it integrates into cacti for network graphs, it can access RANCID SVN repositories to obtain device configurations...I built an SNMP poller that collects traffic data, and produces billing data as both HTML and PDF. I've integrated it with our automated DNS and MX secondary system. The list is pretty huge (hence why this project is almost two years old!).
Before it sounds like I'm just trying to give a list of features that I've written into an application - I'll get to the point. Django and python's flexibility means that I've been able to sit down and write features, I haven't had to sit down and write a lot of generic type functions that add entries to a database, allow them to be updated, and then save them, I haven't had to handle how my site is going to be templated - I've written features. This is the massive difference for me using Django.
Sure, I could get this functionality with just about any framework out there - BUT, Django does this really well - there are very, very few things that you come across and say "Oh, I don't like that" that you can't change. I didn't really like the authentication system that it uses by default - no worries, I can just replace it with an LDAP authentication system for our users, and use the Django one to provide application-specific privileges. Django does things easily, in a sane manner, that you can just code for. What's even better, is it fits in with people like me - who just want to get an application out - but also it fits in with those guys who want to produce just the frontend part of the system - the templating language allows really simple creation of complex pages, without a steep learning curve.
I didn't really plan this entry before I started, but I hope I've got across what I actually wanted to say, Django is a really great framework that's very, very flexible. It's also getting better, they're carefully considering what's added to it, and keeping it so that its very database neutral, and can fit into many, many development styles.
I've written >5,000 lines of just python code in my Django applications, and I'm still finding new and cool things that the framework can do - I really do recommend it for web application RAD!
I've been working on a number of bits of code recently, and have found that it's not entirely practical to check into RCS or SVN for every change that I've made. I really like to work by committing when I've finished adding a feature to a script, or a project. Hence, I've been using the vim "set backup" option. However, this has some limitations, and hence I decided to have a look at what .vimrc could do for me.
set backupdir=~/.vimbackup/
let d = strftime("-%d%m%y-%H%M")
let d = "set backupext=".d
execute d
set backup
Now I have backup files in ~/.vimbackup/ that reflect the time I started editing the file. This is quite handy if you, like me, :wq! and execute when testing. I'll probably need to write a script to cleanup ~/.vimbackup at some point though!
Following getting my roadbike back out for the first time in a while (been really busy since moving to Ealing!) I figured I'd look at if there's anything more about Di2 floating around. It seems the more I see of this system, the more I want it. Perhaps Orca with Di2 is something for 2009?
I've also started tracking my rides (mostly fixed, mostly to and from work at the moment) on this site, if there's any interest, I was pondering publishing the code/a webapp to upload other people's rides. I find that MotionBased is really tedious! Comments/emails welcome on this subject.
Last Friday, Andy Davidson, Jonathan Oddy, and I pushed out some research that has some quite worrying repercussions. Whilst I've heard from a lot of people privately about this matter, there's a big flaw here, and as Andy posted on his blog (which is much more informative than mine, I think!), this is a big problem.
The reason, I think, that we're getting limited public discussion of this exploit (I hesitate to call it an exploit, it's a flaw really, because it's actually a result of the RFC that the problem exists), is because the implementations of 4-byte AS support that are out there already are generally not standards compliant. Let's run down the list:
Juniper - not standards compliant on this matter, some form of AS4_PATH and AS_PATH munge happens during processing, and the paths don't come out with the confeds in. I've verified this by looking at the updates via a Goscomb Technologies Juniper box - look at the monitor traffic output.
Force10 - Greg Hankins has a test peering box running at route-server.cluepon.net, which shows the following
Received from :
72.37.255.12 (72.37.255.1) Best
AS_PATH : 18508 19151 35320 196629 23456
This looks to be doing the same thing as JunOS is doing, and ignoring the invalid parts of the AS4_PATH when building the AS_PATH.
Cisco - IOS XR/XE - I've not yet confirmed this one, but I believe this doesn't have a standards compliant implementation either. I'm hoping to get some time with someone to discuss what they're seeing later tonight, or maybe later this week. I think that, given that we haven't heard anything, and there are likely to be _some_ SPs that are learning 91.207.218.0/23 via 35320, this is probably another platform that doesn't comply.
Cisco - IOS - There's just one lonely IOS release that runs AS4 right now, and that's 12.0(32)S12. This is the IOS that we used to demonstrate how IOS reacts to the flaw in the RFC. When IOS sees AS_CONFED_SET in the AS4_PATH, it drops the session, as required by the RFC
Maybe there are a couple of interesting points here, why are most vendors not actually complying with this RFC, does this mean that they've spotted what Andy, Jonathan and I have reported on, and dropped this requirement? If this is the case, then I wonder, when IETF IDR is so full of people with @juniper.net, and @cisco.com addresses - why did this ever appear in the first place?
This is a serious flaw in the standards, and despite the fact that today, we reported on how the issue has actually come to pass, this is going to remain open, unless we fix the RFC.
The issue here is, with most (if not all) BGP attributes, there's almost an expectation that the immediate neighbour will sanity-check what their peer has sent - if it's one hop away, you can generally interact directly with that neighbour, and work out what the problem is, there's no-one harmed, as just one session is dropped, by two networks sharing some adjacency. A case in point of this, is the problem that we saw with Cisco not obeying the RFC relating to sending UPDATES before KeepAlives in BGP conversations (CSCsu84268). As far as I saw, this bug only affected directly connected neighbours, and hence there was no major impact. Now, let's consider what happens the case of the AS4_PATH problem we reported. AS4_PATH is optional transitive in BGP, hence, if you hand it to a non-AS4 speaker, the router will just transmit it along to the peers it advertises the route to. This is a reasonably neat solution, one would think, as AS4 information is transmitted, but it doesn't require every router in the path between two AS4 speakers to understand it, yet they can still get the same information as they could if the path was completely made up of AS4 speakers. Furthermore, by appending 23456 to AS_PATH, then even the non-AS4 speakers understand that there was some AS in this path. However, this also means that if I announce, to a non-AS4 speaker, a completely invalid AS4_PATH, they don't know anything about it, or the contents, and hence can't sanity check it. This results in me being able to tunnel my AS4_PATH across the internet.
Great, so now I've described, in some more chatty language, what we wrote on NANOG, and C-NSP. What does this mean to any operator? Well, if I take a prefix, originate it, and then announce it to the internet, then I can get the first AS4 speaker I find to tear down whatever session they learned my prefix on. If I combine this with injecting some ASNs into the path, so that some networks don't accept it (due to loop prevention), then I can probably work out a way to get _my_ copy of the update across to you. In IOS's logs, you can't even tell who originated that prefix, and it doesn't seem to show the whole AS_PATH/AS4_PATH either. Say I send two prefixes that you learn one via one transit provider, and the other via another, I'll disconnect your full table connectivity.
This isn't even a bug, this is a flaw in the standard. I'd really like to get this fixed, and the way to do that is to get a bunch of operator experience/views, and take it to the IETF. So, if this concerns you (or you're going to need to deploy a new point release -- like 12.0(32)S12 is, or maybe need hardware support with 12.2SRE...), please put some pressure on your vendor, or drop me a note at rjs@eng.gxn.net.
