[SOLVED] Device or resource busy when connecting to a tun device
This is my first post here, so my apologies if this question isn't in the proper forum. I've got an OpenEmbedded installation running on a Taskit board with an ARM processor. I'm running kernel 2.6.31 with some proprietary code that's using the tun device driver. For the record, I've been following the tutorial at backreference *DOT* org *SLASH* 2010/03/26/tuntap-interface-tutorial/ (sorry for the workaround, I didn't know any other way that I could post a link since my post count is less than 15).
My application is trying to connect to a pre-existing interface, "tun0", that has been created by root. My code first opens /dev/net/tun (which has read/write permissions for all users, per the tutorial). Next, I set the device name (tun0) and the "IFF_TUN" flag in the ifr struct, before finally making the following call:
This code works fine on multiple CentOS machines that I have (I'm not certain what kernel version they're running, but I'm pretty sure it's earlier than 2.6.31). But whenever I run it on my OpenEmbedded installation, I get the error "Device or resource busy." This application is running as root and 'lsof | grep tun' yields no result (indicating that no other process is accessing any device/file relating to tun).
ioctl(fd, TUNSETIFF, (void *) &ifr);
I've attempted creating the tun0 interface with 'tunctl -t tun0' as well as with 'openvpn --mktun --dev tun0'. Both seem to successfully create the interface as it shows up in ifconfig. I can even ping it. But in both cases (whether I use tunctl or openvpn), I get the same error when running my application. I've also tried letting my application create the interface (from my understanding, the same code that connects to an interface will create it if it doesn't exist). I've even gone so far as to try everything with tun driver support compiled into the kernel as well as modularized (same result in each case and combination).
I feel like I've hit a brick wall, exhausting all of the possibilities. In my limited experience, this really seems to be an issue with the kernel. There obviously aren't any external dependencies with the tun driver, and as this is a significantly scaled down installation, I don't see there being any conflicts. Does anyone have any idea of what might be going on? Is there something I'm missing? Does anyone know of a bug relating to Tun driver support in 2.6.31?
ANY help and suggestions are much welcome at this point. Thanks in advance!