PoempelFox Blog

[..] [RSS Feed]
 

Thu, 31. Dec 2009


26c3 Created: 31.12.2009 18:00
Nicht viel dazu zu sagen:
  • - Zu voll
  • + interessante Vortraege
  • - zu voll
  • - teilweise musste man um einen Platz in einem Vortrag zu bekommen 3 Stunden vorher im Saal sein und durfte diesen dann nicht mal zum pinkeln verlassen (sonst wurde der Platz an den naechsten Wartenden vergeben)
  • - zu voll
  • - 2.4 GHz WLAN wegen zu vieler clients tagsueber nicht benutzbar, netzwerkports mangelware
  • - zu voll
  • + guter UMTS Empfang, das war letztlich auch die einzige Moeglichkeit zuverlaessig Internet zu kriegen
  • - zu voll
  • - Steckdosen Mangelware
  • - zu voll
  • - Stuehle Mangelware
  • - zu voll
  • - Kombination aus Stuhl, Netzwerkport und Steckdose seltener als ein Sechser im Lotto
  • - zu voll
no comments yet
write a new comment:
name or nickname
eMail adress (optional)
Your comment:
calculate: (2 times 10) plus 3

Fri, 11. Dec 2009


Fun with in-band remote-management Created: 11.12.2009 23:42
Last modified: 11.01.2010 00:05
The most recent cluster nodes at work use in-band remote-management, that is: The management card that allows resetting the machines and things like that uses the same physical interface the machine uses for its normal ethernet connection. The way this works is that packets tagged with a certain VLAN ID reach only the management card, while everything else goes to the normal network interface that e.g. the linux kernel sees. Though my gut feeling told me this was a stupid idea from the start, we had to accept it for the simple reason that everything else was impractical. There was just no space for another set of cables and switches for dedicated management interfaces.
At first, everything went surprisingly smooth. Everything could be easily configured, and worked flawlessly from the start.
Until we booted a 9.10 Ubuntu instead of the 8.04 LTS that usually runs there. Somewhere in the middle of the messages the kernel writes during boot, the serial console (which is serial-over-lan through the management card) would just stop responding, in fact the whole management card would suddenly not reply to anything anymore, until either the management card or the whole machine was reset.
It took a while to work that one out. The last message on the console before it died was not always the same, but it was usually within the same 10 lines. I finally realized that it always died few seconds after loading the network driver.
Further investigation revealed quite a few amusing details.
  • Ubuntu 8.04 LTS was the only version that would work. All later versions would show the exact same behaviour. The same was true if a current version of the driver for the network card ("igb") was used. Or if the SLES10 SP3 kernel was booted
  • If we compiled the LTS kernel ourself, and used that instead of the official kernel packages, we would have no network at all. The reason is that the normal kernel does not contain any igb module at all, Ubuntu has put that into the "linux-ubuntu-modules" package which is compiled seperately and automagically installed when needed. In that modules package they have in fact two different versions of the igb driver: One is 1.0.8, which is from November 2007 and doesn't even compile with 2.6.24 without heavy patching. The other is version 1.3.28.4, which is not the current version, but a rather current patchlevel of the old "stable" tree. They put this newer driver in as igb-next, and patched it, so that it would only respond to PCI IDs the old igb driver could not handle. In other words, if the network card is recognized by the old driver at all, that driver will be used, regardless of the fact the new driver would probably handle more features of the card. It turns out this approach was great for us, because with 1.3.28.4 the management interface would die. The patched Ubuntu version of 1.0.8 was basically the only version that worked.
  • We found out why the management cards wouldn't respond anymore: When one of the newer drivers was loaded, the linux kernel would suddenly see the packets of the management vlan, so they apparently didn't reach the management card anymore.
  • The reason newer versions of the driver don't work anymore is probably that the network card has hardware support for handling VLAN tags, and they added support for that in the driver some time ago - somewhere between 1.0.8 and 1.3.28 I guess. Every driver which initializes the VLAN handling seems to kill the filter the management card has set up.
  • This generates an interesting effect if you tell the kernel to use that VLAN hardware support: If you load the 801q kernel module, and then tell it to listen on the management VLAN with the command vconfig add eth0 vlanid, the exact opposite happens. The management VLAN is suddenly routed to the management card again, and the kernel cannot see it anymore.
I'm still wondering who is the culprit and who needs to fix the bug here. Is it Intel with the igb driver, because that destroys the VLAN routing during initialization? Or is it IBM, because their management card doesn't realize its interface is gone, and doesn't re-initialize it? I haven't opened a bug report yet, because I'm really not in the mood for a round of "but its THEIR fault" right now.
no comments yet
write a new comment:
name or nickname
eMail adress (optional)
Your comment:
calculate: (2 times 10) plus 3

Sat, 05. Dec 2009


Die legendär nervige Feuerzangenbowle Created: 05.12.2009 12:34
Wie in vielen anderen Städten gibt es auch in Erlangen an der technischen Fakultät jedes Jahr in der Vorweihnachtszeit eine Vorführung der "Feuerzangenbowle". In weihnachtlicher Atmosphäre wird gemeinsam im Hörsaal (bzw. den Hörsälen - weil einer nicht reicht sind es drei) der Film von 1944 geschaut, und einige der Szenen werden vom Publikum entsprechend begleitet - wenn z.B. im Film der Wecker klingelt, klingeln auch im Hörsaal etliche Wecker.
Ich habe den Spass schon mehrmals mitgemacht, dieses Jahr jedoch wohl zum letzten Mal - denn ein Spass war es diesmal nicht, es überwog ganz eindeutig der Nervfaktor.
Zuallererst war da der Eindruck, dass der Hauptzweck der Veranstaltung ein möglichst hoher Absatz des vor den Hörsälen verkauften Glühweins war.
Es war schon immer so, dass man beim angekündigten Filmstart von 20:30
  • spätestens um 19:30 da sein musste um gute Plätze zu bekommen
  • spätestens um 19:50 da sein musste wenn man mehrere zusammenliegende Plätze haben wollte
  • spätestens um 20:00 da sein musste wenn man überhaupt einen Sitzplatz haben wollte. Wie es sein kann, dass mehr Zuschauer da sind als Plätze, obwohl die Sitzplatzzahl im Hörsaal ja wohl bekannt sein sollte, ist mir ein Rätsel.
Das war im Prinzip schon immer so, aber was die Sache diesmal so nervig machte, war dass der Filmstart endlos (bis 21:05 Vorfilm / 21:25 Film) verzögert wurde, mit der Begründung dass ja noch Leute anstehen würden um Glühwein zu kaufen. Ja natürlich stehen die Leute an um Glühwein zu kaufen! Erstens haben sie seit über einer Stunde nichts zu tun als sich Glühwein hinter die Binde zu kippen, weil aufgrund des Lärmpegels eine Unterhaltung mit mehr als dem direkten Nachbarn ohnehin nicht möglich ist. Es blieb also nur saufen, und da braucht man eben regelmässig Nachschub. Zweitens musste niemand der sich Glühwein holte befürchten was zu verpassen, denn vor dem eigentlichen Film gab es ja noch einen Vorfilm, den sicherlich niemand sehen wollte. Hätte man mit dem endlich angefangen, hätte auch der Verkehr zum Glühweinstand abgenommen. Aber das lag wohl nicht im Interesse der Veranstalter, offenbar musste zuerst ein ganzes Glühweinlager entsorgt werden. Den Sprechchören "Anfangen! Anfangen!" nach zu Urteilen war ich übrigens nicht der einzige der genervt war.
Zur Auswahl der Vorfilms möchte ich noch sagen, dass "Dinner for One", noch dazu in falscher Fassung, eine beschissene Wahl ist. Den Film schaut man an Silvester wenn man will, aber nicht Anfang Dezember.
Ich habe bereits den Lärmpegel erwähnt: Der stieg permanent weiter an. Denn durch den übermässigen Glühweingenuss hatten einige bereits einen beachtlichen Alkoholpegel erreicht, was sich in lautem dummen Gröhlen äusserte, und einem manchmal das Gefühl vermittelte, man sei zwischen ein paar hirntote Fussballfans geraten. Apropos hirntot: Wie jemand, der auf die Idee kommt, brennende Wunderkerzen in einem geschlossenen Raum in einen Pappkarton zu stecken, 20 Jahre alt werden konnte ohne sich selbst umzubringen, und sogar noch das Abitur kriegen konnte, ist mir ein Rätsel.
Und übrigens: Es ist extrem asozial, eine Ladung Wunderkerzen vor "der richtigen Zeit", nämlich wenn die richtige Stelle gegen Ende des Films kommt, abzufackeln. Die Dinger stinken bestialisch, die Ausdünstungen sind nicht wirklich gesund, und die Lüftung im Hörsaal ist nicht wirklich ausreichend für 300 Leute plus die Abgase von Wunderkerzen.
Die Krönung des ganzen war dann die Sitzreihe hinter mir, die eine Stunde lang diskutierte ob sie danach ins Paisleys oder doch ins HaWo sollten - in einer Lautstärke, dass man sie deutlich besser verstand als den Film.
Vielleicht werd ich auch einfach nur "zu alt für den Scheiss" [tm].
no comments yet
write a new comment:
name or nickname
eMail adress (optional)
Your comment:
calculate: (2 times 10) plus 3

Sat, 28. Nov 2009


I could swear there was a tape here... Created: 28.11.2009 12:34
In the last posting I already wrote about the defective tape library gripper and what problems it caused. But why did the gripper die? The library is not that old, and hasn't exactly been under heavy stress yet, so it certainly didn't die from senile decay.
For those unfamiliar with how these things work: The gripper sits in the middle aisle of the library. On both sides, there are shelves filled with tapes, and in one place there are a few tape drives. The gripper is mounted on some transport mechanism, so it can move up and down the aisle, and up and down vertically. It also can turn by 180 degrees so that it can reach both sides of the aisle. One side of the gripper assembly has a barcode scanner, so it can read the labels of the tapes, the other side has two grippers (hence the name) for taking or putting tapes. What the gripper usually does is that when the control software requests it, it goes to fetch a certain tape from its shelf, drive to the place where the drives reside, and puts it into the drive. When the tape has been read, the control software will tell it to put the tape back onto the shelf, and it will do that.
The library also has an I/O slot, which can be used to get tapes in or out of the library. It's basically a shelf that can be reached from both sides - one side for the tape robot, one for the human.
It all started when I told the library (remotely) to move some tapes to the I/O slot, because I wanted to take them out for demonstration purposes. However, when I arrived at the library to pick up the tapes, I was greeted with the error message "Gripper unable to pick cartridge" instead. Finding that a bit strange, I checked the inside of the library for obstructions. There was nothing wrong. However, the gripper was making strange noises, and unable to pick any tapes - in fact, it dropped some while trying to pick them. It really must have died when trying to fetch my tapes, because it had put some tapes into drives successfully just a moment before.
When the support technician arrived to change the gripper, he seemed surprised how that could have happened as well - he mumbled something about the gripper being smashed into tiny little bits, everything broken that could be broken. We couldn't help the impression that in private he thought we had treated the gripper with a big hammer because we're such sick bastards.
Only during the long exchange marathon that ensued (see last post) did we eventually realize the true reason.
The library had gotten two additional tape drives just the week before. For putting the new tape drives in, you naturally have to make room, so you have to remove some of the storage slots for tapes. The technician that put in the new drives did that, and placed the tapes that had been there into some other slots in the library. However, he either forgot to let the library see that there are no tapes any more by letting it do a barcode scan after moving the tapes, or it didn't work properly. All slots have a special barcode meaning "there is no tape here" in the back, so when there is no tape in the slot, the barcode scanner sees the "i am empty" label instead of a tape label, and the library then knows there really is no tape. However, the front of the tape drives does not have any labels, and the library still remembered there had been tapes in that place before. Because it didn't see the "empty" barcode either, it assumed the tapes were still there, and just the barcode was bad or had fallen off. When I selected the tapes to remove, I had selected some of these tapes, and the gripper tried to grab them - and slammed into the new tape drives full speed.
Luckily, these drives are a lot more stable than the gripper - else they would have had to exchange the drives as well...
no comments yet
write a new comment:
name or nickname
eMail adress (optional)
Your comment:
calculate: (2 times 10) plus 3

Wed, 28. Oct 2009


Works if you hotplug it Created: 28.10.2009 00:20
At work, there is this nice and rather new tape library. Said library had a defective gripper - that is the part with which it takes the tapes out of their slots and puts them into the tape drives, or the other way round. Why the gripper died is quite possibly a story for another posting, but todays subject is a different one:
The bad gripper was replaced last week, and for almost a week, the library worked flawlessly. Until Monday: The library stopped (again) and displayed an "Error 41A0", an error code on which google returned zero hits. So we called support, and they sent a technician and yet another gripper.
The technician tried to power cycle the library, with the effect that it didn't even get through all the normal power-up tests before displaying "Error 41A0" and stopping. So what is "Error 41A0"? The technician had the answer in his manuals: It means the gripper is incompatible with the library. Of course, that was complete nonsense - after all the library had been running for a week with that gripper before suddenly deciding it's an incompatible one.
So the gripper was replaced - again. The result however stayed the same - "Error 41A0".
It took three hours and numerous phone calls to find out what actually was the problem: The grippers, both the one from last week and the newest one, really were incompatible with our library. As it turns out, there are two types, the normal one, and one which has slightly stronger motors that it needs to be able to reliably put tapes into high density slots. Those are slots where not one but five tapes reside, packed one behind the other, so to get the last tape the gripper first has to pull out the four others sitting in front of it. Support sent us the normal model, but we have high density frames and thus need the stronger model.
 
So why had it worked for a week despite the gripper definitely being the wrong model? Well, almost everything in that library can be hotplugged, or at least semi-hotplugged. When the technician changed the gripper last week, he just told the library to turn off the gripper via software, then changed the gripper, then put the gripper online again via software. Apparrently, the library does not check if the gripper has been replaced with a different model in that situation. So it still saw the old gripper, and since apart from the motor strength they are actually the same, controlling the gripper worked just fine. It would have stayed that way until the next powercycle, if there hadn't been an "inventory" command. It obviously does check the gripper type when doing an inventory - and from that moment on there was no way of getting it to accept that wrong gripper again.
1 comment
Isn't this a little bit like "hotplugging" your girlfriend and then you notice after a while that it's the wrong one...?
RRZEschorscherl 30.10.2009 10:21

write a new comment:
name or nickname
eMail adress (optional)
Your comment:
calculate: (2 times 10) plus 3

Thu, 24. Sep 2009


Heatsinks are overrated Created: 24.09.2009 00:58
One of our cluster nodes at work crashed during the weekend. After a reset, it came up again, but crashed again within a minute. Another reset, and that time it didn't even get through the BIOS before crashing. For every crash, the management card logged either CPU0 IERR asserted or CPU1 IERR asserted.
As we thought it was unlikely that both CPUs died at the same time, we assumed the mainboard to be bad. We opened a support case and waited for a technician to show up to change the board.
However, after we opened the case of the machine, we saw this:
heat sink unscrewed
Yup, those are the heatsinks on the CPUs, and they just were not screwed in. The amusing thing is that this machine is almost three years old, and it came factory integrated, i.e. fully assembled - we unpacked it, put it into the rack, and haven't moved or opened it for almost three years now. The machine has been running without the heatsink screwed on all the time. Apparently, the heat-conductive paste was enough to keep it in place in the beginning. With the paste getting drier and drier over time, the heatsink lost contact at some point - judging from the crashes, that happened last Sunday night...
no comments yet
write a new comment:
name or nickname
eMail adress (optional)
Your comment:
calculate: (2 times 10) plus 3

Wed, 05. Aug 2009


Next business day advance replacements - in 7 weeks Created: 05.08.2009 23:29
I have quite a few switches at work from a certain big manufacturer, lets call them Howling Packrat. Until recently that has always been the same model for many years, nothing fancy, just gigabit switches with 48 ports. We generally like them because they're pretty reliable and just work, unlike the ones from the big C, where they force you to pay a fortune just to get security updates and live in a hell full of crappy bugridden firmware. However, the last one they delivered to us (before they released a new model, a little cheaper but with less features) must have been manufactured on a monday - it made nothing but trouble.
After some power outage a year ago, that switch already showed really strange behaviour. It always booted into some sort of recovery mode that it is supposed to enter only when the firmware image is corrupt. However, that was not the case - from the recovery mode you could just enter the command to boot the firmware, and it would do that without any problems, and in fact we hadn't even tried to update the firmware ever, so corruption was unlikely. The problem disappeared as magically as it had appeared, while we were still trying to work out what was wrong with the help of a support guy, and without any configuration change.
Last week, there was another short power outage. After that outage, the switch did not return. When I went to check it just sat there, all lights on. So I powercycled it, and it started to boot, and everything seemed fine. At least until 3 minutes later the rest of the network went down as well. As it turned out, the switch had completely forgotten its config, which of course put all ports into the same VLAN, and as an added bonus made a nice loop on any trunk port.
Even after resetting the config (and saving) - on the next power cycle it came up with the default config again. That was where I had enough - I opened a support case and requested to replace the switch. That was on the morning of Thursday, the 30.07.

And this is where the fun part starts. It started with the usual madness we have gotten used to, because it happens every time: About an hour after opening the case, a support guy calls. Of course, I checked the box that says "Do not call me, I prefer to be contacted by eMail", but that seems to have no effect whatsoever. And he does what they always do: Ask for the address where the replacement part is to be delivered. Of course, I already entered that when I opened the case, so he has the address right in front of him on the screen, but hey, nothing like wasting a little time for a useless phonecall. I mean I could have moved to another state within the last 60 minutes and taken the equipment with me...
That is where the usual madness ends. What usually would have happened is that the replacement part arrives on the next morning. However, we waited in vain on Friday. Same on Monday. And on Tuesday. And on Wednesday. So I wrote to the case asking where my replacement was. Three hours later I get a call. And they called to tell me that my replacement would take a little longer. They were planning to deliver it on the 15.09., i.e. SEVEN WEEKS late. With that in mind, read how these switches are advertised (brand and product name slightly disguised):

PH ContraEllipse networking products come with hardware warranties you would expect from PH. Our industry-leading PH ContraEllipse Lifetime Warranty features next-business-day advance replacement (available in most countries)**, and includes coverage for fans and power supplies for the entire warranty period.

Ah, so "next business day advance replacement" does not mean you get a replacement on the next business day after something failed, it means you get a replacement on the next business day after the business day in 7 weeks!

PS: In their defense - the replacement actually got shipped a few hours later, after I told them as calm as I could that waiting another 6 weeks for something sold as "next business day" was not acceptable.
no comments yet
write a new comment:
name or nickname
eMail adress (optional)
Your comment:
calculate: (2 times 10) plus 3

Fri, 17. Jul 2009


Denn zum Glück gibt's die Packstation - aber nicht in Erlangen Created: 17.07.2009 21:36
Seit geraumer Zeit betrommelt der gelbe Riese seine Errungenschaft der Packstation: Nichts weiter als ein Automat, an dem man Pakete abholen und versenden kann. Eigentlich eine sehr gute Idee. Dafuer gibts sogar ein schmissiges Werbelied - "Denn zum Glück gibts die Packstation, und die nächste ist auch gar nicht weit". Was allerdings in allen Werbeheftchen und dem Werbelied fehlt ist der Zusatz: "aber nicht in Erlangen" - jedenfalls nicht fuer alle.
Denn Packstationen gibt es eigentlich genug in Erlangen - nur keine öffentlichen. Bis auf eine einzige stehen alle auf dem Firmengelände der "Bank mit angeschlossener Elektroabteilung", manchmal auch "Siemens" genannt. Diese Stationen sind nur für die Mitarbeiter dieser Firma gedacht, und tauchen auch nicht im Packstationfinder auf. Alle anderen, die nicht fuer diese Firma arbeiten, muessen sich die einzige der Allgemeinheit offenstehende Station teilen, und die befindet sich vornehm ausgedrückt am Popo der Welt. Ich kann mich daher seit Jahren nicht des Gefühls erwehren, dass DHL auf mich als Kunden einfach scheisst. Denn einen Ausbau auf mehr als eine öffentliche Station gab es nie, was für eine Stadt mit über 100000 Einwohnern doch etwas mager ist.
Doch es wird noch besser: Heute liegt ein netter Brief im Briefkasten, in dem DHL den Packstationkunden mitteilt, dass die eine einzige öffentliche Packstation Ende des Monats abgebaut wird. Ersatz? Fehlanzeige.
Wenn ich etwas mehr Talent für Grafiken hätte, wuerde ich das ganze wie folgt mit einem Bild untermalen: unten ein paar Menschen, beschriftet mit "Bewohner Erlangens die nicht fuer Siemens arbeiten", und oben ein DHL-Logo, das geradewegs auf eben jene scheisst.
 
PS: Um den Einwänden vorzubeugen, dass es doch noch die Packstation 142 "in Erlangen" gibt: Mir ist bekannt dass es diese gibt, doch sie liegt so weit ausserhalb, irgendwo zwischen Alterlangen und Büchenbach, dass ich sie beim besten Willen nicht als "in Erlangen" bezeichnen würde.
1 comment
Finde es auch unmöglich, dass es in Erlangen nur eine Packstation gibt, die verkehrstechnisch wirklich nicht günstig liegt.
Detective 07.09.2009 16:22

write a new comment:
name or nickname
eMail adress (optional)
Your comment:
calculate: (2 times 10) plus 3

Sat, 20. Jun 2009


traceroute is evil Created: 20.06.2009 18:32
One of the nicest tools to help trace problems on the Intra- or Internet is traceroute. However, it can be horribly misleading. Some of its widely known limitations include:
  • You only can trace the hops in one direction. It gives you no information about the route in the other direction, back to you. These routes can be completely different.
  • Routers usually handle them in software on their rather slow general purpose CPUs, other than the routing they do in hardware. That leads to the strange effect that some hops in a route reply really slow and even drop packets, while the hops further down the road reply fast.
  • If the path to a target is not always the same during the duration of the trace, traceroute will display crap.
I had to learn of another potential problem last week.
What happened was that a contractor noticed some strange effects in traceroute and considered the network to have a problem:

traceroute to 192.168.81.166 (192.168.81.166), 30 hops max, 40 byte packets 1 10.188.3.254 (10.188.3.254) 8.269 ms 8.255 ms 8.248 ms 2 192.168.81.166 (192.168.81.166) 0.177 ms 0.178 ms 0.172 ms

That one was easy to explain - the router is a big one, and though it routes in hardware, the answers to the traceroute have to be generated on its rather slow cpu, leading to delays if the cpu is busy with other things. Packets just passing through it are handled by special hardware, thus they are not delayed even if the cpu is busy with maintenance work, thus the next hop is reachable in roughly 1/50th the time it seems to take to reach the router, even though the packets pass through that exact same router.
However, there was more strangeness. Some traces looked like this:

traceroute to 192.168.81.166 (192.168.81.166), 30 hops max, 40 byte packets 1 10.188.3.254 (10.188.3.254) 1.264 ms 1.256 ms 1.251 ms 2 192.168.81.166 (192.168.81.166) 0.135 ms 0.133 ms *

traceroute to 192.168.81.166 (192.168.81.166), 30 hops max, 40 byte packets 1 10.188.3.254 (10.188.3.254) 1.224 ms 1.217 ms 1.212 ms 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 192.168.81.166 (192.168.81.166) 0.139 ms 0.134 ms 0.125 ms

That seemed very weird at first sight. After all it was not the router that lost replies, it was the target host - and the target host was an idle linux machine with no firewalling configured, so there shouldn't have been any drops there. Was there really a network problem? Did the network lose packets?
As it turns out: No. With the help of tcpdump, the problem became apparent pretty fast. The linux box got the packet, but just did not reply. And once that was clear, the explanation was apparent.
Traceroutes can be done in three different ways: With ICMP, UDP or TCP requests. In any case, the basic trick is to set the Time-to-live (TTL) of the packet sent to the number of the hop you're interested in, and then check from which host the "TTL expired in transit" error message for that packet arrives - voila, that's your hop. However, the last hop (with the target host) in the traceroute is different. Because when the trace reaches the target host, the time-to-live is not expired, so naturally it will not generate a "TTL expired" error message. Instead, it will reply with an "destination port unreachable" error message (for UDP traceroute) or an "icmp echo reply" (for ICMP traceroute). And there lies the problem: The linux traceroute utility by default does an UDP trace. However, even with no firewalling set up, linux limits the number of "destination port unreachable" error messages generated. And that limit by default is set rather low - too low for traceroute to work reliably on fast networks. The traceroute packets can arrive faster than the rate limiting allows the linux host to reply. So there are a few ways to get reliable (w.r.t. the last hop) traceroute results:
  • Use a windows machine for tracerouting. That works because the windows traceroute utility by default uses ICMP, not UDP, and that does not fall into the default rate limiting...
  • Use the traceroute parameter -I to make it use ICMP instead of UDP. Unfortunately, that parameter is only available to root.
  • Turn the rate limiting off at the target host: echo 0 > /proc/sys/net/ipv4/icmp_ratemask - as that limit usually makes sense, this is not recommended.
  • Turn up the rate limit setting a notch in /proc/sys/net/ipv4/icmp_ratelimit. The default is 250, the redhat enterprise default of 1000 seems to make a lot more sense.
Of course, you could just use ping instead if you're interested in the last hop, but that would be boring, wouldn't it?
no comments yet
write a new comment:
name or nickname
eMail adress (optional)
Your comment:
calculate: (2 times 10) plus 3

Fri, 12. Jun 2009


Quo vadis, M-net Support? Created: 12.06.2009 10:43
Last modified: 20.06.2009 17:00
Seit vielen Jahren bin ich Kunde bei M-net. Und mit vielen Jahren meine ich wirklich VIELE Jahre. Mit einer kurzen Unterbrechung in der ich Netz im Wohnheim hatte, bin ich dem Laden seit er noch "Astat" hiess und nur ISDN Dialups ohne Telefonanschluesse anbot treu geblieben. Aus Astat wurde NEFkom, NEFkom verschmolz mit M-net.
In all diesen Jahren brauchte ich den Support nur selten - es lief einfach alles recht reibungslos. Bis zu den Zeiten von einschliesslich ADSL1 war mein einziger Kontakt mit dem Support, als ein Telekomtechniker bei der Schaltung eines neuen Anschlusses beim Nachbarn meinen kappte - ein Problem das der Support schnell regeln konnte.
Der Kontakt mit dem Support wurde häufiger, als ich nach einem Umzug auf ADSL2 wechselte. Denn dafür war ein neues Modem notwendig, und M-net stellte hierfür ein "Sphairon Turbolink AR871" zur Verfügung. Bei diesem Modemtyp war der Ethernet Port sehr anfaellig, er gab nach 1-2 Jahren den Geist auf, und produzierte dann regelmässig Linkausfälle in immer kürzeren Abständen. Das NEFkom/M-net Forum war voll mit Postings zu diesem Problem. Da das Modem bei mir an einem Linuxrouter hängt und Linux anders als Windows hier sehr tolerant ist, fiel das immer erst nach einigen Wochen auf, wenn die Abstände zwischen den Ausfällen so kurz wurden dass die Verbindung schleichend lahm wurde, und das Kernellog überquoll mit:

Apr 26 18:38:22 mulder kernel: eth1: link down Apr 26 18:38:23 mulder kernel: eth1: link up, 100Mbps, full-duplex, lpa 0x45E1 Apr 26 18:38:31 mulder kernel: eth1: link down Apr 26 18:38:33 mulder kernel: eth1: link up, 100Mbps, full-duplex, lpa 0x45E1 Apr 26 18:38:34 mulder kernel: eth1: link down Apr 26 18:38:35 mulder kernel: eth1: link up, 100Mbps, full-duplex, lpa 0x45E1


Zwei mal hatte ich den Spass mit einem auf diese Weise defekten Modem, doch genügte eine kurze Mail an den Support mit der Beschreibung des Problems, und es wurde unter der Bedingung das alte (kaputte) innerhalb von 4 Wochen einzusenden ein neues Modem zugeschickt. Der letzte Tausch war vor ca. einem Jahr, und damals bekam ich als Ersatz einen anderen Modemtyp - ein "Turbolink 1203". Ich hatte also begründete Hoffnung, dass die toten Ethernet-Ports mit dem neuen Modemtyp der Vergangenheit angehörten.
Leider wurde die Hoffnung bitter enttäuscht. Eines Sonntags beschloss das Modem "10 MBit should be enough for anybody", und Autonegotionation hatte es auch ploetzlich verlernt:

Jun 10 00:48:22 mulder kernel: [800471.150524] 0000:02:00.0: eth1: Link is Up 10 Mbps Half Duplex, Flow Control: None Jun 10 00:48:22 mulder kernel: [800471.150706] 0000:02:00.0: eth1: Autonegotiated half duplex but link partner cannot autoneg. Try forcing full duplex if link gets many collisions.


Das war zwar ein leicht anderes Fehlerbild als bei den vorherigen Modemausfällen, nichts desto trotz lag das Problem eindeutig am Ethernet Port des Modems. Nachdem ich also durch Testen mit mehreren Rechnern, Kabeln und sogar einem anderen Modem ausgeschlossen hatte, dass das Problem irgendwo bei mir lag, habe ich eine Mail an den Support geschrieben. Die Highlights dieser Kommunikation moechte ich hier in Ausschnitten wiedergeben:

From: me To: Support Date: Sun, 07 Jun 2009 22:07:26 +0200 Subject: Defekter Ethernet Port Turbolink 1203? Seit es letzten Sonntag ausnahmsweise mal fuer ein paar Minuten aus war, bekommt mein Turbolink 1203 nur noch mit einiger Verzoegerung (es dauert etliche Sekunden bis ueberhaupt die Link LED angeht) und mit 10 MBit half duplex einen Link auf ethernetseite. Das ist natuerlich zu wenig fuer ADSL2. Die Gegenseite konnte ich als Ursache ausschliessen - das Symptom tritt mit unterschiedlichen netzwerkkabeln und gegenstellen (laptop, switch, PC) auf, und gleichzeitig funktioniert mein eigenes Notfall-Ersatzmodem problemlos mit 100 MBit. Ich kann also nur davon ausgehen, dass der Ethernet-Port des Modems mal wieder die Graetsche gemacht hat - auch wenn die Symptome anders sind als bei den vorherigen zwei Ausfaellen mit den alten Sphairon Modellen. Falls sie Remote keine weiteren Ruecksetz- / Diagnose-Moeglichkeiten haben, bitte ich - wieder mal - um Zusendung eines Ersatzmodems. Debitorennummer laut Kundenportal: ****


Die Antwort liess über einen Tag auf sich warten, und war dafür dann nicht nur nutzlos, sondern kontraproduktiv:

From: Support To: me Date: Tue, 9 Jun 2009 11:32:43 +0200 Subject: AW: Defekter Ethernet Port Turbolink 1203? [...] An Ihrem Anschluss lassen sich aktuell keinerlei Probleme feststellen, auch sehen wir keine Abbrüche. Wir haben an Ihrem Anschluss ein anderes DSL-Profil eingestellt, bitte beobachten Sie die Verbindung in den nächsten Tagen und geben Sie uns erneut Rückmeldung, falls weiterhin Probleme auftreten. [...]


"Anderes Profil" ist dabei ein hübscher Euphemismus für "wir haben die Leitung auf 15 MBit gedrosselt". Was natürlich in keinster Weise zur Reparatur des defekten Ethernet Ports beitrug, nur dazu dass ich jetzt auch mit Ersatzmodem weniger DSL Sync bekomme.
Wie mein Geschichtslehrer früher immer sagte: "Gut gemeint ist das Gegenteil von gut gemacht" - und der M-net support meint es offenbar sehr gut, hat aber meine Mail entweder nicht gelesen oder nicht verstanden.

From: me To: Support Date: Tue, 9 Jun 2009 12:17:21 +0200 Subject: Re: AW: Defekter Ethernet Port Turbolink 1203? [...] UM HIMMELS WILLEN NEIN!!!! RUECKGAENGIG MACHEN! Auf DSL-Seite funktioniert(e) alles einwandfrei! Wenn ich (mein eigenes, auf eBay ersteigertes) Ersatzmodem anschliesse, sehe ich auch dass die Synchronisation auf DSL-Seite problemlos >16000 erreicht. Das Problem ist eindeutig der Ethernet-Port des Modems. Und auch hier gilt - mit meinem eigenen Modem gibt es keine Probleme, nur das von M-net gestellte spinnt. [...]


Diesmal dauerte die Antwort noch länger, und war - man glaubt es kaum - noch weniger hilfreich:

From: Support To: me Date: Fri, 12 Jun 2009 08:06:50 +0200 Subject: AW: AW: Defekter Ethernet Port Turbolink 1203? [...] Bitte geben sie uns ihre Kundennummer oder Telefonnummer an um sie eindeutig zu identifizieren. Da der Fehler am Modem liegt, können wir gerne das Modem austauschen. Entweder kommen sie zum Tausch in einen unserer Shops oder wir senden ihnen ein neues Modem zu. [...]


Offenbar ist es unmöglich für M-net, eine Antwort einer von ihnen selbst vor nicht mal einer Stunde verschickten Mail automatisch oder manuell (ueber Subject und From-Adresse) zuzuordnen. Wahnsinn. Aber gut, ich habe mit den gewuenschten Daten und fast einem Fullquote der bisherigen Kommunikation geantwortet.
Die naechste Antwort kam dann immerhin schnell, aber aus Muenchen - was insofern nicht verwundert, als die From-Adresse aller Antworten bisher "support_muc" war, unterschrieben aber trotzdem von einem Nuernberger Mitarbeiter.

From: Support To: me Date: Fri, 12 Jun 2009 15:59:41 +0200 Subject: AW: AW: AW: Defekter Ethernet Port Turbolink 1203? [...] Es tut mir leid,wäre es vielleicht möglich das Sie Ihr Anliegen in ein zwei Sätzen geordnet formulieren könnten, da ich bei dem Durcheinander mich leider nicht zurecht finden kann, vielen Dank. [...]


From: me To: Support Date: Fri, 12 Jun 2009 17:14:23 +0200 Subject: Re: AW: AW: AW: Defekter Ethernet Port Turbolink 1203? [...] Um es kurz zu machen: 1. Der Netzwerkport des mir von M-net zur Verfuegung gestellten DSL-Modems ist kaputt, ich bitte um Zusendung eines Ersatzmodems. 2. Das Problem hat ein Kollege von ihnen [1] falsch verstanden, darum hat er an der Konfiguration meines DSL Ports herumgefummelt, indem er ein anderes Profil mit niedrigerer Bandbreite eingestellt hat. Das war komplett sinnlos, da ich mich nie ueber Verbindungsabbrueche auf DSL Seite beschwert hatte, und dadurch selbstverstaendlich der kaputte Ethernetport des Modems nicht repariert wurde. Ich moechte das das Rueckgangig gemacht wird. Debitorennummer laut Kundenportal: ***** Telefon: ***** [...]


From: Support To: me Date: Sat, 13 Jun 2009 10:31:53 +0200 [...]Die Geschwindigkeit wird am Montag wieder auf volle Leistung eingestellt. Ein neues Modem wird ihnen in den nächsten Tagen zugesendet. Bitte senden sie uns das alte Modem mit dem beigelegten Rücksendeschein zurück.[...]


Das neue Modem kam tatsaechlich am 17ten, und auch das Profil wurde offensichtlich wieder korrigiert (sync mit >17000 KBit). Da auch das Modem funktioniert sieht es aus als haette die Geschichte doch ein Happy End gefunden...
1 comment
Pömpel pömpel pömpel!
Gut gemacht, Fox!
Karin 12.06.2009 15:24

write a new comment:
name or nickname
eMail adress (optional)
Your comment:
calculate: (2 times 10) plus 3

Sun, 31. May 2009


Eee PC 1000HE arrived Created: 31.05.2009 12:35
As sort of a reward for finally doing my tax papers, I got myself an ASUS Eee PC 1000HE. That is an 10 inch Netbook with an Atom N280, 160 GB HDD and 1 GB RAM - and not to forget: a non-glossy display. Unfortunately, unlike its predecessor the 1000H, it is only available with Windows XP home preinstalled. But as the hardware is practically identical to the 1000H except the slightly faster CPU and the larger battery, Linux works flawlessly on it. With Ubuntu 9.04 Netbook Remix everything works out of the box, including suspend to RAM and disc, WLAN, even the Webcam.
What is particularily attractive on this netbook is the long battery life. ASUS claims 9.5 hours, but of course they measure that under Windows, with a display brightness of 40% and everything, including WLAN, disabled. That is not a very realistic usage scenario for me, so first thing for me after installing Linux was to make my own measurements of the battery runtime.
In both tests, bluetooth and the builtin webcam were deactivated in the BIOS. In both tests, WLAN was on, but the actual network connection was through cable. Display brightness was set to 60 to 70 percent. That in my opinion is "normal brightness" for the rather good display, i.e. the brightness you would use if you want to actually see something and not preserve battery life. Turning the display up to 100 percent does not make sense, it's just too bright.
The first test was basically "idleing". All that was running was an IRC client. Normal power saving was active, so it did dim and turn off the screen eventually. In this scenario, the battery lasted for 7.5 hours before reaching "critically low" level. The system then went into "Suspend to RAM" as configured. I was able to wake it up from there another 1.5 hours later. I find both the runtime and the fact that it lasts for ages in the Suspend mode pretty impressive. The (De*l) laptop I have from work hardly lasts two hours and only few minutes more in "Suspend to RAM".
The second test was sort of a "worst case" scenario: Playing back a video (recording of a DVB-S stream at around 900 KByte/sec in pal plus) while running burnMMX in the background. The video was too large to fit into cache, so it was actually read from the hard disc, meaning the disc was not under stress, but could not go to sleep either. The fan was pretty loud during that test, in fact I haven't got it to turn up this far during normal use. But even in this very exaggerated scenario, it survived for 4.5 hours.
There is something I do not like though: You cannot currently buy any (original) spare batteries for the 1000HE - "the internet" tells me ASUS always takes many months to release the spare parts.
Bottom line: I really like my new netbook, and I find it a shame that I have to read on heise.de that ASUS seems to have plans to discontinue the 1000HE in favor of a new model with a crappy glossy display and less battery life (sorry, article is in german). How braindead can managers be? No wait - not only since the banking crisis that is a rhethorical question.
no comments yet
write a new comment:
name or nickname
eMail adress (optional)
Your comment:
calculate: (2 times 10) plus 3

Sun, 10. May 2009


ntpd related linux kernel patch Created: 10.05.2009 19:17
Recent linux kernels exhibit a problem in combination with ntpd: ntpd takes far (read: an order of magnitude) longer to get the clock in sync with the correct time than on other operating systems or older linux kernels. Up to now, this has been an annoyance, but apparently not annoying enough for anyone to bother - after all, the clock is only wrong by a few split seconds, and ntpd will manage to sync it up eventually, although it will usually take a few hours. The only people really noticing it are probably the ones having refclocks, as network latency usually is higher than the error. An excemption to that is when computers are run in an environment where temperature is unstable, because that results in changing frequencies in computer parts, meaning: the clock will start to drift notably, and because ntpd is too slow to correct it in the proper way (by speeding or slowing the clock a little) some little time jumps like on startup may occour.
Luckily, this annoyance should be over soon, because John Stultz was annoyed enough by it to finally track it down. You can read about his findings in this post on the linux kernel mailing list.
Bottom line: The misbehaviour is caused by the rewritten time infrastructure in the linux kernel, and a parameter needs to be tweaked to get back to normal behaviour with the nanokernel. This is a one line kernel patch that in my opinion cannot get into the kernel soon enough. Until then, on linux kernel 2.6.19 to 2.6.29 you can do the patch yourself: open include/linux/timex.h in the linux kernel source tree, locate the line that says #define SHIFT_PLL 4 and change it to #define SHIFT_PLL 2. Then (re)compile your kernel.
Although I have not done any proper benchmarks, the results I have seen so far were very impressive - ntpd will sync within an quarter of an hour now, instead of the many hours it took without the patch. I really hope this goes into the kernel ASAP.
no comments yet

Mon, 13. Apr 2009


LCD Tests with an EA DOGL module Created: 13.04.2009 20:16
As part of a bigger project to (hopefully) build a better bicycle speedometer one day, I played around with some graphical LCD display, the EA (Electronics Assembly) DOG large 128x64. This display has the advantage that it has pins in a 2.54 millimeter grid that can just be soldered onto a printed circuit board (or even a perfboard) or put into some IC socket. Apart from this really easy handling, it can also run with only one 3.0/3.3 supply voltage, and it is available in many different color versions that can be combined with just as many backlight colors. The backlight is actually a seperate part that just gets mounted below the display. But enough with the commercial.
I got the DOGL128W-6, which is black on a white background (FSTN pos. transflective), and an LED68x51-A amber backlight. These parts were put onto a breadboard and connected to an Atmel AVR microcontroller. I then started to write a software library for controlling the display - from scratch. Though (by now) there is some source code available on the internet, I prefer to do things on my own.
This software is available for download at the end of this post. Note that it is only a library with an useless little demo that does some output - it does not do anything useful. But you can use the library in your own projects - at your own risk. It is licensed under GPL version 2 and compiles with avr-gcc / avr-libc.
The library offers the following features:
  • works with EA DOGL 128, and should also work with every other display based on the Sitronix ST7565R chip.
  • variable width fonts.
    • Fonts can be defined in simple text files that get then run through some (included) perl script to generate a space saving font definition that can be programmed into the microcontroller flash.
    • fonts currently have no real limit w.r.t. the width, but can only be at most 8 pixels high.
    • one simple variable width font is included
    • Fonts can be inverted
  • lines can be drawn
  • Images can be drawn from data stored in the microcontroller flash
    • A Perl script is provided to convert images in .png or .gif format to something that can be put into the microcontroller flash.
    • Transparency is supported (also by the converter)
[Download library source]
Below are two pictures from the setup. Note that the 10K Ohm resistor visible in the second picture that connects to the !Reset pin and was intended as an pullup had to be replaced by a normal wire - with an resistor, the display would occasionally lock up under load. And the colors in the first picture are wrong, they are caused by sunlight.
4 comments
Hallo,
ich bin auch gerade am basteln mit dem EA DOG 128 Display und dein Beispiel finde ich super. Leider bin ich nur ein Anfänger und mit einem Grafikdisplay hatte ich noch nie gearbeitet und deshalb ist es eine große Hilfe für mich ein Beispiel zu haben. Danke!
Bobo 21.12.2009 14:33

Hi,

Nice post.
I found this post using google picture search.

Could you tell me the value of the three resistors in image 1 (for the backlight)
Fraggel 20.01.2015 09:52

I'm afraid I don't remember the value of the resistors I used in the picture. However, these are just for powering the backlight, and the backlight is made up of three standard LEDs that require I = 20 mA, so trivial to calculate using the usual formulas. IIRC the voltage drop of the Amber display was 2.1 Volts (but check datasheet), so at 3.3 Volts supply the smallest resistor you could theoretically use would be 60 Ohms. Everything smaller could destroy the backlight, everything larger would just make it a bit less bright. Better be safe than sorry unless you're sure you calculated everything correctly.
PoempelFox 25.01.2015 10:10

Hi,

I home you still have this design. I did not find answer anywhere. Can I use this module with no any back-light. Just as its own.
I need very tiny LCD, while back-light makes it thick.
Mike 10.06.2016 13:14

write a new comment:
name or nickname
eMail adress (optional)
Your comment:
calculate: (2 times 10) plus 3

Mon, 23. Mar 2009


DS1820toUSB Created: 23.03.2009 00:15
When I recently replaced my old Pentium 4 based router with some nice Atom processor based hardware, that left me with a tiny problem: So far, I had connected a DS1620 temperature sensor to the parallel port of the P4, that allowed to log the room temperature and generated some nice graphs. The Atom board however had no parallel port anymore. I therefore had to find another solution.
The solution I built is a board with some Atmel microcontroller that can connect to one or more DS1820 temperature sensors on the one side, and an USB port on the other side.
You can read about it here.
40 comments
Congratulations to the DS1820toUSB adapter, well done ...

But the rom_search code is buggy; i.e. it doesn't find more than two sensors!
mg21 03.07.2010 12:27

It's easily possible there is some bug in the scan logic, but you'd need to be a bit more specific.
PoempelFox 14.07.2010 22:58

do you think I can use attiny2313 instead of tiny45? should I alter the client code? do you have any binaries (i'm running macos and I'm afraid it wouldn't be easy for me to compile that host-related code)
makakasirapuka 03.04.2011 22:44

An atTiny2313 is not suitable, as it only has 2 KB of flash - the code won't fit into that, at least not without a lot of work.
And I do not plan to make binaries for the hostsoftware available.
PoempelFox 06.04.2011 22:16

I asked as there was somewhat tiny15lp on the initial scheme...
btw, did you know that according to datasheet
(http://www.atmel.com/dyn/products/product_parameters.asp?category_id=163&family_id=607&subfamily_id=791&part_id=3618&ListAllAttributes=1)
this attiny45 is equipped with an integrated temp.sensor?
makakasirapuka 07.04.2011 11:15

Oh yes, it does. However, according to that datasheet, it is only usable after calibration, and even then only offers an accuracy of roundabout plusminus 10 degrees. In other words, it's useless.
PoempelFox 07.04.2011 20:19

# ./hostsoftware -v status
ERROR: Command 'status' is unknown.
[...]
--- a/ds1820tousb-20100717/hostsoftware.c
+++ b/ds1820tousb-20100717/hostsoftware.c
@@ -575,5 +575,5 @@ int main(int argc, char ** argv)
  if (strcmp(argv[curarg], "test") == 0) {
    dodevicetest(handle);
- } else if (strcmp(argv[1], "status") == 0) {
+ } else if (strcmp(argv[curarg], "status") == 0) {
    dodevicestatus(handle);
  } else if (strcmp(argv[curarg], "rescan") == 0) {

johnLate 08.07.2011 16:52

"Oups". Fixed version is here: http://git.informatik.uni-erlangen.de/?p=ds1820tousb/.git;a=blob;f=hostsoftware.c;hb=HEAD
PoempelFox 09.07.2011 08:58

hallo,

ich habe den Code / Firmware auf den atMega8 angepasst und auf die AVR CDC-232 portiert. Quarz=12MHz.

Das gesamte Paket würde ich gerne per e-mail zusenden. bitte sende mir mal deine.

Danke Uwe
de0508 28.07.2011 00:11

Naja, das ganze auf nen groesseren AVR bringen ist ja eher trivial :)
Mailadresse steht auf der Homepage? Und Modifikationen fuer andere AVRs wuerde ich wohl eher nicht online stellen - aber drauf verlinken.
PoempelFox 06.08.2011 22:25

Hi guys,
how many temperature sensors can be conected to this system ? ? Did anyone try this ?? I need 16 sensors for my school work and I am a big lama, can anyone help me please? Let me know on email pepino.cz@seznam.cz
thanks a lot guys
Josef 05.09.2011 20:02

Hi, I am interested in buildind such a Thermometer. Its my first project so maybe some of my questions are dumb.
I managed to compile the software in AVR studio, after that on FreeBSD as on that runs my home GW. I just have some questions as the whole thing does not work for me for some reasons.
I am using ATtiny85, 15Mhz Crystal. After compilation the Eprom file is empty. Is this OK? Programming the dss1820 and .elf file went ok.
If I plug it in my Windwos XP desktop, windows tries to do some stuff but finnaly shows that it may by malfunctioning and is unrecognized. Is this OK? ( maybe yes )
Other thing is, the diods 1N4001 get hot and the DS18B20 gets very hot when pluggen in into USB for cca 5 minutes in my desktop. I dont think its ok, is it?
All components are put tohether in a breadboard and the DS18B20 is just directly put into the breadboard, no wire, first I would like to get it working.
On my BSD the USB ports have no power for some unknown reason, but ist an old laptop from 2004, so maybe just broken.
Could someone please answer the 3 questions so I could move forwards, or reset the whole stuff and do it again (i did it once but ended up the same). Thank you.
karol 29.12.2011 12:32

The empty EEPROM is fine. This project doesn't use the EEPROM, but the Makefile is sort of generic, so generates an empty EEPROM file.
I'm not sure what exactly Windows will show when you plug it in, but it is to be expected that Windows will not find a suitable driver for the device - that is not a problem.
However, no component in this circuitry should ever get hot, especially not the DS18B20 - it would be pretty bad if the probe doing the measurement generated so much heat that it would completely spoil any measurement, wouldn't it? If the circuit is working properly, then it uses so little power that the 1N4001 do not create a measurable amount of heat either, even though they are abused as voltage droppers. From the fact that they get hot you can deduce that something in your circuitry is drawing _significantly_ too much power, probably a short-circuit.
As the DS18B20 is also getting hot, my best guess would be that you reverse-poled it, thereby turning it into an expensive short-circuit. For starters, try removing it (the board should also work without a connected probe) and look for other short-circuits.
PoempelFox 04.01.2012 09:41

Im an AVR-n00b and wonder if you can specify what firmwarechanges are needed for using 12MHz Crystal instead of 15MHz?
Thank you for any hints you can give me.
nilsht 08.01.2012 16:35

Hallo,
muss ich am ATTiny45 noch Fuses setzen und wenn ja welche?
Benutze aber einen 12MHz Quarz, da der 15er nirgends zu finden war :'(

Die Hostsoftware sagt mir jetzt, dass die Platine nicht ansteuerbar ist.
donvipre 02.02.2012 09:01

To answer the last two posts: In theory, it should be fine to just adapt the CPUFREQ definition in the Makefile, then "make clean" and "make" again.
For the german question about how to set the fuses: "make uploadfuses" will tell you what I usually set them to, but in the end you need to verify it with the manual of your particular avr controller, especially if you change things like using another quartz.
PoempelFox 10.02.2012 08:12

Hi. I had made this device, it works great. thx/ Truely I fix some in code about frequency of oscillator, manually set the F_CPU.

Now I have two questions:
1. How get access on linux by simple user, i have error like:
"ERROR: Failed to claim ds1820tousb device nr. 1 on the USB: could not claim interface 0: Operation not permitted"

2. Does anybody get it work on Windows system? And how?
tester 17.04.2012 09:01

Hi. I have made this device and it works great with 3 sensors, but it's not possible to get normal work with 4 sensors. I have compiled firmware for 8 sensors (tiny85) and when I connect 4'th sensor I can see full filled list of devices in hostsoftware list (I can see 8 serial numbers, (some duplicate in the list). Does anybody have tried this great device with more then 3 sensors? Maybe the firmware have an error?
Mindaugas 14.11.2012 13:07

would it be possible to buy a chip which is already programmed? For me its no problem to set up the board with the parts but I haven't the stuff (programmer) and the know how to compile the AVR Firmware and send it to the chip.
HDFrank 06.01.2013 22:59

To answer the last posts:
@tester: access to the device on linux as a simple user usually involves configuring udev-rules for that, which is a mess I will not get into.
@Mindaugas: yes, there probably is a bug in the code that scans the bus for the sensors, it seems to fail with certain combinations of sensor serial numbers, however that hasn't been debugged yet.
@HDFrank: AVR programming adapters are really really cheap, so that wouldn't make too much sense. I certainly do not plan to offer it.
PoempelFox 10.01.2013 08:29

do you believe it would work under tomatousb/dd-wrt? what drivers do I need there? what are the pid/mid numbers are set there?
makakasirapuka 25.01.2013 22:33

As long as it has libusb (and the hardware has an USB host port) it should work. I do not understand the last part of your question.
PoempelFox 03.03.2013 20:45

Ah, I've compiled the host software last month for my mac and for tomato router! It runs okay, however, I haven't tested it yet with the device.
I though that I would need the product ID and manufacturer ID of the device but then I realized I don't need it.
Just drew the board - in sop package, plus I want it to run from 5V with two zenners on data lines, rather than dropping voltage from 5 to 3v with diodes.

Now, the problems: It turns out my local suppliers don't have 15MHz quartz here, ordering it from ebay can take another month, and it seems stupid. I've already flashed the µC with your firmware and it would be quite tricky to reflash it (as it needs external crystal).
What makes things even more complicated is I am not familiar with the windows environment (to recompile the code for 12mHz quartz. When I try to do that in macos I get a bunch of errors, which I am not sure how to deal with... Could you be so kind as to add the 12MHz firmware to the archive? (It seems I'm not alone with this question)
makakasirapuka 09.03.2013 12:05

has anyone tried running it from 12MHz crystal? Any success?
Yesterday I set up my virtual windows environment, changed the makefile to attiny85 and 12mhz instead of 15, did 'make' and uploaded the hex file to the µC.
my computer now says:
USBF: 1502185.632 [0xffffff800b263200] The IOUSBFamily is having trouble enumerating a USB device that has been plugged in. It will keep retrying. (Port 1 of Hub at 0x1d000000)
USBF: 1502188.809 [0xffffff800b263200] The IOUSBFamily was not able to enumerate a device.
is it the firmware-related problem, or electrical one?
makakasirapuka 10.03.2013 11:29

Hi, congrats to the complete and a very neat project.
I was wondering, is there a reason for using the crystal? Crystal is not needed for V-USB (i think), to the only reason would be the OneWire code. Is the OneWire done by bitbanging? Sorry for novice questions.
maco 10.03.2013 20:40

the further I go, the more questions I get. sorry for bothering.

should it be working without the sensors connected?
why does it need BOD fuse?
I built the scheme with zeners and recompiled the code for 12MHz crystal, but it seems the scheme just restarts each two seconds...
makakasirapuka 15.03.2013 02:08

To answer the recent posts:
@makakasirapuka: I will not add a 12 MHz firmware to the archive as I would be unable to test it in any way.
@makakasirapuka: There is no way to tell from the USB errors whether the problem is electrical or firmware.
@maco: There are two reasons for the crystal: At the time I did this, V-USBs support for using the AVRs internal clock still seemed very experimental, so I did not want to try it. I also know from experience that the AVRs internal clock is EXTREMELY unstable even when calibrated, and both the onewire bus and the USB are quite timing sensitive, so a more stable clocksource is certainly a good idea.
@makakasirapuka: The BOD fuse prevents the controller from running with severe undervoltage, which would lead to completely unpredictable behaviour of the chip. If it restarts every two seconds, then that is probably not the brownout, but the watchdog timer, as that is set to two seconds (see main.c). If that triggers it means it didn't execute the main loop a single time in two seconds, meaning it got stuck somewhere. I can't tell you out of the top of my head whether it works without any sensors connected - it might well get stuck because there are no sensors at all.
PoempelFox 16.03.2013 23:42

Hi, I have some questions:
1) is possible to re-program programmed attiny85 with this fw? I have programed two and I can' t re-program them after setting fuses lfuse:w:0xff:m
hfuse:w:0xdd:m
efuse:w:0xff:m
my wish is to re-compile fw with support for more than 4 probes and program these tinnys one more time
2) is possible to re-program "dead" attiny85, after setting only one fuse lfuse:w:0xff:m (fuses must be set all at one time!!!, I have try to set one by one and now is tiny dead and does not respond after first lfuse - is locked like at point 1, but at point one I have set all fuses at once and ds18tousb works)
3) how to debug fw for these tinnys? I wish to play with it, but thanks point 1 and 2 I'd rather not to damage more tinnys...
4) where to set support for more than 4 probes? In ds1820.h? And just #define DS1820_MAXPROBES 8? Thats all?
5) What I need to change, when I move to 12MHz Crystal? "...just adapt the CPUFREQ definition in the Makefile..." this means just change CPUFREQ = 15000000UL to CPUFREQ = 12000000UL? And fuses? What to set?
http://www.engbedded.com/fusecalc/
6) find someone similar project for AM2302 (AM2302 (wired DHT22) temperature-humidity sensor)? I realy need am2302tousb... searching searching and nothing :(
7) Is on new hostsoftware 1.14 fixed searching more than 2 probes?

My errors:
1) diodes and temperature probe gets hot, device not recognized - I have reverse polarity on the probe... after reversing probe works very good!
2) device not recognized on system - bad fw on chip or fuses are not set
3) when everything works and no probe is connected, system recognizes ds1820tousb very well, hostsoftware finds ds1820tousb, but while probing returns only zeros (serial and temperature)

Thanks for your great project and time :)
Radius 19.04.2013 15:14

To answer the last post: I'm not sure if I'm following you.
Yes, it is possible to use this firmware with an attiny85 if you properly compile the firmware for it (set chiptype in Makefile) - which you need to do anyways to increase the number of probes allowed. For most fundamental changes you will need to make sure the firmware is fully recompiled - i.e. do a "make clean ; make" not just a make.
In general, it is usually always possible to reprogram a "dead" attiny - although you will usually need to take it out of the circuit and put it into a proper programmer instead (no ISP).
I cannot provide you with personal experience of debugging these except the usual "toggle some of the output lines to signal stuff to the outside" - please ask the internet search engine of your choice about the debugging features like "debugwire" these chips have.
For more probes, you just need to change the define in ds1820.h. Do not set the number of probes too high - if the attiny runs out of memory because you set it too high, it will usually crash silently.
If you still use a crystal and not the internal osc., the only thing you should need to change is the CPUFREQ define. The fuses should not need adaption.
I do not know of a similar project for AM2302.
There is no general problem with more than 2 probes, it can work - it depends on the serials of the probes you have. That bug however is not fixed yet, as still nobody has provided me with the bare minimum to debug it: The serials of probes which cause the bug when used together.
PoempelFox 19.04.2013 20:36

Sorry, you' re follow me not... my bad english.
My situation is, I have working 3 ds18b20 (yes I make it :)) with attiny85, but while doing things to work, I have block one attiny85 (set only one fuse - lfuse:w:0xff:m). And my question is, is possible to unlock him and program one more time corectly? That was point 1 and 2/my question 1 and 2. Your answer is - "...proper programmer instead (no ISP)..." - I have http://www.fischl.de/usbasp/ usbasp programmer, this will not work? Can you please post link to ebay for proper programmer (or programing with serial port will work???)?
3) very thanks
4) very thanks
5) so just change CPUFREQ = 15000000UL (for 15MHz crystal) to CPUFREQ = 12000000UL (for 12MHz Crystal) and nothing more? Seems easy...
6) very thanks
7) the problem is in hostsoftware or in fw? I will try to post serials of probes.

New question:
Who is maintaining this?
http://git.informatik.uni-erlangen.de/?p=ds1820tousb/.git;a=blob;f=hostsoftware.c;hb=HEAD

There is new version of hostsoftware 1.14 and you have on your project 1.12. When I have little time, I will look for differences.


Very thanks for your time and patience.
Radius 24.04.2013 23:15

You probably do not really need a different programmer, the usual problem with bricking an avr is that due to messed up clock configuration in the fuse bits it is expecting an external cpu clocking that just isn't there - provide it (depends on what you set the fuses to of course) somehow externally, and you can reprogram it again. Only in very rare cases can you mess up the fuse bits so badly there is only one way out: High Voltage Programming which requires a pretty expensive programmer then. In general, google for "unbrick avr" - there are a gazillion ways to try.
The bug with multiple probes is definitely in the firmware, in the code that detects the probes attached. There is a documented algorithm for that, and implementing it on the attiny is a PITA due to the limited memory, which is why the code that is currently there is a big mess.
The gitweb repository you mention is mine of course - I linked to it in the previous comments, didn't you see?
PoempelFox 25.04.2013 08:18

Bug:
used probes:
28 000004925723
28 000004927afb
28 00000492a93d

result:
28 00000492a93d
28 000004925723
28 00000492a93d
28 00000492a93d

used probes:
28 00000491d3bd
28 000004927afb
28 000004925723

result:
28 00000491d3bd
28 000004925723
28 00000491d3bd
28 000004925723

used probes:
28 000004925723
28 000004927afb
28 0000049318a7

result:
works

used probes:
28 000004925723
28 000004927afb
28 000004923eec

result:
28 000004923eec
28 000004925723
28 000004923eec
28 000004925723

used probes:
28 000004925723
28 00000492a93d
28 00000491d3bd

result:
works

used probes:
28 000004925723
28 00000492a93d
28 00000491d3bd
28 000004927afb

result:
28 00000492a93d U 72 208 85.00
28 00000491d3bd U 133 147 28.19
28 000004925723 U 194 86 28.31
28 00000491d3bd U 255 25 28.19


used probes:
28 000004925723
28 00000492a93d
28 00000491d3bd
28 000004923eec

result:
28 000004923eec
28 00000492a93d
28 000004923eec
28 000004923eec

used probes:
28 00000492a93d
28 00000491d3bd
28 000004925723
28 0000049318a7

result:
28 00000492a93d
28 00000491d3bd
28 000004925723
28 00000492a93d

used probes:
28 00000492a93d
28 00000491d3bd
28 000004925723
28 000004927afb

result:
28 00000492a93d
28 00000491d3bd
28 000004925723
28 00000491d3bd

On one result, there is bug in temp, sometimes shows with 3 temps too.
2 probes works perfectly everytime, four seems to not work everytime.
And seems that i have found another maybe bug... I will try to inspect it more.

Thanks for your time.
R.
Radius 28.04.2013 19:11

thank you for this helpful report, I will be looking into it.

Update 2013-07-20: I wrote a simulator now, so I can reproduce what the scan routine does. It does indeed reproduce that the scan routine goes into an endless loop with certain combinations of serials.

Update 2013-07-21: I have improved the scan function now, and I hope that the problem is fixed now. Unfortunately I don't currently have a piece of hardware to test it outside of the simulator. If you want to test, compile a current snapshot of ds1820tousb.
PoempelFox 12.05.2013 08:50

I have compiled and tested new software version. It seems that program is working correctly.
I have made some tests with 3, 4, 5, 6, 7 and 8 probes.
We can wait another testers opinion.
Thanks
Mindaugas 27.07.2013 20:58

Hi, very thanks. Seems it is working well with 6 probes. But I have one little question. I have made 5V design and he is working some minutes and after random time it will crash with error:

Windows XP
ERROR: USB error: cygusb0-dll:err [_usb_reap_async] reaping request failed, win error: Zařízení připojené k systému nefunguje.

Translated error:
ERROR: USB error: cygusb0-dll:err [_usb_reap_async] reaping request failed, win error: A device attached to the system is not working.

Linux Mint Debian Edition:
ERROR: invalid interrupt message received from device (0 bytes instead of 8) - continuing
ERROR: USB error: No error

Using Windows XP (testing virtual), compiled with gcc and cygwin.
Using Linux Mint Debian Edition (Debian 8 testing), compiled with gcc.
Runing with command showint.

Schematics:
download vusb and under vusb-20121206.zip\vusb-20121206\circuits\with-zener.png
Only main difference is, that whole design is using 5V from USB and only data pins are lowered with diodes.

I don' t know where is problem, soldering, bad parts or just firmware? Maybe more problems? Any ideas?

And one more time very, very thanks for very good job on probes:) and for your time.
Radius 09.10.2013 22:17

Hi,

Sorry for my latest post - I've already sort it out. I seems that it was bug in soft (I used some old version from github).
Now I'm facing another issue:

root@debian:/ds1820tousb# ./hostsoftware status
Device Version is 00.01
Device time is currently timestamp 13625
4 probes supported by device
fa serial fl lastseen ticksago lastvalue
10 000802aaab23 U 13483 142 3.75
10 000802aaad1b U 13544 81 3.06
00 000000000000 0 13625 0.00
00 000000000000 0 13625 0.00

temperature should show something about 30 C. Why it is showing 3.06 ?
bengbu 15.12.2013 10:44

Because you're apparently using the wrong sensor type. The "10" in the family column suggests its a DS18S20, the cheaper variant of the DS18B20 that has the resolution hardwired to 9 bit (0.5 degrees). To make this work you will need to adjust how the hostsoftware interprets the values from the sensor - in particular, you will at least need to change the line in hostsoftware.c that reads
res = (double)t2 * 0.0625L;
to
res = (double)t2 * 0.5000L;
That should give more realistic values.
BTW: The proper sensors (DS18B20) should have a "family" value of "28".
PoempelFox 17.12.2013 07:11

You were right! I changed sesnor to ds18b20 and it worked just as it should.
You rock, poempelfox!
bengbu 17.12.2013 22:00

Hi, I have question, which software are you using for developing the firmware? AVR Studio?

Radius
Radius 25.01.2014 20:50

I was trying to connect a DS18(S)20 to linux as well. There are solutions without Atmel microcontroller but I've got an even simpler solution to work: I connected RX+TX of a USB-to-serial (CH341) via 220 Ohm resistor to the sensor middle and ground to the two side pins (parasitic mode). digitemp_DS9097 reads it well on a breadboard ...
GMA 27.04.2016 19:32

write a new comment:
name or nickname
eMail adress (optional)
Your comment:
calculate: (2 times 10) plus 3

Tue, 10. Feb 2009


MSI 945GSE Board arrived Created: 10.02.2009 23:23
Last modified: 18.02.2009 20:00
I finally got my MSI 945GSE-A board today. I have been looking for a proper Atom based mainboard for almost a year now. "Proper" in this context means:
  • at least 2 network interfaces onboard, at least one of which must be gigabit and from a good manufacturer
  • good chipset. That means: 945 GSE or US15. Especially NOT 945 GC
  • passive cooling, low power consumption
Although that really is not too much to ask for, up to now that was not really available.
For starters, most boards used the 945 GC chipset. That chipset is just horrible for this application - the complete idiocy of taking a processor that uses only 2 - 4 watts and coupling that with a desktop chipset that uses 22 watts and usually requires active cooling should be pretty obvious. In contrast, the 945 GSE only uses 6 watts.
And if you ever found a board that had two network interfaces, you could bet that it was either 100 mbit, or with a can't-handle-100-mbit-stable-leave-alone-gigabit chipset, or BOTH.
The MSI now does fulfill all those: As the name suggests, it uses the 945 GSE chipset, and thus can be passively cooled without any problems. It also has two nice Gigabit intel NICs onboard. Plus DVI, VGA, the usual audio outputs, and even 2 serial ports on the back and 4 additional port headers on the board. The only downside I have found so far is that the 1.6 GHz hyperthreading Atom N270 used on the board is NOT a 64 bit processor, i.e. it cannot execute AMD64/Intel64 operating systems.
Here are some pictures to make you jealous:
MSI 945GSE-A Mainboard top
MSI 945GSE-A Mainboard front
playing a DVD
the whole system put together
the whole system put together
The case is a Morex Cubid 2677 V3.0. Note that the two case fans visible on the third picture are not connected. The case fits the board pretty well, there is only one slight problem: The power LED has a 3 pin connector, while the board has only a 2 pin header for connecting it. You will have to work around that if you want the LED to light - or you can chose to just not care and do without the green LED.
The whole system has no moving parts except in the DVD ROM. Hard Disk is a 32 GB SSD. Power supply is in the front (below the DVD) and also fanless. It needs 12 volts / 5 amperes DC as input (supplied by an external fanless power supply) and generates the usual ATX voltages from that.
With the case closed, lmsensors shows a CPU temperature of 84 degrees peak when compiling the linux kernel. As fas as I know, the allowed limit is 99 degrees on-die - note however that the 84 degrees mentioned are not measured oncore, but through a sensor on the board. I have no idea how good that sensor is, but it seems as if the CPU is close to its limits - why they did not put a larger heatsink onto it when clearly they had the space beats me. Edit: My trusted source for processor electrical specifications tells me that the official limit is 90 degrees cover temp. That means temperatures are probably OK, as the board sensor usually is below the processor, where the heat dams up.
 
Installing Ubuntu Linux on the board proved a bit tricky. Although the hardware is all intel und thus very well supported by Linux, unfortunately the PCI IDs of the onboard NICs were not yet known by the e1000e driver in the installer of Ubuntu 8.04 (hardy, kernel 2.6.24) or 8.10 (intrepid, kernel 2.6.26). That makes a network install (as I usually do) a bit hard... I had to use the "jaunty" Beta for installation. It uses a 2.6.28 kernel and recognized the network interfaces without any problems.
A collegue tried Opensolaris version 2008.11 on the board: The LiveCD saw the network just fine, but did not manage to bring up X - that however might be a result of the really old 14 inch monitor connected at that time.
 
Here are some things I tried on the board, and whether it is fast enough or not. The CPU usage is taken from top and the sum of all relevant processes (e.g. mplayer and Xorg). Hyperthreading was enabled.
Play DVDsWorks fine. ~70 percent CPU.
Play highres videos (H.264 720p - try Big Buck Bunny) Too slow (though not by much)
Play not-so-highres videos (H.264 480p - try Big Buck Bunny) Works fine. ~80 percent CPU.
Play a DVB-S channel streamed over network (pal+, ~6500 KBit)Works. ~100 percent CPU.
Pull 1 Gigabit from the network with netcat $host $port >/dev/null Works fine (112 MB/s). ~50 percent CPU.
Push 1 Gigabit to the network with cat /dev/zero | netcat -l -p $port Works fine (100 MB/s). ~70 percent CPU for netcat and 30 percent for cat.

For measuring temperatures/voltages/fan speeds (should you really connect one), lm-sensors can be used: The board has sensors detected as Fintek F71882FG/F71883FG Super IO Sensors (linux kernel module f71882fg). In the same SuperIO chipset there also is a watchdog timer which can be enabled in the BIOS, but I have not found Linux-Support for it yet. Be careful when enabling it, it seems disabling it again is not that easy - only after setting timeout to 0, watchdog to disabled, saving, and then powercycling, it stopped resetting.
 
I measured (or rather: estimated with the help of electrical equipment) the power consumption for the whole system (dvdrom, ssd, board, 2 gb memory in the case with the external and internal power supply) with my cheap ammeter: It shows 15.7 watts when idle, and a peak load of 20.5 watts (with 2 burnMMX and glxgears).
 
For reference, here is the lspci -nn output from the machine:

00:00.0 Host bridge [0600]: Intel Corporation Mobile 945GME Express Memory Controller Hub [8086:27ac] (rev 03) 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GME Express Integrated Graphics Controller [8086:27ae] (rev 03) 00:02.1 Display controller [0380]: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller [8086:27a6] (rev 03) 00:1b.0 Audio device [0403]: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller [8086:27d8] (rev 02) 00:1c.0 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 [8086:27d0] (rev 02) 00:1c.1 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 [8086:27d2] (rev 02) 00:1d.0 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 [8086:27c8] (rev 02) 00:1d.1 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 [8086:27c9] (rev 02) 00:1d.2 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 [8086:27ca] (rev 02) 00:1d.3 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 [8086:27cb] (rev 02) 00:1d.7 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller [8086:27cc] (rev 02) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev e2) 00:1f.0 ISA bridge [0601]: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge [8086:27b9] (rev 02) 00:1f.1 IDE interface [0101]: Intel Corporation 82801G (ICH7 Family) IDE Controller [8086:27df] (rev 02) 00:1f.2 IDE interface [0101]: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller [8086:27c4] (rev 02) 00:1f.3 SMBus [0c05]: Intel Corporation 82801G (ICH7 Family) SMBus Controller [8086:27da] (rev 02) 01:00.0 Ethernet controller [0200]: Intel Corporation 82574L Gigabit Network Connection [8086:10d3] 02:00.0 Ethernet controller [0200]: Intel Corporation 82574L Gigabit Network Connection [8086:10d3]
3 comments
quote:
Push 1 Gigabit to the network with cat /dev/zero | netcat -l -p $port Works fine (100 MB/s). ~70 percent CPU for netcat and 30 percent for cat.

Well, if cat takes 30%, why not leave it out and just use "netcat -l -p $port < /dev/zero"? Stdin redirection for the win...
htlaschi 23.02.2009 14:14

Yes, of course that would have saved CPU and given the same 112 MB/s that were achieved in the other direction. But then again, with that I could not have earned a "useless use of cat" award.
Fox 23.02.2009 18:34

Geht das auch auf deutsch? Ich verstehe kaum ein Wort.
bsdice 13.12.2009 22:48

write a new comment:
name or nickname
eMail adress (optional)
Your comment:
calculate: (2 times 10) plus 3

Sun, 08. Feb 2009


Fun with management cards Created: 08.02.2009 01:33
Practically every server today comes with some sort of onboard management interface. Through that interface, the server can - via network of course - be remotely powered up, down or reset if it has crashed. A serial console is practically always available too, which is everything you need for linux or other proper (unixoid) operating systems. If you think you need to run servers on windows, you'll have to get one of the really good ones (and sometimes pay a bit extra for additional licenses), that allow you to redirect graphical output, mouse and keyboard to your pc (usually through a java applet). As an added bonus, they usually allow you to insert an .iso file on your local hard drive into a virtual cdrom drive on the server, so that you e.g. can boot from it.
However, all major manufacturers have in the past managed or still manage to mess some things up in these management interfaces, so here is my personal list of favourite screwups:
  • One manufacturer, lets just say the name starts with an S., manages to build management cards onboard that take 5 minutes to boot. Now that alone would not be horrible - but the thing is, you cannot even power on the server before the management has fully booted! That's right, you plug in the power, and maybe 5 minutes later you're allowed to actually turn the machine on.
  • There is another manufacturer, lets just call him Howling Packrat. Of course, any similarities in name are pure coincidence. The remote control java applet of this one used to be a bit delicate, it would only run with one exact version of java. Not 0.0.1 higher or 0.0.1 lower. Just that one version. Of course, it will happen that you try to run the applet on the wrong version of java, usually resulting in the applet locking up. So you kill your browser and try again. However, you don't really have many attempts there, because usually the management card will lock up after the applet crashed 1 or 2 times, and you have to power cycle the server physically to bring it back to life.
  • A different manufacturer of business machinery, active internationally, does not seem to have understood the concept of TCP on their management interfaces yet. I noticed this last week, when I couldn't get the Java Applet for graphical redirection to run. It just kept spewing nonsense errors (permission denied, class not found, ...) at me. It took me a while to realize that sometimes the simple webpages from the webinterface just stopped loading in the middle of the text. From there on, it was pretty clear what happened: In the management network there was still one 10 MBit switch, because there is close to zero traffic on this network and thus nobody ever cared to exchange it. All remote managements we had ever used before had no problem with that, but not this one: Instead of slowing down when the acknowledgements from the receiving side don't come, and resubmitting packets that got lost due to overflows on the slow link, as a proper TCP implementation would do, this one just closes the connection. That caused the webinterface-pages to be incomplete sometimes, and it prevented the Java applet from ever loading successfully, because the transmission of the rather big file would always die after a few kilobytes. As soon as the switch was exchanged with a 100 MBit one, all of these problems dissapeared. I wonder what will happen if that manufacturer ever builds management cards with a gigabit interface... Hopefully they will have learnt how TCP works by then.
no comments yet
write a new comment:
name or nickname
eMail adress (optional)
Your comment:
calculate: (2 times 10) plus 3

Sun, 01. Feb 2009


Musikdownloadversuche beim Bloed-Markt Created: 01.02.2009 11:12
Letzte Woche sah ich bei heise.de dass der (ich-bin-doch-nicht-)bloed-markt sein Angebot von dem in Deutschland leider immer noch ueblichen DRM-Geficke auf reines MP3 umstellt, und bis 9. Februar guenstige Einfuehrungsangebote hat: 300 Musiktitel fuer 50 cent pro Stueck, und 300 Alben fuer 5 Euro das Stueck.
Es freut mich, dass es sich anscheinend endlich auch bis zu den hirntoten Managern der Musikindustrie herumgesprochen hat, dass es keine gute Idee ist, die zahlende Kundschaft mit DRM zu quaelen bis auch der letzte ehrliche Kaeufer vergrault ist.
Ausserdem finde ich den Preis von 50 cent fuer ein gutes Lied durchaus fair - anders als die normalen Preise, die ich als ueberzogen bezeichnen wuerde.
Das Angebot war also so interessant, dass ich es ausprobieren wollte. Zuerst positive Ueberraschung: sogar das Probehoeren (30 sec. Ausschnitt aus jedem Lied) klappt mit meinem Ubuntu problemlos.
Also mal testweise zwei Stuecke geklickt und fuer 1 Euro gekauft. Oder auch nicht: Zur Bezahlung standen zur Auswahl:
  • ein ominoeser Anbieter bei dem man sich registrieren muss, und ueber den man dann bei ganz vielen Shops ganz toll zahlen kann. Das ganze klang zu sehr nach PayPal um mir sympathisch zu sein.
  • mit Musikdownload-Coupons, die man im bloed-markt kaufen kann. Hatte ich natuerlich nicht.
  • per Kreditkarte
Na aber hallo, Kreditkarte klingt doch gut, auch wenn ich mich frage wie sie da mit Gewinn verkaufen wollen - die Kreditkartengebuehr muss doch bei so Pfennigbetraegen hoeher sein als der Rechnungsbetrag...
Bei dieser Option wird die Abrechnung ueber worldpay durchgefuehrt, man landet also auf einer worldpay-Seite - und nach dem ersten "Weiter" Klick wurde ich von einer Fehlermeldung begruesst. Wirklich klasse. Wenigstens gibt die Fehlermeldung einen Anhaltspunkt wo es hakt: Man muss im Firefox third-party-cookies akzeptieren lassen. Danach liess sich die Bezahlung durchklicken - um auf der letzten Seite ein Popup (natuerlich von Firefox zuerst mal geblockt) mit einer absolut nichtssagenden Fehlermeldung zu liefern.
Geklappt hat die Bezahlung aber wohl trotzdem, denn es kam eine Bestaetigung per Mail, mein Warenkorb war ploetzlich leer, und unter Downloads fand ich die 2 erworbenen Lieder - eines davon allerdings doppelt gelistet. Die MP3-Dateien inclusive cover-jpeg (in Briefmarkengroesse) liessen sich problemlos als .zip runterladen, die doppelt gelistete Datei war allerdings auch doppelt enthalten, einmal mit angehaengter (4) im Dateinamen. Egal, es hatte geklappt, ich war zufrieden.
Die Zufriedenheit verschwand ganz schnell als ich es am naechsten Tag wieder probierte, diesmal mit mehr Liedern: Offenbar hatte der Server Alzheimer, denn bei praktisch jedem Klick wechselte mein Zustand zwischen "eingelogt" und "nicht eingelogt", "Warenkorb voll" und "Warenkorb leer", hin und her. Ausserdem hatte er meinen "Merkzettel" vergessen.
Sonntag frueh klappte es dann wieder problemlos. Da wurde mir dann auch klar wieso das eine Lied doppelt war: Um auf die Seite zu kommen, auf der man alles zusammen als .zip runterladen kann, muss man bei irgendeinem Lied auf "Redownload anfordern" klicken. Dadurch wird genau dieses Lied aber doppelt in das .zip gepackt, und als Bonus: Man verbraucht damit auch 2 der maximal 3 Downloadversuche die man pro Lied hat, obwohl man ja ueberhaupt nur eine einzige Datei, naemlich das .zip, herunterlaedt.
Fazit: Preise ok, aber leider nicht dauerhaft und fuer alles so. Shop vor dem Kauf benutzbar. Bezahlverfahren ein einziger Graus, Gefrickel hoch zehn. Und wenn man erstmal bezahlt hat, ist man ganz offensichtlich nicht mehr wichtig, denn die Bedienbarkeit des Downloadportals laesst stark zu wuenschen uebrig und hat offensichtlich Bugs. Sicher nichts was ich regelmaessig benutzen werde, dazu muessten sie erstmal ihren Webauftritt von jemandem ueberarbeiten lassen der sich mit sowas auskennt, und dauerhaft vernuenftige Preise bieten.
no comments yet
write a new comment:
name or nickname
eMail adress (optional)
Your comment:
calculate: (2 times 10) plus 3

Sat, 31. Jan 2009


Parkplatz-Pfeil-Fail Created: 31.01.2009 17:00
Der Laden bei dem ich ueblicherweise meinen Wocheneinkauf taetige baut seit geraumer Zeit um, und hat im Zuge dessen auch seinen Parkplatz umstrukturiert. Die geaenderte Verkehrsfuehrung wurde mit aufgeklebten Markierungen auf dem Pflaster kenntlich gemacht. Nur irgendwer muss wohl ganz gewaltig gepennt haben beim Kleben, denn seit mindestens einem Monat kann man auf dem Parkplatz diese Markierungen sehen (der Bauzaun steht uebrigens noch nicht lange da, vorher war die Strasse noch deutlich laenger):

Leider bin ich ein Fotographier-FAIL, daher hier eine Vergroesserung des relevanten Ausschnitts auf der man hoffentlich mehr erkennt:

Ein Glueck dass diese Pfeile niemand beachtet, sonst wuerde es wohl irgendwann mal gewaltig krachen...
no comments yet
write a new comment:
name or nickname
eMail adress (optional)
Your comment:
calculate: (2 times 10) plus 3

Fri, 30. Jan 2009


Nur nach Dingen fragen die nicht selbstverstaendlich sind! Created: 30.01.2009 19:00
Am Mittwoch bekamen wir einen Anruf von dem grossen Storage- Hersteller, der unsere neue Tape-Library liefert. Falls jemand sich unter dem Begriff nichts vorstellen kann: Das ist im Prinzip ein Schrank voller Bandkasetten mit Laufwerken und einem Robotergreifarm, der bei Bedarf die benoetigten Kasetten in eines der Laufwerke einlegt bzw. sie wieder zurueckstellt wenn sie nicht benoetigt werden.
Die Hardware war bei uns schon in Einzelteilen angeliefert worden, die Herren wollten wissen ob es okay waere, wenn sie Donnerstag morgen vorbeikommen um das Ding zu montieren. Wir waren einverstanden und sagten ihnen wo sie hinmuessen.
Kurz danach bekamen wir einen zweiten Anruf, sie wollten noch kurz ein paar Fragen klaeren:
  • ob denn schon der Stromanschluss vorhanden waere, damit sie die Library gleich testen koennten. Da die Library ganze ZWEI Haushaltsuebliche Steckdosen benoetigt, konnten wir diese Frage beruhigt bejahen.
  • es waere praktisch wenn wir schon die IP-Adresse der Library wuessten, die koennten sie dann gleich einstellen. Auch das sahen wir nicht als Problem.
Das war alles. Wirklich wichtige Fragen. Wir schuettelten den Kopf und bewunderten andererseits aber die Gruendlichkeit. Man merkt dass die Herren schon sehr lange im Geschaeft sind, und offenbar an jede Kleinigkeit denken, um sie vorher abzuklaeren.
Am Donnerstag kamen die Herren zum vereinbarten Termin, und fingen mit dem Aufbau an. Kurz danach ueberraschten sie uns mit der Frage, wo denn der analoge Telefonanschluss sei. Fuer Remote Support braeuchte die Library einen analogen Telefonanschluss um "nach Hause zu telefonieren", und nein, das koennte man nicht ueber die 2 Gigabit Internetverbindung machen, das geht nur per Analogmodem.
Also halten wir fest: In der Welt von Leuten die professionelle Storage-Produkte verkaufen ist es nicht selbstverstaendlich, dass in einem Rechenzentrum Strom und Netzwerk- oder gar Internet-anschluesse existieren. Wohl aber, dass es analoge Telefonanschluesse gibt.
no comments yet
write a new comment:
name or nickname
eMail adress (optional)
Your comment:
calculate: (2 times 10) plus 3

Thu, 01. Jan 2009


Leap second on NTP Created: 01.01.2009 23:42
There was a leap second 23:59:60 on the 31st december of 2008 - right before the new year started. If you were in the "GMT±0" timezone, you hopefully remembered that, and didn't start your fireworks too early. If you were in a different timezone, you didn't have that problem, because the leap second happened either hour(s) before or past midnight for you.
I'm pretty sure you always wondered, but never dared to ask, how that looks from a computer point of view. Well, the problem is that neither the NTP nor the unix (epoch) timestamps know the concept of leap seconds - the same timestamp exists twice, once for 23:59:60 and once for 0:00:00. In fact, here is what a ntp server with a refclock in germany saw during this leap second:
timecoderefclock_timerefclock_status
01.01.09; 4; 00:59:59; +01:00;     A  ;
 
cd0685ff.00000000  Wed, Dec 31 2008 23:59:59.000
 LEAP ADD WARNING; TIME CODE; PPS; POSITION; (LEAP INDICATION; PPS SIGNAL; POSITION) 
01.01.09; 4; 00:59:60; +01:00;       L;
 
cd068600.00000000  Thu, Jan  1 2009  0:00:00.000
 LEAP SECOND; TIME CODE; PPS; POSITION; (LEAP INDICATION; PPS SIGNAL; POSITION) 
01.01.09; 4; 01:00:00; +01:00;        ;
 
cd068600.00000000  Thu, Jan  1 2009  0:00:00.000
 TIME CODE; PPS; POSITION; (LEAP INDICATION; PPS SIGNAL; POSITION)
As it is in GMT+1, the leap happens at 1 in the morning instead of midnight. The reference clock knows there is a leap second coming up from decoding of the GPS signal that it has as input. NTP will pass this information on to the linux kernel and to its clients, which then hopefully do the proper thing to handle it. However, in linux they apparently weren't so proper - a race condition was discovered that would freeze heavily loaded machines, because the code that printed the warning inserting leap second 23:59:60 UTC could cause a deadlock. This should be fixed in kernel 2.6.29, and the next leap second comes in 1-3 years, so you have hopefully upgraded to a kernel that does not have this problem by then.
no comments yet
write a new comment:
name or nickname
eMail adress (optional)
Your comment:
calculate: (2 times 10) plus 3
 
EOPage - generated with blosxom