"fatal error" avec dig/host/nslookup

In article <439eb7bf$0$15742$636a15ce@news.free.fr>,
Stephane Madrau <stephane@madrau.com> wrote:

Le plus intéressant est qu'il ne le fait qu'avec mon compte. Si je me
logge avec n'importe quel autre utilisateur de la même machine, admin ou
non, ça passe sans erreur.

- donne exactement les commandes que tu tapes et qui cause une erreur
- essaye les mêmes commandes en indiquant le chemin complet de
l'exécutable (obtenu avec which)

éventuellement tu peux faire un ktrace :

ktrace ta_commande tes_arguments
ktrace -C

pour lire le résultat :

kdump -f ktrace.out

puis finalement :

rm ktrace.out

pour pas encombrer ton disque

patpro

patpro ~ Patrick Proniewski wrote:

- donne exactement les commandes que tu tapes et qui cause une erreur

dig

si, si, rien d'autre. Juste ça, sans argument, et ça plante.

alors que

sudo dig

là ça marche

Remarque, si je n'étais pas clair: c'est une erreur du programme, pas
une erreur kernel ou autre. C'est un cas prévu, ça correspond à un type
d'adresse IP inconnu (il ne la reconnait pas ni comme une IPv4 ni comme
une IPv6, donc il s'arrête).
L'erreur doit venir du parsing de l'IP, mais comment trouver qui fait
ça, et pourquoi il plante, je n'en sais rien.

- essaye les mêmes commandes en indiquant le chemin complet de
l'exécutable (obtenu avec which)

idem
j'ai poussé le vice à 1) copier l'executable d'une machine sur l'autre:
pareil; 2) à recompiler un dig depuis les sources de bind => pareil.

éventuellement tu peux faire un ktrace :
ktrace ta_commande tes_arguments
ktrace -C
pour lire le résultat :
kdump -f ktrace.out

Je ne connaissais pas ktrace. Lancé, ok, mais le résultat est un peu
gros pour être mis ici...
Je vais tacher de voir la différence (si elle est visible) en le lançant
sous les deux user et comparer les résultats.

--
Stephane

Stephane Madrau wrote:

Je vais tacher de voir la différence (si elle est visible) en le lançant
sous les deux user et comparer les résultats.

Voici la partie où il y a réellement une différence flagrante.
D'abord quand ça marche, ensuite quand ça plante.

La différence vient du contenu du message (avant dernière ligne de
chaque dump ci-dessous) qui est envoyé au socket. En gros, demande
erronée, retour erroné, d'où arrêt avec erreur, d'après ce que je comprends.

Ceci dit, ça ne m'explique pas pourquoi le contenu du buffer est
différent dans les deux cas.

----------------------- (marche)
........
16643 dig NAMI "/etc/resolv.conf"
16643 dig RET open 3
16643 dig CALL fstat(0x3,0xbffff798)
16643 dig RET fstat 0
16643 dig CALL read(0x3,0x1807200,0x1000)
16643 dig GIO fd 3 read 89 bytes
"search wanadoo.fr
nameserver 80.10.246.2
nameserver 80.10.246.129
nameserver 192.168.0.1
"
16643 dig RET read 89/0x59
16643 dig CALL read(0x3,0x1807200,0x1000)
16643 dig GIO fd 3 read 0 bytes
""
16643 dig RET read 0
16643 dig CALL close(0x3)
16643 dig RET close 0
16643 dig CALL sigaction(0x1,0xbffffbd8,0)
16643 dig RET sigaction 0
16643 dig CALL ppc_gettimeofday(0xbffff9f0,0)
16643 dig RET ppc_gettimeofday 1134479860/0x439ec9f4
16643 dig CALL socket(0x2,0x2,0x11)
16643 dig RET socket 3
16643 dig CALL fcntl(0x3,0x3,0)
16643 dig RET fcntl 2
16643 dig CALL fcntl(0x3,0x4,0x6)
16643 dig RET fcntl 0
16643 dig CALL setsockopt(0x3,0xffff,0x400,0xbffffb44,0x4)
16643 dig RET setsockopt 0
16643 dig CALL setsockopt(0x3,0xffff,0x4,0xbffffb50,0x4)
16643 dig RET setsockopt 0
16643 dig CALL bind(0x3,0xf8470,0x10)
16643 dig RET bind 0
16643 dig CALL recvmsg(0x3,0xbffff9e0,0)
16643 dig RET recvmsg -1 errno 35 Resource temporarily unavailable
16643 dig CALL sendmsg(0x3,0xbffff9a0,0)
16643 dig GIO fd 3 wrote 17 bytes
""M^?^A^A^B^A"
16643 dig RET sendmsg 17/0x11
........
----------------------- (plante)
........
16559 dig NAMI "/etc/resolv.conf"
16559 dig RET open 3
16559 dig CALL fstat(0x3,0xbffff598)
16559 dig RET fstat 0
16559 dig CALL read(0x3,0x1807200,0x1000)
16559 dig GIO fd 3 read 89 bytes
"search wanadoo.fr
nameserver 80.10.246.2
nameserver 80.10.246.129
nameserver 192.168.0.1
"
16559 dig RET read 89/0x59
16559 dig CALL read(0x3,0x1807200,0x1000)
16559 dig GIO fd 3 read 0 bytes
""
16559 dig RET read 0
16559 dig CALL close(0x3)
16559 dig RET close 0
16559 dig CALL sigaction(0x1,0xbffff9d8,0)
16559 dig RET sigaction 0
16559 dig CALL ppc_gettimeofday(0xbffff7f0,0)
16559 dig RET ppc_gettimeofday 1134477787/0x439ec1db
16559 dig CALL socket(0x2,0x2,0x11)
16559 dig RET socket 3
16559 dig CALL fcntl(0x3,0x3,0)
16559 dig RET fcntl 2
16559 dig CALL fcntl(0x3,0x4,0x6)
16559 dig RET fcntl 0
16559 dig CALL setsockopt(0x3,0xffff,0x400,0xbffff944,0x4)
16559 dig RET setsockopt 0
16559 dig CALL setsockopt(0x3,0xffff,0x4,0xbffff950,0x4)
16559 dig RET setsockopt 0
16559 dig CALL bind(0x3,0xf8470,0x10)
16559 dig RET bind 0
16559 dig CALL recvmsg(0x3,0xbffff7e0,0)
16559 dig RET recvmsg -1 errno 35 Resource temporarily unavailable
16559 dig CALL sendmsg(0x3,0xbffff7a0,0)
16559 dig GIO fd 3 wrote 17 bytes
"^F
^A^A^B^A"
16559 dig RET sendmsg 17/0x11
.........
-----------------------


--
Stephane

In article <439ecc5f$0$15706$636a15ce@news.free.fr>,
Stephane Madrau <stephane@madrau.com> wrote:

Stephane Madrau wrote:

Je vais tacher de voir la différence (si elle est visible) en le lançant
sous les deux user et comparer les résultats.

Voici la partie où il y a réellement une différence flagrante.
D'abord quand ça marche, ensuite quand ça plante.

La différence vient du contenu du message (avant dernière ligne de
chaque dump ci-dessous) qui est envoyé au socket. En gros, demande
erronée, retour erroné, d'où arrêt avec erreur, d'après ce que je comprends.

Ceci dit, ça ne m'explique pas pourquoi le contenu du buffer est
différent dans les deux cas.

ça marche et ça plante pour les mêmes domaines ? ou est ce qu'il y a des
domaines qui "plantent" et d'autres qui "marchent" ?

Peut tu essayer de faire la même chose en coupant ton DNS local ?
(192.168.0.1)

Peux tu refaire la manip avec un tcpdump pour capturer les paquets,
histoire de voir un peut plus clairement ce qui se dit entre le client
et le serveur de noms ?


patpro

patpro ~ Patrick Proniewski wrote:

ça marche et ça plante pour les mêmes domaines ? ou est ce qu'il y a des
domaines qui "plantent" et d'autres qui "marchent" ?

sans aucun argument, donc sur les domaines par défaut à chaque fois !

pour l'utilisateur "stephane", ça plante quel que soit le domaine
choisi, y compris sans argument
pour tous les autres utilisateurs, ça marche quel que soit le domaine
choisi, y compris sans argument

Peut tu essayer de faire la même chose en coupant ton DNS local ?
(192.168.0.1)

Alors là. 192.168.0.1 c'est mon modem routeur.
Qu'il apparaisse dans /etc/resolv.conf, je ne vois pas comment.
Il n'est pas explicitement défini comme DNS dans les "Preferences" Réseau.

Je peux couper la fonction DNS sur le routeur si il y en a une, mais
j'imagine mal comment cela aura une quelconque influence sur le contenu
de /etc/resolv.conf
...
Non, en fait je ne sais même pas si on peut couper cela (c'est un DG834G).

(ceci dit: l'iBook utilise le même routeur, et ça marche pour tous les
users de l'iBook - je ne peux pas par contre donner le contenu de
/etc/resolv.conf sur l'iBook, je n'y ai pas accès maintenant)

Peux tu refaire la manip avec un tcpdump pour capturer les paquets,
histoire de voir un peut plus clairement ce qui se dit entre le client
et le serveur de noms ?

euh, je vais essayer de voir comment tcpdump fonctionne.

...
bon, après avoir purgé ce qui ne concerne pas le problème (je fais ça
par ssh sur la machine) voici le contenu des paquets


Ceux qui plantent:
15:05:42.508923 IP 192.168.0.2.62069 >
dns-abo-static-a.wanadoo.fr.domain: 62821+ NS? . (17)
15:05:42.538927 IP dns-abo-static-a.wanadoo.fr.domain >
192.168.0.2.62069: 62821 13/0/0 NS B.ROOT-SERVERS.NET.,[|domain]

Ceux qui marchent:

15:06:43.384726 IP 192.168.0.2.62106 >
dns-abo-static-a.wanadoo.fr.domain: 36431+ NS? . (17)
15:06:43.413404 IP dns-abo-static-a.wanadoo.fr.domain >
192.168.0.2.62106: 36431 13/0/0 NS K.ROOT-SERVERS.NET.,[|domain]


Il n'y a aucune différence (hors le numéro) ! Donc ce n'est pas à ce
niveau... Les paquets partent bien, le retour fonctionne bien. C'est
donc que mon souci se situe dans la manière de "décortiquer" le résultat...

Merci de ta patience

--
Stephane

Stephane Madrau wrote:

Il n'y a aucune différence (hors le numéro) ! Donc ce n'est pas à ce
niveau... Les paquets partent bien, le retour fonctionne bien. C'est
donc que mon souci se situe dans la manière de "décortiquer" le résultat...

Je redonne alors les différences du ktrace après la réception du paquet
en retour:

Dans un cas au retour il a probablement une valeur d'erreur ce qui le
conduit à afficher directement le message "fatal error", dans l'autre
cas il parse correctement le paquet et affiche son contenu.

Je n'ai toujours pas plus d'idée quant au pourquoi.


--------------- (sans erreur)
16643 dig GIO fd 3 wrote 17 bytes
""M^?^A^A^B^A"
16643 dig RET sendmsg 17/0x11
16643 dig CALL select(0x4,0xbffffbb0,0xbffffc30,0,0xbffffba0)
16643 dig RET select 0
16643 dig CALL select(0x4,0xbffffbb0,0xbffffc30,0,0xbffffba0)
16643 dig RET select 1
16643 dig CALL recvmsg(0x3,0xbffff8f0,0)
16643 dig GIO fd 3 wrote 228 bytes
(contenu du paquet snippé)
16643 dig RET recvmsg 228/0xe4
16643 dig CALL fstat(0x1,0xbffff6f8)
16643 dig RET fstat 0
16643 dig CALL ioctl(0x1,0x4004667a ,0xbffff678)
16643 dig RET ioctl 0
16643 dig CALL write(0x1,0x245000,0x1)
16643 dig GIO fd 1 wrote 1 byte
"
"
16643 dig RET write 1
16643 dig CALL write(0x1,0x245000,0x16)
16643 dig GIO fd 1 wrote 22 bytes
"; <<>> DiG 9.2.2 <<>>
"
...............
--------------- (avec erreur)
16559 dig GIO fd 3 wrote 17 bytes
"^F
^A^A^B^A"
16559 dig RET sendmsg 17/0x11
16559 dig CALL select(0x4,0xbffff9b0,0xbffffa30,0,0xbffff9a0)
16559 dig RET select 0
16559 dig CALL select(0x4,0xbffff9b0,0xbffffa30,0,0xbffff9a0)
16559 dig RET select 1
16559 dig CALL recvmsg(0x3,0xbffff6f0,0)
16559 dig GIO fd 3 wrote 228 bytes
(contenu du paquet snippé)
16559 dig RET recvmsg 228/0xe4
16559 dig CALL write(0x2,0xbfffefe0,0x47)
16559 dig GIO fd 2 wrote 71 bytes
"/SourceCache/bind9/bind9-11/bind9/lib/isc/sockaddr.c:398: fatal
error: "
...............


--
Stephane

patpro ~ Patrick Proniewski wrote:

ça marche et ça plante pour les mêmes domaines ? ou est ce qu'il y a des
domaines qui "plantent" et d'autres qui "marchent" ?

Tiens, une découverte: si je ferme ma session "graphique", et que je
lance "dig" par ssh depuis une autre station, là du coup ça fonctionne.

En fait, j'avais un ssh d'ouvert où "dig" plantait, et j'y ai killé
"loginwindow" tout bêtement, et là depuis la même session ssh "dig"
fonctionne.

ça devient de plus en plus étrange.

--
Stephane

In article <439ed85b$0$15711$636a15ce@news.free.fr>,
Stephane Madrau <stephane@madrau.com> wrote:

ça marche et ça plante pour les mêmes domaines ? ou est ce qu'il y a des
domaines qui "plantent" et d'autres qui "marchent" ?

sans aucun argument, donc sur les domaines par défaut à chaque fois !

que ce soit bien clair, il n'y a pas de domaine par défaut... host, dig
et compagnie font des requêtes DNS, pour résoudre un nom ou une IP en IP
ou en nom :

$ host www.truc.com
www.truc.com has address 206.207.85.33

Peut tu essayer de faire la même chose en coupant ton DNS local ?
(192.168.0.1)

Alors là. 192.168.0.1 c'est mon modem routeur.
Qu'il apparaisse dans /etc/resolv.conf, je ne vois pas comment.
Il n'est pas explicitement défini comme DNS dans les "Preferences" Réseau.

tu es en DHCP surement, c'est pour ça qu'il se retrouve en DNS.

Non, en fait je ne sais même pas si on peut couper cela (c'est un DG834G).

sudo -s
ipfw add 2 deny ip from any to 192.168.0.1 dst-port 53

par exemple ;) (ipfw delete 2 pour la virer ensuite)
Mais bon, comme c'est pas ton DNS local (celui qui pourrait tourner sur
le Mac), ça ne sert pas a grand chose de tester ça.

(ceci dit: l'iBook utilise le même routeur, et ça marche pour tous les
users de l'iBook - je ne peux pas par contre donner le contenu de
/etc/resolv.conf sur l'iBook, je n'y ai pas accès maintenant)

ok.

euh, je vais essayer de voir comment tcpdump fonctionne.

...
bon, après avoir purgé ce qui ne concerne pas le problème (je fais ça
par ssh sur la machine) voici le contenu des paquets

non, là il y'a pas le contenu ;)
essaye un truc comme ca plutot :

tcpdump -s 250 -Xvvi en0 src or dst port 53

en remplaçant en0 par en1 si tu es en Airport plutot qu'en ethernet.

patpro

In article <439ee307$0$15733$636a15ce@news.free.fr>,
Stephane Madrau <stephane@madrau.com> wrote:

patpro ~ Patrick Proniewski wrote:

ça marche et ça plante pour les mêmes domaines ? ou est ce qu'il y a des
domaines qui "plantent" et d'autres qui "marchent" ?

Tiens, une découverte: si je ferme ma session "graphique", et que je
lance "dig" par ssh depuis une autre station, là du coup ça fonctionne.

En fait, j'avais un ssh d'ouvert où "dig" plantait, et j'y ai killé
"loginwindow" tout bêtement, et là depuis la même session ssh "dig"
fonctionne.

ça devient de plus en plus étrange.

non, car si ça marche avec les autres utilisateurs, c'est lié à ta
session.
Tu pourrais commencer à regarder tes variables d'environnement, ou les
gadgets que tu as installé, mais bon, c'est pas toujours facile.

patpro

patpro ~ Patrick Proniewski wrote:

que ce soit bien clair, il n'y a pas de domaine par défaut...

ok, abus de langage.
"Comportement de dig en l'absence d'argument" j'aurai du dire, tu as raison.

Il n'est pas explicitement défini comme DNS dans les "Preferences" Réseau.
tu es en DHCP surement, c'est pour ça qu'il se retrouve en DNS.

certes

non, là il y'a pas le contenu ;)
essaye un truc comme ca plutot :
tcpdump -s 250 -Xvvi en0 src or dst port 53

Effectivement, il n'y avait que le header. Mais le résultat est
identique ci-desous

Résultat:

--------------- (marche)

16:25:25.338612 IP (tos 0x0, ttl 64, id 32217, offset 0, flags [none],
length: 45) 192.168.0.2.63209 > dns-abo-static-a.wanadoo.fr.domain: [udp
sum ok] 39983+ NS? . (17)
0x0000: 4500 002d 7dd9 0000 4011 f62f c0a8 0002 E..-}...@../....
0x0010: 500a f602 f6e9 0035 0019 61b5 9c2f 0100 P......5..a../..
0x0020: 0001 0000 0000 0000 0000 0200 01 .............
16:25:25.366385 IP (tos 0x0, ttl 55, id 0, offset 0, flags [DF],
length: 256) dns-abo-static-a.wanadoo.fr.domain > 192.168.0.2.63209:
39983 q: NS? . 13/0/0 . NS M.ROOT-SERVERS.NET., . NS
A.ROOT-SERVERS.NET., . NS B.ROOT-SERVERS.NET., . NS C.ROOT-SERVERS.NET.,
. NS D.ROOT-SERVERS.NET., . NS E.ROOT-SERVERS.NET., . NS
F.ROOT-SERVERS.NET., . NS G.ROOT-SERVERS.NET., . NS H.ROOT-SERVERS.NET.,
. NS I.ROOT-SERVERS.NET., . NS J.ROOT-SERVERS.NET., .[|domain]
0x0000: 4500 0100 0000 4000 3711 3c36 500a f602 E.....@.7.<6P...
0x0010: c0a8 0002 0035 f6e9 00ec 9da8 9c2f 8180 .....5......./..
0x0020: 0001 000d 0000 0000 0000 0200 0100 0002 ................
0x0030: 0001 0002 681f 0014 014d 0c52 4f4f 542d ....h....M.ROOT-
0x0040: 5345 5256 4552 5303 4e45 5400 0000 0200 SERVERS.NET.....
0x0050: 0100 0268 1f00 0401 41c0 1e00 0002 0001 ...h....A.......
0x0060: 0002 681f 0004 0142 c01e 0000 0200 0100 ..h....B........
0x0070: 0268 1f00 0401 43c0 1e00 0002 0001 0002 .h....C.........
0x0080: 681f 0004 0144 c01e 0000 0200 0100 0268 h....D.........h
0x0090: 1f00 0401 45c0 1e00 0002 0001 0002 681f ....E.........h.
0x00a0: 0004 0146 c01e 0000 0200 0100 0268 1f00 ...F.........h..
0x00b0: 0401 47c0 1e00 0002 0001 0002 681f 0004 ..G.........h...
0x00c0: 0148 c01e 0000 0200 0100 0268 1f00 0401 .H.........h....
0x00d0: 49c0 1e00 0002 0001 0002 681f 0004 014a I.........h....J
0x00e0: c01e 0000 0200 0100 0268 1f00 .........h..


--------------- (plante)
16:25:27.372374 IP (tos 0x0, ttl 64, id 32227, offset 0, flags [none],
length: 45) 192.168.0.2.63210 > dns-abo-static-a.wanadoo.fr.domain: [udp
sum ok] 12513+ NS? . (17)
0x0000: 4500 002d 7de3 0000 4011 f625 c0a8 0002 E..-}...@..%....
0x0010: 500a f602 f6ea 0035 0019 cd02 30e1 0100 P......5....0...
0x0020: 0001 0000 0000 0000 0000 0200 01 .............
16:25:27.401633 IP (tos 0x0, ttl 55, id 0, offset 0, flags [DF],
length: 256) dns-abo-static-a.wanadoo.fr.domain > 192.168.0.2.63210:
12513 q: NS? . 13/0/0 . NS D.ROOT-SERVERS.NET., . NS
E.ROOT-SERVERS.NET., . NS F.ROOT-SERVERS.NET., . NS G.ROOT-SERVERS.NET.,
. NS H.ROOT-SERVERS.NET., . NS I.ROOT-SERVERS.NET., . NS
J.ROOT-SERVERS.NET., . NS K.ROOT-SERVERS.NET., . NS L.ROOT-SERVERS.NET.,
. NS M.ROOT-SERVERS.NET., . NS A.ROOT-SERVERS.NET., .[|domain]
0x0000: 4500 0100 0000 4000 3711 3c36 500a f602 E.....@.7.<6P...
0x0010: c0a8 0002 0035 f6ea 00ec 0a0f 30e1 8180 .....5......0...
0x0020: 0001 000d 0000 0000 0000 0200 0100 0002 ................
0x0030: 0001 0002 681d 0014 0144 0c52 4f4f 542d ....h....D.ROOT-
0x0040: 5345 5256 4552 5303 4e45 5400 0000 0200 SERVERS.NET.....
0x0050: 0100 0268 1d00 0401 45c0 1e00 0002 0001 ...h....E.......
0x0060: 0002 681d 0004 0146 c01e 0000 0200 0100 ..h....F........
0x0070: 0268 1d00 0401 47c0 1e00 0002 0001 0002 .h....G.........
0x0080: 681d 0004 0148 c01e 0000 0200 0100 0268 h....H.........h
0x0090: 1d00 0401 49c0 1e00 0002 0001 0002 681d ....I.........h.
0x00a0: 0004 014a c01e 0000 0200 0100 0268 1d00 ...J.........h..
0x00b0: 0401 4bc0 1e00 0002 0001 0002 681d 0004 ..K.........h...
0x00c0: 014c c01e 0000 0200 0100 0268 1d00 0401 .L.........h....
0x00d0: 4dc0 1e00 0002 0001 0002 681d 0004 0141 M.........h....A
0x00e0: c01e 0000 0200 0100 0268 1d00 .........h..





(voir l'autre branche du fil, aussi:

je n'arrive à reproduire ce comportement que si je fais ça avec
l'utilisateur qui a une session graphique ouverte au même moment. Testé
avec plusieurs utilisateurs, en changeant de session graphique par
permutation des utilisateurs, celui qui plantait marche, et vice-versa)

Donc les trois tools sont perturbés par la présence de loginwindow ...

--
Stephane