Friday, October 29, 2010

Android VPN - Want to kill self

After days of trying to setup openswan and make it work via IPSec/L2TP with roadwarriors and ultimately make it work with my Nexus One, I now want to kill myself. Setting up openswan is no easy task and requires reading from various sources and skim through outdated posts.

However I did get it to work as expected with Windows road warriors.

It appears that racoon (the IKE daemon on Nexus) dies soon after the tunnel is established:


I think that's why you get all that l2tp traffic on the loose where it isn't supposed to be. I abandon all hope it maybe an openswan | NETKEY issue on CENTOS 5.2.

I will instead go for the OpenVpn solution which I am already using for my net.

Sunday, October 17, 2010

Prepare HylaFax for email to fax gateway with qmail

So this took me some time (mainly because I forgot all about qmail configuration), hence I thought to make a note.

We will use virtual domains in qmail to send faxes with Hylafax.

The default in the hylafax supplied script is to use a 'fax' top level name and send emails of the form user@number.fax. I prefer to use fax.mydomain.com instead. To accomplish this:

1)Add to (or create) /var/qmail/control/virtualdomains the line:
.fax.mydomain.com:fax

Be careful to include the dot in front of the domain. It simply means that we're catching anything below it.

2)Add to /var/qmail/control/rcpthosts:
.fax.mydomain.com

Which means that anything below the domain will be served locally.

3)Create /var/qmail/alias/.qmail-fax-default and add:
| /usr/local/bin/mailfax

4)Copy from hylafax-source-dir/faxmail/mailfax.sh-qmail to /usr/local/bin/mailfax
If you cannot find it, create it empty and read on.

5) Edit /usr/local/bin/mailfax as:


My edits are simply fixing location errors for redhat flavors and add support for emails in the form recipientuser@faxnumber.fax.mydomain.com

6) Do not forget to send a HUP to qmain-send.

Converting text files to fax fails - Hylafax, Ghostscript, FC10

I have been trying to solve the infamous error:

/usr/sbin/textfmt: No font metric information found for "Courier-Bold"

when running sendfax to test asterisk + hylafax.

This is a bug in ghostscript-8.70-1 & fonts for Fedora Core 10. So if you are not using FC10 this may not be the answer you 're looking for.

To fix the error:

1) Download & extract latest ghostscript-fonts http://sourceforge.net/projects/gs-fonts/
2) View the fonts.dir file and locate the file name of the font you wish to use for Courier-Bold, I chose n022004l.pfb
3) Copy n022004l.* (2 files) to /usr/share/fonts/default/ghostscript/
4) Edit /usr/share/ghostscript/8.70/Resource/Init/Fontmap.GS and change:

/Courier-Bold /NimbusMonL-Bold ;

to:

/Courier-Bold (n022004l.pfa) ;

Try it now and it should work.

Of course this is just one of many solutions, the main point being that NimbusMonL-Bold cannot be found and causing the issue.

Tuesday, March 2, 2010

Getting AOC-E to work in Asterisk 1.6

This is my approach to get AOC-E to work under asterisk.

The problem is when then non AOC receiving channel hangs up first. The call is destroyed, thus when AOC-E is received it cannot be saved.

A fast solution is to use the manager API and generate events for these situations.

This is the diff for chan dahdi



Make sure you save the AOC in your cdr in the cases that is retrieved when call is still there, in your outgoing context you should have something like:
Set(CDR(units)=${AOCE_UNITS});

Now for the other scenario you should have a manager listening to CDR AOC events (user events really). Using the span/logical/offset you can associate the AOC info to a call on your CDR. I am doing this manually having associations in the database like channel DAHDI/100 is at 5/0/1. Then simply finding the last outgoing call which involved that channel and updating the AOC does the trick.

Lastly note that this can be as precise as it looks. When matching the AOC information to a call's cdr outside asterisk there is always a chance of failing to find the correct one. In my manager app I am taking extra steps to avoid miss-associations using a rate estimator and the disposition of the call. Although it is working perfectly until now, I will need to work a bit more on it before releasing it..

Finally... If you are using B410P make absolutely sure you apply this patch otherwise you will loose calls and the changes will not have any effect under certain circumstances.