Dankzij een motie die Arda Gerkens (SP) en Martijn van Dam (PvdA) willen gaan indienen gaat demissionair minister Maria van der Hoeven van Economische Zaken onderzoeken of de overheid bij aanbestedingen verplicht moet vragen naar IPv6.
Goed nieuws voor IPv6 acceptatie. Soms moet een overheid de aanmerkelijke macht inzetten om de markt even een sturing te geven in een richting die later nuttig is voor diezelfde markt.
Bron: Kamerleden @ArdaG en @martijnvdam zijn top. Besteden ook aandacht aan niet-sexy maar wel belangrijke zaken - Twitterbericht Erik Huizer.
De adsl aansluiting is tijden stabiel op 7968/1024 ipv 8000/1024. Met alles rond de aankomende xs4all snelheidsverhoging wilde ik weten of dit de maximale snelheid was die uit de lijn wilde komen. Ik heb in de logs terug zitten graven en sinds de omschakeling van fast op interleaved is 7968 de standaard snelheid. Daarvoor was de downloadsnelheid een tijdje instabiel. Verder lijken de specs ok:Downstream Upstream Margin [dB] : 10.5 20.0 Attenuation [dB] : 19.0 11.5 OutputPower [dBm] : 19.0 12.5 Available Bandwidth Cells/s Kbit/s Downstream : 18792 7968 Upstream : 2415 1024Als ik zo lees over adsl interleaving kan het toch wel kloppen dat de snelheid nu 7968 kilobit/seconde is en ga ik straks naar een hogere snelheid (ergens in de buurt van 16000 kilobit/seconde).
Update : Later bedacht ik me dat ik ooit de adsl config opermode had aangepast naar multimode om stabieler te zijn met adsl1. De grens van adsl1 zit ergens rond 8000 kilobit. Dus geprobeerd:[adsl]=>config opermode = multi_adsl2plusEn nu zijn de specs:Downstream Upstream Margin [dB] : 6.0 18.0 Attenuation [dB] : 20.0 11.5 OutputPower [dBm] : 2.0 13.0 Available Bandwidth Cells/s Kbit/s Downstream : 18879 8005 Upstream : 2426 1029Ik ben benieuwd wat het oplevert als er straks 16000/1024 (nee, nogsteeds geen upstream verbetering..) ingesteld wordt. Mocht het tegenvallen dan heb ik de optie om het adsl modem wat nu op zolder staat een stuk dichter bij het aansluitpunt te plaatsen.
We volunteered ntp.cs.uu.nl for extra capacity for the Turkish ntp pool, and the results are quite visible in the ntp.cs.uu.nl statistics. Suddenly peaks are near 5000 packets per second. But ntpd (and the freebsd kernel) deal with it without problems.
I tried to use the --filter option in rsync but I was a bit baffled by the syntax and the manpage is nice but I couldn't understand. I wanted certain directories completely, other directories default excluded and certain files in one directory but not all. After some trail and error and talking to the teddybear:rsync -rvv --progress /home/koos/rsyncsource/ /home/koos/rsyncdest --filter='merge /home/koos/rsyncfilter'And in the filter file name things to include and exclude:+ /wel/ - /niet/ + /random/file - /random/*And the result is what I want:$ ~/bin/testrsync building file list ... [sender] showing directory wel because of pattern /wel/ [sender] hiding directory niet because of pattern /niet/ [sender] hiding file random/niet because of pattern /random/* [sender] showing file random/file because of pattern /random/file 7 files to consider delta-transmission disabled for local transfer or --whole-file random/ random/file 0 100% 0.00kB/s 0:00:00 (xfer#1, to-check=4/7) wel/ wel/file1 0 100% 0.00kB/s 0:00:00 (xfer#2, to-check=2/7) wel/file2 0 100% 0.00kB/s 0:00:00 (xfer#3, to-check=1/7) wel/file4 0 100% 0.00kB/s 0:00:00 (xfer#4, to-check=0/7) total: matches=0 hash_hits=0 false_alarms=0 data=0 sent 319 bytes received 126 bytes 890.00 bytes/sec total size is 0 speedup is 0.00Now to do this on a filesystem with 151000 files.
The year 2010 seems to be an unfathomable far future, I just found another Y2.01K problem. The zonecheck tool gives a warning which reads '2010 is not a valid year':w> The format of the serial number is not YYYYMMDDnn | Ref: RFC1912 (p.3) | The recommended syntax is YYYYMMDDnn (YYYY=year, MM=month, DD=day, | nn=revision number). `----- -- -- - - - : The serial 2010010502 doesn't seem to be in the YYYYMMDDnn format. `..... .. .. . . .And the code indeed shows:# DESC: recommanded format for serial is YYYYMMDDnn def chk_soa_serial_fmt_YYYYMMDDnn(ns, ip) serial = soa(ip).serial return true if (serial > 1999000000) && (serial < 2010000000) { 'serial' => serial } endThe far future is happening today.
Filed as Ubuntu bug #503501.
Power failure this morning at work.. which left us not in the dark (enough
emergency lighting) but with a completely silent serverroom. When the power
came back we had some hours of work to get everything up and running again.
Worst problem was with a number of Xen based virtualhosts, some centos upgrade
had suddenly created a network device virbr0 which uses NAT and a
local dhcp pool and enslaved all xen domU network interfaces under that
bridge with no access to the 'real' network because NAT was not set up so
their NFS root mount failed. The details on virbr0:
virbr0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
inet addr:192.168.122.1 Bcast:192.168.122.255
A bit hard to disable, but at the end
ifconfig virbr0 down ; brctl delbr virbr0 helps to get rid of the
weird bridge, and all domUs will start after that.
Na de verhuizing van HCC!net mail (met diverse mailtjes aangekondigd) blijf ik nu zien uit fetchmail:fetchmail: Server CommonName mismatch: localhost.localdomain != pop.hccnet.nl fetchmail: Server certificate verification error: self signed certificateEn daar is geen uitleg over in de Veel gestelde vragen over HCC!net mail. Workaround: sslproto ssl23 in de regel voor pop.hccnet.nl zodat er geen TLS gebruikt wordt (ontleend aan How can I tell fetchmail not to use TLS if the server advertises it? Why does fetchmail use SSL even though not configured? - The Fetchmail FAQ). Beter zou natuurlijk zijn als pop.hccnet.nl gewoon een echt certificaat zou hebben.
Opmerkelijk is trouwens de sterk ontbrekende optie om HCC!net support te bereiken via e-mail op de contact pagina. Ik ga geen 60 cent per minuut betalen om ze uit te leggen dat ze het stuk gemaakt hebben.
Maybe related to the constructionwork at home or to problems with the DSL network to my provider but 29 October was a day of intermittant DSL problems. And indeed, the resulting line quality graph looks 'interesting'.
I'm playing a bit with NDPMon - IPv6 Neighbor Discovery Protocol Monitor, now at version 1.4.0. Sofar, after configuring it in the right configuration file it likes one part of the home network (the wired part). I'm looking at it both from the viewpoint of playing with IPv6 and from the viewpoint of network security: can I use this to trace users of a network. In a large network like the one at work I could imagine ndpmon doing for IPv6 what arpwatch does for IPv4. Combine that with logs from the switches for tracing ethernet addresses and I see possibilities for a big, usable and at the same time manageable and secure network.
I updated my PXElinux boot menu with a few changes to the pxelinux.cfg/default so there are a number of handy extra booting options:DEFAULT vesamenu.c32 PROMPT 0 TIMEOUT 100 MENU TITLE Heavy Duty Boot Service MENU BACKGROUND boot.jpg # http://www.flickr.com/photos/bottinex/2948585175/ LABEL local MENU LABEL ^Boot from local disk (default) localboot 0 LABEL memtest MENU LABEL ^Memory test kernel memtest86 LABEL pldrescue MENU LABEL ^PLD Linux rescue KERNEL pld-20090221/boot/isolinux/vmlinuz APPEND initrd=pld-20090221/rescue.cpi,pld-20090221/custom/custom.cpi root=/dev/ram0 CONF=”`/dev/fd0:/rescue`;;;;;;;;;;;” IPAPPEND 1 LABEL ubuntu-i386 MENU LABEL Ubuntu i386 menu KERNEL menu.c32 APPEND ubuntu-installer/ubuntu-i386.cfg LABEL ubuntu-amd64 MENU LABEL Ubuntu amd64 menu KERNEL menu.c32 APPEND ubuntu-installer/ubuntu-amd64.cfg LABEL cpuid MENU LABEL ^Identify Processor KERNEL cpuidtest.c32The ubuntu submenus are copied from the ubuntu CD's and slightly adjusted to the local situation:MENU TITLE Ubuntu i386 menu DISPLAY ubuntu-installer/i386/boot-screens/boot.txt LABEL install kernel ubuntu-installer/i386/linux append vga=normal initrd=ubuntu-installer/i386/initrd.gz -- LABEL linux kernel ubuntu-installer/i386/linux append vga=normal initrd=ubuntu-installer/i386/initrd.gz -- LABEL cli kernel ubuntu-installer/i386/linux append tasks=standard pkgsel/language-pack-patterns= pkgsel/install-language-support=false vga=normal initrd=ubuntu-installer/i386/initrd.gz -- LABEL expert kernel ubuntu-installer/i386/linux append priority=low vga=normal initrd=ubuntu-installer/i386/initrd.gz -- LABEL cli-expert kernel ubuntu-installer/i386/linux append tasks=standard pkgsel/language-pack-patterns= pkgsel/install-language-support=false priority=low vga=normal initrd=ubuntu-installer/i386/initrd.gz -- LABEL rescue kernel ubuntu-installer/i386/linux append vga=normal initrd=ubuntu-installer/i386/initrd.gz rescue/enable=true -- LABEL mainmenu MENU LABEL Return to main menu KERNEL vesamenu.c32 APPEND ~The PLD Linux rescue CD is ofcourse based on PXE remote boot for your home/work lab. I tried the Ubuntu 'rescue' mode once but the PLD linux rescue environment works a lot better for me.
A bit of reading on pxelinux and syslinux and it looks easy to set up my own pxeboot server at home so I don't have to fiddle with floppies, cd-roms or other media anymore.
First of all I wanted the dhcp server to only respond with pxelinux to real pxe clients. There is other stuff which uses dhcp and tftp and might get confused by pxelinux.0 being offered as boot image such as VoIP phones. That can be done with the following in the right context in dhcpd.conf:
if substring (option vendor-class-identifier, 0, 9) = "PXEClient" { filename "/pxelinux.0"; next-server 10.42.2.1; }Next a tftp server is needed, I installed atftpd serving /tftpboot.The next part is the menu structure for pxelinux. The following files are in /tftpboot:
root@greenblatt:/tftpboot# ls -lR .: total 628 -rw-r--r-- 1 root root 30920 2009-09-01 21:20 boot.jpg -rw-r--r-- 1 root root 307200 2009-09-01 20:06 boot.png -rw-r--r-- 1 root root 103204 2009-09-01 21:23 memtest86 -rw-r--r-- 1 root root 35732 2009-09-01 18:29 menu.c32 -rw-r--r-- 1 root root 14146 2009-09-01 17:57 pxelinux.0 drwxr-xr-x 2 root root 4096 2009-09-01 21:34 pxelinux.cfg -rw-r--r-- 1 root root 122988 2009-09-01 18:29 vesamenu.c32 ./pxelinux.cfg: total 8 -rw-r--r-- 1 root root 117 2009-09-01 18:02 bootmenu.txt -rw-r--r-- 1 root root 463 2009-09-01 21:34 defaultAnd the content of pxelinux.cfg/default is:DISPLAY bootmenu.txt DEFAULT vesamenu.c32 PROMPT 0 TIMEOUT 100 MENU TITLE Remote Boot Services MENU BACKGROUND boot.jpg # http://www.flickr.com/photos/bottinex/2948585175/ LABEL local MENU LABEL ^Boot from local disk localboot 0 LABEL memtest MENU LABEL ^Memory test kernel memtest86Note that the memtest86+.bin image is renamed memtest86: the original filename did not want to boot.The image of the heavy duty boot is rotated and scaled to 640x480 and brought down in quality. I will probably add the PLD linux rescue CD image and ubuntu so I won't be bothered by boot medium problems anymore. An environment for a heavy duty boot, hence the image.
What do you get when documentation for Polycom SoundPoint IP phones suggests.. and suggests again and again you should set up an ftp account PlcmSpIp with password PlcmSpIp? Well, what do you expect other than:Sep 1 13:12:44 greenblatt sshd[24658]: Invalid user PlcmSpIp from 202.39.75.16 Sep 1 13:12:47 greenblatt sshd[24661]: Invalid user PlcmSpIp from 220.132.192.198 Sep 1 13:12:50 greenblatt sshd[24753]: Invalid user PlcmSpIp from 220.132.192.220 Sep 1 13:12:52 greenblatt sshd[24823]: Invalid user PlcmSpIp from 202.39.75.16 Sep 1 13:12:55 greenblatt sshd[24827]: Invalid user PlcmSpIp from 202.39.75.16 Sep 1 13:12:57 greenblatt sshd[24832]: Invalid user PlcmSpIp from 220.132.192.198 Sep 1 13:13:00 greenblatt sshd[24834]: Invalid user PlcmSpIp from 220.132.192.220 Sep 1 13:13:02 greenblatt sshd[24839]: Invalid user PlcmSpIp from 220.132.192.198 Sep 1 13:13:05 greenblatt sshd[24863]: Invalid user PlcmSpIp from 202.39.75.16 Sep 1 13:13:08 greenblatt sshd[24866]: Invalid user PlcmSpIp from 220.132.192.198I rather have phones use tftp on a local network and/or http when chances are the setup will be remote.
Update 2009-09-02: And what do I find from someone who has actually configured this for provisioning his phones: Security issue related with PlcmSpIp someone who reports an actual visit on the PlcmSpIp account.
Cat-5E cable helps, compared to Cat-5:eth0: negotiated 1000baseT-HD flow-control, link okA new cable for 'connecting something in the living room'. The previous cable was Cat-5 and usually reverted to 100 megabit speed. But the switch and the computer support gigabit so I want that.
Grappig: Introweb komt nu met een IPv6-only adsl aanbod voor een symbolische prijs van 6 euro per maand (dat is minder dan de KPN lijnhuur!). Ik heb al IPv6 via xs4all dus ik laat dit aanbod aan anderen die een goede reden hebben voor een gescheiden IPv6 uplink.
Bezoekers aan mijn homepage zien al eventjes de IPv6 exhaustion counter in de rechterkolom .. wat verderop naar beneden. Met dank aan de onvolprezen Hurricane Electric voor hun IPv4 exhaustion counters.Het is echt tijd dat meer mensen nadenken over IPv6 en er iets mee gaan doen. Vooral het netwerk tussen provider en thuisgebruiker heeft momenteel geen werkend IPv6, en daar moet nodig wat aan gedaan worden.
Recente publicatie: Wanneer krijgt IPv6 een gezicht? - Computable
I run an irc server for a very small irc network, and in the past I tried to ipv6-enable it, but failed and let it at that mainly because that was in the hurry of trying to migrate services. Today, with all the ipv6 news from the ripe conference in mind I gave it a go again.I use ircd-hybrid 7.2.2 (ubuntu package) which should support ipv6. But I never configured the IP to listen on, which makes it default to 0.0.0.0, v4-only. The fix was to define two IP addresses and ports:
listen { host = "1.2.3.4"; port = 6667; host = "fe80::525f:c4ca"; port = 6667; }Now the irc server is both ipv4 and ipv6 reachable, and updated in the dns. My client irssi needed an option /set resolve_prefer_ipv6 ON to actually use it, but now I have it working. One more service converted!
I'm in Paris at the Alcatel-Lucent Enterprise Forum. Lots of presentations about the future of IP telephony, how to save money with IP telephony in the current financial climate and lots of future visions involving UC (Unified Communications). Even realistic ones where people want to look at the organization first before deciding wheather UC is a good idea to spend money on.
Last year I was at the 2008 edition and an analyst told that TDM (digital intracompany telephony) had no future left. This year it isn't even mentioned anymore. IP telephony is the future and there is a move from proprietary protocols to SIP. One standard, pick the SIP PBX that does best what you want and pick the SIP phones that do what you want. For standard features (calling and being called) any standard SIP phone is good enough.
The conference center has wireless network for the forum guests with limited access: only port 80 and 443 seem to work. Good thing xs4all runs sshd on port 80 on the shell servers so I can still get somewhere and use my screens. My tip now for Internet access for road-warriors: bring a 2 meter UTP cable too. Wifi may be everywhere, but our hotel (Hotel California in Paris, makes me wonder how hard it will be to leave) offers free Internet access when you bring your own utp cable.
I'm typing this while sitting in the Thalys high-speed train between Antwerp and Brussels (so no 300 km/h yet). The first class has free wi-fi Internet access. I had to lower the mtu of the wireless interface to be able to use ssh and screen to access my normal home environment, so path mtu discovery is probably b0rken somewhere. I appear from a Belgian IP, no idea how they do the uplink from the train.
Update 2009-03-06: Found on the Thalys website: WiFi - Internet access for everyone! with an explanation how satellite Internet and UMTS/GPRS are used to tunnel the Internet to the train. The whole tunneling thing is probably what is causing the mtu problem.
I got reminded of my Alcatel stats again and some google searches and some combining of clues (the logical place would be in the 'td call' command) led me to the right answer at DMTv7 für Speedtouch 516 536 546 585 608 706 716 780 to get the dsl linestats from a Speedtouch 546/546i: :td call cmd="tdsl getData all". Trying it:* ____/ * ------------------------------------------------------------------------ =>:td call cmd="tdsl getData all" =====================DISCLAIMER====================== Access to expert commands is intended for qualified personnel only. ==================END=OF=DISCLAIMER================== Vendor Information phyType=2 phyMjVerNum=4 phyMnVerNum=0 phyVerStr=B2pBT004.d15b drvMjVerNum=14 drvMnVerNum=20482 drvVerStr=15bAnd suddenly lots of data including the signal/noise ratio per carrier. So after stopping gathering Alcatel Speedtouch graphs in 2005 because I switched to a Speedtouch 546i I can now gather the stats again and create the graphs daily. In the mean time gnuplot changed a bit but with some tweaking of the plotscript I now have the first S/N graph of the 546i as I want it.
It being Friday afternoon I fired up vlc to see if there were any interesting announcements of multicast streams. And yet another university, this time one in the UK was leaking their entire TV program lineup (all UK terrestrial programs, which is quite a list). I tried the programs but nothing worked until I tried the last one: BBC HD. This one does work, giving over 20 megabit of video in HD. Screenshot of the BBC HD logo animation (1600x1080px)
A bit of reading on