Over time it is hopped that VanLUG members will contribute to this section of the site in order to build an area that can be useful to other members and to the wider community.
If you have just squashed a nasty bug, learnt a new trick, or jumped over a technical hurdle please consider adding to the site. Everyone who has created an account on the web site can add content.
ISPs and related issues are a popular topic on the VanLUG mailing list. This section of the web site is a great please to put information related to local (Vancouver and the surrounding area) ISPs.
I'm writing this up mainly because it took a long time for me to figure out what the problem was and phoning the good folks at Shaw technical support yielded no assistance.
The Summary
Having problems sending email to Shaw or other ISPs? In addition to black lists and the like, check your reverse DNS it may be too "generic".
The Problem
Mail sent from my mail server to Shaw's (ie anyone@shaw.ca) would sit in my outgoing queue for a long time, some times over 24 hours. 95% of the time it would eventually be delivered, however 5% of the time it would bounce after sitting in my outgoing queue for too long.
The error message being reported by the Shaw mail server was "550 Too many invalid recipients". This would happen even if there was only a single recipient and the address was known to be good. Clearly the description was not accurate.
Some Background
I host my own email on a postfix server I run at home. I pay for a static IP address and the IP is not listed in any blacklists.
Several months ago I switched ISPs and at about the same time I noticed that email to @shaw.ca addresses would sit in my outbound queue for a long time before being delivered. Calls to both my ISP and Shaw proved less than useful. Having been a Shaw customer at one point, and having used their email servers, I put this down to being a mail server issue at their end.
Yesterday I sent an email to someone via Craigslist and the message bounced. Unlike Shaw's error message the message from Craigslist described the problem and pointed to http://www.craigslist.org/about/help/generic_DNS which defines "Generic DNS as":
A hostname that contains:
The Sollution
The reverse DNS entry for my IP address managed to trigger two of the "generic DNS" issues, it included both my IP and "dsl".
I phoned my ISP and asked to have the IP reverse to the hostname of my mail server. Once the DNS had updated the problem was solved.
This book was created as a place to put information related to virtualisation.
The g729 codec requires a $10USD license for use with Asterisk (available from Digium). This license is tied to the MAC addresses of the network devices in the machine. Under Xen, unless it is told otherwise, a new MAC address is generated for each virtual interface (vif) each time the domU is restarted. With this is mind it is very important to configure a static MAC address(es) for your asterisk domU when using the g729 license.
In your domUs .cfg file you can pass the mac address like so:
#
# Networking
#
vif = [ 'mac=00:16:3e:45:f8:71,ip=192.168.2.15' ]
This will ensure that the same MAC address is used each time and your license will continue to work through domU restarts.
I've finally sorted out Asterisk in a Xen domU with ztdummy and figured I should share.
ztdummy is required as a timing source for MeetMe (conference calls) and is also involved in moh (music on hold) and a few other things.
The problem with ztdummy under Xen is that it expects to have access to the rtc (real time clock) on x86/x86_64 systems, but that is not the case in a Xen domU. The fix is to comment out the #define USE_RTC statements in ztdummy.c so that ztdummy uses the kernel timer.
While googling I saw references to checking the HZ setting in the kernel (mine claims 250HZ in the kernel .config) and adjusting the #define ZAPTEL_RATE 1000 in ztdummy.c accordingly, however when I changed it to 250 asterisk's menu audio played back four times too quickly. Switching ZAPTEL_RATE back to 1000 solved this problem and the interactive voice menus played at the correct speed.
I wasn't quite finished. With ztdummy loaded my moh became very garbled whereas before it had played properly. Switching asterisk moh from mpg123 to files (in /etc/asterisk/musiconhold.conf) and my mp3s to 8kHz 8bit mono wav files fixed moh.
I now have Asterisk with MeetMe and moh working properly in my Xen domU.