BBB Node og RS232

Gør ttyO1 tilgængelig fra boot (bemærk det er ttyO1, ikke tty01, altså et stort o, ikke et 0 (nul)):
http://beaglebone.cameon.net/home/serial-ports-uart

# ls -l /dev/ttyO*
crw-rw---- 1 root tty 247, 0 Jul 18 21:42 /dev/ttyO0

Rediger /boot/uEnv.txt

# nano /boot/uEnv.txt

Tilføj:

optargs=capemgr.enable_partno=BB-UART1
# reboot

Kontroller:

# ls -l /dev/ttyO*
crw-rw---- 1 root tty     247, 0 Jul 18 22:13 /dev/ttyO0
crw-rw---T 1 root dialout 247, 1 Jul 18 22:13 /dev/ttyO1

Installer node-serialport, express og socket.io

cd /var/lib/cloud9
npm install serialport && npm install express && npm install socket.io

Virker under node v0.10.38, npm v1.4.21

BBB Debian static IP

Rediger /etc/network/interfaces

nano /etc/network/interfaces

Tilføj/ret:

auto eth0
iface eth0 inet static
    address 192.168.1.215
    netmask 255.255.255.0
    gateway 192.168.1.1
    dns-nameservers 8.8.8.8
    dns-nameservers 8.8.4.4

Fjern wicd:

wicd er måske installeret og vil OGSÅ bestemme over ip config.
Ved afbrydelse og gentilslutning af netværk bestemmer wicd, ikke /etc/network/interfaces !!!

apt-get remove wicd-daemon
apt-get autoremove
reboot

Kontroller:

ifconfig

Diverse BBB Debian kommandoer

Dato/klokkeslet

Tidszone:
dpkg-reconfigure tzdata
Stil klokken automatisk:
ntpdate -b -s -u pool.ntp.org

-b Force the time to be stepped using the settimeofday(2) system
 call, rather than slewed (default) using the adjtime(2) system
 call. This option should be used when called from a startup file
 at boot time.

-s Divert logging output from the standard output (default) to the
 system syslog(3) facility. This is designed primarily for conve-
 nience of cron(8) scripts.

-u Direct ntpdate to use an unprivileged port for outgoing packets.
 This is most useful when behind a firewall that blocks incoming
 traffic to privileged ports, and you want to synchronise with
 hosts beyond the firewall. Note that the -d option always uses
 unprivileged ports.

Stil klokken manuelt:
date -s "Aug 3 17:41 CEST 2015"

400 bad request

So today I decided to work on a pet project of mine, where a Raspberry Pi is controlling a LED light. The Pi is controlled by a website.

Cool.

Except…

When the Pi tries to connect to my local running iis express server, the response is 400 bad request.

Why ohhh why.

IP address… Yes, the servers ip has changed, but I did change the connection url on the Pi, so what then?

A little digging with fiddler didnt show anything. I mean that literally, the connection attempts didnt show on the server, at all.

It turns out it was the %userprofile%\My Documents\IISExpress\config\applicationhost.config that needed a small update to reflect the new ip address.

old:

<binding protocol=”http” bindingInformation=”*:52591:localhost” />
<binding protocol=”http” bindingInformation=”*:52591:192.168.1.222″ />

new:

<binding protocol=”http” bindingInformation=”*:52591:*” />

wohooo, no ip address needed, asterix for the win 😀

More on http://max-it.dk/wp/2014/06/12/iis-express-enable-external-request/

iis express enable external request

Shameless ripping of info from http://stackoverflow.com/questions/3313616/iis-express-enable-external-request

Add <binding protocol=”http” bindingInformation=”*:52591:*” />

to the <bindings> section of

%userprofile%\My Documents\IISExpress\config\applicationhost.config

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.applicationHost>
    <sites>
      <site name="iCentral" id="1580449741">
        <bindings>
          <binding protocol="http" bindingInformation="*:52591:*" />
        </bindings>
      </site>
    </sites>
  </system.applicationHost>
</configuration>

Note:
The snippet above is not a nearly a complete applicationhost.config, it just shows where the binding line is supposed to be in the hierarchy!

Hearthbleed (Raspberry Pi)

The affected versions of OpenSSL are OpenSSL 1.0.1 through 1.0.1f (inclusive). Later versions (1.0.1g and ulterior[60]) and previous versions (1.0.0 branch and older) are not vulnerable. Installations of the affected versions are vulnerable unless OpenSSL was compiled with OPENSSL_NO_HEARTBEATS.

http://en.wikipedia.org/wiki/Heartbleed#Affected_OpenSSL_installations

Check openssl version:

$> openssl version -a
OpenSSL 1.0.1e 11 Feb 2013
built on: Sun Mar 24 12:44:00 UTC 2013

That’s bad, update needed!

$> sudo apt-get update
$> sudo apt-get install -y libssl1.0.0 openssl

Check version again:

$> openssl version -a
OpenSSL 1.0.1e 11 Feb 2013
built on: Sun Apr 20 11:41:41 UTC 2014

Version is still one of the affected versions, but build-date indicates a patch.

According to http://www.raspberrypi.org/forums/viewtopic.php?t=74133 debian backported a patch to 1.0.1e-2+rvt+deb7u5

$> sudo apt-cache show openssl
Package: openssl
Version: 1.0.1e-2+rvt+deb7u7

We are good, just reboot now:

$> sudo reboot

Oh, also replace any and all certificates and make all users replace their passwords, you know the drill.