BMW X5 manuals

Posted: October 30, 2013 in Uncategorized

I have been looking for a BMW X5 Service/Repair manual for a while and finally found workshopmanuals4all.co.uk – If you have a BMW and like to do maintenance/repairs yourself (as a hobby and a cost saving) go here – BMW Service Manuals

This is a usefulΒ titbit. I battled to delete a remote branch with the suggested

git branch -d -r remotebranch

Finally managed to do it using

git push origin :remotebranchname

Hope this helps someone else

IMSBench is a great tool to test the performance and scalability of your IMS platform. I’ve been using IMSBench in the lab for a while now and recently wanted to use it to simulate a real-world environment with 1000s of registered users doing various activities. The tricky part of this is trying to simulate a number of concurrently connected users each with their own unique IP address. IMSBench/sipp allows you to use a single IP address/port pair for each registration (in UDP mode only) but again, this is not realistic, especially when you want to properly test IMS core component, like PCRF. So I embarked on a way to simulate as many users as possible, all with their own unique IP address.

We managed to achieve what we were looking for by using Solaris zones, VLANning (not required but we needed it to support a massive block of users and still be route-able on our network). Basically for each Solaris zone (we can have many of these depending on hardware), we were able to configure 8000 (max allowed per interface is 8192) virtual IP addresses. Bear in mind that all these IPs are route-able on our network and as a result, “live”.

By default, the maximum number of IPs per interface on Solaris is 256 as can be seen using:

ndd -get /dev/ip ip_addres_per_if

You can bump this up to the max as follows:

ndd -set /dev/ip ip_addres_per_if 8192

The sipp test agents will therefore be able to use one of the 8000 IPs to register, make, or receive calls. If you want to add even more IPs, create a few more zones πŸ˜‰

One thing I haven’t yet tested is to create another virtual interface for the zone. Theoretically this will allow me to have 8192 virtual IPs per vnic….and multiple vnics per zone

So I spent a good amount of time today chasing my tail trying to find out why my IMSDroid would fail to register with my S-CSCF. Initially, I thought there was a problem on the S-CSCF side calculating the response from the AKA challenges. One of the worst things to have when debugging code is having and erratic failure, ie. inconsistent failures. My IMSDroid would register perfectly 19 times out of 20. It was that one failure that was concerning me. Was this memory corruption, authentication vector bug, etc?

The only way to debug this was to use the failed data and re-create the problem in a separate environment to eliminate as many variables as possible. So I wrote a small program to do only the AKAv1 Authentication (from the S-CSCF perspective – HSS and UE perspectives are obv. different sets of calculations).

Turns out that if the MAR from the HSS has an aothorisation key that has a 0-byte in the payload we get the failure. The reason is because a strlen(authorisation) will return a shorter length because of the 0 in the payload and thus affect the calculations. Specifically in this case the HA1 is corrupt (an MD5(IMPU:REALM:AUTHORISATION). So from the get-go you have the wrong HA1 and form there you are never going to generate the right response to authenticate the UE.

I will write Mamadou and co. at the Doubango team to resolve.

for now, onwards and upwards πŸ˜‰ – at least nothing wrong with our S-CSCF πŸ˜€

Boycott Apple

Posted: July 30, 2012 in banter

As most of my friends know, I am no fan of Apple. In fact they will probably see me as a huge Google punter. Actually I’m not….. well not really. What I am getting at here is that I am pretty fickle when it comes to tech. I generally choose what’s best for the job, but most importantly what is open. Integration and sharing within and between apps nowadays is paramount. So, back to Apple. I really dislike the company for various reasons that have been brilliantly articulated by someone else, called David Amerland. I’m posting his article here so I have a link to redirect my mates to when they give me a hard time πŸ˜‰

Boycott Apple
Beyond the simple kneejerk reaction of the #BoycottApple Β trend in response to the banning of the Galaxy Nexus, there are seveneight nine good reasons why Apple should be on the receiving end of some hard questions:

1. Control-freakery – it all started with Steve Jobs and his internal culture of fear. It continues, to a lesser extent, today.
2. Dubious production methods. From virtual slave labor conditions to a totally unempathic approach to doing business abroad. Apple’s changing the world in terms of style but not substance.
3. Overpriced. It is no accident that the company is so profitable. Their profit-margin is the sort which any business would die for.
4. Anti-competitive. They lock consumers into their ecosystem and developers out of it. They make it hard for you to port your data. Once the Apple shackles go on, boy they ain’t coming off.
5. Data hogs. They take your data, lock it into their verticals and never allow you to even see what they do with it.
6. Haters. Their approach to banning products until patent issues have been resolved has never endeared them to me. Particularly since Steve Jobs himself said that Apple was one of the greatest thieves of ideas.
7. Anti-social. They truly fail to ‘get’ social both as an enterprise and as a community. They think generating a wave of bad will against them is OK as long as they still make money.
8. No conscience. At a time when most companies work hard to integrate themselves in their communities and develop a social conscience, Apple remains conscience-free. h/t +Kershaw Rustomji
9. Environmentally unfriendly. Apple has repeatedly come under fire for its environmentally unfriendly production methods. I admit that here I do not know how they stack up against the competition but Google at least has become a trailblazer in its Green Data Canters. h/t +Chuck Fresh

Running some sipp tests today and I wanted to generate all usable IPs in the range 10.0.0.0/16. So here’s a nice bash script πŸ˜‰

for i in {1..254}; do for j in {1..254}; do echo 10.0.$i.$j; done; done

And here’s the code to append sequneitally this range to the end of each line in a file

#!/bin/bash
count=0
for line in $(cat reg_data); do
count=`expr $count + 1`;
j=`expr $count / 254`;
k=`expr $count % 254 + 1`;
if [ $k == 0 ]; then
k=1;
fi
echo $line';'10.0.$j.$k;
done;

A really useful tool I recently found is pips. prips will print all the IP adresses in a range/CIDR. To install, apt-get install prips

SIP-related RFCs

Posted: July 17, 2012 in SIP
Tags:

RFC 1950 – Deflate*
RFC 2246 – TLS
RFC 2429 – RTP Payload – H.263+*
RFC 2617 – HTTP Digest Authentication
RFC 2976 – The SIP INFO Method
RFC 3261 – SIP
RFC 3262 – Reliable 1xx Responses
RFC 3263 – Locating SIP Servers
RFC 3264 – SDP Offer-Answer Model
RFC 3265 – SIP Specific Event Notification
RFC 3267 – RTP Payload – AMR&AMR-WB
RFC 3311 – The SIP UPDATE Method
RFC 3320 – Sigcomp*
RFC 3321 – Sigcomp Extended Op*
RFC 3323 – A Privacy Mechanism for SIP
RFC 3325 – Asserted Identity
RFC 3389 – RTP Payload – Comfort Noise
RFC 3420 – message-sipfrag
RFC 3428 – SIP Extension for IM*
RFC 3485 – Sigcomp Dictionary SIP/SDP*
RFC 3515 – The SIP REFER Method
RFC 3550 – RTP/RTCP
RFC 3551 – RTP Audio/Video Profile
RFC 3581 – Symmetric Response Routing
RFC 3605 – RTCP attribute in SDP
RFC 3608 – Service Route
RFC 3611 – RTCP XR*
RFC 3680 – Registration Event Package
RFC 3711 – SRTP*
RFC 3761 – Enum
RFC 3764 – Enum registration for SIP AOR
RFC 3824 – Using E.164 numbers with SIP
RFC 3830 – MIKEY*
RFC 3840 – UA Capabilities
RFC 3841 – Caller Preferences
RFC 3842 – MWI Event Package for SIP
RFC 3856 – Presence Event Package*
RFC 3857 – winfo Event Package*
RFC 3858 – XML for Watcher Information*
RFC 3861 – im and pres Resolution*
RFC 3862 – CPIM Message Format*
RFC 3863 – PIDF*
RFC 3891 – The SIP Replaces Header
RFC 3903 – Publish*
RFC 3952 – RTP Payload – iLBC
RFC 3959 – Early Session Disposition
RFC 3960 – Early Media and Ringing Tone
RFC 3966 – The TEL URI
RFC 3984 – RTP Payload – H.264*
RFC 4028 – SIP Session-Timers
RFC 4091 – ANAT Semantics for SDP
RFC 4092 – Use of ANAT in SIP
RFC 4479 – A Data Model for Presence*
RFC 4480 – Rich PIDF*
RFC 4481 – Timed Presence Ext. to PIDF*
RFC 4482 – Contact Info. for PIDF*
RFC 4538 – Target Dialog
RFC 4566 – SDP
RFC 4567 – Key Mgmt ext for SDP*
RFC 4568 – SDP security descriptions*
RFC 4661 – XML Filters*
RFC 4662 – Resource List Subscriptions
RFC 4733 – RTP Payload for DTMF/Tones*
RFC 4745 – Common Policy*
RFC 4825 – XCAP*
RFC 4826 – Resource Lists*
RFC 4827 – XCAP Usage for Presence*
RFC 5025 – Presence Authorization*
RFC 5049 – Sigcomp and SIP*
RFC 5196 – UA Caps ext. to PIDF*
RFC 5261 – XML Patch Ops.*
RFC 5262 – Partial PIDF*
RFC 5263 – Partial Notify*
RFC 5264 – Partial Publish*
RFC 5367 – Embedded RL Subscriptions*
RFC 5389 – STUN*
RFC5411 – SIP (A Hitchhiker’s Guide)
draft-ietf-behave-turn*
draft-ietf-behave-turn-tcp*
draft-ietf-mmusic-ice*
draft-ietf-mmusic-ice-tcp*
draft-ietf-simple-xcap-diff – XCAP Diff XML*
draft-ietf-sip-gruu
draft-ietf-sip-outbound
draft-ietf-sipping-cc-transfer
draft-ietf-sip-xcapevent – XCAP event*
draft-zimmermann-avt-zrtp*