Com­plete net­work loss on Sol­aris 10u10 CPU 2012-​10 on vir­tu­al­ized T4-​2

The prob­lem I see at work: A T4-​2 with 3 guest LDOMs, vir­tu­al­ized disks and net­works lost the com­plete net­work con­nectiv­ity “out of the blue” once, and maybe “sporadic” dir­ectly after a cold boot. After a lot of dis­cus­sion with Or­acle, I have the im­pres­sion that we have two prob­lems here.

1st prob­lem:
Total net­work loss of the ma­chine (no zone or guest LDOM or the primary LDOM was able to have re­ceive or send IP pack­ets). This happened once. No idea how to re­pro­duce it. In the logs we see the mes­sage “[ID 920994 kern.warning] WARNING: vnetX: ex­ceeded num­ber of per­mit­ted hand­shake at­tempts (5) on chan­nel xxx”. Ac­cord­ing to Or­acle this is sup­posed to be fixed in 148677 – 01 which will come with Sol­aris 10u11. They sug­ges­ted to use a vsw in­ter­face in­stead of a vnet in­ter­face on the primary do­main to at least lower the prob­ab­il­ity of this prob­lem hit­ting us. They were not able to tell us how to re­pro­duce the prob­lem (seems to be a race con­di­tion, at least I get this im­pres­sion based upon the de­scrip­tion of the Or­acle en­gin­eer hand­ling the SR). Only a re­boot helped to get the prob­lem solved. I was told we are the only cli­ent which re­por­ted this kind of prob­lem, the patch for this prob­lem is based upon an in­ternal bu­gre­port from in­ternal tests.

2nd prob­lem:
After cold boots some­times some ma­chines (not all) are not able to con­nect to an IP on the T4. A re­boot helps, as does re­mov­ing an in­ter­face from an ag­greg­ate and dir­ectly adding it again (see be­low for the sys­tem con­fig). To try to re­pro­duce the prob­lem, we did a lot of warm re­boots of the primary do­main, and the prob­lem never showed up. We did some cold re­boots, and the prob­lem showed up once.

In case someone else sees one of those prob­lems on his ma­chines too, please get in con­tact with me to see what we have in com­mon to try to track this down fur­ther and to share info which may help in maybe re­pro­du­cing the prob­lems.

Sys­tem setup:

  • T4-​2 with 4 HBAs and 8 NICs (4 * igb on-​board, 4 * nxge on ad­di­tional net­work card)
  • 3 guest LDOMs and one io+control do­main (both in the primary do­main)
  • the guest LDOMs use SAN disks over the 4 HBAs
  • the primary do­main uses a mirrored zpool on SSDs
  • 5 vswitch in the hy­per­visor
  • 4 ag­greg­ates (aggr1 – aggr4 with L2-​policy), each one with one igb and one nxge NIC
  • each ag­greg­ate is con­nec­ted to a sep­ar­ate vswitch (the 5th vswitch is for machine-​internal com­mu­nic­a­tion)
  • each guest LDOM has three vnets, each vnets con­nec­ted to a vswitch (1 guest LDOM has aggr1+2 only for zones (via vnets), 2 guest LDOMs have aggr 3+4 only for zones (via vnets), and all LDOMs have aggr2+3 (via vnets) for global-​zone com­mu­nic­a­tion, all LDOMs are ad­di­tion­ally con­nec­ted to the machine-​internal-​only vswitch via the 3rd vnet)
  • primary do­main uses 2 vnets con­nec­ted to the vswitch which is con­nec­ted to aggr2 and aggr3 (con­sist­ency with the other LDOMs on this ma­chine) and has no zones
  • this means each en­tity (primary do­main, guest LDOMs and each zone) has two vnets in and those two vnets are con­figured in a link-​based IPMP setup (vnet-linkprop=phys-state)
  • each vnet has VLAN tag­ging con­figured in the hy­per­visor (with the zones be­ing in dif­fer­ent VLANs than the LDOMs)

The pro­posed change by Or­acle is to re­place the 2 vnet in­ter­faces in the primary do­main with 2 vsw in­ter­faces (which means to do VLAN tag­ging in the primary do­main dir­ectly in­stead of in the vnet con­fig). To have IPMP work­ing this means to have vsw-linkprop=phys-state. We have two sys­tems with the same setup, on one sys­tem we already changed this and it is work­ing as be­fore. As we don’t know how to re­pro­duce the 1st prob­lem, we don’t know if the prob­lem is fixed or not, re­spect­ively what the prob­ab­il­ity is to get hit again by this prob­lem.

Ideas /​ sug­ges­tions /​ info wel­come.

StumbleUponXINGBalatarinBox.netDiggGoogle GmailNetvouzPlurkSiteJotTypePad PostYahoo BookmarksVKSlashdotPocketHacker NewsDiigoBuddyMarksRedditLinkedInBibSonomyBufferEmailHatenaLiveJournalNewsVinePrintViadeoYahoo MailAIMBitty BrowserCare2 NewsEvernoteMail.RuPrintFriendlyWaneloYahoo MessengerYoolinkWebnewsStumpediaProtopage BookmarksOdnoklassnikiMendeleyInstapaperFarkCiteULikeBlinklistAOL MailTwitterGoogle+PinterestTumblrAmazon Wish ListBlogMarksDZoneDeliciousFlipboardFolkdJamespotMeneameMixiOknotiziePushaSvejoSymbaloo FeedsWhatsAppYouMobdiHITTWordPressRediff MyPageOutlook.comMySpaceDesign FloatBlogger PostApp.netDiary.RuKindle ItNUjijSegnaloTuentiWykopTwiddlaSina WeiboPinboardNetlogLineGoogle BookmarksDiasporaBookmarks.frBaiduFacebookGoogle ClassroomKakaoQzoneSMSTelegramRenrenKnownYummlyShare/​Save

Book re­view: FreeBSD Device Drivers

In mid-​April a wo­man from the mar­ket­ing de­part­ment of No Starch Press con­tac­ted me and asked if I am in­ter­ested to do a pub­lic re­view of the FreeBSD Device Drivers book by Joseph Kong (no link to a book shop, go and have a look in your pre­ferred one). Just this simple ques­tion, no strings at­tached.

I had my nose in some device drivers in the past, but I never wrote one, and never had a look at the big pic­ture. I was in­ter­ested to know how everything fits to­gether, so this made me a good vic­tim for a re­view (novice enough to learn some­thing new and to have a look if enough is ex­plained, and ex­per­i­enced enough to un­der­stand what is go­ing on in the FreeBSD ker­nel).

Some minutes after I agreed to re­view it (but with a little no­tice that I do not know how long I need to re­view it), I had the PDF ver­sion of the book. That was faster than I ex­pec­ted (maybe I am too old-​school and used to have pa­per ver­sions of books in my hands).

Let the re­view be­gin… but bear with me, this is the first time I do a real pub­lic re­view of a book (in­stead of a tech­nical re­view for an au­thor). And as this is my very own per­sonal opin­ion, I will not al­low com­ments here. This page is all about my opin­ion while read­ing the book, ques­tions I have while read­ing the book shall serve as a hint about the qual­ity of the book and they should be answered in the book, not here.

In short, the book is not per­fect, but it is a good book. There is room for im­prove­ment, but on a very high level. If you want to write a device driver for FreeBSD, this book is a must. I sug­gest to read it com­pletely, even chapters which do not be­long to the type of driver you want to write (spe­cially the case stud­ies of real drivers). The reason is that each chapter has some notes which may not only ap­ply to the chapter in ques­tion, but to all kinds of device drivers. The long re­view fol­lows now.

The first chapter is titled “Build­ing and run­ning mod­ules”. The au­thor be­gins with de­scrip­tion of the usual device driver types (NIC driver, pseudo-​device, …) and how they can be ad­ded to the ker­nel (stat­ic­ally linked in or as a mod­ule). The first code ex­ample is a small and easy ker­nel mod­ule, so that we do not have to re­boot the sys­tem we use to de­velop a driver (ex­cept we make a fault dur­ing driver de­vel­op­ment which causes the ma­chine to panic or hang). Every part of the ex­ample is well ex­plained. This is fol­lowed by an over­view about char­ac­ter devices (e.g. disks) and a simple character-​device driver (so far a pseudo-​device, as we do not have real hard­ware we ac­cess) which is not only as-​well ex­plained as the module-​example, but there is also a note where the code was sim­pli­fied and what should be done in­stead.

After read­ing this chapter you should be able to write your own ker­nel mod­ule in 5 minutes (well, after 5 minutes it will not be able to do a lot – just a “hello world” – but at least you can already load/​unload/​execute some code into/​from/​in the ker­nel).

I have not tried any ex­ample my­self, but I com­piled a lot of mod­ules and drivers I mod­i­fied in the past and re­mem­ber to have seen the de­scribed parts.

The second chapter ex­plains how to al­loc­ate and free memory in the ker­nel. There is the pos­sib­il­ity to al­loc­ate maybe-​contiguous memory (the nor­mal case, when your hard­ware does not do DMA or does not have the re­quire­ment that the memory re­gion it makes DMA from/​too needs to be con­tigu­ous), and really con­tigu­ous. For the size ar­gu­ment of the free­ing of the the con­tigu­ous memory there is the sen­tence “Gen­er­ally, size should be equal the amount al­loc­ated.”. Im­me­di­ately I wanted to know what hap­pens if you spe­cify a dif­fer­ent size (as a non-​native eng­lish speaker I un­der­stand this sen­tence in a way that I am al­lowed to spe­cify a dif­fer­ent size and as such are able to free only parts of the al­loc­ated memory). Un­for­tu­nately this is not answered. I had a look into the source, the ker­nel frees memory pages, so the size ar­gu­ment (and addr ar­gu­ment) will be roun­ded to in­clude a full page. This means the­or­et­ic­ally I am able to free parts of the al­loc­ated memory, but this is a source-​maintenance night­mare (needs know­ledge about the ma­chine spe­cific page bound­ar­ies and you need to make sure that you do the ab­so­lutely cor­rect size cal­cu­la­tions).  To me this looks more like as long as nobody is point­ing a gun at my head and tells me to use a dif­fer­ent size, spe­cify­ing the same size as made dur­ing the al­loc­a­tion of this memory re­gion is the way to go.

After read­ing this chapter you should know how to kill the sys­tem by al­loc­at­ing all the RAM in the ker­nel.

Again, I did not try to com­pile the ex­amples in this chapter, but the dif­fer­ence of the memory al­loc­a­tion in the ker­nel com­pared with memory al­loc­a­tion in the user­land is not that big.

The third chapter ex­plains the device com­mu­nic­a­tion and con­trol in­ter­faces (ioctl/​sysctl) of a driver. The ioctl part teached me some parts I al­ways wanted to know when I touched some ioctls, but never bothered to find out be­fore. Un­for­tu­nately this makes me a little bit nervous about the way ioctls are handled in the FreeBSD linuxu­lator, but this is not ur­gent ATM (and can prob­ably be handled by a com­mend in the right place). The sy­sctl part takes a little bit longer to fol­low through, but there is also more to learn about it. If you just modify an ex­ist­ing driver with an ex­ist­ing sy­sctl in­ter­face, it prob­ably just comes down to copy&paste with little modi­fic­a­tions, but if you need to make more com­plex changes or want to add a sy­sctl in­ter­face to a driver, this part of the book is a good way to un­der­stand what is pos­sible and how everything fits to­gether. Per­son­ally I would have wished for a more de­tailed guide when to pick the ioctl in­ter­face and when the sy­sctl in­ter­face than what was writ­ten in the con­clu­sion of the chapter, but it is prob­ably not that easy to come up with a good list which fits most drivers.

After read­ing this chapter you should be able to get data in and out of the ker­nel in 10 minutes.

As be­fore, I did not com­pile the ex­amples in this chapter. I already ad­ded ioctls and sy­sctls in vari­ous places in the FreeBSD ker­nel.

Chapter 4 is about thread syn­chron­iz­a­tion – mu­texes, shared/​exclusive locks, reader/​writer locks and con­di­tion vari­ables. For me this chapter is not as good as the pre­vi­ous ones. While I got a good ex­plan­a­tion of everything, I missed a nice over­view table which com­pares the vari­ous meth­ods of thread syn­chron­iz­a­tion. Brendan Gregg did a nice table to give an over­view of DTrace vari­able types and when to use them. Some­thing like this would have been nice in this chapter too. Apart from this I got all the info I need (but hey, I already wrote a NFS cli­ent for an ex­per­i­mental com­puter with more than 200000 CPUs in 1998, so I’m fa­mil­iar with such syn­chron­iz­a­tion prim­it­ives).

Delayed ex­e­cu­tion is ex­plained in chapter 5. Most of the in­form­a­tion presen­ted there was new to me. While there where not much ex­amples presen­ted (there will be some in a later chapter), I got a good over­view about what ex­ists. This time there was even an over­view when to use which type of delayed ex­e­cu­tion in­fra­struc­ture. I would have pre­ferred to have this over­view in the be­gin­ning of the chapter, but that is maybe some kind of per­sonal pref­er­ence.

In chapter 6 a com­plete device driver is dis­sec­ted. It is the vir­tual null mo­dem ter­minal driver. The chapter provides real-​world ex­amples of event-​handlers, cal­louts and taskqueues which where not demon­strated in chapter five. At the same time the chapter serves as a de­scrip­tion of the func­tions a TTY driver needs to have.

Auto­mated device de­tec­tion with New­bus and the cor­res­pond­ing re­source al­loc­a­tion (I/​O ports, device memory and in­ter­rupts) are ex­plained in chapter 7. It is easy… if you have a real device to play with. Un­for­tu­nately the chapter missed a para­graph or two about the sus­pend and re­sume meth­ods. If you think about it, it is not hard to come up with what they are sup­posed to do, but a little ex­pli­cit de­scrip­tion of what they shall do, in what state the hard­ware should be put and what to as­sume when be­ing called would have been nice.

Chapter 8 is about in­ter­rupts. It is easy to add an in­ter­rupt hand­ler (or to re­move one), the hard part is to gen­er­ate an in­ter­rupt. The ex­ample code uses the par­al­lel port, and the chapter also con­tains a little ex­plan­a­tion how to gen­er­ate an in­ter­rupt… if you are not afraid to touch real hard­ware (the par­al­lel port) with a res­istor.

In chapter 9 the lpt(4) driver is ex­plained, as most of the top­ics dis­cussed so far are used in­side. The ex­plan­a­tion how everything is used is good, but what I miss some­times is why they are used. The most prom­in­ent (and only) ex­ample here for me is why are cal­louts used to catch stray in­ter­rupts? That cal­louts are a good way of hand­ling this is clear to me, the big ques­tion is why can there be stray in­ter­rupts. Can this hap­pen only for the par­al­lel port (re­spect­ively a lim­ited amount of devices), or does every driver for real in­ter­rupt driven hard­ware need to come with some­thing like this? I as­sume this is some­thing spe­cific to the device, but a little ex­plan­a­tion re­gard­ing this would have been nice.

Ac­cess­ing I/​O ports and I/​O memory for devices are ex­plained in chapter 10 based upon a driver for a LED device (turn on and off 2 LEDs on an ISA bus). All the func­tions to read and write data are well ex­plained, just the part about the memory bar­rier is a little bit short. It is not clear why the CPU re­order­ing of memory ac­cesses mat­ter to what looks like func­tion calls. Those func­tion calls may be mac­ros, but this is not ex­plained in the text. Some little ex­amples when to use the bar­ri­ers in­stead of an ab­stract de­scrip­tion would also have been nice at this point.

Chapter 11 is sim­ilar to chapter 10, just that a PCI bus driver is dis­cussed in­stead of an ISA bus driver. The dif­fer­ences are not that big, but im­port­ant.

In chapter 12 it is ex­plained how to do DMA in a driver. This part is not easy to un­der­stand. I would have wanted to have more ex­amples and ex­plan­a­tions of the DMA tag and DMA map parts. I am also sur­prised to see dif­fer­ent sup­por­ted ar­chi­tec­tures for the flags BUS_​DMA_​COHERENT and BUS_​DMA_​NOCACHE for dif­fer­ent func­tions. Either this means FreeBSD is not co­her­ent in those parts, or it is a bug in the book, or it is sup­posed to be like this and the reas­ons are not ex­plained in the book. As there is no ex­pli­cit note about this, it prob­ably leads to con­fu­sion of read­ers which pay enough at­ten­tion here. It would also have been nice to have an ex­plan­a­tion when to use those flags which are only im­ple­men­ted on a sub­set of the ar­chi­tec­tures FreeBSD sup­ports. Any­way, the ex­plan­a­tions give enough in­form­a­tion to un­der­stand what is go­ing on and to be able to have a look at other device drivers for real-​live ex­amples and to get a deeper un­der­stand­ing of this topic.

Disk drivers and block I/​O (bio) re­quests are de­scribed in chapter 13. With this chapter I have a little prob­lem. The au­thor used the word “un­defined” in sev­eral places where I as a non-​native speaker would have used “not set” or “set to 0”. The word “un­defined” im­plies for me that there may be garbage in­side, whereas from a tech­nical point of view I can not ima­gine that some ran­dom value in those places would have the de­sired res­ult. In my opin­ion each such place is ob­vi­ous, so I do not ex­pect that an ex­per­i­enced pro­gram­mer would lose time/​hairs/​sanity over it, but in­ex­per­i­enced pro­gram­mers which try to as­semble the cor­res­pond­ing struc­tures on the (un­ini­tial­ized) heap (for whatever reason), may struggle with this.

Chapter 14 is about the CAM layer. While the pre­vi­ous chapter showed how to write a driver for a disk device, chapter 14 gave an over­view about how to an HBA to the CAM layer. It is just an over­view, it looks like CAM needs a book on its own to be fully de­scribed. The simple (and most im­port­ant) cases are de­scribed, with the hardware-​specific parts be­ing an ex­er­cise for the per­son writ­ing the device driver. I have the im­pres­sion it gives enough de­tails to let someone with hard­ware (or pro­tocol), and more im­port­antly doc­u­ment­a­tion for this device, start writ­ing a driver.

It would have been nice if chapter 13 and 14 would have had a little schem­atic which de­scribes at which level of the kernel-​subsystems the cor­res­pond­ing driver sits. And while I am at it, a schem­atic with all the driver com­pon­ents dis­cussed in this book at the be­gin­ning as an over­view, or in the end as an an­nex, would be great too.

An over­view of USB drivers is given in chapter 15 with the USB printer driver as an ex­ample for the ex­plan­a­tion of the USB driver in­ter­faces. If USB would not be as com­plex as it is, it would be a nice chapter to start driver-​writing ex­per­i­ments (due to the avail­ab­il­ity of vari­ous USB devices). Well… bad luck for curi­ous people. BTW, the au­thor gives point­ers to the of­fi­cial USB docs, so if you are really curi­ous, feel free to go ahead. :)

Chapter 16 is the first part about net­work drivers. It deals with ifnet (e.g. stuff needed for if­con­fig), if­me­dia (sim­pli­fied: which kind of cable and speed is sup­por­ted), mbufs and MSI(-X). As in other chapters be­fore, a little over­view and a little pic­ture in the be­gin­ning would have been nice.

Fi­nally, in chapter 17, the packet re­cep­tion and trans­mis­sion of net­work drivers is de­scribed. Large ex­ample code is broken up into sev­eral pieces here, for more easy dis­cus­sion of re­lated in­form­a­tion.

One thing I miss after reach­ing the end of the book is a dis­cus­sion of sound drivers. And this is surely not the only type of drivers which is not dis­cussed, I can come up with crypto, firewire, gpio, watch­dog, smb and iic devices within a few seconds. While I think that it is much more easy to un­der­stand all those drivers now after read­ing the book, it would have been nice to have at least a little over­view of other driver types and maybe even a short de­scrip­tion of their driver meth­ods.

Con­clu­sion: As I wrote already in the be­gin­ning, the book is not per­fect, but it is good. While I have not writ­ten a device driver for FreeBSD, the book provided enough in­sight to be able to write one and to un­der­stand ex­ist­ing drivers. I really hope there will be a second edi­tion which ad­dresses the minor is­sues I had while read­ing it to make it a per­fect book.

Free DLNA server which works good with my Sony BRAVIA TV

In sev­eral pre­vi­ous posts I wrote about my quest for the right source format to stream video to my Sony BRAVIA TV (build in 2009). The last week-​end I fi­nally found some­thing which sat­is­fies me.

What I found was ser­viio, a free UPnP-​AV (DLNA) server. It is writ­ten in java and runs on Win­dows, Linux and FreeBSD (it is not lis­ted on the web­site, but we have an not-​so-​up-​to-​date ver­sion in the ports tree). If ne­ces­sary it transcodes the in­put to an ap­pro­pri­ate format for the DLNA ren­derer (in my case the TV).

I tested it with my slow Net­book, so that I was able to see with which in­put format it will just re­mux the in­put con­tainer to a MPEG trans­port stream, and which in­put format would be really re-​encoded to a format the TV un­der­stands.

The bot­tom line of the tests is, that I just need to use a sup­por­ted con­tainer (like MKV or MP4 or AVI) with H.264-encoded video (e.g. en­coded by x264) and AC3 au­dio.

The TV is able to chose between sev­eral au­dio streams, but I have not tested if ser­viio is able to serve files with mul­tiple au­dio streams (my wife has a dif­fer­ent mother lan­guage than me, so it is in­ter­est­ing for us to have mul­tiple au­dio streams for a movie), and I do not know if DLNA sup­ports some­thing like this.

Now I just have to re­place min­idlna (which only works good with my TV for MP3s and Pic­tures) with ser­viio on my FreeBSD file server and we can for­get about the disk-​juggling.

For­cing a route in Sol­aris?

I have a little prob­lem find­ing a clean solu­tion to the fol­low­ing prob­lem.

A ma­chine with two net­work in­ter­faces and no de­fault route. The first in­ter­face gets an IP at boot time and the cor­res­pond­ing static route is in­ser­ted dur­ing boot into the rout­ing table without prob­lems. The second in­ter­face only gets an IP ad­dress when the shared-​IP zones on the ma­chine are star­ted, dur­ing boot the in­ter­face is plumbed but without any ad­dress. The net­works on those in­ter­faces are not con­nec­ted and the ma­chine is not a gate­way (this means we have a machine-​administration net­work and a production-​network). The static routes we want to have for the ad­dresses of the zones are not ad­ded to the rout­ing table, be­cause the next hop is not reach­able at the time the routing-​setup is done. As soon as the zones are up (and the in­ter­face gets an IP), a re-​run of the routing-​setup adds the miss­ing static routes.

Un­for­tu­nately I can not tell Sol­aris to keep the static route even if the next hop is not reach­able ATM (at least I have not found an op­tion to the route com­mand which does this).

One solu­tion to this prob­lem would be to add an ad­dress at boot to the in­ter­face which does not have an ad­dress at boot-​time ATM (prob­ably with the de­prec­ated flag set). The prob­lem is, that this sub­net (/​28) has not enough free ad­dresses any­more, so this is not an op­tion.

An­other solu­tion is to use a script which re-​runs the routing-​setup after the zones are star­ted. This is a prag­matic solu­tion, but not a clean solu­tion.

As I un­der­stand the in.routed man-​page in.routed is not an op­tion with the de­fault con­fig, be­cause the ma­chine shall not route between the net­works, and shall not change the rout­ing based upon RIP mes­sages from other ma­chines. Un­for­tu­nately I do not know enough about it to be sure, and I do not get the time to play around with this. I have seen some in­ter­st­ing op­tions re­gard­ing this in the man-​page, but play­ing around with this and sniff­ing the net­work to see what hap­pens, is not an op­tion ATM. Any­one with a config/​tutorial for this “do not broad­cast any­thing, do not ac­cept any­thing from outside”-case (if pos­sible)?

ADSL RAM … fi­nally aban­doned (but with good news)

As I already wrote, the­or­et­ic­ally ADSL RAM is avail­able at my place. The ana­lysis of the situ­ation re­vealed first that the ISP side of my line uses out­dated hard­ware. After the tech­ni­cian I know un­of­fi­cially took care about it (re­motely switch­ing me to a dif­fer­ent port), I have seen an im­me­di­ate im­prove­ment of the sig­nal to noise ra­tio. It is about 20 dB bet­ter.

Un­for­tu­nately this was not enough to be able to switch to the rate ad­apt­ive mode. Ac­cord­ing to their data­base the line length al­lows to give me 1.5 MBit. My line is run­ning already at 2 MBit and my ADSL mo­dem tells me it could do 8 MBit, so I dis­agree a bit with their data­base.

As the tech­ni­cian agrees with me, the next step would be to tem­por­ary move my house by some hun­dred meters to­wards the ISP en­d­point of the line, un­for­tu­nately the higher man­age­ment seems to be hav­ing some busi­ness ideas with our re­gion (FTTT, Fiber To The Town (which means we will prob­ably get 16 MBit via ADSL) … but maybe even FTTH), so they are now mon­it­or­ing the data­base for such changes since a while.

I have the im­pres­sion they seem to pre­vent such changes to the data­base be­cause they think that if people get 2 MBit (in­stead of noth­ing, large parts of a town nearby does not even have the slow­est ADSL con­nec­tion) or 8 MBit (in­stead of 2 MBit), they are not in­ter­ested in get­ting FTTH (or 16 MBit). To­gether with their IPTV ini­ti­at­ive I do not really un­der­stand it. To get their IPTV, you need to have at least a 8 MBit line. With 8 MBit you can only cover one TV at SD res­ol­u­tion (at least with their IPTV of­fer), if you want HD res­ol­u­tion, you need to switch to their VDSL stuff (which is not avail­able in our town). What people are do­ing cur­rently is to switch to a cable pro­vider where they can get about 32 MBit (I do not switch, switch­ing is a risky ac­tion here, I rather stay with a slow con­nec­tion that to have no con­nec­tion at all for some months). With 32 MBit (and TV) people have less a need to switch to fiber (and pay 150 EUR for the work to get fiber into the house) than with 2 MBit or noth­ing.

The fi­nal out­come is, that the tech­ni­cian I know does not want to ask someone to play with the data­base to move my house tem­por­ary (which I can un­der­stand). The good part of those news is, that I may get more than 8 MBit in the not so dis­tant fu­ture (the cur­rent plan­ning is to fin­ish the FTTT work un­til au­tumn).