All posts by Daniel Stenberg

USB converter woes

USB to rs232 converters are just never sold properly advertising what chip’s inside and right now I want to know if this one UART I’m working with perhaps is not playing fine with my existing converter cable.

I have this XScale PXA270 on a toradex-colibriboard, and it has only one full featured RS232 (FFUART) and I’m about to move things over to the lesser featured BTUART.

A theory is that my current USB converter that is based on a “Prolific PL2303” doesn’t play nicely on the serial port that isn’t a full RS232.

So I ran off and bought a new cable. I grabbed the only model I found in my local Kjell & Company store – it’s quite different looking than my existing but there’s no hint anywhere on the package or inside of it that says what chipset that empowers it.

A quick drive back home (I’m working from home in this assignment), I plugged it in and I got to see this depressingly familiar dmesg output:

usbcore: registered new interface driver usbserial
usbserial: USB Serial support registered for generic
usbcore: registered new interface driver usbserial_generic
usbserial: USB Serial Driver core
usbserial: USB Serial support registered for pl2303
pl2303 2-2.4:1.0: pl2303 converter detected
usb 2-2.4: pl2303 converter now attached to ttyUSB0
usbcore: registered new interface driver pl2303
pl2303: Prolific PL2303 USB to serial adaptor driver

So what now? I hate how (my) computers these days don’t have serial ports while the entire embedded world still very much uses them. I think I’ll go searching in my closet to see if I can find an old crap computer with a serial port to try.

Another theory is that the port simply is broken hw-wise on the dev board but that’s harder to check for me right now.

Update: it was (as usual) only my stupidity that prevented this from working. If I switch it over to the correct baudrate the usb converter does fine. But before I found that out, I did find a computer with a serial port and I did see it working on that too…

User data probably for sale

It’s time for a little “doomsday prophesy”.

Already seen happen

As was reported last year in Sweden, mobile operators here sell customer data (Swedish article) to companies who are willing to pay. Even though this might be illegal (Swedish article), all the major Swedish mobile phone operators do this. This second article mentions that the operators think this practice is allowed according to the contract every customer has signed, but that’s far from obvious in everybody else’s eyes and may in fact not be legal.

For the non-Swedes: one mobile phone user found himself surfing to a web site that would display his phone number embedded on the site! This was only possible due to the site buying this info from the operator.

While the focus on what data they sell has been on the phone number itself – and I do find that a pretty good privacy breach in itself – there’s just so much more the imaginative operators just very likely soon will offer companies who just pay enough.

Legislations going the wrong way

There’s this EU “directive” from a few years back:

Directive 2006/24/EC of the European Parliament and of the Council of 15 March 2006 on the retention of data generated or processed in connection with the provision of publicly available electronic communications services or of public communications networks and amending Directive 2002/58/EC

It basically says that Internet operators must store information of users’ connections made on the net and keep them around for a certain period. Sweden hasn’t yet ratified this but I hear other EU member states already have it implemented…

(The US also has some similar legislation being suggested.)

It certainly doesn’t help us who believe in maintaining a level of privacy!

What soon could happen

There’s hardly a secret that operators run network supervision equipments on their customer networks and thus they analyze and snoop on network data sent and received by each and every customer. They do this for network management reasons and for such legislations I mentioned above. (Disclaimer: I’ve worked and developed code for a client that makes and sells products for exactly this purpose.)

Anyway, it is thus easy for the operators to for example spot common URLs their users visit. They can spot what services (bittorrent, video sites, Internet radio, banks, porn etc) a user frequents. Given a particular company’s interest, it could certainly be easy to check for specific competitors in users’ visitor logs or whatever and sell that info.

If operators can sell the phone numbers of their individual users, what stops them from selling all this other info – given a proper stash of money from the ones who want to know? I’m convinced this will happen sooner or later, unless we get proper legislation that forbids the operators from doing this… In Sweden this sell of info is mostly likely to get done by the mobile network operators and not the regular Internet providers simply because the mobile ones have this end user contract to lean on that they claim gives them this right. That same style of contract and terminology, is not used for regular Internet subscriptions (I believe).

So here’s my suggestion for Think Geek to expand somewhat on their great shirt:

i-read-your-everything

(yeah, I have one of those boring ones with only the first line on it…)

C Code Commandments

I’m an old school C programmers guy and I stay true to some of the older and commonly used rules present in many open source and similar projects. Since I sometimes rant about this to people, I thought I’d amuse my surrounding by stating them here for public use/ridicule. Of course heavily inspired by the great and superior The Ten Commandments for C Programmers. My commandments are not necessarily in any prio order.

Thy Code Shall Be Narrow

Only in very rare situations should code be allowed to be wider than 80 columns. I want my two or three windows next to each other horizontally and still see the code fine. Not to mention the occasional loading up in an editor in a 80 columns terminal and that is should be possibly print nicely (for reviews etc). Wide code is also harder to read I think, quite similarly to how very wide texts in web pages etc aren’t kind to your eyes either.

Thou Shall Not Use Long Symbol Names

To be able to keep the code easily readable by human eyes so that you quickly get an overview and understand things, you simply need to keep the function and variable names fairly short. Not to mention that the code gets harder to keep within 80 columns if you use ridiculously long names.

Comments Shall Be Plenty

Yes, this is something we know everyone says and few live up to. In statistical analyzes of my own C code I usually reach around 25-27% comments and I’m usually happy with that amount. Comments should explain what is otherwise not obvious in the code.

No Hiding What’s Really Happening

I’m not a fan of overloaded operators or snazzy macros that do fancy stuff without it being noticeable in the code. It should be clear when reading the code what it does. That’s also one of the reasons you don’t catch me doing a lot of C++ work…

Thou Shalt Hunt Down and Kill Compiler Warnings

Compiler warnings may be significant and in some cases they are not. Either way, it is our duty to silence them at all times. Firstly because it is often simpler to fix the code to not warn than to figure out if the warning is indeed right or not, but perhaps primarily because it makes it harder to see new warnings appearing if the old ones have been left there.

Write Portable Code Unless Forced by Evil

You may first believe that your code will live on forever on this single platform with this single compiler, but soon and very soon you will learn otherwise. Then you will cheer this rule as it makes you consider unaligned memory accesses, assuming byte-order of binary data or the size of your ‘long’ variable type.

Repeat Not, Use Functions

I see a lot of “copy and paste” programming in my daily life and I’ve learned that sooner or later such practices lead to sorrow. If you paste the same code on multiple places it not only makes it repetitive and boring to update it when an API or something changes, more seriously it increases the risk that you address bugs only on one out of many places or that the fix differ etc. It also makes the code larger and thus harder to follow and understand.

Thou Shalt Not Typedef Away Pointers

A really nasty habit to be seen in some source codes is when people use typedefs to define their own types that is simply a pointer to something. Like with ‘typedef struct whatever * whatever_t’. While I’m in general against excessive typedefing, I’m fine with them in many cases but not when used to hide pointers to look like “ordinary” types. It makes code harder to follow.

Defines, no fixed numbers

Code that relies on zero and non-zero can get away without this, but as soon as you start relying on more numbers in the code you must start using #defines or possibly enums to make them appear with names in the code. Using names is more clever than hardcoded numbers since you can avoid having to explain the number in a comment, and of course it’ll be easier to change the actual number in the code at a later point without it being a painful search-and-replace operation.

libssh2 1.1

I’m happy to announce that we now have a version 1.1 of libssh2 released! Noticeable changes this time include:

  • Downloads using SCP or SFTP are now significantly faster
  • Added a Libtool -export-symbols-regex flag to reduce the number of exported symbols in shared libraries.
  • Added a bunch of new man pages and renamed some of the previous ones
  • Enhanced download performance
  • Made libssh2_scp_recv() and libssh2_scp_send() deal with spaces in filenames
  • Fixed the bad randomness and off-by-one in libssh2_channel_x11_req_ex()
  • Added libssh2_version()
  • Fixed libssh2_channel_direct_tcpip_ex() to not fail when called a second time
  • Fixed libssh2_channel_write_ex problems in blocking situations
  • ‘make check’ runs fine on cygwin
  • Added libssh2_channel_receive_window_adjust2() and deprecated  libssh2_channel_receive_window_adjust()
  • better socket error handling internally on win32
  • libssh2 now always set the socket non-blocking internally and deals with the interface as blocking or non-blocking set by libssh2_session_set_blocking.

The library is rapidly maturing and is getting really usable. I’m happy to see that there’s a community slowly building up around this and I’m also grateful for my sponsor paying for parts of the fixes that contribute to make this release the best ever in libssh2’s history.

libssh2

libssh2.haxx.se

libssh2I’ve played around with a possible new design for the libssh2 web site and I’ve put it up on libssh2.haxx.se for everyone to play around with and comment (on the libssh2-devel list please).

The original and actual home page for the project is still over at www.libssh2.org but I’m not happy with that because of a few things:

The wiki duplicates info that we these days write in man pages and hardly anyone updates the wiki so it lags behind or just contains false or outdated info. I also think having the entire site a wiki a bit problematic for things like menus and generic site layout etc.

I want daily snapshots, web versions of the man pages and mailing list archives to be somewhat integrated in the site to be easier to find.

I already hosted libssh2-related stuff anyway so I’ve just packaged it in a slightly more friendly way. In my view.

What do you think?

Haxx for you

So our company is named Haxx and it has been named like this for more than a decade, but the name is considered by some people be a mark of evil or something.

In my closest circle of friends we’ve kind of “always” liked using silly names and we’ve since long had a fascination with double Xes. Once upon the time in the early 90s we teamed up under the name Frexx and we did some funky programs on the Amiga. Most notably a programming language called FPL and the text editor FrexxEd.

When we then during the second half of the 90s needed to start an actual company to easier cater for our “spare time businesses” we wanted a new name but still one in a similar spirit. Being big friends and practitioners of writing “quick hacks” (“hack” in the sense that it is a quickly done program/script that perhaps isn’t always written very solidly or nice but works for the moment) to solve our own problems both at work and at home, we found Haxx to be a perfect name for us – Hack in pluralis, spelled with double-x.

Already at the time we took the name we knew about this bad habit at places that seemed to lump Hackers with Crackers or similar so we knew there would be a risk that some could assume us to be something else based on our name, but what the heck, we liked the name and we are and were hackers and we do and did a lot of hacks. Haxx it was. Haxx it is.

These days we get some minor problems due to this. At some companies (let’s not name any specific but you know the kind) they have black-listed haxx.se web sites (presumably because of the name ‘haxx’ in the domain name), some people get mails from us our the mailing lists we host easier filtered as spam and we get our share of strange suggestions etc.

I guess the upside of it is that we get our chances to whine on people and systems who decide to filter contents purely based on the presence of a single 4-letter word, either in a domain name or in web page or mail contents, and that is actually hilariously stupid.

Haxx

HD is the thing

Thomson apparently brought the new mp3hd format for music the other day. “HD” is apparently the thing we need to have included when a new term is announced. Why does the world need another lossless music format?

It seems they’ve introduced a crafty dual-format thing where they stuff MPEG-4 SLS lossless encoded data in a new id3 XHD3 tag within the mp3 and then stuff a “regular” mp3 as the normal data in there. This way it is supposed to still work fine with existing and older mp3 players. Of course the total size of all id3v2 tags is limited to 256MB, which could be a limiting factor for it.

As usual, you can find a thriving discussion on this topic on hydrogenaudio.

Rockbox should of course be possible to at first use the mp3 parts and if this truly is an existing established lossless codec there’s a chance it might be able to play that part in the future.

Rockbox 3.2

The never-ending flow of creativity in the Rockbox project was today turned into a release that we label 3.2. The goodies this time include the things below. The three-months release cycle does prevent the list from growing terribly big…

  • Faster text/graphics rendering on colour targets and in the greyscale library, speeding up list scrolling noticeably on ipod Video.
  • PictureFlow supports all targets except Archos Player, and can function during playback on all non-Archos targets.
  • Add LCD sleep/wakeup for iPod Video (5G, 5.5G) which allows significant increase of battery runtime.
  • New game, Goban plugin.
  • Battery charging on Sansa e200v1/c200v1.
  • PictureFlow resizes cover art on load, and supports greyscale targets.
  • Preliminary support for Ipod accessories.

What didn’t get included:

  • The ‘natsort’ which sorts files with numbers as the number and not by ascii. This caused quite a lot of discussions and will be sorted out for 3.3
  • The Rockbox USB stack. It has been enabled in SVN build for several weeks already, but due to it causing some pretty drastic problems to some users we decided to play it safe and disable it in the release. We really hope it’ll be fine for 3.3.
  • Support for any new targets. The Gigabeat S, the Ondas and the AMS sansas aren’t terribly far away, but still not “there”.

A more detailed list can be found in the Release notes for 3.2.

Rockbox

Code re-use is fun

Back in 2003 I wrote up support for the HTTP NTLM authentication method for libcurl. Happy with my achievement, I later that year donated a GPL licensed version of my code to the Wget project (which also was my first contact with the signed paper stuff with the GNU/FSF to waive my copyright claims and instead hand them over). What was perhaps not so amusing with this code was when both curl and Wget 2005 were discovered to have the same security flaw due to my mistakes in this code shared by both projects!

Just recently, the neon project seems to be interested in taking on the version I adjusted somewhat for them, so possibly the third HTTP code is soon using this. Yeah I posted it on their mailing list back then so it has been sitting there in the archives maturing for some 6 years by now…

I also happened to fall over the SSH Tunnel Creator tool, which I’ve never used myself, that apparently snatched my neon donation (quite according to what the license allowed of course) and used it in their tool to do NTLM!

It’s actually not until recent years I discovered libntlm, and while I don’t know how good it was back in the days when I wrote my first NTLM stuff I generally think using existing libs is the better idea…