This is to announce the release of Pound v2.4. This is really the 2.4f
code, packaged as an official, stable version. Changes since version
2.3:

Enhancements:
  - added PARM session type. Old PARM is now URL (change your config
    file as required!)
  - added support for IPv6 (but host caching was removed)
  - allow AddHeader for HTTP listeners as well
  - allow -1 for session (all types) TTL. Will hash the key to a fixed
    value
  - Redirect takes an optional code parameter (301, 302/default or 307)
  - new config param to allow printing the SSL certificate in a single
    line
  - new config param to control the maximal size of the input line
  - added better error messages for SSL loading problems
  - added XML output for poundctl
  - cleaned resurrection code
  - added RR threads scheduling
  - added display of configuration switches
  - added grace period for shutdown (based on an idea from Rune Saetre)
  - added more detailed error messages
  - now using lh_hash for the session tables
  - moved to GPLv3

Bug fixes:
  - fixed problems with chunked encoding
  - fixed problem long lines (thanks to Rune Saetre)
  - fixed pcreposix autoconf for systems that also require pcre
  - fixed problem with IP session handling
  - allow case-sensitive matching for URLs
  - fixed memory leak in DNS searches
  - if the same cookie is defined more than once use LAST definition
  - fixed test for owner/group (BSD portability)
  - fixed problem with premature opening of control socket
  - fixed back-end enable/disable (priority computing)

The software is at version 2.4 (production quality). Further testing
(especially under heavy loads), improvements and suggestions are
welcome.[...]

Hello,

I am coming from IP address 76.224.247.54. Since Feb 10, 2008, I have not
been able to see the www.apsis.ch web site. The trace route shows:

  1     3 ms     1 ms     1 ms  192.168.5.1
  2     3 ms     2 ms     2 ms  76.224.247.54
  3    12 ms    10 ms    10 ms  bras1-l0.sndgca.sbcglobal.net
[151.164.184.143]

  4     9 ms     9 ms     9 ms  dist1-vlan60.sndg02.pbi.net [63.200.206.194]
  5     9 ms     9 ms     9 ms  151.164.94.2
  6    15 ms    13 ms    13 ms  151.164.93.167
  7    13 ms    14 ms    14 ms  151.164.248.194
  8   178 ms   246 ms   238 ms  217.239.39.98
  9   178 ms   178 ms   178 ms  62.153.202.250
 10     *        *        *     Request timed out.
 11     *        *        *     Request timed out.
 12     *        *        *     Request timed out.
 13     *        *        *     Request timed out.
 14     *        *        *     Request timed out.
 15     *        *        *     Request timed out.

www.apsis.ch resolves to "mail.aspsis.ch" which is 80.254.173.44. 

Do other people on the west coast of the USA have a problem connecting to
the APSIS web site?
[...]

On Mon, 2008-02-11 at 07:38 -0800, Jacob Anderson wrote:[...]

Can't really help you there - the mysteries of the back-bone are subtle.
It may just be that some host on the way blocks the traceroute packets.
However the Pound site itself (not Apsis, but only the Pound related
stuff), as well as the mailing list, are mirrored on Google groups
http://groups.google.com/group/pound_proxy?hl=en

Hope this helps a bit...[...]

> Hello,[...]

Maybe you could try using ICMP (traceroute -I)?

Simon

Hi Simon,

Windows XP Pro tracert doesn't have "-I" option, and no ICMP control switch.
So I did it from the CentOS box that is running pound:

 1  Home Base IP Addresses ...
 2  Home Base IP Router ...
 3  sndgca1wce1-gige6-0.wcg.net (65.77.90.41)  0.429 ms  0.280 ms  0.739 ms
 4  anhmca1wcx3-pos0-3.wcg.net (64.200.249.13)  2.607 ms  2.917 ms  3.034 ms
 5  64.200.249.122 (64.200.249.122)  11.549 ms  25.753 ms  10.723 ms
 6  64.200.249.142 (64.200.249.142)  10.635 ms  10.715 ms  10.714 ms
 7  te-3-2-70.car4.SanJose1.Level3.net (4.68.110.25)  11.369 ms  10.916 ms
10.975 ms
 8  ae-43-99.car3.SanJose1.Level3.net (4.68.18.197)  12.188 ms  12.546 ms
12.197 ms
 9  COGENT-COMM.car3.SanJose1.Level3.net (4.68.110.138)  13.737 ms  13.589
ms  13.615 ms
10  vl3498.ccr02.sjc01.atlas.cogentco.com (154.54.6.233)  13.594 ms  13.574
ms  13.598 ms
11  te2-1.ccr02.sfo01.atlas.cogentco.com (154.54.1.129)  14.953 ms  14.815
ms  14.791 ms
12  te9-3.ccr02.mci01.atlas.cogentco.com (154.54.24.118)  48.245 ms  48.383
ms  48.204 ms
13  te2-3.ccr02.ord01.atlas.cogentco.com (154.54.6.213)  60.423 ms  60.443
ms  59.861 ms

14  te9-3.mpd01.bos01.atlas.cogentco.com (66.28.4.197)  80.996 ms  80.684 ms
80.532 ms Icmp checksum is wrong

15  te8-3.mpd03.jfk02.atlas.cogentco.com (66.28.4.202)  160.083 ms Icmp
checksum is wrong 159.710 msIcmp checksum is wrong   159.578 ms Icmp
checksum is wrong

16  te4-1.mpd02.par01.atlas.cogentco.com (130.117.1.246)  160.336 ms Icmp
checksum is wrong 160.159 msIcmp checksum is wrong 160.386 ms Icmp checksum
is wrong

17  te4-1.mpd01.par02.atlas.cogentco.com (130.117.2.82)  149.277 ms Icmp
checksum is wrong 149.349 msIcmp checksum is wrong 149.267 ms

18  te1-1.mpd02.fra03.atlas.cogentco.com (130.117.2.13)  160.530 ms  160.589
ms  160.416 ms
19  te1-2.ccr01.str01.atlas.cogentco.com (130.117.3.82)  163.244 ms  163.006
ms  163.132 ms
20  te1-2.ccr01.zrh01.atlas.cogentco.com (130.117.3.14)  165.643 ms  165.952
ms  165.439 ms
21  green-ch-ag.demarc.cogentco.com (130.117.243.174)  165.614 ms  165.468
ms  165.937 ms
22  zh2-lns01-ge0-1.noc.green.ch (80.254.161.51)  165.799 ms  165.854 ms
165.761 ms
23  zux173-044.adsl.green.ch (80.254.173.44)  175.616 ms  176.010 ms
175.405 ms


[...]

>  Hi Simon,[...]

Ah right, maybe that's why it's called tracert instead of traceroute :)
[...]

Insteresting, this box seems to reach the www.apsis.ch site without any
problems. Did you try it with the same connection (at least the routes
seems to be very different)?

Simon
[...]

Hi Simon,

 > Insteresting, this box seems to reach the www.apsis.ch site [...]

Yeah, I can reach the site now. It only happens now and then that I can't
reach the apsis web site. The problem might be packet tagging through the
AT&T connection to Europe. The other trace route was from a static DSL
connection. This last trace route was from a hard colocation line.

I also have customers in Warsaw, Poland, who get very poor connectivity to
my colocation in Calfornia because of a bad router in Portugal. I think that
one was an AT&T problem too.
[...]