Open to new opportunities!

KlebrigDatasikkerhet, IT, Office 365

Since I left my position as the Cyber Security officer at BI Norwegian Business School on January 31st 2023, I have been without a job. I spent February doing some home renovation, but now I am looking for and open to new opportunities within the cyber/information security field.

I have been working in the IT field for more than 30 years, and have had cyber/information security as my area of responsibility and expertise for more than 25 years. I helped introduce a Management System for Information Systems while working as a CISO, and lead the IRT/CERT function from 2017 to 2023. I also organized the yearly National Cyber Security Awareness Month each October for several years and had my own «Infomation Security Tip of the Week» column on the intranet.

In addition, I have been a course instructor, project manager, server and application admin (Windows and Linux servers), mail server admin, Microsoft 365 manager, Dropbox admin, network manager and much, much more. I have migrated 50,000 student and 2,500 employee mail accounts from Lotus Domino to Exchange Online (Microsoft 365) while being a platform manager for Microsoft 365, and I have worked with Microsoft Azure (Azure AD, VMs, XaaS). I am a CISSP (Certified Internet Systems Security Professional).

As a result, I carry with me a lot of knowledge that I am eager to put to good use with a new employer.

So if you have vacant full time position and are looking for a versatile cyber/information security person feel free to reach out to me. My main focus is strategic advisory. I have no problem standing in front of crowds talking, if the position requires this. I am available and can start immediately. I am located in Oslo, Norway, and and can’t relocate. But I have no problem working remotely.

In the meantime, I have my own sole proprietorship, Bjørseth IT, and I am happy to come and talk to you and your employees about Zero Trust, IAM (Identity and Access Management), Microsoft 365/Azure, cyber security best practices, password policies or any other cyber/information security topic that can be introduced in 30-45 minutes.

Please use the contact form to reach out.

Disk speeds with the Raspberry Pi 4 Model B

Dingser, Diverse, IT, RaspberryPi

Background

The Raspberry Pi Foundation released the Raspberry Pi 4 Model B (I’ll call it RPi4 in this article) in June 2019, and a lot has already been said about the new features. The dual Mini HDMI ports and a selectable memory size (1, 2 or 4 GB ram) are the most obvious differences from the previous models, but the RPi4 also has a true gigabit ethernet port and two USB 3.0 ports. This makes the RPi4 a better candidate for a small NAS, as data transfers will be much faster than with the previous models.

I have testet a few different drive options for my RPis in the last couple of years, so I have collection of different drive types and adapters. This is mostly as I am skeptical to running what I consider «critical» systems from an SD card, and to see if there was any performance improvements to move from SD cards to different USB solutions. And so I started booting them from USB thumbdrives, bought a couple of USB-to-mSata HATs before I now have two USB-to-M.2 cases and one USB-to-NVMe case. And with this variety of USB equipment, I decided to see what kind of drive speeds I can expect with the new RPi4 hardware.

The equipment

SD cardSandisk Ultra 16 GB, Class 10, HC 1  
USB Thumb drive #1Sandisk Ultra Fit 64 GB, USB 3.0
USB Thumb drive #2Samsung Flash Drive FIT 64 GB, USB 3.0
mSATA SSDKingston 240 GB mSATA SSD + SupTronics X850 v1.3 mSATA HAT
M.2 SSD driveKingston UV500 120GB M.2 SSD + ICY Box IB-1815WP-C31 (USB-to-mSata case)
NVMe drive120 GB (Probably a Samsung EVO something) + Noname USB-to-NVMe case

So how was the tests performed?

I started out the tests with an RPi4 with a freshly installed and updated Raspbian Buster Lite 2019-07-10. Since RPi4 can’t boot from anything else than SD cards as the time of this writing, the RPi4 was booted this way, and the USB drives were connected one after the other, so no more than one USB connected drive was attached at any given time.

The command I ran was

hdparm -t <device> <device> <device> <device> <device> <device> <device> <device> <device> <device> 
example:
hdparm -t /dev/sda /dev/sda /dev/sda /dev/sda /dev/sda /dev/sda /dev/sda /dev/sda /dev/sda /dev/sda

By repeating the <device> 10 times on the command line, I get 10 consecutive read tests without any pause in between them. With 10 tests I can check for variations, and then calculate the average. I even repeated the series of 10 tests 3-4 times to see if I got varying results between the series, but the results were very stable. Even the strange M.2 results were stable.

For some reason, I couldn’t get the mSata HAT from SupTronic to work with the RPi4, so I haven’t been able to test this solution. I’ll dig out the other mSata HAT from the pile of equipment at a later date to see if I get that one to work.

OK, enough talk, let’s see some numbers

Here are the results so far:

As you can see, and probably already knew, there is a big performance difference between SD cards and the other disk types.

  • The SD card actually performed better than I had anticipated. I don’t know if the RPi4 has a faster SD card reader than the previous RPis – I might have to test this some time.
  • The two USB Thumb drives are approximately 4 and 3 times faster than the SD card, and their performance is quite stable.
  • As mentioned, I couldn’t get the mSata HAT to work, so I have to add the results for this drive later.
  • The M.2 SSD surprised me, as the results varied a lot. The best result was more than twice as fast as the slowest one. I ran the test several times, and there was always one of the ten runs that was much slower than the others. To exclude the possibility of equipment errors, I found my other, identical M.2 SSD drive and identical Icy Box case, but the same thing happened with this as well. So I have no idea why the results vary so much within a series of 10 tests run
  • The NVMe drive was by far the fastest one, and this is no surprise. The technology IS faster, so as long as the USB bus isn’t maxed out earlier in the test, the NVMe should really shine compared to the other drives. And it did.

I’ll have to dig up some more tests (write tests) to further check the performances of the different drives, but based on the hdparm tests I know what media I would prefer if maximum performance is a must.

Reading information from your AMS power meter #02: Attaching the USB-to-MBUS adapter to the AMS smart meter

Diverse, IT, RaspberryPi, SmartHouse

In the first post in this series, I explained how to get startet and connect your USB-to-MBUS adapter to the Raspberry Pi. In this post, I will explain how to connect the USB-to-MBUS adapter to your AMS smart meter, so you can receive data from the meter.

As mentioned in the first post, the standard HAN port interface (in Norway!) is an RJ45 connector. To connect your USB-to-MBUS adapter to the AMS smart meter HAN port, all you need is a sacrificial ethernet cable of suitable length. It does not have to be more than a Cat 5 cable, using a Cat 5e or higher cable will not add anything but cost.

When you have your ethernet cable, cut off one of the plugs as close to the plug as possible so you don’t waste any cable and strip off 1-2 centimeters of the cable jacket, exposing the four twisted pairs inside the cable. Now check the end of the plug you cut off. The colors inside the plug should look like one of these two:

(picture from www.theengineeringprojects.com)

It doesn’t matter if your cable looks like the left or the right color combination – the important thing is to check which one of the two you have got. My cable has orange/white and orange in pin 1 and 2 respectively, so those are the two wires I will use in my setup.

Pin 1 and 2 (left to right on the plug) are the only ones used, so make a note of the colors of the wires in location 1 and 2 in your plug. These are the two wires you must keep, the remaining 6 can be cut off to avoid confusion.

Now you need to strip off approx. 5 millimeters of the coating on each of the two wires you will use, to expose the bare metal inside. Take care not to cut of any of the many thin strands within each wire, you need them all to make a good connection to the USB-to-MBUS adapter. When ready, insert the wires into the two connectors on the adapter, and tighten the screws to make a good, solid connection. It doesn’t matter which wire goes into which connector on the adapter – the M-Bus is non-polar so there is no traditional «plus» or «minus/ground» in the wires.

My connection looks like this in it’s demo version. I will make a more solid and professional looking connection when it goes into production:

Now you are ready to connect the ethernet cable to the HAN port on the AMS smart meter. It’s as simple as connecting any ethernet cable to any RJ45 socket. I suggest you power on your RPi and connect the adapter to the RPi first, and then connect the adapter to the HAN port on the AMS smart meter. There is no real reason for doing it in this sequence, it just seems like the right way for me to do things…

That’s it for the physical connection. If you did a good job with the ethernet cable, your AMS smart meter should be connected to the USB-to-MBUS adapter, which in turn is connected to the RPi.

In the next post we will start experimenting with code, to try to read information from the adapter.

Reading information from your AMS smart meter #01: Connecting a HAN-to-USB device to your Raspberry Pi

Diverse, IT, RaspberryPi, SmartHouse

About a year ago, we got one of those new AMS smart meters from Aidon (the Aidon 6525), with an integrated HAN (Home Area Network) port. This port enables me to read power usage stats from the power meter, with a high sample rate so I get close to real time stats. Previously I had to report the energy consumption usage every month, but now it is reported automagically almost in real time (we’re talking every few seconds). This is something I want to explore, to see what I can do with it. Until now I haven’t done anything to try to read values and create my own dashboard at home, but this is about to change.

So what is the HAN port? The HAN port is a simple M-BUS interface, and all Norwegian smart meters must have one HAN port in the physical shape of an RJ45 contact, where only pin 1 and 2 are used for the M-BUS protocol, the other 6 pins are unused. There are several different options for adapters to connect to the AMS smart meter.

Just before the summer vacation, I ordered the HAN port to be opened from my power supplier, and I also ordered a cheap USB-to-MBUS slave module from AliExpress:

While we were away on vacation the module arrived, so it’s time to get this project started. I’ll use a Raspberry Pi Model B 3+ (I’ll simply call it RPi from now on) as the «brain», and connect the module to the RPi. The progress will be slow, as I do not have too much spare time for this, but I want to see this finished as quickly as possible

The first thing to do is to do a fresh install of Raspbian on the RPi. As of this writing, the latest Raspbian version is Raspbian Buster (Raspbian 10). I expect that you know how to install Raspian and boot up the RPi, so I won’t cover this. If you are fresh to Raspberry Pis, you can findt the official documentation here: https://www.raspberrypi.org/documentation/

After installing Raspbian and booting up, remember to secure the installation according to best practices. You can find some good help here: https://raspberrytips.com/security-tips-raspberry-pi/.

So now you have booted your RPi, and it is reasonably secure. Before you try to connect the USB-to-MBUS adapter, let’s see what USB devices are already attached. Run the lsusb command:

$ lsusb
Bus 001 Device 004: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge
Bus 001 Device 005: ID 0424:7800 Standard Microsystems Corp.
Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

The first device is my mSata to USB bridge, as I am running my RPi from a mSata disk instead of a SD card. The rest of the devices are the standard RPi devices that are present on all RPis

Let’s attach the USB to MBUS adapter, and see if the RPi will recognise the adapter. Run the lsusb command again after attaching the adapter:

$ lsusb
 Bus 001 Device 004: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge
 Bus 001 Device 006: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
 Bus 001 Device 005: ID 0424:7800 Standard Microsystems Corp.
 Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
 Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Hey presto! A new USB device has appeared on the list! The USB to MBUS adapter is detected as a «PL2303 Serial Port», which only means that the adapter contains a PL2303 chip to «translate» signals from serial to USB, so the RPi is detecting this as a PL2303. It can’t see what is «behind» the PL2303 interface. This is common for all devices that use a PL2303 chip, so nothing strange.

So how can I communicate with the USB-to-MBUS adapter? It must have some kind of device file that can be used. We can use the command dmesg to find this information:

$ dmesg
[45236.494952] usb 1-1.1.3: new full-speed USB device number 6 using dwc_otg
 [45236.627927] usb 1-1.1.3: New USB device found, idVendor=067b, idProduct=2303, bcdDevice= 3.00
 [45236.627935] usb 1-1.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
 [45236.627939] usb 1-1.1.3: Product: USB-Serial Controller
 [45236.627943] usb 1-1.1.3: Manufacturer: Prolific Technology Inc.
 [45236.679684] usbcore: registered new interface driver usbserial_generic
 [45236.680958] usbserial: USB Serial support registered for generic
 [45236.684271] usbcore: registered new interface driver pl2303
 [45236.684447] usbserial: USB Serial support registered for pl2303
 [45236.684639] pl2303 1-1.1.3:1.0: pl2303 converter detected
 [45236.688644] usb 1-1.1.3: pl2303 converter now attached to ttyUSB0

From the dmesg output, we can see that the adapter was detected, and was attached to ttyUSB0. This means that the device can be reached as /dev/ttyUSB0. We need this when we get a little further down the track.

For now, we have a fresh Raspbian install, and a connected USB-to-MBUS adapter. That is it for this post – in the next posts I will connect the adapter to the AMS power meter and see if we can receive anything.

Using PowerShell to connect to Office 365: Index was out of range

IT, Office 365, PowerShell, Windows,

A while ago I got this rather annoying problem when I wanted to connect to Office 365 using PowerShell to administer my tenants. I have always connected using the classic connection script that can be found anywhere in internet. It looks like this, and had been unchanged for a couple of years:

$adminCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $adminCredential -Authentication Basic -AllowRedirection
Import-PSSession $Session -DisableNameChecking
Import-Module MSOnline
Connect-MsolService -Credential $adminCredential

When run, the script began to return this error a few months ago:

Import-PSSession : Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index
At C:\Users\MYUSER\office365\powershell\Connect_to_MSOnline.ps1:3 char:1
+ Import-PSSession $Session -DisableNameChecking
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Import-PSSession], ArgumentOutOfRangeException
    + FullyQualifiedErrorId : System.ArgumentOutOfRangeException,Microsoft.PowerShell.Commands.ImportPSSessionCommand

So what was wrong? The $session variable had the expected content, so I knew the New-PSSession command had finished without error, but still the Import-Session command threw the «Index was out of range» error.

At first, my suspiscion went to Microsoft and the everchanging Office 365 sphere. Could I have missed a notice saying I had to upgrade the Microsoft Online Services Sign-in Assistant? A quick check confirmed that I had the latest version, but I reinstalled it just to be safe. What about the Windows Azure Active Directory Module? Also the latest, but I reinstalled this one as well.

Still no go!

I then turned to the PowerShell version. I had upgraded to Windows 10 when it was released, and I am running PowerShell 5. I have a Windows 7 virtual machine where the connection script worked as it should, and this VM is running PS 4. I found no information indicating that the PS version should have anything to do with the problem, though.

So what else is the difference between the Windows 7 VM and my Windows 10 PC? Both are domain joined and in the same OU, so there are no computer GPOs that are only effective on one of the computers. But then I noticed that on the Windows 7 VM, I was logged in with a local account, not a domain account. Could there be a user GPO in effect? This got me thinking.

Then it dawned on me – AppLocker! We introduced AppLocker when we started our general Windows 10 deployment, and I had forgotten that they had tightened the screw with the AppLocker rules. Our AppLocker rules state that regular users are not allowed to run anything from the temp directories (C:\Windows\Temp, %TEMP% and %TMP%). This is to prevent malware to run on the computer, but it also means that files that are downloaded when the Import-Module command is run can’t execute, and the session won’t be imported.

So how can I work my way around this AppLocker policy, being a regular user? If a regular user could change the AppLocker rules locally, that would render the rules pointless. So I have to find another way to make my script run.

The solution: If I can’t run anything from the temp directory, could I possibly redirect where the script thinks the temp directory is located? It was worth a shot.

Luckily, our AppLocker rules state that all users can run their problematic «special» programs from a predefined directory. Let’s just call it C:\Approved for now. I can manipulate the $env:temp variable inside the script, so the Import-Module command downloads it’s files to C:\Approved just for this script. You could use any other directory where regular users have write and execute access.

So I added a single line to the top of my connection script:

$env:tmp = «C:\Approved»

Then I held my breath and ran the script.

Eureka! The script ran beautifully! The module is downloaded and imported (I can see the files on the disk), and all cmdlets are available.

When the module is downloaded, it now creates a temporary directory inside the C:\Approved directory. This directory is given a name that starts with «tmp_» followed by 8 random characters and a random 3 character extension. Inside the directory three files are created. These three files have the same random name with .ps1xml, .psd1 and .psm1 extensions.

So will I have hundreds of randomly named directorys in my C:\Approved directory after a while? No, when I close my PowerShell session with the command «Get-PSSession | Remove-PSSession» or simply by closing PowerShell ISE, the directory and files are deleted automagically. Nice!

So that’s it. That is how I got my connection script running again…

Raspberry Pi og GPS, del 1

Dingser, Diverse, IT, Linux, RaspberryPi

GlobalSat ND-100s GPS DongleEt mål med min RPi var å teste ut om jeg kunne bruke en GPS-dongle for å hente ut informasjon om lokasjon, fart og høyde osv. Klarer jeg det burde det ikke være noe problem å sende det via SMS for å rapportere evt. bevegelse eller noe sånt.

Da er det på tide å teste om det er mulig å få kontakt med GPS-dongelen min.  Det enkleste er å bare plugge den inn og se hva som skjer.

Jeg plugget GPS receiver i en ledig port på min PiHub, og sjekket i loggen (/var/log/messages) om noe ble rapportert, og sannelig dukket det opp treff der:

# tail -20 /var/log/message
Feb  7 23:18:13 raspberrypi kernel: [ 9701.726689] usb 1-1.3.2: new full-speed USB device number 7 using dwc_otg
Feb  7 23:18:13 raspberrypi kernel: [ 9701.832322] usb 1-1.3.2: New USB device found, idVendor=067b, idProduct=2303
Feb  7 23:18:13 raspberrypi kernel: [ 9701.832361] usb 1-1.3.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Feb  7 23:18:13 raspberrypi kernel: [ 9701.832381] usb 1-1.3.2: Product: USB-Serial Controller D
Feb  7 23:18:13 raspberrypi kernel: [ 9701.832399] usb 1-1.3.2: Manufacturer: Prolific Technology Inc.
Feb  7 23:18:13 raspberrypi kernel: [ 9701.938148] usbcore: registered new interface driver pl2303
Feb  7 23:18:13 raspberrypi kernel: [ 9701.938347] usbserial: USB Serial support registered for pl2303
Feb  7 23:18:13 raspberrypi kernel: [ 9701.938486] pl2303 1-1.3.2:1.0: pl2303 converter detected
Feb  7 23:18:13 raspberrypi kernel: [ 9701.950444] usb 1-1.3.2: pl2303 converter now attached to ttyUSB3

Ergo ble GPS-receiveren registrert, og den kan adresseres som /dev/ttyUSB3.

Enn så lenge får jeg ikke gjort noe fornuftig med denne informasjonen, så jeg må installere noen GPS-programmer og -biblioteker for å få brukt dette til noe fornuftig:

# apt-get install gpsd gpsd-clients python-gps

En liste med programvarepakker blir installert.

Så må programmet som kommuniserer med GPSen startes. Kommandoen spesifiserer hvilken port som skal brukes, og hvilken fil som skal fungere som «socket» (for å kommunisere med enheten):

# gpsd /dev/ttyUSB3 -F /var/run/gpsd.sock

Du får ingen tilbakemelding på denne kommandoen hvis alt gikk ok.

Nå er det på tide å sjekke om jeg får lest ut noe fornuftig fra GPS’en. Dette gjøres med kommandoen cgps:

# cgps -s

Følgende informasjon vises hos meg:

┌───────────────────────────────────────────┐
│    Time:       2014-02-10T22:56:51.000Z   │
│    Latitude:    5X.YYYYYY N               │
│    Longitude:   1X.YYUUUU E               │
│    Altitude:   535.9 ft                   │
│    Speed:      0.0 mph                    │
│    Heading:    0.0 deg (true)             │
│    Climb:      0.0 ft/min                 │
│    Status:     3D FIX (324 secs)          │
│    Longitude Err:   +/- 43 ft             │
│    Latitude Err:    +/- 88 ft             │
│    Altitude Err:    +/- 155 ft            │
│    Course Err:      n/a                   │
│    Speed Err:       +/- 121 mph           │
│    Time offset:     1.089                 │
│    Grid Square:     JO59kw                │
└───────────────────────────────────────────┘
┌─────────────────────────────────┐
│PRN:   Elev:  Azim:  SNR:  Used: │
│  21    45    174    19      Y   │
│   2    08    042    13      Y   │
│  23    11    309    26      Y   │
│  31    34    220    28      Y   │
│  13    14    340    29      Y   │
│  29    59    087    27      Y   │
│   5    25    066    17      N   │
│  16    24    297    21      N   │
│                                 │
└─────────────────────────────────┘

Boksene oppdateres hvert sekund, og de vises egentlig ved siden av hverandre, men kolonnebredden på bloggen gjorde at jeg viser de under hverandre. Første boks viser min posisjon, fart og høyde, mens den andre boksen viser informasjon om satelittene GPS-dongelene plukker opp.

Konklusjon så langt: Det var ikke noe problem å hente ut automatisk oppdatert informasjon fra GPS-dongelen. Det som gjenstår er å hente ut et valgfrie verdier ved behov, så jeg f.eks. kan sende en SMS med posisjon og fart hvis enheten begynner å flytte på seg.

Raspberry Pi og GSM-modem, del 1: Sende SMS

Dingser, Diverse, IT, Linux, RaspberryPi

Huawei_E173Det aller første jeg ville gjøre var å klargjøre min RPi og sjekke om jeg fikk sendt en SMS med GSM-dongelen min. Slik gjorde jeg dette:

Via http://www.raspberrypi.org/downloads lastet jeg ned NOOBS og installerte standard Raspian på SD-kortet mitt. Beskrivelse av det du trenger finnes på nevnte adresse.

Etter første gangs oppstart opprettet jeg en egen bruker for meg (liker å ha min egen bruker):

adduser MinBruker    (legger til brukeren)
passwd MinBruker    (setter nytt passord)
sudo cp -a /home/pi /home/MinBruker
sudo chown -R MinBruker:MinBruker /home/MinBruker

Å legge inn en egen bruker for meg er bare en «greie» jeg har, så miljøet blir mest mulig likt på denne enheten som de andre Linux-boksene jeg bruker. RPi kommer med en vanlig bruker som heter «pi» som er den som er ment brukt til alle vanlige oppgaver.

Deretter installerte jeg gammu, som er en programvarepakke som lar meg kommunisere med GSM-modemet og sende SMS.

$ sudo apt-get install gammu

(det installeres samtidig endel ekstra pakker pga dependencies/avhengigheter)

Jeg installerte også et par tilleggspakker, som strengt tatt ikke er nødvendige:

$ sudo apt-get install gammu-doc wammu

(det installeres samtidig endel ekstra pakker pga dependencies/avhengigheter)

Plugg inn USB-modem med SIM-kort på plass. Jeg har et Huawei E173, som skal fungere fint med RPi. Restart din RPi så denne scanner etter maskinvare og oppdager GSM-modemet.

Logg inn på din RPi med valgt bruker. Bytt til root-bruker for å få satt opp alt uten å måtte kjøre sudo hele tiden:

$sudo su -

Merk: Etter å ha byttet til root-bruker endrer kommandopromptet seg fra «MinBruker@raspberrypi ~$ » til «root@raspberrypi:/home# «. Den viktigste forskjellen er siste tegn i promptet – #. Dette tegnet indikerer at du er root.

Hva sier «dmesg»? Ble GSM-modemet funnet ved oppstart?

# dmesg | grep tty
 [    0.000000] Kernel command line: dma.dmachans=0x7f35 bcm2708_fb.fbwidth=1872 bcm2708_fb.fbheight=1168 bcm2708.boardrev=0xe bcm2708.serial=0xb3cf95db smsc95xx.macaddr=B8:27:EB:CF:95:DB sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000  dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p6 rootfstype=ext4 elevator=deadline rootwait
 [    0.000000] console [tty1] enabled
 [    0.530054] dev:f1: ttyAMA0 at MMIO 0x20201000 (irq = 83) is a PL011 rev3
 [    0.872363] console [ttyAMA0] enabled
 [   15.580525] usb 1-1.3.4: GSM modem (1-port) converter now attached to ttyUSB0
 [   16.001385] usb 1-1.3.4: GSM modem (1-port) converter now attached to ttyUSB1
 [   16.290602] usb 1-1.3.4: GSM modem (1-port) converter now attached to ttyUSB2

Joda, dmesg viser også at GSM-modemet ble funnet ved boot, og at det har tre tilgjengelig porter (ttyUSB0, ttyUSB1 og ttyUSB2).

Sjekk om gammu også finner GSM-modemet ditt. Det er ikke mye hjelp i at Linux finner GSM-modemet hvis ikke gammu gjør det. Da er du like langt. Kjør kommandoen «gammu-detect» og se hva slags svar du får:

# gammu-detect
 ; Configuration file generated by gammu-detect.
 ; Please check The Gammu Manual for more information.

[gammu]
 device = /dev/ttyUSB0
 name = Phone on USB serial port HUAWEI_Technology HUAWEI_Mobile
 connection = at

[gammu1]
 device = /dev/ttyUSB1
 name = Phone on USB serial port HUAWEI_Technology HUAWEI_Mobile
 connection = at

[gammu2]
 device = /dev/ttyUSB2
 name = Phone on USB serial port HUAWEI_Technology HUAWEI_Mobile
 connection = at

opening socket: No such device

Ikke bry deg om feilmeldingen nederst – det viktigste er at GSM-modemet ble funnet.

Bruk kommandoen «gammu-config» for å konfigurere gammu-oppsettet. Du må f.eks. velge hvilket av de 3 oppdagede GSM-portene som skal benyttes:

# gammu-config

Du skal nå få opp et grensesnitt for å konfigurere gammu-programvaren:

ââââââââââââââââââââââââââââââââââââââââââââââââ
â Current Gammu configuration                  â
â                                              â
â  P Port                 (/dev/ttyUSB0)       â
â  C Connection           (at19200)            â
â  M Model                ()                   â
â  D Synchronize time     (yes)                â
â  F Log file             (/var/log/messages)  â
â  O Log format           (nothing)            â
â  L Use locking          ()                   â
â  G Gammu localisation   ()                   â
â  H Help                                      â
â  S Save                                      â
â                                              â
â                                              â
â          <Ok>              <Cancel>          â
â                                              â
ââââââââââââââââââââââââââââââââââââââââââââââââ

Begynn med «Port» og velg først at du vil bruke «/dev/ttyUSB0«.
Deretter velger du «Save» for å lagre inntillingen.
Det er mulig du må bekrefte lagring. Gjør i så fall det.

Etter at du har lagret kjører du kommandoen «gammu –identify» for å se om du valgte korrekt port, og at gammu klarer å hente ut informasjon fra SIM-kortet ditt. Dette skal i så fall ligne på dette:

# gammu --identify
Device               : /dev/ttyUSB0
Manufacturer         : Huawei
Model                : E173 (E173)
Firmware             : 11.126.15.02.00
IMEI                 : xxxxxxxxxxxxxxx   (anonymisert)
SIM IMSI             : xxxxxxxxxxxxxxx   (anonymisert)

Hos meg fant gammu SIM-kortet på første forsøk, på port «/dev/ttyUSB0«. Jeg har sett andre rapportere at det kan variere hvilken port som er korrekt. Det kan også variere med hvilken USB-port du bruker på din RPi (eller på tilkoblet USB-hub). Hvis gammu ikke finner SIM-kortet og viser inforomasjon om dette så repeterer du forrige avsnitt («gammu-config») og velger port «/dev/ttyUSB1» før du fortsetter med dette avsnittet. Får du heller ikke nå noe resultat repeterer du rutinen og velger port «/dev/ttyUSB2».

Sett SIM-kortets PIN-kode:

gammu --entersecuritycode PIN 9999    (erstatt "9999" med PIN)

(Merk: Du får ingen tilbakemelding når kommandoen er ferdig.)

Prøv å sende en SMS, med gammu sin kommandolinje:

# echo "Testmelding fra RPi, sendt via gammu" | gammu  \ --sendsms TEXT xxxyyzzz

(erstatt xxxyyzzz med riktig telefonnummer). Du skal nå få se fremdriften, og forhåpentligvis ser det ut som dette:

If you want break, press Ctrl+C...
Sending SMS 1/1....waiting for network answer..OK, message reference=-1

Meldingen er sendt, det er bare å vente…

Hurra! Meldingen kom fram:
Suksess! Første SMS kom fram.

Så hva gjenstår? Dette var en enkelt, frittstående SMS. Dette må samles i et script som kan kalles og kjøres hver RPi skal sende en SMS. Jeg må også lese meg opp på mottak av SMS, så GSM-dongelen kan ta imot kommandoer via SMS, utføre kommandoen og sende resultatet til min mobil.

Prosjekt: Raspberry Pi

Dingser, Diverse, IT, Linux, RaspberryPi
RPi_Starter_KitProsjektet

Før jul kjøpte jeg meg en Raspberry Pi (RPi) for å se om den kunne brukes til noe morsomt. Inspirert av hva andre har gjort med denne lille dingsen var planen å teste den som mediesenter (OpenELEC), kartplotter (OpenCPN) og ellers sjekke ut om den kunne brukes som «vakt» i båten (sensorer, kamera og SMS-varsling) om vinteren.

Hva er RPi? En RPi er en liten datamaskin laget av The Raspberry Pi Foundation, litt større enn et kredittkort. Maskinen har utganger for lyd og bilde, og USB-porter for å koble til andre enheter. Den kan brukes til stort sett alt det en vanlig PC kan brukes til, men den er ikke spesielt kraftig, og den kan ikke kjøre Windows operativsystem. Den kan derimot kjøre flere forskjellige operativsystemer basert på Linux, android eller helt andre plattformer.

En av de store styrkene til RPi er at den er strømsnill, og den er liten og lett å gjemme bort i en stereobenk eller et rom i båt/bil. I tillegg til de vanlige tilkoblingsportene (USB, HDMI osv) har den flere litt mer spesielle muligheter (8 dedikerte GPIO pinner, UART, i2c buss, SPI buss, i2s audio m.m.).

Utstyr

I utgangspunktet bestilte jeg et Raspberry Pi Starter Kit fra MPX for å få alt jeg trengte for å komme igang i én enkelt pakke, og så installerte jeg en preview av Kano OS. Jeg har støttet Kano-prosjektet på Kickstarter og har dermed tilgang på deres programvare, men Kano OS var ikke noe å satse på for dette prosjektet.

OK, det første jeg ville teste var å sende SMS. Jeg bestilte derfor inn to Huawei E173 USB-baserte GSM-modemer via eBay. Disse USB-pinnene har både GSM-modem og en microSD-kontakt så man kan installere et ekstra minnekort hvis man trenger mer lagringsplass. Det var også flere som kunne bekrefte at de fungerer fint med Raspberry Pi.

Fordi GSM-modemet suger endel strøm fra USB-porten kjøpte jeg en PiHub fra Pimoroni. Dette er en USB-hub som har 3000mA strøm på deling mellom portene, så den kan drive enheter som RPi ikke klarer å drive alene. Den er også skreddersydd for RPi, så den kan både gi strøm til RPi og la RPi bruke den for å koble flere enheter til RPI’en. Noen USB-huber takler ikke at en RPi er koblet til i «loop», dvs at RPi både henter strøm fra PiHub via én port og kommuniserer med de andre USB-enhetene via en annen port (to kabler mellom RPi og PiHub). Jeg har tegnet et kontantkort-abonnement hos OneCall – det var det billigste jeg fant sånn i farta, og jeg kunne hente kortet på Narvesen eller 7-11 etter bare en times tid.

Etterhvert vil jeg også teste ut den USB-baserte GPS-pinnen jeg har liggende – en GlobalSat ND-100S GPS Dongle. Foreløpig er den testet med en vanlig PC med Windows 7 og OpenCPN, og den skal også fungere på Linux og Android.

Jeg har også en USB-dings fra Clas Ohlson som logger temperatur og luftfuktighet (http://www.clasohlso…ogger/36-4208-1). I utgangspunktet er den ment som frittstående logger, og lagrer alle verdier til internminne på pinnen, og så bruker man et Windows-basert program for å lese ut historiske data i ettertid. Jeg håper det er mulig å hente ut noe i sanntid (f.eks. med 5 minutters mellomrom), men det gjenstår å se.

Helt til slutt ser jeg også etter andre sensorer for tilkobling direkte på RPi’ens kretskort (dvs ikke via USB). Det gjenstår å se hva det blir. Foreløpig er det snakk om å få de nevnte USB-dingsene til å fungere.

 

God jul og godt nytt år!

Diverse

Som jeg antydet i forrige post så var vi lovlig sent ute med julekortene i år. Det betyr at mottakerne neppe finner dem i postkasssa før i romjula.

For alle de som ikke mottar et papirbasert kort (og for papirkort-mottakerne som ikke kan vente) legger jeg julekortet ut her i elektronisk form, så dere også har «mottatt» det, og ikke minst har dere fått det før de som får det via posten.

Julekort 2010

Som kortet sier:

Vi ønsker dere en riktig god jul og et godt nytt år!

Hilsen Alma, Klara, Mari og Thomas

Hvordan ordne julekort (Thomas-metoden)

Diverse

Her er en kjapp beskrivelse av Thomas-metoden for julekort-prosessen. Eventuelle lesere står fritt til å bruke metoden vederlagsfritt.

  1. I år begynner vi tidlig, dere! Tankeprosessen begynner i november.
  2. Beslutning: Bestille ferdige kort eller skrive ut selv? Konklusjon: Skrive ut selv!
  3. Drøy litt lenger enn fornuftig, gjerne til halvveis ut i desember før du begynner.
  4. Kreativ fase: Designe julekortet (med heller begrensede kreative egenskaper).
  5. Tanke: Egen utskrift – god unnskyldning for å kjøpe ny skriver? Ja!
  6. Bestille skriver.
  7. Vente på skriver som ikke blir levert når den skal.
  8. Hente skriver, vent gjerne et par dager før den kobles opp.
  9. Konvolutter! Vi har ikke kjøpt konvolutter! Løp og kjøp!
  10. 4-5 dager etter postens innleveringsfrist – begynn å skrive ut.
  11. Lever kortene på posten mens funksjonæren smiler overbærende.
  12. Kryss fingrene og håp kortene kommer fram før 2011.
  13. Send ut unnskyldning til alle mottakere mens du venter.
  14. Note to self: Neste år bestiller vi ferdige kort på nett, og sørger for å få det gjort senest 1. desember. Jadda…

PS: Til de av dere som får julekort av oss, så beklager vi at de kommer litt sent i år. Vi hadde et kjedelig tilfelle av uforklarlige hendelser utenfor vår kontroll, og skylder på force majeure. La meg ikke gå i detaljer, men kortene er på vei, om enn noe forsinket!  😉