Kategoriarkiv: IT

Disk speeds with the Raspberry Pi 4 Model B


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> 
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

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

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

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

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

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.

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

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

 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             :
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


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.).


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.


Anbefales: AirCruiser G PCI WLAN nettverkskort

Gigabye Technologies GN-WP01GSJeg tenkte jeg skulle skrive et par ord om et trådløst nettverkskort som jeg snublet over hos Clas Ohlson og har installert i et par maskiner – Gigabyte Technology sitt AirCruiser G PCI Adapter (GN-WP01GS). For en tid tilbake var jeg på jakt etter et billig PCI-basert WLAN-kort til en slektning, og fordi Elkjøp var utsolgt for det jeg skulle ha ruslet jeg inn på Clas’ern med et ørlite håp om at de kanskje hadde noe som kunne brukes. Og det hadde de.

Kortet er ute av produksjon nå i følge Gygabyte sine nettsider (det er listet som «legacy»), men det er mulig å få tak i det på Clas Ohlson fremdeles – jeg kjøpte et nå på lørdag (03.10.2009).

Årsaken til at det har imponert meg er at det har gitt veldig god ytelse i begge maskinene hvor det er testet. Begge står inne i eller under en pult, klemt inn mot side- og bakvegg og med masse ledninger og annet kaos rundt. Ikke akkurat ideelle forhold for en bitteliten antennestump. I tillegg har begge maskiner stått et stykke unna aksesspunktene de har vært assosiert mot. Den ene maskinen står bak 3 vegger og et flislagt bad, mens den andre PCen står på kontoret hos oss, to etasjer opp og diagonalt gjennom boligen sett fra aksesspunktet.

I begge tilfeller har jeg fått over 90% signalkvalitet og -styrke, og problemfri forbindelse, og med helt smertefri installasjon. På kontoret brukte jeg tidligere en Linksys WRT54GL med OpenWRT satt opp som bridge. Denne hadde aldri mer enn 50% signalkvalitet eller -styrke, selv om den hadde mer optimal plassering og to antenner.

Av funksjoner verdt å nevne er disse:

  • 802.11b og 802.11g (ikke 802.11n)
  • WEP (som du ikke vil bruke!), WPA og WPA2.
  • AES-støtte
  • 802.1x-autentisering
  • Lav formfaktor – både høy og lav bakplate følger med
  • Standard PCI-buss
  • Avtagbar antenne med SMA-kontakt, så man kan bytte til en annen antenne enn den medfølgende bittelille 2dBi-antennen.

Driver til Windows 98SE/ME/2000/XP32 følger med på CD, og via Gigabyte sine nettsider kan man også laste ned driver til Windows XP64/Vista32/Vista64. Chipsettet (Ralink RT2561) har også støtte i Linux, så det burde ikke være noen problemer å bruke det med Linux også.

Det er veldig like hokus-pokus med dette kortet, men det er også poenget mitt. Det bare virker. Og det virker bra.

Now playing: Thulsa Doom – Why Do You Keep On (Watching The Porno) After You Came
via FoxyTunes

Det svenske Piratpartiet i EU-parlamentet

PiratpartietDet svenske Piratpartiet (PP) befester sin posisjon, og det foreløpige resultatet etter valgnatten fra det svenske valget til Europaparlamentet viser at PP endte med 7,1% av stemmene og de får dermed 1 mandat (av 18 mandater). Dette gjør PP til det femte største partiet i Sverige ved dette valget. Det endelige resultatet er foreløpig ikke klart, men etter at 4083 av 6060 valgdistrikter er opptalt ligger PP foreløpig enda bedre an, med 7,25% av stemmene når dette skrives. Tallene oppdateres fortløpende, og du finner disse her.

I følge PP sine egne nettsider så viser Valmyndighetenes simulator at PP ligger på vippen til å få et av de to ekstramandatene som Sverige blir tildelt hvis Lisboa-traktaten blir endelig ratifisert, så PP kan ende med 2 mandater etter at alle stemmer er gjort rede for.

Det som imponerer meg er at de blant annet har fått flere stemmer enn etablerte partier som Kristdemokraterna, Centerpartiet og Vensterpartiet. Vi snakker tross alt om et parti som ikke deltok for fire år siden (de ble stiftet 01.01.2006), men de nyter jo blant annet godt av all medieomtale rundt Pirate Bay-saken.

En ting som overrasket meg er at PP jevnt over får godt med stemmer fra alle län i landet. Ingen län har gitt mindre enn 5.68% av stemmene (etter at 4083 valgdistrikter er talt). I mitt hode var PP et urbant fenomen, men valgresultatene så langt viser at der tok jeg feil.

Jeg skal ikke ta stilling til den politikken PP står for, men noterer meg at de nå har begynt å bli «a force to reckon with». Det blir spennende å se hvordan det går ved Riksdagsvalget den 19, september 2010.

Alle tall tatt fra den svenske Valmyndighetens hjemmeside.

[Edit 20090610 – 1020: Jeg ser at VG hadde dette som sak for et par dager siden. Jeg er sent ute som vanlig… 🙂 ]

[Edit 20090610 – 1030: Jeg ser at også Dagbladet kommenterer Piratpartiets brakvalg]

Now playing: Led Zeppelin – Dazed And Confused
via FoxyTunes

Hvordan sikre ditt trådløse nettverk?

Mye er sagt og skrevet om sikring av trådløst nettverk i hjemmet, og her kommer enda noen ord. Jeg har lagt vekt på å gjøre dette så enkelt som mulig, uten å ofre sikkerheten i nettverket ditt.

Hvorfor sikre det trådløse nettverket?

Det er flere grunner til at du vil sikre det trådløse nettverket ditt. Husk at trådløst nettverk er radiobølger, og disse går i alle retninger. Den trafikken som går mellom din PC og aksesspunktet ditt kan sees av andre i din nærhet:


En av grunnene til å sikre det trådløse nettverket er at du vil hindre at uvedkommende kan plukke opp trafikken i nettverket ditt. Uten kryptering kan alle som plukker opp signalene også se alt innholdet i nettverkstrafikken og på den måten eventuelt plukke opp brukernavn/passord til en mailkonto, se hvilke nettsider du besøker eller lignende. Merk: Trafikken til og fra nettbanken din er alltid kryptert, så akkurat det trenger du ikke tenke på.

En annen grunn til å kryptere trafikken er for å unngå at uvedkommende får tilgang til ditt trådløse nettverk. Eksempelet alle bruker for å skremme er at hvis uvedkommende får tilgang til ditt trådløse nettverk kan de bruke dette til å surfe på barneporno, men det er også andre ting de kan gjøre. Et par eksempler er å prøve å få tilgang til din(e) datamaskin(er) eller sende ut spam via ditt nett.

Uansett hva motivet måtte være så kan det bety trøbbel for deg hvis de får tilgang!

Hva kan du gjøre?

Det er noen alternativer som dukker opp hver gang man snakker om sikring av trådløse nettverk, men dessverre er ikke alle like gode. Her nevner jeg tre punkter, og forklarer hvorfor de ikke nødvendigvis er veldig fornuftig og/eller praktisk å bruke to av dem.

De tre punktene er:

  1. SSID (nettverksnavnet)
  2. MAC-adressefilter (for å begrense hvilke maskiner som kan få tilgang til nettverket)
  3. Kryptering (så ingen kan se hva du sender/mottar)

La oss se litt nærmere på det vi har å jobbe med…

Det er to ting du kan gjøre med SSID (nettverksnavnet): Du kan skjule SSIDen, og du kan bruke en SSID som ikke direkte identifiserer deg eller din familie.

Å skjule SSIDen så den ikke kringkastes ut i nabolaget nevnes ofte som en sikkerhetsmekanisme, men så lenge det går trafikk via det trådløse nettverket er det mulig å finne nettverksnavnet. Det er også noen trådløse nettverkskort som har problemer med skjult SSID, så det kan gi problemer hvis du velger å bruke skjult SSID. Konklusjon: Falsk sikkerhet og potensielle problemer.

Når det gjelder valg av SSID (nettverksnavn), så anbefaler jeg å ikke bruke noe som enkelt identifiserer at nettet tilhører deg. Bruk derfor ikke fornavn, etternavn, navn på kjæledyr, adresse eller noe annet som direkte forteller de som lytter at det er ditt nettverk. Ikke kall nettverket ditt «OleHansen» hvis det er navnet ditt, men bruk en nøytral SSID. Da blir det bittelitt vanskeligere å identifisere og angripe deg spesifikt. Konklusjon: Jeg anbefaler en nøytral SSID.


Alle nettverkskort har en unik adresse som kalles MAC-adresse (Media Access Control). Et MAC-adressefilter gir kun registrerte MAC-adresser (og dermed kun kjente maskiner) tilgang til ditt nettverk. I utgangspunktet høres jo dette forlokkende ut, men MAC-adresser kan forfalskes. En som sniffer på nettverkstrafikken din kan se hvilke MAC-adresser som er i bruk (dvs har tilgang), og kan deretter selv kode om sin egen MAC-adresse og bruke en av de adressene som ble oppdaget. I tillegg medfører et slikt filter at alle maskiner som skal bruke det trådløse nettet først må registreres på aksesspunktet. Har du kun et fåtall maskiner er det kanskje en jobb du vil ta, men har du familie, venner eller andre som er innom og vil bruke ditt trådløse nett blir det fort mye jobb for en veldig liten sikkerhetsgevinst (hvis noen). Konklusjon: Mye bryderi og lav sikkerhet.

Da står vi igjen med kryptering.


Kryptering kan sikre at uvedkommende ikke får tilgang til nettverket ditt, men du må bruke en standard som er sikker. Det betyr at du ikke skal bruke WEP (Wired Equivalent Privacy) i ditt nettverk, for den standarden er ikke god nok. Krypteringsnøkkelen er kun 40 eller 104 bits (pluss 24 bits IV – Initialization Vector), den er statisk (endres aldri), og ved å sniffe nok trafikk kan man knekke nøkkelen.

Det nivået du må legge deg på er WPA2 (Wi-Fi Protected Access 2). Kort fortalt sørger WPA2 for å bytte ut krypteringnøkkelen regelmessig, og nøkkelen er 256 bits lang. Den initielle passordfrasen som må være kjent for alle tillatte brukere bør være relativt lang, og bruk gjerne tipsene fra Hvordan velge et godt passord for valg av passordfrase. Sørg for at passordfrasen er på over 15-20 tegn, så er den trygg nok pr. idag. Selve krypteringsnøkkelen lages som en utregning basert på SSID og passordfrasen, men hvordan dette skjer trenger du ikke tenke på – det går helt automatisk.

WPA2 bruker CCMP-protokollen og AES-krypteringsstandarden, men igjen er det noe du ikke trenger å tenke på. Husk WPA2, så er det nok. Konklusjon: Bruk WPA2.

Så hva er essensen av denne posten?

Essensen er kort og godt at du kan droppe flere av de punktene som ofte nevnes når man skal sikre sitt trådløse nettverk. Det eneste du egentlig trenger er sterk kryptering med WPA2 og en god passordfrase. Bruk også en SSID som ikke direkte identifiserer deg, så er mye gjort.

Hva annet kan jeg gjøre for å sikre de trådløse nettverket mitt?

Det er flere andre ting du kan gjøre, men det holder i praksis å bruke WPA2-kryptering med en lang og god passordfrase. Vil du prøve mer kan du alltids skjule din SSID og skru på MAC-filtrering, men min erfaring er at dette gir mer ekstraarbeid og problemer enn positiv effekt. De som virkelig vil inn på akkurat ditt trådløse nett vet hvordan de skal finne en skjult SSID, og de vet hvordan de forfalsker en MAC-adresse. Bruker du en nøytral SSID må de peile signalene for å vite at «Andebynett» er det nettverket som er i bruk hos deg. Det de derimot ikke vet er krypteringsinformasjonen din, og de klarer ikke finne denne hvis du velger en god passordfrase og holder den hemmelig. Hvis du har gitt passordfrasen til mange rundt deg så bytter du den.

Lykke til!