Bug#426744: Cronjob senddigests reports ValueError: timestamp out of range for platform time_t
Package: mailman Version: 1:2.1.9-7 Severity: normal Hi! Every day I get a mail from cron daemon about a cronjob that has a problem: Date: Wed, 30 May 2007 12:00:04 +0200 From: Cron Daemon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Cron [EMAIL PROTECTED] [ -x /usr/lib/mailman/cron/senddigests ] /usr/lib/mailman/cron/senddigests Traceback (most recent call last): File /usr/lib/mailman/cron/senddigests, line 94, in ? main() File /usr/lib/mailman/cron/senddigests, line 86, in main mlist.send_digest_now() File /usr/lib/mailman/Mailman/Digester.py, line 60, in send_digest_now ToDigest.send_digests(self, mboxfp) File /usr/lib/mailman/Mailman/Handlers/ToDigest.py, line 112, in send_digests timetup = time.localtime(mlist.digest_last_sent_at) ValueError: timestamp out of range for platform time_t Any idea how to avoid this? (appart from filtering the email or make the cronjob less chatty...:-) ) cheers, Bernie -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.27-powerpc Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages mailman depends on: ii adduser 3.102Add and remove users and groups ii apache [httpd] 1.3.34-4.1 versatile, high-performance HTTP s ii cron3.0pl1-100 management of regular background p ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy ii exim4 4.63-17 metapackage to ease exim MTA (v4) ii exim4-daemon-heavy [mail-tr 4.63-17 exim MTA (v4) daemon with extended ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii logrotate 3.7.1-3 Log rotation utility ii lsb-base3.1-23.1 Linux Standard Base 3.1 init scrip ii pwgen 2.05-1 Automatic Password generation ii python 2.4.4-2 An interactive high-level object-o ii python-support 0.5.6automated rebuilding support for p ii ucf 2.0020 Update Configuration File: preserv mailman recommends no packages. -- debconf information: * mailman/site_languages: de, en * mailman/used_languages: de en * mailman/create_site_list: * mailman/queue_files_present: * mailman/default_server_language: en * mailman/gate_news: false -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#424984: openser: Insert Route HF (from Path) messes up
Hi Julien
I believe to have located the problem an wrote a patch (against the
current debian stable) to circumvent it:
- The Route HF is inserted after the last Via HF,
which means right before the From HF (in my case)
- If I also change the From HF, I run into the known limitation of
OpenSER 'changing a HF twice gets unpredictable results' (lump stuff).
It looks like that changing a HF and inserting a HF right before the
changed one, ends up in same case as changing the HF twice.
- To circumvent the problem I rewrote the file
openser/branches/1.1/modules/tm/path.c
in such a way, that the Route HF is (if no Route HF present yet) always
inserted right before the Call-ID HF, as the Call-ID MUST NOT be changed
(unless you are a B2BUA).
If there is no Call-ID HF, an error is returned.
(This means I presume, that Call-ID must be present and not be changed)
Please find the patch in the attachment.
I have tested it on my system and it apprears to work fine.
cheers,
Bernie
Bernie Hoeneisen [EMAIL PROTECTED] wrote:
Hi,
Thus, it seems that calling the subst() function before the
(Path-info) Route HF is inserted causes the problem.
Thanks for the testing, I'll watch for the bug upstream.
I imagine you can't test openser 1.2 ?
JB.
--
Julien BLACHE [EMAIL PROTECTED] | Debian, because code matters more
Debian GNU/Linux Developer| http://www.debian.org
Public key available on http://www.jblache.org - KeyID: F5D6 5169
GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
diff -r -u openser-1.1.0/debian/changelog openser-1.1.0.new/debian/changelog
--- openser-1.1.0/debian/changelog 2007-05-19 14:03:16.0 +0200
+++ openser-1.1.0.new/debian/changelog 2007-05-19 12:19:22.0 +0200
@@ -1,3 +1,9 @@
+openser (1.1.0-9etch1-1) stable; urgency=low
+
+ * Workaround for problem with (Path-)Route HF insertion
+
+ -- Bernie Hoeneisen [EMAIL PROTECTED] Sat, 19 May 2007 12:18:57 +0200
+
openser (1.1.0-9etch1) testing-proposed-updates; urgency=low
* Security fixes for Etch (closes: #412904).
diff -r -u openser-1.1.0/modules/tm/path.c openser-1.1.0.new/modules/tm/path.c
--- openser-1.1.0/modules/tm/path.c 2006-01-30 17:37:30.0 +0100
+++ openser-1.1.0.new/modules/tm/path.c 2007-05-19 12:42:56.0 +0200
@@ -34,36 +34,32 @@
* Save given Path body as Route header in message.
*
* If another Route HF is found, it's placed right before that.
- * Otherwise, it's placed after the last Via HF. If also no
- * Via HF is found, it's placed as first HF.
+ * Otherwise, it's placed before the Call-ID HF. If also no
+ * Call-ID HF is found, it will return an Error.
*/
int insert_path_as_route(struct sip_msg* msg, str* path)
{
struct lump *anchor;
char *route;
- struct hdr_field *hf, *last_via=0;
+ struct hdr_field *hf, *callid=0;
for (hf = msg-headers; hf; hf = hf-next) {
if (hf-type == HDR_ROUTE_T) {
break;
- } else if (hf-type == HDR_VIA_T) {
- last_via = hf;
+ } else if (hf-type == HDR_CALLID_T) {
+ callid = hf;
}
}
if (hf) {
/* Route HF found, insert before it */
anchor = anchor_lump(msg, hf-name.s - msg-buf, 0, 0);
- } else if(last_via) {
- if (last_via-next) {
- /* Via HF in between, insert after it */
- anchor = anchor_lump(msg, last_via-next-name.s - msg-buf, 0, 0);
- } else {
- /* Via HF is last, so append */
- anchor = anchor_lump(msg, msg-unparsed - msg-buf, 0, 0);
- }
+ } else if(callid) {
+ /* Call-ID HF found, insert before it */
+ anchor = anchor_lump(msg, callid-name.s - msg-buf, 0, 0);
} else {
- /* None of the above, insert as first */
- anchor = anchor_lump(msg, msg-headers-name.s - msg-buf, 0, 0);
+ /* None of the above */
+ LOG(L_ERR, ERROR: insert_path_as_route(): Failed to get anchor. No Call-ID HF found\n);
+ return -1;
}
if (anchor == 0) {
Only in openser-1.1.0.new/utils/openserunix: openserunix.d
Bug#424984: openser: Insert Route HF (from Path) messes up if UTF-8 chars around
Package: openser Version: 1.1.0-9etch1 Severity: normal Tags: l10n Hi! I am testing the Path HF usage. When the usage of Path causes a insertion of a Route HF and the (original) SIP INVITE request contains UTF-8 characters, the Route HF gets inserted at the wrong place, e.g. between the CR and LF (Hexadecimal 0D and 0A) at the end of the From HF: INVITE sip:[EMAIL PROTECTED]:6051;line=nfy9nuy8 SIP/2.0 Record-Route: sip:127.0.0.1;r2=on;lr=on;ftag=as19d6b213 Record-Route: sip:130.89.10.194;r2=on;lr=on;ftag=as19d6b213 Remote-Party-ID: Bernie Höneisen sip:[EMAIL PROTECTED] Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bK77a8.e46b2c74.1 Via: SIP/2.0/UDP 130.89.10.195:5060;branch=z9hG4bK53c948e4;rport=5060 From: Bernie Höneisen sip:[EMAIL PROTECTED];tag=as19d6b213^MRoute:sip:130.89.10.194;lr;received=sip:97.56.98.20:3051 To: sip:[EMAIL PROTECTED] [] (This example has been anonymized. Original available on request.) The Hexadecimal code of the UTF-8 char is: C3 B6 (o with Umlaut) I guess the detection for the anchor, where the Route HF has to be inserted gets confused by the UTF-8 character. cheers, Bernie -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (990, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages openser depends on: ii adduser 3.102Add and remove users and groups ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries openser recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#424984: openser: Insert Route HF (from Path) messes up if UTF-8 chars around
Hi Julien Thanks for your quick answer. Can you do another test with a From header that contains 2 multibyte characters ? I suspect something is counting characters and not bytes, in which case with 2 multibyte characters in the header you should be getting the Route header inserted before the \r. I've just made such a test. Result: Not matter how many UTF-8 characters there are in the From HF, openser behaves the same way. Hope that helps. cheers, Bernie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#424984: openser: Insert Route HF (from Path) messes up if UTF-8 chars around
Hi Julien
I made some further testing. It looks like the reason for the strange
behavior is not the fact, that UTF-8 is around.
I figured out, that this behavior has a different cause.
I use a feature, that adds a name to a phone number, when the call is
coming from the PSTN and the phonenumber is known (saved in the db). For
this I put the following line into the config:
subst('/^(From:).*(sip:[EMAIL PROTECTED].*)$/\1 $avp(s:679) $avp(s:680)
\2/ig')
whereas avp(s:679) and avp(s:680) contain first- and lastname from the db.
While the above line is commented out, the insertion of the Route HF works
correctly. Otherwise it inserts the Route HF between CR and LF.
Thus, it seems that calling the subst() function before the (Path-info)
Route HF is inserted causes the problem.
cheers,
Bernie
On Fri, 18 May 2007, Julien BLACHE wrote:
tags 424984 - l10n
thanks
Bernie Hoeneisen [EMAIL PROTECTED] wrote:
Hi,
I am testing the Path HF usage. When the usage of Path causes a
insertion of a Route HF and the (original) SIP INVITE request contains UTF-8
characters, the Route HF gets inserted at the wrong place, e.g. between
the CR and LF (Hexadecimal 0D and 0A) at the end of the From HF:
INVITE sip:[EMAIL PROTECTED]:6051;line=nfy9nuy8 SIP/2.0
Record-Route: sip:127.0.0.1;r2=on;lr=on;ftag=as19d6b213
Record-Route: sip:130.89.10.194;r2=on;lr=on;ftag=as19d6b213
Remote-Party-ID: Bernie Höneisen sip:[EMAIL PROTECTED]
Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bK77a8.e46b2c74.1
Via: SIP/2.0/UDP 130.89.10.195:5060;branch=z9hG4bK53c948e4;rport=5060
From: Bernie Höneisen sip:[EMAIL
PROTECTED];tag=as19d6b213^MRoute:sip:130.89.10.194;lr;received=sip:97.56.98.20:3051
To: sip:[EMAIL PROTECTED]
Can you do another test with a From header that contains 2 multibyte
characters ?
I suspect something is counting characters and not bytes, in which
case with 2 multibyte characters in the header you should be getting
the Route header inserted before the \r.
JB.
--
Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED]
Public key available on http://www.jblache.org - KeyID: F5D6 5169
GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
Bug#379915: listadmin: Incorrectly flag some messages as spam with spamlevel 14
Hi Petter IMHO this is a bug in listadmin 2.30. I suspect this is due the the empty header field X-Spam-Level: in the examined mails. It looks like that due to this bug, the RegExp matches the next header field name (length 14): X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham instead of the content the current header field. Have you tried the lastest upstream version of listadmin? http://heim.ifi.uio.no/~kjetilho/hacks/ There have been some substantial changes in this particular part of listadmin, so it should be fixed upstream. Have fun! cheers, Bernie PS: Noel, maybe you could release the latest upstream version (listadmin-2.32) to unstable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308321: kphone does not use realm from 401 for authentication
Package: kphone Version: 1:4.1.0-2 Severity: normal Hi! I discovered the following behavior of kphone: When I start up kphone and kphone tries to register with a SIP Registrar, the SIP Registrar sends 401 Unauthorized Response with the header field: WWW-Authenticate: Digest realm=abc.ch, nonce=427f4ed676e719cad44d2a46de09894e77ca6c16 As a reaction to this, kphone asks for the password. So far just normal... But asking the passwort from the user in a question window, it displays Server xyz.abc.ch, which it takes from the local configuration for Default Outbound Proxy, instead of the WWW-Authenticate (realm) header field. When I provide the password for realm abc.ch, the authentcation fails. Kphone sends in the INVITE: Authorization: Digest username=test, realm=abc.ch, nonce=427f4ed676e719cad44d2a46de09894e77ca6c16, uri=sip:xyz.abc.ch, cnonce=abcdefghi, nc=0001, response=6471881d832fa1e92d9a905c0ffebd78, opaque=, algorithm=MD5 I guess it calculates the response with the wrong realm/Server value. Notes: - In the examples I have replaced the real values with abc.ch and xyz.abc.ch for privacy reasons. - Default Outbound Proxy: sip:xyz.abc.ch - SIP address: sip:[EMAIL PROTECTED] - Realm: abc.ch - authentication username: test - The IP address (DNS A record) of xyz.abc.ch points to the SIP Registrar - The IP address (DNS A record) of abc.ch is not pointing to the SIP Registrar - the SRV and NAPTR records for abc.ch are configured in that way, that SIP requests are sent to xyz.abc.chm if the SIP client queries the SRV records Issues: - Authentication doesn't work, if Default Outbound Proxy is not the same as the realm. - When asked for the password, the Server value is taken form the local Configuration Default Outbound Proxy instead of from the 401 message. - Also in the config file ~/.qt/kphonerc kphone saves the wrong value from the Default Outbound Proxy setting (to SipServer in Registration section): [Registration] AutoRegister=Yes Password=secret SipServer=xyz.abc.ch SipUri=Tester sip:[EMAIL PROTECTED] UserName=test qValue= cheers, Bernie -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.9-powerpc Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=de_CH (charmap=ISO-8859-1) Versions of packages kphone depends on: ii libc62.3.2.ds1-21GNU C Library: Shared libraries an ii libgcc1 1:3.4.3-12 GCC support library ii libice6 4.3.0.dfsg.1-12 Inter-Client Exchange library ii libpng12-0 1.2.8rel-1 PNG library - runtime ii libqt3c102-mt3:3.3.4-3 Qt GUI Library (Threaded runtime v ii libsm6 4.3.0.dfsg.1-12 X Window System Session Management ii libssl0.9.7 0.9.7e-3SSL shared libraries ii libstdc++5 1:3.3.5-12 The GNU Standard C++ Library v3 ii libx11-6 4.3.0.dfsg.1-12 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-12 X Window System miscellaneous exte ii libxt6 4.3.0.dfsg.1-12 X Toolkit Intrinsics ii xlibs4.3.0.dfsg.1-12 X Keyboard Extension (XKB) configu -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
