Pi & Lazarus I2C

I’ve been asked a few times now how we got I2C working without third party code. The reality is that thanks to the way Linux handles drivers it’s pretty easy and I’d expect direct access to 1 wire to be the same (We have bridges with FIFOs, parasitic power etc so we  dont need to try it)

First make sure you can talk to your I2C decvice with I2Ctools. Theres loads of info on this, off you go and hunt it down.

latest versions of Raspbian use a new way of handling devices, make sure you use a tutorial that matches the way your system is setup as simply uncmmenting things in the modules blacklist may not be enough.

You shouldnt be running code as root, developing, yes, running as an end product, no. There are arguments against developing too but thats not why this article is here.  By default only root has access to I2C and we need to change that if your apps are going to work in userland. Its easy to do. Say we want pi to be able to do it:

sudo groupadd i2c pi

Now we can use the standard FPOpen(), FPRead(), FPWrite() to do the job.

  DEV_IMU : integer;
addr : byte;

This is the handle for the fle we are about to open and addr is the target device address on the bus

procedure openI2c;
   count : integer;
   data: byte;
   reg : byte;
  DEV_IMU:= fpopen(‘/dev/i2c’,O_RDWR);
  if DEV_IMU= -1 then begin
             // we couldn’t open the bus
else begin
// associate this handle with an address on the bus
fpioCTL(DEV_IMU,1795, pointer(addr));


Now to read:

function readbyte(reg:word):word
    count : integer;
   data : byte;
// we have to write before the read to send the register we want
     count := fpwrite(DEV_IMU,reg,1);
     if count <> 1 then begin
              // we couldnt do the write!
// now read
    count := fpread(DEV_IMU,data,1);
     if count =0 then begin
              // nothing came back
  else result := data;

And the write is easy enough. The read is write then read as we always nbeed to send the target register out. In the case of a write we can do this ‘back to back’

procedure writebyte(reg,data:byte)
    buffer : array [1..2] of byte;
    count : integer;
     buffer[1] := reg;
     buffer[2] := data;
     count := fpwrite(DEV_IMU,buffer,2);
     if count <> 2 then begin
              // write failed
     else // write ok

This should have you up and running in no time.

Security Through Obscurity…

Time and time again we are told the above doesnt work and yet it still happens, why and why is it important.

In the process of our big tracker project I’ve been looking at packages that do the job already and also a number of control systems. Bearing in mins what these do, there is no security on most of it and token security on one of them. You may think that this isnt a big thing and in most cases it isnt, but there are good reasons it is. So lets take a look at two culprits…

Veichle control Systems:
I’ve looked at three of these in the last few days and one thing is common with all three. No encryption, no ability to detect errors and no authentication. For the best part this isnt a huge problem, in fact its a boon, I know how all three work and can talk to them. However the bar is set low and any of them can be subverted easilly. In the case of the first two I looked out you wouldnt gain a lot past the ability to turn things on and off but the potential is there. The third is a fully integrated system and is designed to control all aspects of the vehicle including battery management and its also designed to be linked to an onboard computer, now here there is scope for trouble. The system concerned could easilly be subverted by malware and then the fun begins. Further digging on this one turns up no encryption is used on the comms link to the office either, but it gets worse…

Of the dispatch and tracking systems looked at not one uses encryption, for the more basic ones this means simply you can rap the tracking data out of the air and at least one was fooled easilly to connect to a wifi network and forwd the unencrypted traffic over my network, patient details, addresses etc all in the clear. This means that this data can also be modified so this particular system couldbe subverted pretty easilly with a laptop and either data creamed off and used for nefarious means (ask someone how expensive ambulance kit is!) or worse. Tracking data can be falsified, fed back to the base meaning the veichle doesnt show as being where it belongs and uh-oh, the SOS button isnt going to help if someone jumps the ‘bus’

There is no excuse for this. None at all and the scary thing is that the same can be found in Automotive systems from the factory and has recently been found in Avionics systems too!

Serial channels can simply and effectively be secured. Even our most basic bus system, TRNet uses authentication and device tracking mechanisms. If a device doesnt authenticate, its ignored, even if it does it must be recognised on the bus else the system, will lock the bus out. This is done by a few dozen lines of code and although it could be subverted with a moderate amoun of effort you’d need access to a lot of information to get started. This also allows us to give a mechanism for making sure the bus is reliable. Scarilly all but one of the three systems we looked at just kept sending the same data over and over again with no control path back to the master. Although it’ll work it means bit flips can happen in transmission and may be ignored (no CRC/Checksum used) and there is a wealth of data for someone to grab and decode.

Data channels running over a network should also be secured and only links trusted should be used. Again this is basic common sense and doesnt take a lot of code, for this application we are using a pretty hardcore authentication system based on AES but its neither difficult to do or expensive. With the system we have both ends of the chain must be compromised and in such a way that pe-encrypted data is grabbed, key shifts mean that just grabbing the encrypted stream and a session key wont help you, even if you do grab a key you need the previous key to use it so good luck.

There is still a strong sense in the embedded and bespoke software/hardware market that no one is interested in specialist applications, wont try and thus you dont need to bother about security above making it convoluted. This is fallacy, the value of the equipment on an ambulance is truly amazing to those not in the know so gaining the ability to send such a veichle to a false location of your choice, disabling its tracking  and ability to call for help is going to be of interest.


A Precautionary Word About Driver Updater Utilities

I see and remove a lot of these and they are almost universally hated by the IT industry and a VERY bad idea for the end user, but why?

First up the Malware side of things. A lot of these updaters are Malware/Foistware. The same trick is used as is pulled with a lot of ‘Heatlh’ checkers. Find lots of problems, tell the mark you can fix them and then charge for doing so, even though the problems likeley didnt exist or wernt problems at all. There are driver programs that do just this.

RansomWare, well not quite but thats what it tries to do. Does the same as above and likley will actually find issues and be able to update drivers but once again, you’ll have to fork out for something you could do yourself and may be harmful.

Next up apps that do actually do something. Most of these still fall into the dangerous category, even those that are free and do seem to work. Why? Because the method they use is fundamentally broken. Almost all hardware provides two bits of information to the PC without being told or needing drivers, this is the PID and VID or Product ID and Vendor ID. These are used by these programs to go and find out who made the hardware and what it is. It’ll then grab a generic driver from the manufacturer or its library  and off it goes. No harm done? Well not really no.

For a large number of devices this is just find and dandy but some developers are a bit lazy and this is where it falls over.  The idea was that each PID/VID combination would be unique, the IDs are provided by the chips used and the idea is that the company making the perhipheral should assign their own values and not use the defaults. In reality very few do.

Two Examples. One, we have a Laptop using an ATI X1300 GPU, Its in a laptop and this GPU provides some secondary functions, in this case, it can take control of the backlight. The Laptop manufacturer hasnt changed the PID or VID and this wasnt something the ATI drivers were written for. Along comes the utility, matches the PID and VID to the default ATI driver, installs and blammo. You have no backlight anymore, the new drivers dont know how to drive the backlight and so dont.

Next we have the RealTek ALC892, fairly common sound chip. However this thing has options out of the wazoo. There are hundreds of combinations of speakers, inputs, outputs, mics etc and these will all be changed by the vendor, however not all of them are there in the default driver, in particulat there are a few general purpose I/O pins used to drive LED’s, power control for amps and more. SO with the driver the manufacturer of the hardware supplies this all works, in comes the default driver and once again, all these features are gone.

Both these scenarios could lead to physical damage to the machine as well as malfunctions in use so it really not worth it.

With time and research you can normally find the right drivers and its also why you should stick to manufacturers drivers, especially on customised hardware such as Laptops or SFF PC’s. Its also why sometimes the right drivers dont really seem to work as planned. Its also the reason the Microsoft drivers arent always that great and why you should always update core drivers on a new install, an example of these were the older VIA based motherboards that would run like a dog with the MS drivers. Only if you’ve tried everything should you think about these programs, and even then, here be dragons!

Test, test test and TEST

After doing some work and applying the PPP changes from previous posts I was rewarded with nice, rock solid PPP connectivity, excellent. I still neet to take timeouts down and work out another way of monitoring link quality but for all purposes it works.

However something that did work, posting tracking reports, now doesnt. One report is posted with the link establishment and then it all breaks. A look at logs shows that the tracker reconnection code has stopped working.

After a few tweaks and changes I really couldnt work out what was going on, then it hit me.

The PPP code fires off two events, LanDown and LanUp, these are used to decide if the GPS module should try and bring the link up again or if it should sit tight and wait. In wholesale re-writing the PPP control code I forgot to fire either event, DOH!

Always test, test, test and then test again when changing things that sit in a chain!

PPPppppppppickup a modem…..

Apologies to non UK readers, the pun above wont make much sense…

The issue with PPPD is persisting. However I think I have it cracked.

I need to get PPPD up, running and connected, during this I need to know what it’s up to, I also need to know when it stops so I can force it back up.

First PPPD has the ‘persist’ option to do this, however I need to have control over it as I will be doing other QOS monitoring above the LCP monitoring done by PPPD so I’ll probobly kill it off before it thinks its had a problem.

Next up, there is some support for doing this, I can tell that PPPD is up and running by looking in /var/run but this just says its running. Worse still this doesnt help before PPPD starts nor does it tell me that the link is there. Off we go to two provided scripts in /etc/PPPD.

IP-UP runs once the link is up and running, IP-DOWN surprisingly, runs when the link goes down. So the first attempt we drop a file in /tmp to say that we are up and remove it when we are down. So we now know that PPPD is up and when its connected and when it goes away. Sadly this still leaves us a problem. When the scripts to bring the modem up run, they are forked elswhere and PPPD doesnt generate a PID till the CHAT script hands over. This means going by the fles and PID our program thinks the link is still down and will be trying to bring it back. Pesky, harmless but fills the logs with rubbish.

We are using the PON/POFF scripts so for now we will edit /usr/bin/pon. We will leave POFF alone as the interface going down will clear out the files. In /usr/bin/pon we now drop a file called pppstarting.sem to indicate that we got to the end of the startup script OK and we are now going to attempt to dial.

This all works provided the modem is present. if not it all breaks as as yet I cant find out how to deal with this and take out the pppstarting.

Both PFSense and SmoothWall seem to do the same sort of thing so I may go and pick apart their PPP scripts for ideas.

There may also be a need to loop back the power LED to the PI as helpfully, the power button needs to be toggled, there is no way to know if its on or off witout talking to the modem.