Server and network in the shed, up and running complete with IPv6. It won't get an IP55 rating (being able to deal with a bit of water) but it pings, measures the powerline network throughput and makes pretty graphs of that throughput.
Shednet is upSomehow I found this an interesting sight to photograph. And I like the term Shednet.
So the first component is tested: I can get a system running there complete with network. Now to find some time to set up the PC and a weather station and measure temperature and humidity in the shed.
Update 2010-08-22: I remembered why I originally got the idea to test a PC in the shed: to test a weather-station in the shed as a preparation for doing something again for project sundial. The "powered by alternative energy" part of that project isn't going to be implemented: solar panels would be really expensive but something really low-power with Linux in a (semi-)outdoor housing would work nicely for a weather station and ntp server.
De adsl snelheid is nu helemaal gezakt. Na eerdere problemen met hikken heb ik weer
eens xs4all gebeld. Hun oplossing was nu om de lijn terug te zetten naar een
12 megabit profiel. Dat ging een tijdje goed en leverde een stabiele lijn op
maar toen ging het weer mis...
=>:adsl info
Modemstate : up
Operation Mode : G.992.5 Annex B
Channel Mode : interleaved
Number of resets : 6
Vendor Local Remote
Country : 0f b5
Vendor : TMMB BDCM
VendorSpecific : 0000 ff91
StandardRevisionNr : 00 02
Downstream Upstream
Margin [dB] : 17.5 9.0
Attenuation [dB] : 20.5 12.0
OutputPower [dBm] : 10.0 13.0
Available Bandwidth Cells/s Kbit/s
Downstream : 13389 5677
Upstream : 2426 1029
Transfer statistics
Errors
Received FEC : 816402
Received CRC : 222198
Received HEC : 7040
Transmitted FEC : 0
Transmitted CRC : 8329
Transmitted HEC : 8097
Near end failures since reset
Loss of frame: 0 failures
Loss of signal: 0 failures
Loss of power: 0 failures
Errored seconds: 2830 seconds
Near end failures last 15 minutes
Loss of frame: 0 seconds
Loss of signal: 0 seconds
Loss of power: 0 seconds
Errored seconds: 1 seconds
Near end failures current day
Errored seconds: 4 seconds
Near end failures previous day
Errored seconds: 2826 seconds
Minder dan 6000 kilobit, tijd om er weer eens achteraan te zitten. Het lijkt
alsof er een verband is met regenbuien, en dan moet er echt eens door KPN naar
de lijn gekeken worden...
At work one of my main projects at the moment is improving monitoring for beta-ict. I am used to mon at the computer science department but that shows its age a bit and I wanted to try something newer.The choice in monitoring system was mainly for something which could monitor both system variables (free disk space, free memory, system load, whether certain needed processes were running) and service availability (is the network available, is ldap available, are web servers up and not giving out weird error messages).
I chose zabbix. It has an interesting approach: it measures variables, stores results and trends and then you can do stuff with the stored data. Such as monitoring whether certain thresholds aren't crossed, so you can do your normal tests. Or more complicated monitoring of trends or changes. But you can also make graphs of that same data. And you can use the triggers to make nice long-term availability reports.
One thing I learned is that the suggestion in the manual to use a new version postgres (>= 8.3) is to be taken serious. With 8.0 the server running zabbix regularly got up to a load of 10 on adding new systems to be monitored and historic monitoring data was lost for certain time periods. Dumping the database, installing postgres 8.4 and importing the data again and continuing with the same setup made everything lots faster and no data has been lost since.
What is also interesting is the option to use remote proxies to gather data from otherwise firewalled networks and the option to split servers / services into groups. Eventually we may give the 1st-line servicedesk their own view of our zabbix server where they can view whether main services are available so they are aware of troubles before they need to ask us.
According to Google finally indexing the IPv6 internet - Fix6 the first sightings have been done of a googlebot with an IPv6 address. My IPv6-reachable websites haven't been blessed by a visit from the IPv6 googlebot yet. What will googlebot do when I post a link to http://[2001:980:14ca:42::18] ?And on a different note about google: last year I noticed googledns did not give out AAAA records for www.google.com. I retested it and found it (now?) depends on where you ask. At a place not in the google IPv6 program:
koos@kolham:~$ dig +short @8.8.8.8 www.google.com aaaa www.l.google.com. koos@kolham:~$ dig +short @8.8.4.4 www.google.com aaaa www.l.google.com. koos@kolham:~$And at a place in the google IPv6 program:koos@greenblatt:~$ dig +short @8.8.8.8 www.google.com aaaa www.l.google.com. 2a00:1450:8001::63 koos@greenblatt:~$ dig +short @8.8.4.4 www.google.com aaaa www.l.google.com. 2a00:1450:8001::63 koos@greenblatt:~$Yes, that first place needs to turn their plans about IPv6 into doing something with it.
Ik ben blij dat ik geen mobiel Internet van T-mobile gebruik: T-Mobile wil websites laten betalen voor doorgifte - Bits of Freedom waar ik mijn eigen commentaar aan heb toegevoegd (het lijkt weer ouderwets "bellheads versus netheads").Ook een mooie actie: Neelie Kroes krijgt van een mobiele aanbieder een sms die de regels over hoge tarieven wel erg typisch uitlegt. Jammer voor die provider dat Neelie Kroes zelf die regels heeft (mee-) bedacht.
De SpeedTouch 510 levert ook interresante getallen op:
[adsl]=>:adsl info
Modemstate : up
Operation Mode : G.DMT Annex B [ISDN Overlay Mode]
Channel Mode : interleaved
Number of resets : 2
Vendor Local Remote
Country : 0f b5
Vendor : ALCB BDCM
VendorSpecific : 0000 6291
StandardRevisionNr : 01 01
Downstream Upstream
Margin [dB] : 6.5 9.0
Attenuation [dB] : 24.0 12.0
OutputPower [dBm] : 18.5 12.0
Available Bandwidth Cells/s Kbit/s
Downstream : 16905 7168
Upstream : 2113 896
Transfer statistics
Errors
Received FEC : 988
Received CRC : 583
Received HEC : 447
Transmitted FEC : 21
Transmitted CRC : 42
Tranmsitted HEC : 34
Nog geen 8 megabit (het is geen adsl2 of adsl2+, dus ergens bij 8000 zit wel
de limiet) en de errorcounters lopen al op.
Gisterenavond maar eens de xs4all
klantenservice gebeld over de matige ADSL snelheid en de regelmatige hikken.
Dat was even flink in de wacht staan: ondanks de aankondiging dat het
"iets meer dan 1 minuut wachttijd" zou zijn duurde het bijna 25 minuten
om iemand aan de lijn te krijgen.
Eigenlijk wilde ik gewoon een downgrade naar 8 megabit om van het probleem
af te zijn. Maar aan de hand van mijn beschrijving van de problemen en de
metingen en logs aan de kant van xs4all kwam de medewerker van de
klantenservice met de suggestie dat het wel eens een storing aan het
modem of aan de telefoonlijn zou kunnen zijn. De aanpak is nu om het eens
met een ander modem te proberen, en aan de hand van wat dat oplevert
KPN er op uit te sturen om eventuele roestige verbindingen in de lijn
te vinden en/of alsnog een downgrade aan te vragen.
Ik ben eens begonnen met het modem van ADSL2+ mode terug te zetten naar
ADSL2 en dat levert interresante getallen op:
=>:adsl info
Modemstate : up
Operation Mode : G.992.3 Annex B
Channel Mode : interleaved
Number of resets : 116
Vendor Local Remote
Country : 0f b5
Vendor : TMMB BDCM
VendorSpecific : 0000 ff91
StandardRevisionNr : 00 02
Downstream Upstream
Margin [dB] : 8.0 8.0
Attenuation [dB] : 18.5 12.0
OutputPower [dBm] : 19.0 12.5
Available Bandwidth Cells/s Kbit/s
Downstream : 18030 7645
Upstream : 2426 1029
Transfer statistics
Errors
Received FEC : 2333249
Received CRC : 305427
Received HEC : 14957
Transmitted FEC : 0
Transmitted CRC : 123909
Transmitted HEC : 230400
ondanks dat de snelheid aangepast is blijven er relatief veel errors
langskomen. Vanavond eens met een SpeedTouch ST510i proberen, en ik heb
binnenkort beschikking over een andere ST546i.
Vandaag had ik de tijd om even langs het xmsnet huis in Utrecht te gaan om eens te vragen naar de voortgang. Ik heb tijden geleden aangegeven bij de xmsnet utrecht postcodecheck dat ik wel interresse heb, maar daar kwam nooit een reactie op. Een medewerker van xmsnet heeft het even nagevraagd en de aanvraag is keurig opgenomen in het systeem maar de interesse in onze buurt is niet groot genoeg op dit moment om te gaan graven, en dat kan afhankelijk van allerlei factoren nog maanden of jaren duren.Het fiber-to-my-home project schiet dus nog niet op. En dat terwijl het televisie aanbod bij xmsnet (van glashart media) al het verschil met ziggo basis televisie waard is. Technisch op den duur ook: opnemen van digitale televisie met behulp van de computer is iets wat door xmsnet niet geblokkeerd wordt.
Misschien toch maar eens wat buren enthousiast proberen te maken. Dat helpt altijd volgens de mensen van xmsnet. Hallo buren in "Plan 60" in Overvecht in Utrecht: U wilt glasvezel van xmsnet.
Update 2010-07-19: In andere gebieden van Nederland gaat de glasvezel makkelijker: Henk van de Kamer kan in Aalten glasvezel verwachten. En doet dat dus ook van harte. Opmerkelijk is ook dat als 40% van de potentiele aansluitingen zich vooraanmelden het aangelegd kan worden naar alle aanmelders en bij 60% naar alle potentiele aansluitingen, waarbij de niet-klanten dan gewoon een glasvezel koppelpunt in de meterkast krijgen waar verder geen diensten op aangeboden worden. Op zich is dat natuurlijk wel iets wat je huis potentieel meer waard maakt, een glasvezel koppelpunt in de meterkast. Jammer dat je als huiseigenaar in dit land nog nergens de mogelijkheid hebt om te zeggen "doe maar, en ik neem (een deel van) de initiele investering over".
The Hurricane Electric IPv4 Exhaustion Counter on this page has dropped below 365 days. What does this mean exactly?At the end of that period there will be no more IPv4 address blocks to give out to the several Regional Internet Registries. But those have their own buffers so it won't be all over at that moment (and the IPv4 Internet will not stop functioning either).
What will happen is that when those buffers run out the moment will come that one of those Regional Internet Registries will have to answer "NO, not available" to a request for IPv4 space. The timeframe at which this will happen may vary between months (APNIC, Asia-Pacific region) and years (AfriNIC, Africa) given the current rates. What this will mean is a situation where IPv6 is the only working way to give new systems on the Internet working unique addresses. Will the world be ready for this moment? Probably not.
The vision of T-mobile USA for the near future: IPv6 is the network protocol, IPv4 is "legacy" and will be hidden behind NAT64 gateways. Content providers better take note:"Our users are going to access your content over IPv6. The only relevant question is 'will we make the AAAA record or will you?' Wouldn't you rather be the one to do it so you have control?"Time for content-providers to think about IPv6 strategy. Via T-Mobile is pushing IPv6. Hard. - Living with IPv6.
De ADSL lijnsnelheid is nogsteeds voodoo. Tijdens onze vakantie heeft het er zelfs een dag uitgelegen, maar dat was niet op ADSL niveau. Alleen kon er geen sessie opgebouwd worden met xs4all. Later in die vakantie ging de download snelheid naar 8083 kilobit en bleef daar. Na een softwarematig schopje in het modem ging de snelheid weer naar ruim 14 megabit maar na een poosje stabiliseerde het zich op 12334 kilobit. Het is dat er geen abonnement tussen 8 en 16 megabit zit, maar met al deze instabiliteit is 8 megabit misschien toch weer veiliger.
Marco Hogewoning presented the IPv6 CPE survey at the recent RIPE Meeting in Prague. RIPE Labs now has the results on-line: IPv6 CPE Survey, what equipment is available at the moment to get IPv6 at home and what is it compatible with. There is a scary story in the lack of width of the resulting matrix: only a few vendors support IPv6 and not the ones (Alcatel / Speedtouch / Thomson / Technicolor or whatever they are called today) which produce the really big numbers.
De niet maximale snelheid van de ADSL ligt duidelijk niet aan de binnen
bekabeling. Ondertussen staat het ADSL modem beneden in de meterkast en
is er uit het afbreken van die telefoonlijn naar zolder een interresante
verbinding gekomen.
Ook een testje zonder ADSL splitter leverde geen echte verandering op.
Grappig is dat na het terugzetten van de splitter de snelheid iets omhoog
is gegaan (van 13 megabit naar 15 megabit). Gaat vast wel weer een keer
omlaag. Ooit had ik een 2draads huurlijn op maar liefst 33.6 kilobit die bij
zware regenbuien naar 28.8 kilobit of zelfs minder wegzakte, daar moet ik
nu aan terugdenken.
=>:adsl info
Modemstate : up
Operation Mode : G.992.5 Annex B
Channel Mode : interleaved
Number of resets : 19
Vendor Local Remote
Country : 0f b5
Vendor : TMMB BDCM
VendorSpecific : 0000 ff91
StandardRevisionNr : 00 02
Downstream Upstream
Margin [dB] : 6.5 16.0
Attenuation [dB] : 21.5 12.5
OutputPower [dBm] : 20.5 13.0
Available Bandwidth Cells/s Kbit/s
Downstream : 35702 15138
Upstream : 2426 1029
End of an era: Duke university is to shut down their Usenet server, the place where it all started.This week marks the end of an era for one of the earliest pieces of Internet history, which got its start at Duke more than 30 years ago.Maybe newer services like twitter and facebook have taken over, but there is still nothing compared to the distributed nature of Usenet. Those services all have centralized storage of their data which means there is one place to delete it. With Usenet, you can't unpublish anything. This is both a blessing and a curse.On May 20, Duke will shut down its Usenet server, which provides access to a worldwide electronic discussion network of newsgroups started in 1979 by two Duke graduate students, Tom Truscott and Jim Ellis.
Working with a graduate student at UNC-Chapel Hill, they came up with a simple program to exchange messages and files between computers at Duke and UNC using telephone modems.
Ok, this one was new to me:-bash: ./storscript: /bin/bash: bad interpreter: Text file busyHow? the script was copied using scp and there was a hanging sshd (something about a not 100% reliable network).
Ik dacht: ik vraag vandaag eens die 'upgrade' aan bij xs4all, van lite-oud 8 megabit naar lite-nieuw 16 megabit, dan doen ze die maandag of dinsdag en dan weet ik waar ik aan toe ben met de bekabeling omdat ik daar toch al wat meer problemen verwacht.Binnen 5 minuten na 'bevestigen' deed de telefoonlijn hik en stond er ineens 14583 kilobit downstream. Zo automatisch gaat dat blijkbaar, daar is vast geen monteur aan te pas gekomen. Maar er is dus duidelijk ruimte voor verbetering aan de bekabeling: de verbinding is nu niet heel stabiel, de snelheid is al even omhooggegaan naar 14769 en toen weer gezakt naar 12743 kilobit. Tijd om te kijken hoe een en ander beter kan. Maar aangezien de telefoon ook wat raars doet kijk ik even verder naar mogelijkheden.
De adsl verbinding had weer een slechte dag vandaag, de downstream snelheid was gezakt van 8006 naar 7344 kilobit. Maar eens de telefoonlijn die voor adsl gebruikt wordt nagekeken en het bleek dat deze lijn een rare aftakking had. Dat helpt natuurlijk niet. Die aftakking er af gehaald en toen schoot de noise margin weer omhoog. En na een hint naar het modem om even de snelheid opnieuw te bepalen was het weer 8006 kilobit.
De optie om de hele lange telefoonkabel op te heffen en het adsl modem beneden te zetten blijft natuurlijk. Maar dan moet er weer iets met utp kabel door het huis.
IP version 6 has grown up: I just noticed the first ipv6 firewall log entries which I did not cause with my own testing:SRC=2002:915e:bf90:000d:f9c9:eab8:7632:0f6d DST=2001:0888:1011:0000:0000:0000:0000:0694 LEN=72 TC=0 HOPLIMIT=120 FLOWLBL=0 PROTO=TCP SPT=49494 DPT=445 WINDOW=8192 RES=0x00 SYN URGP=0A 6to4 IPv6 address trying something stupid with windows filesharing. IPv6 has grown up!
Werkend IPv6 via zowel de tunnel als via de native aansluiting. Ik hou nog even de tunnel aan omdat die een voorspelbare v6 range heeft en ik daarin services heb die extern bereikbaar moeten zijn zoals deze website:$ dig +short idefix.net aaaa 2001:888:1011::694En nog veel lastiger om te wijzigen:Server Name: NS2.IDEFIX.NET IP Address: 2001:888:1011:0:0:0:0:694 IP Address: 82.95.196.202 Registrar: EPAG DOMAINSERVICES GMBHIk heb er dus voor gekozen wireless clients adressen uit de native range te geven en te routeren via die link, en de server en de wired aansluitingen nog via de v6 tunnel. Daar is rulebased routing voor nodig, en omdat ik verbindingen vanaf de server nog via de tunnel wil is 'native' de uitzondering voor mij. Eerst probeerde ik 'niet tunneladres' als regel:ip -6 rule add type unicast not from 2001:888:1011::/48 priority 32765 table 17En dan de routing in /etc/ppp/ipv6-up.d/default :ip -6 route add default dev ${PPP_IFACE} table 17Maar dat werkte niet: verkeer vanaf de server naar de wireless clients werd ook de ppp0 link opgestuurd, dat werkte dus niet. Dat was weer te omzeilen door een regel voor het wireless netwerk in table 17 te dupliceren, maar dat is niet handig bij eventuele wijzigingen van de IPv6 range.
Beter: een filter maken wat 'native' verkeer herkent. Een beetje voorkennis helpt: in de xs4all native dsl proef krijgen klanten een /48 uit 2001:980::/32. Dus dan in /etc/ppp/ipv6-up.d/default :ip -6 rule add type unicast from 2001:980::/32 priority 32765 table 17 ip -6 route add default dev ${PPP_IFACE} table 17 || trueDe gewone ipv6 default route komt uit /etc/network/interfaces :auto xs4allipv6 iface xs4allipv6 inet6 v4tunnel endpoint 194.109.5.241 address 2001:888:10:11::2 netmask 64 up ip tunnel change xs4allipv6 ttl 64 up ip -6 addr add 2001:888:1011::13/128 dev xs4allipv6 up ip -6 route add unreachable 2001:888:1011::/48 # rest /48 nullrouten, specifiekere routes hebben voorrang up ip -6 route add default via 2001:888:10:11::1 src 2001:888:1011::13 up ip -6 addr change 2001:888:10:11::2/64 dev xs4allipv6 preferred_lft 0 # tunneladres nooit als uitgaand adres gebruiken # down ip -6 route del unreachable 2001:888:1011::/48 # maar dan moet ik ook die nullroute weer weghalen :)En nu werkt het voor beide IPv6 ranges. Native:$ traceroute6 abaris traceroute to abaris.idefix.net (2001:470:1f15:db:131:211:84:204) from 2001:980:111b:2:21f:e1ff:fe45:2894, port 33434, from port 63747, 30 hops max, 60 byte packets 1 2001:980:111b:2:21f:c6ff:fe59:76f6 (2001:980:111b:2:21f:c6ff:fe59:76f6) 1.517 ms 1.773 ms 5.713 ms 2 lo1.dr4.1d12.xs4all.net (2001:888:0:4401::1) 37.795 ms 39.791 ms 20.754 ms 3 2001:888:0:4403::2 (2001:888:0:4403::2) 30.975 ms 17.414 ms 20.025 ms 4 0.ge-1-2-0.xr1.sara.xs4all.net (2001:888:2:2::1) 19.104 ms 21.797 ms 26.274 ms 5 10gigabitethernet3-3.core1.ams1.he.net (2001:470:0:e8::1) 24.385 ms 17.858 ms 17.255 ms 6 gige-gbge0.tserv11.ams1.ipv6.he.net (2001:470:0:7d::2) 24.295 ms 24.621 ms 23.004 ms 7 abaris.idefix.net (2001:470:1f15:db:131:211:84:204) 30.448 ms 27.849 ms 21.872 msEn tunnel:$ traceroute6 abaris traceroute to abaris.idefix.net (2001:470:1f15:db:131:211:84:204) from 2001:888:1011::13, port 33434, from port 53569, 30 hops max, 60 byte packets 1 xs4all17.ipv6.xs4all.nl (2001:888:10:11::1) 17.177 ms 16.589 ms 17.447 ms 2 104.ae0.xr4.1d12.xs4all.net (2001:888:0:3::1) 25.176 ms 22.599 ms 15.982 ms 3 0.ge-0-2-0.xr1.sara.xs4all.net (2001:888:2:1::1) 22.124 ms 19.112 ms 19.868 ms 4 10gigabitethernet3-3.core1.ams1.he.net (2001:470:0:e8::1) 19.501 ms 16.943 ms 15.742 ms 5 gige-gbge0.tserv11.ams1.ipv6.he.net (2001:470:0:7d::2) 24.070 ms 20.348 ms 19.108 ms 6 abaris.idefix.net (2001:470:1f15:db:131:211:84:204) 25.500 ms 24.720 ms 21.881 msDe juiste data in radvd.conf komt uit een slim scriptje wat net nadat wide-dhcp6c de interfaces geconfigureerd heeft toeslaat. Op het moment dat het script /etc/wide-dhcpv6/dhcp6c-script uitgevoerd wordt is iets te vroeg, dus ik heb daar in staan:RADVDCONF=/etc/radvd.conf genradvdconf () { echo > $RADVDCONF for IFACE in "$@" do /etc/wide-dhcpv6/iface2radvd.sh $IFACE >> $RADVDCONF done } ( sleep 5 ; genradvdconf eth0.1 eth0.3 ; /etc/init.d/radvd reload ) &En even doordenkend: als ik ooit iets probeer te benaderen bij een andere xs4all-v6-native klant heb ik inderdaad een probleem (met het ontvangen van de antwoorden). Deze oplossing is dus niet blijvend. Maar als IPv6 over dsl gewoon wordt dan hoef ik niet meer met die tunnel bezig te zijn.
De speedtouch 510 geeft een duidelijk slechtere lijnkwaliteit:=>:adsl info Modemstate : up Operation Mode : G.DMT Annex B [ISDN Overlay Mode] Channel Mode : interleaved Number of resets : 1 Vendor Local Remote Country : 0f b5 Vendor : ALCB BDCM VendorSpecific : 0000 6291 StandardRevisionNr : 01 01 Downstream Upstream Margin [dB] : 8.5 8.0 Attenuation [dB] : 24.0 11.5 OutputPower [dBm] : 18.5 12.0 Available Bandwidth Cells/s Kbit/s Downstream : 17962 7616 Upstream : 2113 896Eens kijken of daar nog iets aan verandert met multimode:[adsl]=>config opermode = multimodeNee, gegevens blijven hetzelfde. Tijd om de speedtouch 546i om te programmeren naar pptp mode zodat die het werk kan doen. Dan heb ik ook weer adsl carrier stats.
