Skip to main content


Showing posts from July, 2017

Automatically login to Guest Wifi on Cisco routers

If you're near a coffee shop with a free Wifi network with a guest login that uses a Cisco router, you can use a simple script to automatically login so you have free Wifi without any annoying login pages!

I reverse engineered the compressed JS of the login page to find out how login works (won't go into details it was a few years ago). Anyways, it turns out you can login with a simple curl request. Here's how.

Getting required parameters
First, manually connect to the Wifi, but don't login!.

Now run `ifconfig` or `ipconfig` to get the MAC address of the wifi card of your device and the ipaddress it assigned you.

The MAC address will be a series of hex separated by colons like:  `00:AB:CD:EF...`. Note this down.

The IP address will 4 sets of numbers  like ``.

Next get the guest password from the Coffee shop, usually they have them posted inside or just ask them (and buy a cup of coffee!).

Login command Now that we have everything login is pretty simple.

Creating your own iOS framework

It took a while to make xcode happy with my custom built Python for iOS framework for  enaml native.

Most of it was pretty straightforward (they describe it in their Anatomy of Frameworks docs). You need to simply create the directory structure  they give.

MyFramework.framework/ MyFramework -> Versions/Current/MyFramework Resources -> Versions/Current/Resources Versions/ A/ MyFramework Resources/ English.lproj/ InfoPlist.strings Info.plist Current -> A

Simple enough. Make a few folders add a few symlinks. Resources is optional, so skip that. Add it into xcode, link it, then either add it as embedded executable or create a copy files rule. Click run, all looks good. Then boom!

Failed to load Info.plist from bundle at path /Users/jrm/Library/Developer/CoreSimulator/Devices/76...FC/data/Library/Caches/…

Creating a single static or shared library (dylib) that supports multiple arches

OSX has a nice tool that takes static, dylibs, or shared libraries for different system architectures and can pack them into a single library that can be loaded on different hardware called `lipo`.

Not sure where the name comes from (I see people call the libraries it creates `fat` libraries but lipo is supposed to remove fat? Idk). Anyways it's simple to use:

lipo -output <file> -create <lib/arch1.dylib> <lib/arch2.dylib> # etc...

Use man lipo for more info

LIPO(1)                                                                LIPO(1)
NAME        lipo - create or operate on universal files
SYNOPSIS lipo  [-info]  [-detailed_info]  [-arch  arch_typeinput_file]  ...  [ input_file] ...  [-arch_blank arch_type]  [-create]  [-thin  arch_type]        [-replace  arch_typefilename] ...  [-remove arch_type] ...  [-extract arch_type]  ...    [-extract_family   arch_type]   ...    [-verify_arch arch_type ...]  [-output output_file] [-segalign arch_typevalue] ...

Fixing dyld: Symbol not found Expected in: flat namespace error

When trying to load Python on iOS within a framework I was getting the following error:

dyld: Symbol not found: _GENERAL_NAME_free   Referenced from: /.../data/Containers/Bundle/Application/D4..9D/
  Expected in: flat namespace
Expected in flat namespace? What? 
What's also interesting is that it would load fine if all the libraries were linked directly to the executable.  Well turns out it was giving the error when just liking to the Python.framework because that was only linking Python, not all the dependencies python has (libffi and openssl). 
I had the correct CFLAGS and LDFLAGS for including a dependency and headers so it compiled fine. But when it went to load, iOS didn't know where to find the dependent libraries!  Added in the missing " -l<lib>" flags, recompiled, verified with "otool -L" and all is good to go!
Happy coding!

Enaml Native - iOS support - Cross compiling python and extensions for iOS

I'm working on adding iOS support to enaml-native and the major step in doing this is cross compiling Python AND python modules for iOS.

Well after a few long nights over the past two weeks, I got it! Since I've spent literally days figuring this out. I thought I'd share my findings and how I fixed a lot of the roadblocks I ran into.

Please note this is for targeting devices with iOS 8 and up.  Older versions do not allow linking dynamic libraries on the App Store (at least thats my understanding).
Cross compiling Python for iOS Most of the existing "Python for iOS" and similar toolchains (ex kivy-ios and python-for-ios) compile everything as static '.a' libraries since old versions of iOS didn't allow dynamic libraries.

Well since iOS 8 (we're at 10.2 now?) this has changed and dynamic libs are actually now recommended to be used.

The only projects I found for building  Python as a shared library was this, which builds python 2.7.6 and says "…

Python library for Wavetrend L-RX201 Active RFID readers

I wrote a library for communicating with Wavetrend RFID tags in school.

It's been sitting on my computer collecting dust for several years so I thought I should share it as someone might want to use it.

Code on github:

Demo on youtube:


Introducing Enaml Native - Write native Android apps in python

In my recent post on react-native vs kivy, I suggested an alternative that bridges some of the concepts of each of the two projects together. Well, I decided to make one. The result is enaml-native.

What is enaml-native? The goal of enaml-native is to be the python version of react-native.  Or to change their tag line:
enaml-native lets you build mobile apps using only python. It uses the same design as enaml, letting you compose a rich mobile UI from declarative components.
How does it differ from Kivy or Rubicon? 

enaml-native borrows a lot from kivy, including pyjnius, and python-for-android. Much of the bootstrap code was based on kivy's implementation. However, unlike kivy, which includes it's own widget framework, enaml-native uses native widgets. Edit: enaml-native no longer relies on pyjnius. It now uses the JNI directly to improve startup times (or Websockets for remote debugging).

It differs from kivy and BeeWare's rubicon projects in that it uses a bridge, like…