IPv6, Canal Digital og Linux.

December 2nd, 2014

Canal Digital tilbyr, som en av ikke altfor mange norske ISPer ennå, nå IPV6 til kundene! De har derimot bare brukerguide for den trådløse ruteren de tilbyr. Jeg hadde allerede trådløs ruter, og bestemte meg for å sette opp en Linux-maskin som gateway mot Canal Digital. Linux har god støtte for IPV6, så dette burde være grei skuring, men det skulle vise seg at det er noen fallgruver. Disse skal jeg dokumentere her, slik at andre kanskje slipper å gå i dem.

Canal Digital tilbyr ipv6 vha DHCPV6 med prefix delegation. Dette betyr at man vha DHCPV6-protokollen får tildelt et helt nettverk med offisielle addresser, som man så igjen kan dele opp internt. Canal Digital gir deg et såkalt ::/48-nettverk, noe som gir deg plass til hele 65536 lokalnettverk av anbefalt størrelse (::/64). Det er ingen som helst grunn til å bruke noe annet enn ::/64 for lokalnettet, den størrelsen gjør alt lettere. Samtidig vil det *alltid* være stort nok.

Jeg valgte å sette opp wide-dhcpv6 i kombinasjon med radvd etter oppskriften her

Utside-interfacet mitt heter eth0, innside-interfacet eth1. Jeg har DHCP for ipv4 mot kanal digital, og fast ip-adresse på innsiden. Min /etc/network/interfaces inneholder da

iface eth0 inet dhcp

iface eth1 inet static
address 192.168.1.250
netmask 255.255.255.0

Ipv6 settes opp separat, med wide-dhcpv6-klienten. Siden jeg kjører Debian, finnes det oppstartsscript for denne, så det er bare å skru det på, med å putte følgende linje i /etc/default/wide-dhcpv6-client

INTERFACES="eth0"

Min /etc/wide-dhcpv6/dhcp6c.conf blir

interface eth0 { # external facing interface (WAN)
send ia-na 1;
send ia-pd 1;
request domain-name-servers;
request domain-name;
script "/etc/wide-dhcpv6/dhcp6c-script";
};
id-assoc pd 1 {
prefix ::/48;
prefix-interface eth1 {
sla-id 0;
sla-len 16;
};
};

id-assoc na 1 {
};

Denne definerer konfigurasjonen for eth0-interfacet mitt. Den spesifiserer:

  • send ia-na 1; spesifiserer at den skal be om en NA-adresse, dvs. en tildelt ip-adresse
  • send ia-pd 1; spesifiserer at den skal be om en Prefix Definition med id 1.
  • request-linjene sier at den skal be om navnetjenere samt hva domenenavnet vårt er.
  • scriptet er et script som kjøres når en tildeling er gjort, f.eks. for ekstern konfigurasjon. Default-scriptet som kommer med wide-dhcpv6-klienten på Debian håndterer å legge inn info i /etc/resolv.conf
  • id-assoc pd 1-definisjonen er definisjonen for PD-delegeringen med ID 1.
  • prefix ::/48; sier at vi skal be om en prefix av denne størrelsen. Dette er det Canal Digital tildeler uansett…
  • prefix-interface eth1-definisjonen definerer informasjon som skal legges til på innside-interfacet
  • sla-id 0; betyr at første subnett under definisjonen skal brukes, dvs. 0
  • sla-len 16; betyr at 16 bits etter prefix-definisjonen skal definere nettet. 48-16=64, så subnettet blir ::/64
  • id-assoc na 1-definisjonen er definisjonen for den tildelte utside-adressen. Her trenger det ikke å stå noen ting, men den må være der….

På eth1 må vi så sette opp radvd. Dette er en tjeneste for å sette opp stateless autoconfiguration. Kort fortalt forteller den alle klientene på nettverket at ruten til verden kan nåes gjennom den, og så gir den nettverks-definisjonen en klient kan bruke for å generere sin egen adresse på nettverket. Man må da sørge for at klienter har IPV6 og stateless autoconfiguration på. På Linux:

$ cat /proc/sys/net/ipv6/conf/all/disable_ipv6
0
$ cat /proc/sys/net/ipv6/conf/all/accept_ra
1

Min /etc/radvd.conf tar jeg rett fra eksempelet:

interface eth1 # LAN interface
{
AdvManagedFlag off; # no DHCPv6 server here.
AdvOtherConfigFlag off; # not even for options.
AdvSendAdvert on;
AdvDefaultPreference high;
AdvLinkMTU 1280;
prefix ::/64 #pick one non-link-local prefix assigned to the interface and start advertising it
{
AdvOnLink on;
AdvAutonomous on;
};
};

Dette skulle egentlig virket. Men da jeg hadde satt det opp, forsvant prefixet hver halvtime, og i et kvarter deretter, før det så begynte å virke igjen. Så følg med, for her kommer det du ikke finner i noen annen guide!

Aller først skrudde jeg på debug og restartet klienten. Dette gjorde jeg med å endre i /etc/init.d/wide-dhcpv6-client og legge til opsjonene -d -D (etter ) i linjen for start-stop-daemon i start-seksjonen:

start-stop-daemon --start --quiet --pidfile $DHCP6CPID \
--oknodo --exec $DHCP6CBIN -- -d -D -Pdefault $INTERFACES

Jeg skal spare deg for hele feilsøkingen, men til slutt endte jeg opp med å lese kildekoden for å finne ut hva som egentlig skjedde. Da fant jeg en bug i kildekoden! Det finnes to måter å løse denne på:

  • Fikse kildekoden
  • Nettverket og rutingen virker også uten denne utside-adressen, fordi rutingen går via link-local-adresser. Det går alså an å fjerne send-ia na 1;, og alt vil virke ruting-messig.

Patchen er meget enkel (dette er en unified diff):
diff -ru wide-dhcpv6-20080615.old/addrconf.c wide-dhcpv6-20080615.new/addrconf.c
--- wide-dhcpv6-20080615.old/addrconf.c 2008-06-15 09:48:40.000000000 +0200
+++ wide-dhcpv6-20080615.new/addrconf.c 2014-12-02 07:48:07.000000000 +0100
@@ -173,7 +173,7 @@
sacreate ? "create" : "update",
in6addr2str(&addr->addr, 0), addr->pltime, addr->vltime);

- if (sa->addr.vltime != 0)
+ if (sa->addr.vltime != 0 && sacreate)
if (na_ifaddrconf(IFADDRCONF_ADD, sa) < 0) return (-1);

Det som manglet var en sjekk på om sacreate-variabelen var "true" før man prøvde å legge til adressen på interfacet. Er den false, eksisterer adressen fra før, og kallet for å legge den til vil feile. Funksjonen dette er definert i, update_address, vil returnere med -1, og resten av funksjonen ble ikke utført. Denne fiksen var relativt lett, fordi tilsvarende update_prefix-funksjon er nesten helt lik, og har denne testen.

Når denne fiksen ble utført, gikk fornyelsene av utside-addressene også greit, og problemet var løst!

Enda en gang om DRM.

August 21st, 2013

I det siste har jeg tenkt ennå mer på DRM.

Aschehoug gjør det mulig å sende bøker til Kindle (uten fysisk DRM iallefall), og En anerkjent norsk utgitt forfatter selger sine nyeste bøker uten DRM til en svært forbrukervennlig og fornuftig pris.

Så jeg begynte å tenke litt, på hvorfor jeg egentlig liker dette? Jeg hører til den gruppen veletablerte mennesker som har råd til å betale for meg. Så hvorfor liker jeg ikke DRM?

Jo, det skal jeg si dere – og spesielt bransjen: Som betalende kunde forventer jeg å bli behandlet som det, og ikke som en skurk. Hvis du går på restaurant og du til enhver tid har personale til stede som passer på at du ikke rapper bestikket, eller må igjennom metalldetektor for sjekk på vei ut, ja da *går* du ikke dit flere ganger.

I tillegg forventer jeg en viss frihet – hvis jeg liker å spise med venstre hånd, så gjør jeg det. Og hvis jeg heller vil ha en skje å spise med, forventer jeg at restauranten stiller opp med det, og ikke insisterer på at “beklager, det eneste vi støtter her er å spise med gaffel”.

Sånn er det med innhold jeg kjøper også. Kjøper jeg en e-bok, forventer jeg å bestemme hvordan jeg leser den. Jeg er veldig glad i å lese på min Paperwhite, og den eneste grunnen til at jeg kjøper norske e-bøker, er at det er såpass lett, tross alt, å strippe DRM og konvertere til Kindle-format.

Ånei! Der gjorde jeg det, jeg også! Innrømmet et lovbrudd. Eller kanskje ikke? Det finnes ennå ingen rettsavgjørelser på hvilke ikke-effektive brukssperrer som er lov å bryte. E-bok-DRM er knapt nok effektiv, litt googling og en alvtime, så har du knekt både Adobe sin og Amazon sin…

Men likevel: For meg har det en verdi å kjøpe fra bokhandler uten DRM. Fagbøker hos O’Reilly, uten DRM, er gjerne littegrann dyrere enn de samme bøkene med DRM fra Amazon. Så selv om jeg kan strippe DRMen fra Amazon-bøkene, kjøper jeg dem hos O’Reilly? Så hvorfor det?

Jo, igjen: Jeg trives med å bli behandlet som en ærlig kunde! Og jeg har tross alt råd til å betale for meg!

Om filmbransjen og deling – hvordan tjene mer penger for mindre innsats!

February 7th, 2013

Jeg er overbevist om en ting. Og det er at med fornuftige priser og enkel og god tilgjengelighet, er de aller fleste så ærlige at de vil betale for seg. Men siden filmbransjen tydeligvis ikke er det, så har jeg tenkt å fortelle dem i detalj hva de skal gjøre for å få folk til å ville betale for seg, i et par steg:

  • På kino-perioden kan godt være eksklusiv, iallefall den første biten. Men den eksklusive biten må ikke vare altfor lenge, for da begynner folk å kopiere fordi dere ikke vil selge til dem.
  • Utleie på DVD må skje samtidig med utleie i “enkeltleie”-markedet på nettet. Det finnes to typer mennesker: De som liker fysiske medier og de som liker å hente alt på nettet. Her er stort sett ikke overlapp, selv om det finnes en god del mennesker som gjerne kjøper fysiske medier etter de har sett det på nettet. Men de som ikke lenger bruker fysiske medier, de vil ikke vente på at folk skal være ferdig med å kjøpe fysiske medier. Da kopierer de heller, og da tapte dere et salg fordi dere ikke hadde varen å tilby denne gangen heller.
  • Når filmen blir sluppet for visning på TV, kan tjenester med fast månedspris, som Netflix o.l., få lov til å inkludere dem i sortimentet sitt. Ikke to år etterpå. Da kopierer folk, fordi et fåtall lenger forholder seg til hva som faktisk går på TV når de skal se en film. De vil ha større utvalg enn 15 filmer (=ca.-snittet av de kanalene som viser en film på det tidspunktet du hadde tenkt å se film)
  • Internett kan ikke deles opp i regioner og markeder, iallefall ikke slik at et marked får noe lenge før det andre. En viss prissegmentering kan nok likevel gå an – det er tilgjengelighet, og at prisen oppleves som rettferdig, som er det viktigste.
  • Folk godtar ikke at ikke prisene går ned når de fysiske mediene forsvinner.
  • Dropp DRM! Er det tilgjengelig til en fair pris vil folk kjøpe, og dropper du DRM vil du også nå de som ikke kan bruke/eier/har råd til det utstyret du tenkte på når du designet tjenesten.
  • En viss kopiering vil alltid skje, spesielt blandt folk som ikke har så god råd. Dere må konsentrere dere om å være minst like tilgjengelig som privatkopiene. Da vil de som har råd til det, betale for det. Og de som har kopiert før, vil lett gå over til å begynne å betale når de får råd til det.
  • Jeg overlater det til dere å tenke ut en løsning på hva de advoktatene dere sparer på denne strategien skal brukes til.

Nok en Microsoft-skatt unngått…..

August 17th, 2011

Min gamle EEE 901 som gjorde nytten på weekendturer hit og dit og var fryktelig grei å ha, har lenge ligget i skapet og samlet støv med en knust LCD-skjerm. Men i sommer tenkte jeg at noe skulle gjøres med den, så jeg ringer leverandøren, som sier:

“Nei, beklager. Det vil nok ikke lønne seg, og koste masse penger. Da er det nok mer lønnsomt å kjøpe ny”.

Kjøpe ny. Hmm. For en nerd med inntekt og god nok råd, kan det nok være fristenee, men: De har sluttet å selge mini-bærbare uten Microsoft-operativsystemer. Begrunnelsen leverandørene har gitt har vært mildt sagt varierende: “Vi fikk for stor returrate på produktet”, “passer ikke inn i sortimentet” og lignende. Andre igjen påstår at returraten på modeller med MS og Linux har vært ganske tilsvarende.

Her er min overbevisning:

  • Leverandørene er lite villige til å lære seg noe nytt.
  • Leverandørene valgte lite brukte Linux-distribusjoner lite basert på funksjonalitet, men mer basert på at det “lignet mer på Windows”, i den tro at de og brukerne ville være mer fornøyd med det.
  • Og sist men ikke minst – og dette er jeg overbevist om at fortsatt skjer – Microsoft sine selgere la press på sine kontakter hos leverandørene for å få dem til å enten droppe Linux eller la Microsoft se mer fordelaktig ut.

Noen uker til ble EEEen liggende i skapet, til jeg tilfeldigvis surfet innom en nettsjappe i Kina. Stor og fin, gunstige priser, og gratis frakt. De fleste vet sikkert hvilken jeg mener, men dette var ikke ment som et reklameinnlegg for dem 🙂

Jeg ser at de har fryktelig mye reservedeler til ymse hardware, og jommen: De hadde skjermer til EEE 901. Kosta ikke mange hundrelappene heller. Og bruksanvisningen som lå der, så ut som at selv en hardwarekløne som meg burde kunne klare å bytte den.

Som sagt så gjort, og i dag er den byttet!

Og mitt løfte fra noen år tilbake om at jeg hadde betalt min siste Microsoft-skatt er fortsatt ikke brutt. Take that, Microsoft og hardware-leverandører!

Menns livsstil…

March 18th, 2010

I går, da jeg skulle hjem fra speidermøte, hadde jeg 15 minutter på busstasjonen mellom bussene, så jeg tok en tur innom bladhylla på Narvesen. Der gikk jeg forbi en hylle med tittelen “Livsstil Menn”. Så jeg tittet litt nysgjerrig i den, for å finne ut hva slags livsstil jeg egentlig er ment å ha, som mann…

Resultatet av en kjapp telling viste at det var *105* blader om ting med motorer i. Vanlige biler, racerbiler, sportsbiler, traktorer, anleggsmaskiner, campingbiler – de sto der, alle sammen.

Andre blader? Null. Niks. Zero.

Vi er visst noe ensporet, vi menn….

this is sent via jabber

January 27th, 2010

Sending this to my blog

January 27th, 2010

This is a picture

I am blogging this

January 27th, 2010

This is a blog

Rainbow at sunset.

August 19th, 2008

On my way home by bus in the evening, I came across this beautiful rainbow in sunset light. Naturally, I had to push the stop button and jump off the bus to photograph it. Click on a picture to go to this gallery.

Backporting apt and hildon-application manager…

March 4th, 2008

…or, a failed attempt at breaking OS2008!

Recently, I’ve been mildly annoyed by an application manager bug, namely this one: A long version field making only a very small portion of the name shown in the list of available packages.

Seeing that it’s supposed to be fixed in the next version of ITOS, I decided to go on the wild side: What about trying to compile the SVN version of application manager? The source is on garage, and can be checked out with svn checkout https://garage.maemo.org/svn/hildon-app-mgr.

Trying to compile it in scratchbox, I found I needed a newer libapt-pkg-dev-package than what can be found from the
repositories. So, off hunting for newer version of apt, which I found here. And it compiled without a hitch – so I upgrade the scratchbox apt, apt-utils and libapt-pkg-dev to version 0.7.6maemo3-unreleased. And we’re back to hildon-application-manager compiling.

hildon-application-manager now compiles! And also installs in scratchbox. So, now it’s time to get really adventurous: what about on my n810? The apt and apt-utils packages installs without a hitch, but – nuts, the hildon-application-manager package conflicts with hildon-update-notifier, that is required by a bunch of packages I don’t feel like uninstalling. And now, my old hildon-application-manager no longer works. I’m starting to feel like this was a bad idea – but I had half expected it when I started.

So I start digging around, and find that there’s no overlap on any files in what’s provided by hildon-application-manager and hildon-update-notifier. But hildon-application-manager now includes a file libhildon-update-notifier.so! Digging around in the debian/control, I see that it’s specified there: It conflicts with and replaces hildon-update-notifier. Aha! So it has simply included it in the application itself. But seeing that it doesn’t actually conflict with any files, I decide to get more experimental: I removes hildon-update-notifier from the Conflicts: and Replaces: field, and rebuild the package. And now, it even install on the device.

It’s worth to note that it probably conflicts with osso-software-version too. But I had already uninstalled that package when I installed the RTCOMM beta, so I wasn’t too worried about that….

But, installing isn’t all, I was more interested in whether or not it actually worked. And I’m happy to say, it does! I’m not sure I can recommend this route for anyone that wants to walk on the safe side of the road, but so far, I have not noticed any problems using it. And it did actually solve my problem with the long version number 🙂

So if you feel like walking on the wild side, either compile it yourself (it’s a good introduction to simple scratchbox development), or download the packages here: