Change in syntax and functionnality in Asterisk AstDB functions

Since Asterisk 1.2+, the methods to access the AstDB database (a berkeley local database) were changed from DBGet,DBPut,DBDel to the merged "simpler" one named Set (except for DbDel which seems to still exist). There was a functionnality that when a key was not found in AstDB, a jump would be done to n+101. So the following would be OK:

exten = s,1,Set(forward_number=${DB(FORWARD/1234)})
exten = s,2,Background(one_local/forward/forward_number_is)
exten = s,3,sayalpha(${forward_number})
exten = s,4,Goto(s-report_mode,1)
exten = s,102,NoOp(Pas de valeur ce qui est normal)
exten = s,103,Goto(s-not_set,1)

But with my newly installed Asterisk 1.4.4, it doesn't jump anymore. It continues to s,2 :-(.
So I guess I need to add a supplementary line to explicitely test the presence of the key:

exten = s,1,GotoIf(${DB_EXISTS(FORWARD/${F_EXT})}?:102)
exten = s,2,Set(forward_number=${DB_RESULT})
exten = s,3,Background(one_local/forward/forward_number_is)
exten = s,4,sayalpha(${forward_number})
...
exten = s,102,NoOp(Pas de valeur ce qui est normal)

Nice introduction article on Pylons

Pylons is a cool web framework (one more, besides TurboGears, Django, Zope, etc.). Someone posted on the mailing list a reference to a nice introduction.

Troll of the day: Why Ruby sucks and why Python rocks!

I found a nicely written article about the problems with Ruby, written by a Ruby user, and why he found Python to be really good. There's even a quote about Twisted!

And, there are a bunch of things available to a Python guy that Ruby just can’t compete with that are of particular interest to me. Two that come to mind immediately are Twisted and Stackless Python. The former was used by others at TurnTide for creating a really powerful SMTP testing tool and the latter was used by TurnTide’s competitor IronPort to build one of the industry’s best MTAs.

I didn't knew that IronPort was done in Python, even in Stackless Python!

New Apache module for integrating WSGI apps

Finally, after such painful setups, I really never could find a really suitable configuration that could satisfy me. Here are the different methods I tried to implement TurboGears/Pylons or similar WSGI/Python projects (MoinMoin for example):

• FastCGI: So complex to setup, crashes on its own so often, and leaves running processes in memory so have to kill them each time manually to start again with a clean environment. I have to admit it is easier to configure on Lighttpd.
  
• SCGI: As complex as FastCGI and not so used in the world, but not bad. Too few options.
• Proxy: Redirecting on a local different port gives nore work, and as soon as you have several other virtual hosts, you'll have to keep a registry of all your allocated ports. Painful, but easy to setup. Maybe be hard to configure if you're using Zope, and if you need some remote information (ip address of the user for example), you're dead!
• Direct Access: Configuring you app to run on a local ip alias on your machine and eventually configure your firewall to DNAT on it. Not that complex to setup, but requires access to you OS confiugration and many apps don't allow you to only listen on a specific interface (MoinMoin allows it, that's cool)
• mod_python: Loads Python into memory. Everybody shares the same namespace. Dangerous.
  

Now here's a new contender, mod_wsgi written by Graham Dumpleton. That's right, it will not work for every app. Zope, not being WSGI aware, is out of the way, except for Zope 3.x. But most of Python apps can be modded to be WSGI aware (MoinMoin is an example).

PyPy 1.0 has been announced!

PyPy version 1.0 is now available. That's really a great news, and a milestone for the Python community (and the rest of the programming world). It's not yet recommended to use it in production, but we're not that far from that.

Please read the announcement and go in the different links referenced there to learn more about PyPy and what it will change in your life.

Python is so cool.

How to understand the ARP queries and replies fields with pypcap

I had a hard time understanding the function of each field in an ARP packet. The problem is that the fields change of meaning, depending on the opcode field. The two useful ones are for ARP queries (what is the ethernet address of the ip address I'm giving now) and ARP replies (that ip address is located at this ethernet address).

So to fix this problem once for all, I decided to write a python script that shows the different field values when an ARP packet is captured.

There are several libraries available to the pythonista to manipulate network packets. The most known is certainly pylibpcap which is quite old now, and not really object oriented. It is more an adaptation one-to-one of the C libpcap library, which may be useful for some people.
Another library is pypcap, which is like pylibpcap, but much much more object oriented.
pypcap includes a huge quantity of protocols definitions, so it's really cool to use, especially because it also includes a network packet capture method. There is no included method to send packets, but there are examples of how to do this in the test files.
Another possibility is scapy, which is an extremely complete program (more a program than a library, even though you can use it as a module). The fact that it's not that easy to include scapy in my own program, even though there's now a howto. My program doesn't need all the bells and whistles given by scapy, so I settled on pypcap.

import dpkt, pcap
from socket import inet_ntoa

def ether_decode(p):
   return ':'.join(['%02x' % ord(x) for x in str(p)])

if __name__ == '__main__':
   iface_name = 'eth1'  # Here set your listening interface

   pc = pcap.pcap(iface_name)
   pc.setfilter('arp')

   for ts,pkt in pc:
       packet = dpkt.ethernet.Ethernet(pkt)

       print "ARP packet received:"
       print "op=%d" % packet.data.op
       print "src=%s" % ether_decode(packet.src)
       print "dst=%s" % ether_decode(packet.dst)
       print "spa=%s" % inet_ntoa(packet.data.spa)
       print "tpa=%s" % inet_ntoa(packet.data.tpa)
       print "tha=%s" % ether_decode(packet.data.tha)
       print "sha=%s" % ether_decode(packet.data.sha)
       print

That's it. Now, for example, 192.168.4.3 wants to get 192.168.4.254's ethernet address (192.168.4.254 has 00:90:4c:49:00:2a address and 192.168.4.3 has 00:50:70:b4:19:0c), here is the output:

ARP packet received:
op=1
src=00:50:70:b4:19:0c
dst=ff:ff:ff:ff:ff:ff
spa=192.168.4.3
tpa=192.168.4.254
tha=00:00:00:00:00:00
sha=00:50:70:b4:19:0c

ARP packet received:
op=2
src=00:90:4c:49:00:2a
dst=00:50:70:b4:19:0c
spa=192.168.4.254
tpa=192.168.4.3
tha=00:50:70:b4:19:0c
sha=00:90:4c:49:00:2a

Extension for Twisted AMP to support dictionaries and lists

Henrik Thostrup Jensen announced on the Twisted Users mailing list he made two extensions for the Twisted AMP protocol.

Currently there are two types: A dictionary and a list. The types of the element must be specified (key and value can be different in the dictionary), otherwise they are free form, i.e., the keys in the dictionary can have any name, and the list can be of any size. The types can be nested, e.g., you can create a list of list of strings. I use (or will) the latter to return a query result, for which I do not know the row size. This is currently impossible (AFAICT), in the otherwise excellent AMP protocol.

You can get them on http://www.cs.aau.dk/~htj/code/amptypes-0.1.tar.gz

For people that live under a rock, AMP is a new communication protocol for Twisted (added in Twisted 2.5) much lighter/simpler than PB. It is just a request/response protocol over a persistent connection.