blog do deadcow

Bom hoje eu estava navegando pelo google, e encontrei essa tool, do Jon Oberheide que verificava em tempo real de modo passivo se um dns estaria ou não vulneravel a nova falha de DNS Cache Poison que o Dan Kaminsky descobriu,até ai tudo bem. se não fosse uma das dependecias da tool, o pypcap, do dugsong, mesmo autor do dsniff, que eh uma extensão da libpcap para o python, depois de ter instalado com o comando "yaourt -S pypcap" direto, sem editar o PKBUILD no Arch, rodei o arquivo e sempre me retornava isso:

[deadcow@mosdef ~]$ ./pdpt.py 
Traceback (most recent call last):
  File "./pdpt.py", line 86, in 
    DNSMonitor().main()
  File "./pdpt.py", line 39, in main
    pc = pcap.pcap(self.opts.device)
  File "pcap.pyx", line 171, in pcap.pcap.__init__
TypeError: exceptions must be strings, classes, or instances, not type
[deadcow@mosdef ~]$

bom, perguntei o google sobre o erro e ele nao me respondia nada, aliás até respondia sobre um problema de compatibilidade com o Pyrex e o Python 2.6, mas eu não tinha a noção nem do que o pyrex fazia, a versão do  meu python é 2.6 mas sequer o pyrex eu tinha instalado, enfim passei com os olhos fechados sobre os endereços, baixei outra tool que também utilizava o pypcap pra ter certeza que o problema era no mesmo no pypcap, e sim, era.

Resolvi então compilar na unha o pypcap, derepente podia ter algum erro no código ou coisa do tipo que eu mesmo pudesse concertar, qual não é minha surpresa quando resolvo dar um head no pcap.c ?:

[deadcow@mosdef pypcap-1.1]$ head -n1 pcap.c 
/* Generated by Pyrex 0.9.3 on Sun Oct 16 19:38:39 2005 */
[deadcow@mosdef pypcap-1.1]$ 

poisé é, pra isso que o Pyrex servia, só pra esclarecimento a descrição do Pyrex:

Pyrex lets you write code that mixes Python and C data types any way you want, and compiles it into a C extension for Python.

Resolvi então ler aqueles endereços que eu passei desapercebido no google, e lá explicava que o pyrex tinha passado por uma mudança na versão 0.9.6 para acomodar o uso do novo estilo de classes do python 2.5, e recomendava a instalação da ultima versão do Pyrex.

Como eu toda vez que utilizava o pypcap recebia um erro praticamente idêntico ao problema no site, resolvi então instalar o Pyrex na minha maquina e tentar gerar um novo pcap.c para o pacote do pypcap:

[deadcow@mosdef pypcap-1.1]$ su -
Password: 
[root@mosdef ~]# pacman -Ss pyrex
extra/pyrex 0.9.8.4-1
    Language for writing Python extension modules
[root@mosdef ~]# pacman -S pyrex
resolving dependencies...
looking for inter-conflicts...

Targets: pyrex-0.9.8.4-1  

Total Download Size:    0.00 MB
Total Installed Size:   1.25 MB

Proceed with installation? [Y/n] y
checking package integrity...
(1/1) checking for file conflicts                   [#####################] 100%
(1/1) upgrading pyrex                               [#####################] 100%
[root@mosdef ~]# exit
[deadcow@mosdef pypcap-1.1]$ pyrexc pcap.pyx
[deadcow@mosdef pypcap-1.1]$ head -n1 pcap.c 
/* Generated by Pyrex 0.9.8.4 on Wed Jul 30 15:51:07 2008 */
[deadcow@mosdef pypcap-1.1]$ python setup.py config;su -c 'python setup.py install'
...
[root@mosdef deadcow]# python pdpt.py -i eth0
listening on eth0: udp and dst port 53 

Bingo!, o problema realmente era esse, mas isso podia ficar mais simples se você usa arch:

[deadcow@mosdef ~]$ yaourt -S pypcap

==> Downloading pypcap PKGBUILD from AUR...


Comment by: tom5760 on 20070207 [18:54:30]
A simplified object-oriented Python extension module for libpcap.

Comment by: tom5760 on 20070213 [16:17:10]
Added license.

Comment by: rabyte on 20070705 [19:57:41]
Please add the LICENSE file to the source array.

Comment by: tom5760 on 20070728 [16:03:36]
I never use this anymore, sorry. Someone else can have it if they actually use it.

Comment by: warl0ck on 20080227 [19:16:38]
Take ownership from Tom, fix the license.

      First Submitted: Wed, 07 Feb 2007 18:54:30 +0000
      Last Updated: Wed, 27 Feb 2008 19:17:54 +0000
pypcap 1.1-3 (Unsupported): Python extension module for libpcap.

==> pypcap dependencies:
 - python (already installed)
 - libpcap (already installed)
==>  Edit the PKGBUILD (recommended) ? [Y/n] ("A" to abort)
==>   ----------------------------------------------
==>y
Please add $EDITOR to your environment variables
for example:
==> Edit PKGBUILD with: (replace gvim with your favorite editor)

==> Edit ./PKGBUILD with: vi

É aqui o pulo do gato voce vai alterar, isto tendo o Pyrex na ultima versão instalado na maquina, a flag build() do PKGBUILD de:

build() {
  cd $startdir/src/$pkgname-$pkgver
  python setup.py config
  python setup.py build
  python setup.py install --root=$startdir/pkg
  mkdir -p $startdir/pkg/usr/share/licenses/$pkgname/
  cp $startdir/src/$pkgname-$pkgver/LICENSE $startdir/pkg/usr/share/licenses/$pkgname/
} 

para:

build() {
  cd $startdir/src/$pkgname-$pkgver
  pyrexc pcap.pyx 
  python setup.py config
  python setup.py build
  python setup.py install --root=$startdir/pkg
  mkdir -p $startdir/pkg/usr/share/licenses/$pkgname/
  cp $startdir/src/$pkgname-$pkgver/LICENSE $startdir/pkg/usr/share/licenses/$pkgname/
} 

E o resto, todos nós Archeiros conhecemos. Eu realmente não considero um erro do mantenedor do pacote, já que o responsável de manter o código 'up do date' é o programador e não o cara que criou o pacote, mas é uma dica simples que não deixa você com horas de dor de cabeça, abraços.