Older blog entries for johnnyb (starting at number 143)

OK. I have to say that I am thoroughly unimpressed with YourPay and LinkPoint. It took me all day just to figure out how to CONNECT to their test server. Here is the email I sent them. Hopefully google will pick this up and help any poor, weary traveller who is searching to find the answer to these issues if they don't revise their help pages.

----

There are several issues with connecting to your server using Java which were not mentioned in any manual, and which I spent most of the day tracking down. Perhaps if I mention this to you, you can get an FAQ or something written to help out anyone else who has to deal with this.

1) The certificate files that you download from the interface are in the wrong format for Java. Java seems to require keys to be in the PKCS12 format. Instead of having a helpful error message, Java gives something akin to the following error message:

java.io.IOException: toDerInputStream rejects tag type 45

In order to solve the problem, you must use openssl to convert the certificate into one that is usable. So, for the file 12345.pem, you would do:

openssl pkcs12 -export -out 12345.pkcs -in 12345.pem

Then you would use 12345.pkcs as your client certificate file.

2) Now, this works great for connecting to your production server. However, your test server is a different problem. Connecting to your test server gives the following error:

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: No trusted certificate found

This is because you have self-signed your testing certificate. Java doesn't like that. Now, you can import your own certificate into Java, provided you actually have the certificate. I didn't find your certificate on your website, but I found a way to grab it from the SSL connection. If you do:

openssl s_client -connect staging.linkpt.net:1129

It will spit out the certificate file during connection. You can then copy that into a file to use to import into your Java KeyStore (I'm using staging_certificate.txt for this example).

They way you import it into the Java keystore is as follows:

keytool -import -keystore /PATH/TO/YOUR/KEYSTORE/cacerts -file staging_certificate.txt -alias linkptstaging

The /PATH/TO/YOUR/KEYSTORE/cacerts varies by platform. Of course, this entire step would be avoided if you simply bothered to spend the $300 to sign the certificate for your staging server.

I love garbage-collected languages. Here's a nice algorithm in Scheme to calculate the multiple at which a given vector from the origin comes closest to a point in n-dimensional space:

(define (vector:closest-to-point vec point)
  (/
   (vector:sum (vector:map * vec point))
   (vector:sum (vector:map * vec vec))))

If you don't have my handy-dandy vector library, you can do it with lists just as easily:

(define (closest-to-point vec point)
  (/
    (apply + (map * vec point))
    (apply + (map * vec vec))))

Compared to what you have to do in C or other lower-level languages, this is a dream. I didn't even have to define any variables.

For those of you who do barcoding applications, I just found out that someone has made traces of an OCRB raster, and given us this nice Type 1 file for free:

http://thinking-forth.sourceforge.net/OCRB.pfb

I found some OpenGL oddities that weren't very clear from the documentation that I had read so far. The two things I found were oddities with gluPickMatrix and glRasterPos*.

With gluPickMatrix I was under the impression that this only modified the projection matrix. However, it actually modifies both the Projection matrix and the ModelView matrix. That took a long time to figure out. Also, the hit records are laid out really wierd. They even record hits if there are no names in the name stack.

The other thing I figured out is with glRasterPos. First of all, I was under the impression that glutBitmapCharacter and glutBitmapString just render from the origin of the current modelview. I was wrong. It appears that it actually renders from the current RasterPosition, and advances forward along the raster position, and I think it is independent of the ModelView Matrix from that point on, moving the current raster position. FreeGLUT may be different, but I need to test it. It will also use the color from the time of the call to glRasterPos*, not from the call to glutBitmapCharacter. That's a little counterintuitive, except that the documentation mentions that glRasterPos* works just like glVertex*. Therefore, it is transformed and colored just as if it were a vertex. So when a bitmap is drawn at the raster position, it uses the OpenGL state that was present when the raster position was set up, not how the render state currently is.

Hopefully, my ANOPA viewer (which is what I'm working on for this project) will be ready to show sometime soon. Working through these two problems helped a lot, especially the gluPickMatrix stuff, as well as figuring out the details of what is returned in the selection buffer.

Also, I'm hopefully going to generate some nice utility functions for opengl.egg for Chicken Scheme.

If anyone is having problems with IE support for PNG images (displaying them darker than your background color, for example), then I've found your solution. Apparently Photoshop always saves gamma information to your PNG. You need to strip it out. You can do this with pngcrush (which you should be using anyway).

pngcrush -rem gAMA infile outfile

I made a simple webpage for this for internal use, and it works quite handily.

I believe GIMP works if you choose to leave off the Gamma information.

Just posted a new article to IBM's Developerworks. This one is on recursive programming and program proving, and touches on C, Scheme, and even assembly language. You can see it here:

Mastering Recursive Programming

Anyway, if you're interested, please email your comments on it to me! johnnyb@eskimo.com

I have an application that integrates with DHL's online shipping rate calculator HTTP interface. This calculator has always been dumb from one perspective -- it doesn't allow floating-point values for the weight. However, I can kind of overlook that. In fact, generally I like their calculator because the API for it is described in just a few pages, as opposed to, say, UPS, that has hundreds of pages of documentation just to get a stupid rate quote.

What's really stupid, though, is that they changed the output format of their web requests, and I don't think they even realize it. It looks like it was a dumb formatting bug, and they don't even know it happened.

Let's look at the old format of the data:

  GND, NAS, SDS, EXP

   $6.25, $28.5, $13.3, $32.25

Now, let's look at the new format of the data:

                                                                               
                                                                               
  GND, NAS, SDS, EXP
  <br>
  $6.25, $28.5, $13.3, $32.25
                                                                                                                                                                                                                                             

(note that the indentation is actually the same on both of them, I think, but I couldn't replicate it due to some HTML or Advogato wierdness).

First, they added two blank lines to the beginning of the document. Second, they added a stupid <br> tag in the middle of the data. This would throw off many reasonable parsers of this data.

Why did this happen? My guess is that someone added some sort of stupid output filter to their web application, and forgot to set it not to filter the web apps that are used by programs as API's rather than by humans.

Well, DHL lost a customer for that one. UPS may have a large API for those of us who just want rate requests, but at least I have a reasonable expectation that they're output formats might be consistent.

Despite what I said in my previous post, I found this article which explains better how DHCP renews its leases. And, in fact, it will start trying to renew the lease at 50% of its lease time.

Yay!

Apologies to the developer of DHCP if I in any way offended you.

I used to think it was great -- wonderful to auto-configure. You can manage your whole network on it! But I was wrong. Why? Because lease-times have no ranges.

In DHCP the client gets an address for a specified lease time. When that time expires, it attempts to get a new address. However, if the DHCP server is not there, it will STILL give up its IP address. There must be a reason for this, but to me it seems both unintuitive and stupid.

The problem is that this makes your DHCP server a critical point of failure for no reason whatsoever. If your DHCP server tanks, then all of the network items who try to renew while the DHCP server is down will be without an IP address. If your DHCP server tanks at night or over the weekend, and all your phones use VoIP and DHCP, then this means that when you get there in the morning your phone system will not be working.

There are workarounds. You could cluster your DHCP servers, but this is just stupid for small networks. There is no reason that I can see why you shouldn't be able to specify both a lease-time and a max-lease-time, the first of which is when the computer BEGINS to ask for a new IP address, and the last of which is when the computer RELINQUISHES the given IP address. This way, if you are a lone network admin for a company, you can go on vacation with the expectation that the network will have some sort of resiliency for little effort. Just set the distance between the BEGIN and RELINQUISH stages to be a week or so, and you're all set.

And that brings me to devices which lose their IP address on reboot. Same problem. Is there no way to save that IP address? Then, when you reboot, if you can't find the DHCP server, just go with the IP address you were originally assigned. Do a ping test if it matters to you. Or at least have that as an option.

I'm getting ready to move to all static IP's except for a small pool for roaming computers. The idiocy of DHCP is just absolutely aggravating. I refuse to add the complexity to the network that a redundant DHCP server would add. That is just ludicrous.

If you are having interrupt misses in asterisk, here are the things that Digium suggested I do:

• Verify that the card was not sharing an interrupt (check /proc/interrupts, lspci -v, and lspci -vb
• Verify the DMA mode of the IDE drive (add -d 1 -X udma2 -c 3 -- add to /etc/sysconfig/harddisks)
• Turn X-windows off, and other applications which may adversely affect interrupt load
• Don't use a serial console
• Don't use a framebuffer (append vga=normal to your kernel command line
• Turn off ACPI power management (add acpi=off to your kernel command line)
• Turn off your APIC interrupt controller (add noapic to your kernel command line)

The results of zttest over an extended period (I usually test 5 minutes to an hour) should not at any time go below 99.98%, with 99.975% being the absolute lowest. The last one, noapic, really, really, REALLY helped my box.