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