Category: Problems

Workarounds, patches and unsolved software bugs.

PHP array references

Hit this one at work, where we use RHEL4’s PHP 4.3.9.

The online documentation doesn’t mention it any more, but there’s a history of PHP not dealing well with array references.

PHP segfaults. Unfortunately it’s quite hard to reproduce artificially; we don’t see the segfault until way after the reference was taken (presumably after the GC has done its rounds). It’s 100% reproducible in our program, but I’m still working on a minimal test case.

Apache 304s and mod_deflate

The deflate output filter in Apache breaks Apache’s handling of the HTTP cache validation model. It won’t send an HTTP 304 status if mod_deflate is actively filtering the response, even if the Etag and Last-Modified allow it to. I asked, and apparently this is a known issue. I might have to wait until after exams before making a patch for this one.

In its current state, this introduces a tradeoff for large, uncompressed static files (like CSS and Javascript):

  • gzip stuff, and you improve site performance the first time someone visits, but it never gets any faster.
  • allow Apache to send 304 statuses, let the user have a slow load on their first visit, but celebrate as they hit their cache thereafter

The second option looks more attractive.

xl2tpd woes

I’ve been trying to get an IPsec/L2TP VPN server going on spade. This kind of VPN involves several layers (ipsec, l2tp and ppp) which all seem to fail independently and differently depending on how I test a configuration. So far it’s been a 4-day epic.

I figured I should establish that L2TP worked in a trivial case before trying to glue it together with ipsec. So I installed xl2tpd on scuff and tried to connect over the local network.

Here are some lessons learnt:

  • Bringing LACs up is a bit convoluted (you write “c lacname” to the control file).
  • The xl2tpd.conf file sets PPP and L2TP parameters. These shouldn’t be confused: auth file, hostname and challenge are L2TP things.
  • As a consequence, always use /etc/ppp/chap-secrets, not the l2tp secrets file.
  • xl2tpd has a bug that means refuse authentication in a LAC does the opposite of what you think it should do.

When you write refuse authentication = no in a LAC section, xl2tpd adds refuse-chap and refuse-pap to the PPP options unconditionally. This results in a lot of “peer refused to authenticate” PPP errors. The bug is present in version 1.2.0 and Debian’s dfsg-1 release. I made some noise on their list and a bug report.

I guess hardly anybody manually creates L2TP client connections, because this would be really obvious (at least that there was something wrong, finding the problem took me a day of tcpdumps, source perusal and log file reading).

Update: patch accepted in xl2tpd 1.2.2