Google killing XMPP federation with their Google Hangouts?

Leave a reply

According to the Ars Technica article on Hangouts, we can expect Google to drop support for XMPP federation.

We should apparently be happy that Google is not dropping XMPP client-to-server connections.

The instant messaging space is apparently turning into a duopoly of Microsoft’s Skype and Google’s Hangouts with everyone else shoved to the sidelines. I’m not counting Facebook Chat as a serious alternative, and iMessage is not intended as an instant messaging service.

I hopefully don’t have to point out how much this frustrates and annoys me. Google is turning out to be worse than Microsoft ever was: they’re actively backpedaling on their past promises. They’re backstabbing the “open”. Scratch that — they’re throwing a stake through open’s heart, ripping it in pieces, then gorging on its still beating remains. Instead of reading RSS through Reader, we’re supposed to read custom posts via the closed and locked down Google+. They are killing iGoogle. They’re basically killing the open web and open Internet, while at the same time paying lip service to open.

Android, which is just-enough-Linux-but-not-really. Rich authorship markup, which requires two-way linking to Google+ instead of using the semantic web techniques.

I’ll keep on looking for ways to back out of Google ecosystem as much as possible. What’s next — Gmail that can’t send emails out?

Routing IPv6 traffic through Debian pptpd into Hurricane Electric's IPv6 tunnel

1 Reply

This is a repost of an answer I made to my own question on SuperUser (the “non-programmer” Stack Overflow) regarding setting up pptpd under Debian to route IPv6.

In the post, I’m also looking into using this under Mac OS X 10.8 Mountain Lion. I fully understand that PPTP is an insecure protocol and have separately also set up OpenVPN. However, I’m looking at this because PPTP is much more ubiquitous than OpenVPN and it’s easier to set up at both server and client side; no playing with certificate authorities, no playing with distributing configuration files to clients, etc. (Yes, I’m highly annoyed at the OpenVPN client for iOS not supporting the static key setup. Yes, I understand static key is less secure. No, I’m not dealing with stuff that require total and complete anonymity or encryption; I just want a VPN to work.)

This post does not deal with routing the segment through OS X once you got it to OS X.

This post only minimally deals with Windows as a client, because it Just Works™, and does not deal with GNU/Linux as a client, because it didn’t “magically” work under Ubuntu when I tried it, and I am not interested enough to figure out why.

Main goal here is documenting what an OS X user who has access to a Debian server with a public IP needs to do in order to get his OS X machine onto public IPv6 Internet without exposing it to public IPv4 Internet.

Client OS

Mac OS X does not particularly like IPv6 over PPP. Use the following after the connection has been set up:

sudo ipconfig set ppp0 AUTOMATIC-V6
sudo route add -inet6 default -interface ppp0

The prior seems to make OS X adhere to router advertisements; the latter adds a default route for IPv6. (Now, if only the certain-fruity-mobile-operating-system version of route provided -inet6, I’d be a happy wooden boy.)

Also take note that OS X will ignore whatever address was supposed to be negotiated over IPv6 and set up only a local address. This may interfere with routing towards OS X.

On the other hand, Windows 8 (of all systems!) has happily picked up the address sent over PPP, took note of the router advertisement, and overall configured itself flawlessly. PPTP really works nice in Windows.

Server

First thing I missed was that Hurricane Electric’s tunnel broker actually assigns TWO /64 prefixes; one is supposed to be solely for client use, while the other is intended for routing additional clients (such as the PPTP client). And if you need more addresses (or prefixes!), you can even get a /48 prefix. (With IPv6, this means there’s more bits for ‘your’ use; HE’s prefix takes ‘only’ 48 bits. So that provides you a few more bits to control before the auto-generated suffix, created from a MAC address or even created randomly, kicks in and takes over last 64 bits. You could theoretically wiggle and subnet even with only 64-bits to spare, but I’ve seen strange behavior on either Windows 8 or OS X, so I wouldn’t rely too much on that.)

Instead of configuring radvd directly and running it as a server — simply don’t configure it globally. That is, don’t run it as a service on Debian.

Instead, let’s follow Konrad Rosenbaum’s example, at Silmor.de, and have radvd configured after pppd creates the PPP interface.

  1. Set up your IPv6 connectivity. I use Hurricane Electric; I’ve configured it as follows: 
    # hurricane electric tunnel
# based on: http://www.tunnelbroker.net/forums/index.php?topic=1642.0
auto he-ipv6
iface he-ipv6 inet6 v4tunnel
    address 2001:470:UUUU:VVVV::2
    netmask 64
    endpoint  216.66.86.114
    ttl 255
    gateway 2001:470:UUUU:VVVV::1
    ## from http://lightyearsoftware.com/2011/02/configure-debian-as-an-ipv6-router/
    # I did not set up the routing of the /64 nor the /48 prefix here, but
    # this would ordinarily do it.  
    #up ip link set mtu 1280 dev he-ipv6
    #up route -6 add 2001:470:WWWW:VVVV::/64 he-ipv6

    # Note that Hurricane Electric provides different /64 IPv6 prefixes
    # for the client (UUUU:VVVV) and routing (WWWW:VVVV). 
    # And the /48 prefix is very different altogether.

  2. Install pptpd. (Of course, take note of PPTP’s insecurity as a protocol, and consider using OpenVPN or some other alternative.)

  3. Edit /etc/ppp/pptpd-options 
    name pptpd
refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
require-mppe-128
proxyarp
nodefaultroute
lock
nobsdcomp
ipv6 ::1,::2

    Note the last line is different from the text in my question. You’re assigning some static addresses which may be respected by your client OS or not. (OS X seems to ignore them, but Windows uses them.)

  4. Create users for PPTP. Second column filters based on name argument in pptpd-options. Edit /etc/ppp/chap-secrets: 
    ivucica pptpd AHyperSecretPasswordInPlainText 10.0.101.2 10.0.101.3 10.0.101.4

    You’re supposed to be able to replace the addresses with * instead of listing them manually. I did not try that out.

  5. Assign your PPTP users some IPv6 prefixes. NOTE: this is solely used by the script I’ll list below, which is derived from Konrad’s script.

    Edit /etc/ppp/ipv6-addr:

    ivucica:1234
littlejohnny:1235
  6. Add new file /etc/ipv6-up.d/setupradvd: 
    #!/bin/bash
ADDR=$(grep ^$PEERNAME: /etc/ppp/ipv6-addr |cut -f 2 -d :)
if test x$ADDR == x ; then
 echo "No IPv6 address found for user $PEERNAME"
 exit 0
fi

# We'll assign the user a /64 prefix.
# I'm using a Hurricane Electric-assigned /48 prefix.

# Operating systems seem to expect to be able to assign the 
# last 64 bits of the address (based on ethernet MAC address
# or some other identifier). So try to obtain a /48 prefix.

# If you only have a /64 bit prefix, you can try to assign a
# /80 prefix to your remote users. It works, but I'm only now
# trying to enable these users to have routing.

USERPREFIX=2001:470:XXXX:$ADDR
USERPREFIXSIZE=64
USERPREFIXOURADDRESS=1
USERPREFIXUSERADDRESS=2

# Add the address for your side of the tunnel to the PPP device.
ifconfig $IFNAME add $USERPREFIX::$USERPREFIXOURADDRESS/$USERPREFIXSIZE

# establish new route
# (when a packet is directed toward user subnet, send it to user ip)
route -6 add $USERPREFIX::/$USERPREFIXSIZE gw $USERPREFIX::$USERPREFIXUSERADDRESS

#generate radvd config
RAP=/etc/ppp/ipv6-radvd/$IFNAME
RA=$RAP.conf
echo interface $IFNAME >$RA
echo '{ AdvSendAdvert on; MinRtrAdvInterval 5; MaxRtrAdvInterval 100;' >>$RA
echo ' prefix' $USERPREFIX::/$USERPREFIXSIZE '{};' >>$RA

# Instead of your DNS...
#echo ' RDNSS $USERPREFIX::$USERPREFIXOURADDRESS {}; };' >>$RA
# ...try assigning the Google DNS :)
echo ' RDNSS 2001:4860:4860::8888 {}; }; ' >> $RA

# The creation of radvd configuration could be more readable, but whatever.

# Start radvd
/usr/sbin/radvd -C $RA -p $RAP.pid

exit 0

    Don’t forget to chmod the script to make it executable by pppd:

    chmod 755 /etc/ipv6-up.d/setupradvd
  7. The script spews radvd configuration into /etc/ppp/ipv6-radvd/… ensure that the folder exists! 
    mkdir /etc/ppp/ipv6-radvd
  8. Also add /etc/ppp/ipv6-down.d/setupradvd (and make it executable!) — taken verbatim from Konrad: 
    #!/bin/bash
RAP=/etc/ppp/ipv6-radvd/$IFNAME
kill `cat $RAP.pid` || true
rm -f $RAP.*

    And

    chmod 755 /etc/ppp/ipv6-down.d/setupradvd

I have not tested using DHCPv6 to distribute the routing information, addresses or DNS information, especially since rtadv should be fulfilling these roles. It also would not help me, because as of Mountain Lion, OS X still does not ship with a DHCPv6 client (perhaps intentionally; nine out of ten dentists most of IPv6 experts agree that DHCP is evil).

Once again, please note Michael’s comments on PPTP security; consider using OpenVPN in production.

Yes, Konrad Rosenbaum also has a nice tutorial on IPv6 over OpenVPN. 🙂

A simple WiX template for games

Leave a reply

Over the last few days, I’ve got some comments and emails about my old, old post about WiX in which I promised to release a functional template.

Since that work with WiX was originally done for some games, and in the meantime I began working with OS X most of the time, it took “a while” for me to grab some time and remove company branding, create a sample project, and finally prepare and release the template for my own as well as other people’s use.

You can the template from its Bitbucket repository . Have fun!

Core Data: Migrating ignores manual mapping model (or fails migration) despite mapping model's existence

Leave a reply

Let’s say you created a somewhat complex migration model. Among other things, let’s say it includes entity migration policies (you know — subclasses of NSEntityMigrationPolicy).

However, Core Data ignores your manual migration model. Why, oh why?

You can try looking into this by clicking on schema name in Xcode 4, picking the “Run” sidebar ‘tab’, picking the “Arguments” tab, and adding -com.apple.CoreData.MigrationDebug 1. (See tech note TN2124.)

Alright, so now you see what the source persistent store’s version hashes are, and what the expected destination store’s version hashes should be. Then you see how Core Data starts migration by telling you its conclusion about what the hashes are (for the second time). Finally, it starts iterating over your manual mapping models (the .xcmappingmodel bundles).

And then you see that it finds your mapping model, picks up on it, then decides the hashes are wrong and ignores it!

“What the…?” you wonder. You compare hashes, and they are listed in different order, but essentially the same.

I can only conclude this is a bug in Core Data (or in the entity editor in Xcode4).

Luckily it’s easy to remedy! Go to the mapping model, pick another source and destination model version, then restore to the correct source and destination model versions. Definitely do make a git commit prior to making this change so you can compare what happened.

Alternatively, an answer on StackOverflow has a different solution which can be applied in case you know what is the version of the original persistent store. It involves manually setting version hashes on the NSEntityMappings inside the NSMappingModel.

Patching an unrecognized selector into a misbehaving OS X app

Leave a reply

Let’s say you have an app that misbehaves. As in, it raises an exception mentioning an unrecognized selector.

Of course, it’s third party and closed-source.

But you are an enterprising young developer and you really want to patch this app.

I will not identify the app that I patched, to avoid any impression that I’m cracking the app. (It’s a popular app and I’ve run into pretty nice anti piracy protection blocking gdb on multiple layers. Since I’m not familiar with cracking and was not even attempting that, I’ve decided that it’s best to simply avoid mentioning the app name.)

Makefile

all: misbehavingappfixer.dylib

misbehavingappfixer.dylib: misbehavingappfixer.o
        gcc \
                -dynamiclib \
                -undefined suppress -flat_namespace \
                misbehavingappfixer.o \
                -framework Cocoa -o misbehavingappfixer.dylib
run:
        DYLD_FORCE_FLAT_NAMESPACE=1 DYLD_INSERT_LIBRARIES=`pwd`/misbehavingappfixer.dylib /Applications/Misbehaving\ App.app/Contents/MacOS/Misbehaving\ App

misbehavingappfixer.c

#include 
#include 
static CFStringRef nameImp(id self, SEL _cmd)
{
        return CFSTR("IVFlawedClass");
}

void inject_init(void) __attribute__((constructor));
void inject_init(void)
{
        Class _IVFlawedClass = objc_getClass("IVFlawedClass");
        if(!_IVFlawedClass)
        {
                printf("Could not find IVFlawedClass");
                return;
        }

        SEL nameSel = sel_registerName("name");
        class_addMethod(_IVFlawedClass, nameSel, (IMP)nameImp, "@@:");
}

I avoided using Objective-C because I had some issues when I tried going that route. It should work, but I didn’t want to spend any more time on this than I already have.

Now, to use this:

make
make run

This will compile the fix dylib, and then launch the Misbehaving App while first preloading our fix dylib.

For more information, see these:

Note: from comments on Mike Ash’s post, it seems that since I’m not overwriting symbols, I don’t need to (and, more importantly, *should* not) be using flat namespace. That means, I should not be using DYLD_FORCE_FLAT_NAMESPACE and -flat_namespace.

But, it works for me, so what the hell. 🙂

Movie to animated gif

Leave a reply

To get an animated gif from a movie, I do this:

ffmpeg -i themovie.mov themovie-%02d.png
convert -verbose +dither -layers Optimize themovie*.gif GIF:- > themovie.gif

convert comes from ImageMagick. I could/should pass some more stuff to ffmpeg and convert, such as -s to resize and -r to change FPS of the PNGs, or -resize to resize the output gif.

More info in this gist.