Digivation Hack Central

The watts clever envi has a USB serial adapter which is a Prolific pl2303. When inserted it is assigned /dev/ttyUSB0 by udev, among a few other symlinks. I have now obtained an RS485 serial adapter on ebay for A$13.98 delivered which uses the exact same chip, which makes it indistiguishable from the envi’s port. What I needed was a way to guarantee uniqueness regardless of the enumeration order on boot or random hot plugin. Naturally, this is for the Aurora GCI which will be installed when they become available in May.

Researching udev a bit, I found /lib/udev/rules.d/60-persistent-serial.rules (mine is a debian system). This file shows how the standard symlinks are done. Since each USB port is unique, I should be able to use that uniqueness to map another symlink to the device.

Firstly plug in the device in the chosen USB port and issue
udevadm info --query=all --name=/dev/ttyUSB1

This shows a heap of stuff but mainly we are interested in
P: /devices/pci0000:00/0000:00:1a.0/usb2/2-1/2-1:1.0/ttyUSB1/tty/ttyUSB1

Create a file in /etc/udev/rules.d/70-persistent-serial.rules which contains

#see /lib/udev/rules.d/60-persistent-serial.rules

ACTION!=”add|change”, GOTO=”persistent_serial_end”
SUBSYSTEM!=”tty”, GOTO=”persistent_serial_end”
KERNEL!=”ttyUSB[0-9]*|ttyACM[0-9]*”, GOTO=”persistent_serial_end”

IMPORT=”usb_id –export %p”
#IMPORT=”path_id %p”

ENV{ID_SERIAL}==”", GOTO=”persistent_serial_end”

# usb nearest ethernet connector
ENV{DEVPATH}==”*usb2/2-2/2-2:1.0*”, SYMLINK+=”serial/by-name/envi”
#bottom front connector
ENV{DEVPATH}==”*usb7/7-1/7-1:1.0*”, SYMLINK+=”serial/by-name/rs485″
# usb below nearest ethernet connector
ENV{DEVPATH}==”*usb2/2-1/2-1:1.0*”, SYMLINK+=”serial/by-name/rs485″

LABEL=”persistent_serial_end”

Replug and voila you get /dev/serial/by-name/rs485 which will always be the correct device.

Now I just have to run the wire to where the GCI will be installed.

I have found that on some linux systems when you compile with gcc and g++ the error messages have funny characters like

test.c: In function â:
test.c:6: warning: unused variable â


This is due to the default locale being set to something other than the default.

in /etc/default/locale you will have a line like

LANG="en_AU.UTF-8"

add

LC_CTYPE=C

Restart the shell and compile again and the errors are now meaningful.

test.c: In function 'main':
test.c:6: warning: unused variable 'x'


Naturally you could set it in the local shell for the session, but then you would have to do it every time.

There are times when domains on windows change and thus your user id changes. However, you may have lots of files owned by you that are not in your user dir. Migrating these user ids to you new one, I’ve found, is not too difficult after all.

All you need is a tool from microsoft called subinacl.

Download and install the msi. Install path is

C:\Program Files\Windows Resource Kits\Tools\subinacl.exe

So use this for the command name below.

First find your old userid. Use a file you know you used to own. E.g. the projects directory.

Subinacl /file c:\projects /display

Copy and paste yours for use in the commands below

Now for the commands. Do for all drives if you have multiple disks.
The lines below are for me of course so sub in your cut S-xxx and new user id

Subinacl /subdir c:\ /accountmig=S-x-x-xx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxx-xxxx=newdomain\username

also the primary group, which can be found up the top of the display dump.

Subinacl /subdir c:\ "/accountmig=S-x-x-xx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxx-xxxx=newdomain\Domain Users"

all registry keys

Subinacl /subkeyreg HKEY_CURRENT_USER /accountmig=S-x-x-xx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxx-xxxx=newdomain\username

Subinacl /subkeyreg HKEY_LOCAL_MACHINE /accountmig=S-x-x-xx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxx-xxxx=newdomain\username

Subinacl /subkeyreg HKEY_CLASSES_ROOT /accountmig=S-x-x-xx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxx-xxxx=newdomain\username
(none found, so optional)

and the groups
Subinacl /subkeyreg HKEY_CURRENT_USER "/accountmig=S-x-x-xx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxx-xxxx=newdomain\Domain Users"

Subinacl /subkeyreg HKEY_LOCAL_MACHINE "/accountmig=S-x-x-xx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxx-xxxx=newdomain\Domain Users"

Subinacl /subkeyreg HKEY_CLASSES_ROOT "/accountmig=S-x-x-xx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxx-xxxx=newdomain\Domain Users"

After you are happy

Subinacl /subdir c:\ /suppresssid=S-x-x-xx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxx-xxxx

Subinacl /subkeyreg HKEY_CURRENT_USER /suppresssid=S-x-x-xx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxx-xxxx

Subinacl /subkeyreg HKEY_LOCAL_MACHINE /suppresssid=S-x-x-xx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxx-xxxx

When you are finished, everything you used to own you will own again.

I use

chgrp -R www-data wp-content
chown -R g+w wp-content


To make this work with wordpress, edit wp-admin/includes/file.php in function get_filesystem_method() and comment out

if ( getmyuid() == fileowner($temp_file) )

to

#if ( getmyuid() == fileowner($temp_file) )


If the test file can be written, who cares if it is not owned by the webserver.

You will have to reapply this edit every time wordpress core is updated.

Ref: why-wordpress-asks-connection-info

Since wince 4.2 is quite old and not that well supported by OEM device manufacturers, it is often hard or impossible to get drivers for wince4.2 for these devices.

However the API into coredll and other parts of the wince system libraries is, if not identical, then almost identical.

I had an instance recently where I needed to make a USB wifi device work with wince4.2. After doing some research, I chose a ralink 2471W based device. However it came with a wince5 driver. Binary only of course.

Looking at the driver dll, all the imported functions were available except 1 in the ndis.dll, that being NdisQueryPacket. In wince4.2, this fucntion is provided by a #define, but in wince5 it is a instantiated function.

The solution is to compile the following code to an obj, and use the lib32 to add it to ndislib.lib in the private tree.


// local modded copy of ndis.h
#include "ndis.h"
#include <pkfuncs.h>


VOID
NdisQueryPacket(
IN PNDIS_PACKET _Packet,
OUT PUINT _PhysicalBufferCount OPTIONAL,
OUT PUINT _BufferCount OPTIONAL,
OUT PNDIS_BUFFER * _FirstBuffer OPTIONAL,
OUT PUINT _TotalPacketLength OPTIONAL
)
{
NdisQueryPacketDef(_Packet, _PhysicalBufferCount, _BufferCount, _FirstBuffer, _TotalPacketLength);
}

Also add the export definition to the end of ndis.def so that it becomes exported when ndis.dll is built with the system.

Finally, remember to put these 2 files back in the private tree where you got them from.

Now when the system is rebuilt with platform builder, the new ndis.dll will contain this extra function, thus allowing the USB wifi driver to function perfectly without modification.