Older blog entries for thiagom (starting at number 8)

Oh, the other idea I had was to create a still new class in kdelibs, called KHostname. Its constructor would receive a text hostname and then someone could call KHostname::lookup() and receive all the data in a QList<KSocketAddress>

Problem: I'd use getaddrinfo() to do the lookup, which would either be:

  • a repetition of the code needed in KExtendedSocket to do the same loookup
  • called by KExtendedSocket to do the lookup, which in turn means KHostname would need port/services

Given that, I am in doubt whether this class would be better integrated into KExtendedSocket alone.

I have had some new ideas for the IPv6 implementation in KDE. First and foremost, I thought that maybe I should not try to make it in kdelibs, but in QT. I have seen that KDE and QT duplicate a lot of code and effort, like QSocket and KSocket, QUrl and KURL. So, question is: would we all benefit more from a IPv6-transparently-enabled QSocket or KSocket?

Let me emphasize the word transparent. Both QSocket and KSocket already support IPv6 in a manner or another. But neither implementation is good enough, to the point that KSocket's implementation is practically non-existant. Even if the preprocessor directives were enabled in KSocket, it still wouldn't work.

I am currently aiming to make my work to kdelibs. That is, all the code left behind in QT would be left unused. However, there's (so far) nothing preventing change into QT (read: KSocketAddress and others would fit nicely in QSocketAddress).

Problem with QT is: QSocket would change signature, while KSocket wouldn't necessarily have to.

I have just concluded writing a couple of classes for KDE in the new project I am starting, regarding full IPv6 support. The classes are:

  • KSocketAddress
  • KInetSocketAddress
  • KUnixSocketAddress

Those classes are simple and actually change nothing in current KDE's implementation of sockets. Next step is now to add class KExtendedSocket (probably inherited from QIODevice), which will do everything sockets need to do. After that is done, I'll rewrite KSocket from the scratch, keeping the same signature, to use KExtendedSocket.

Mail me if you want the files

Later yesterday, I got kdenetwork 1.92 and set off to enable IPv6 on it. Now, I've got a question for kdenetwork's developers: did you know there was a class called KSocket that you were supposed to use?

Well, the only major program to not use KSocket was knode. There was some well-written code there, but completely redundant, to open a connection. I say redundant because that's exactly what KSocket was supposed to do. So, all in all, I removed that code (#if 0/#endif) and added half a dozen lines to enable KSocket in its place. That done, knode now speaks IPv6.

Kppp also uses socket() but I haven't had the time to check on what. What I did have time to change was the addition of some devfs serial devices that weren't present on it. Since you are not allowed to type your own dial-out device (should that be changed?), I added four new devices, /dev/tts/0, /dev/tts/1, etc.

That also meant checking the locking code for Kppp, since you can't create a file with a slash in its name. I'd like to know what we're supposed to replace it with. I used an underscore ('_').
Also, I noticed that the locking code is still not correct. From what I know, you're supposed to lock the file you were given and lock any other devices your file pointed to, in case it was a symlink.

Patch is here: kdenetwork-1.92.1.diff

I've got version 0.0.1 of allifdump ready. It seems to work here, at home.
The problematic bug I was facing was using realloc() and still keeping a pointer to the old buffer. Since I fixed that, it seems to work fine now. Threaded mode is still not-done.

Since I decided to enable IPv6, I needed an IPv6-enabled tcpdump. So, I got tcpdump 3.5 and it understands IPv6 fine, but it can only show one interface at a time.

I decided, then, to write a small wrapper program that would run several tcpdumps, one on each interface, and parse the output into a simple output, indicating the interface the packet came from.

I'm calling it allifdump.

I've been trying to get some IPv6 code working for the past few months. Some attempts at it worked, but not much more than simple connection opening and listening programs. Recently, I've managed to work out some real IPv6 IPs on the 6bone, via FreeNet6. If you're interested, you can (could) reach me at:

loki.br.freenet6.net (3ffe:b00:c18:1fff::1e7)

Given that, I decided I needed an IPv6-enabled browser. Since I already had determined to make KDE2 IPv6 enabled, I set off making Konqueror able to talk at 6bone.net. Guess what?
It worked.

The patch is here and must be applied on top of a clean kdelibs 1.92 (beta 3 -- korner) code. It'll completely replace the KSocket & KServerSocket classes and will add some patches to kio/http/http.cc and kio/ftp/ftp.cpp (why don't everyone use .cpp?).

For the moment, only HTTP browsing is enabled in IPv6 mode. FTP under IPv6 adds two (more?) new commands I haven't yet mastered, so I didn't mess with that.

I had some time today and I decided I would spend it on IRC, helping people out as well as I could. If you wish to talk to me, I´m always at DALNet (irc.dal.net) channel #linux, under the nick FAdmThiago (beaware that I´m away a long time).

I spent some time with people from Conectiva and a couple of people from other parts of the world

I also decided to track down a Kernel Oops I was getting. Though I found the eventual reason, I am not sure whether this is a kernel bug or was caused by me in the long run of applying patches to the source.
If you wish to have a look at that on your own, send me an e-mail and we´ll talk.

Well, right now I'm involved with a non-Open Source project. What can I say? It pays well.

Anyways, I'll resume coding OS software whenever possible.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!