30 replies to this topic

[max-sat]

Beste wensen voor het nieuwe jaar! :-)

Basis info:
box: Vu+ duo
image versie: OpenPLi-2.1-beta-vuduo-20111228_usb.zip 2011/12/28 02:28 - 36.33MB
kernel versie: 2.6.18
eth0 config: dhcp:yes
dyndns: niet geinstalleerd

dns-server: Win2k-sp4

Beschrijving:
Waar ik tegen aan loop is dat nslookup en ping niet goed om gaan met mijn forward-lookup zone gedefinieerd in Wintendo DNS server.
De zones afkomstig van de Forwarders gaan wel goed.

Referentie:
Als referentie materiaal heb ik tests uitgevoerd op:[list]
[*]een Vu+ duo (OpenPLi-1.0-2010-09-06)
[*]een DM7025 (jade3-2009-11-16);
[*]een Win7 client;
[/list]
hierbij waren er geen problemen.


Vraag:
Kennelijk is er in de beta-2.1 een dingetje geslopen die de eigenaardigheden van Wintendo niet meer snapt.
Wat speelt er en hoe moet ik dit ondervangen.
Entries opnemen in de hosts-file is welliswaar mogelijk echter, niet de oplossing die ik zoek.

Laatste courante image versie:
Voordat ik dit topic poste heb ik geprobeerd de laatste images te flashen.
[Whow Leute! Op het scheiden van de markt en zelfs als nieuw begin van 2012 nog een update uitbrengen! Absoluut klasse!]
Eerst OpenPLi-2.1-beta-vuduo-20111231_usb.zip 2011/12/31 18:16 - 38.84MB
en daarna OpenPLi-2.1-beta-vuduo-20120101_usb.zip 2012/01/01 02:20 - 38.84MB
Helaas kreeg ik ze niet aan de praat.
Daarom ben ik verder gegaan met de versie van dd 2011/12/28 02:28.

Testresultaten:
testresultaat op forward-lookup gebruikmakend van de forwardes met de Vu+ duo met OpenPLi-2.1-beta 2011/12/28 02:28

root@vuka:~# nslookup www.buienradar.nl
Server:	192.168.0.21
Address 1: 192.168.0.21 solomon-1
Name:	  www.buienradar.nl
Address 1: 194.109.134.103 www.buienradar.nl

testresultaat op reverse-lookup met de Vu+ duo met OpenPLi-2.1-beta 2011/12/28 02:28

root@vuka:~# nslookup 192.168.0.35
Server:	192.168.0.21
Address 1: 192.168.0.21 solomon-1
Name:	  192.168.0.35
Address 1: 192.168.0.35 vuduo.dream.local

testresultaat op forward-lookup met de Vu+ duo met OpenPLi-2.1-beta 2011/12/28 02:28

root@vuka:~# nslookup vuduo.dream.local
Server:	192.168.0.21
Address 1: 192.168.0.21 solomon-1
nslookup: can't resolve 'vuduo.dream.local'

testresultaat op forward-lookup met de Vu+ duo met OpenPLi-1.0-2010-09-06

root@vuduo ~ # nslookup vuduo.dream.local
Server:	192.168.0.21
Address 1: 192.168.0.21 solomon-1
Name:	  vuduo.dream.local
Address 1: 192.168.0.35 vuduo.dream.local

testresultaat op forward-lookup met de DM7025 met jade3-2009-11-16

root@twin ~ # nslookup vuduo.dream.local
Server:	 solomon-1
Address:	192.168.0.21
Name:	   vuduo.dream.local
Address:	192.168.0.35

testresultaat op forward-lookup met de Win7-client

C:\Users\max-sat>nslookup vuduo.dream.local
Server:  solomon-1
Address:  192.168.0.21
Name:	vuduo.dream.local
Address:  192.168.0.35

Naast deze test heb ik ook andere entries beproefd en gaven exact hetzelfde resultaat.
Alvast dank voor jullie hulp.

[max-sat]

[edit]
oeps, de update naar laatste versie had ik mss toch voor elkaar kunnen hebben als ik dit had gelezen:

Als een VU+duo niet wil opstarten met de nieuwe firmware, dient de bootloader bijgewerkt te worden.

Sorry...

[Erik Slagter]

Maar is dat dns-probleem nou al opgelost?

[max-sat]

Maar is dat dns-probleem nou al opgelost?

Nee nog niet...
De laatste versie van dd: 2012/01/01 02:20 heb ik nog niet actief vanwege de vele opnamens die stonden ingepland.
Image: OpenPLi-2.1-beta-vuduo-20111228 is dus nog actief.

Met netmon op de w2k-server heb ik geprobeerd na te gaan of er afwijkende queries werden uitgevoerd.
Voor zover ik begijp wat de datagrammen betekenen, kon ik geen afwijkingen waarnemen.
De dns logging heb ik aangezet op de server. Deze bevat ook geen meldingen.

[Erik Slagter]

Kun je als de laatste versie hebt geinstalleerd nog even proberen, melden wat je precies doet en het resultaat?

[max-sat]

Kun je als de laatste versie hebt geinstalleerd nog even proberen, melden wat je precies doet en het resultaat?

Op de nieuwe VU+duo draait nu de laatste versie en helaas zonder verbetering...
OpenPLi-2.1-beta-vuduo-20120101_usb.zip 2012/01/01 02:20 - 38.84MB

Hier even puntsgewijs de acties en resultaten:
zie att's voor output[list]
[*]uitvoeren vanuit de gui: "network test: lan connection"
--> test oke
[*]ifconfig
--> ipadres verkregen volgens reservering op basis van mac
[*]more /etc/hosts
--> bevat 1 regel met localhost definitie
[*]ping dns-server op ipadres
--> succes
[*]nslookup van dns-server op ipadres
--> succes
[*]nslookup van dns-server op fqdn
--> nslookup: can't resolve 'solomon-1.bld.local'
[*]nslookup van openpli.org op fqdn
--> succes
[*]nslookup van andere vu+ duo op ipadres
--> succes
[*]nslookup van andere vu+ duo op fqdn
--> nslookup: can't resolve 'vuduo.dream.local'
[*]fqdn entry opnemen in /etc/hosts
[*]nslookup van dns-server op fqdn
--> succes
[/list]
nu dezelfde acties vanuit andere vu+ duo met image van dd: OpenPLi-1.0-2010-09-06[list]
[*]uitvoeren vanuit de gui: "network test: lan connection"
--> test oke
[*]ifconfig
--> ipadres verkregen volgens reservering op basis van mac
[*]more /etc/hosts
--> bevat 1 regel met localhost definitie
[*]ping dns-server op ipadres
--> succes
[*]nslookup van dns-server op ipadres
--> succes
[*]nslookup van dns-server op fqdn
--> succes
[*]nslookup van openpli.org op fqdn
--> succes
[*]nslookup van andere vu+ duo op ipadres
--> succes
[*]nslookup van andere vu+ duo op fqdn
--> succes
[/list]

Voor zover de tests

Attached Files

•  vuka_OpenPLi-2.1-beta-2012-01-01.log   2.66KB   3 downloads
•  vuduo_OpenPLi-1.0-2010-09-06.log   2.66KB   1 downloads

[Erik Slagter]

Er is nog iemand anders met problemen die hierop lijken, zie: http://openpli.org/f...et-werken-niet/

[Erik Slagter]

Ik wil wel even opmerken dat voor nslookup het geen zin heeft om iets in de hosts file te zetten, nslookup (of beter: host) zoekt altijd via DNS, nooit in andere bronnen zoals /etc/hosts.

[Erik Slagter]

Ik heb een succesvolle update van mijn dm800 gedaan en bij mij werkt alles qua dns en http gewoon, het is dus niet iets structureels zo te zien.

[max-sat]

Ik wil wel even opmerken dat voor nslookup het geen zin heeft om iets in de hosts file te zetten, nslookup (of beter: host) zoekt altijd via DNS, nooit in andere bronnen zoals /etc/hosts.

Ja, daar zeg je wat. Mijn test wijst anders uit.

root@vuka:~# more /etc/hosts

127.0.0.1 localhost.localdomain localhost

#192.168.0.21 solomon-1.bld.local solomon-1

root@vuka:~#

root@vuka:~# nslookup solomon-1.bld.local

Server: 192.168.0.21

Address 1: 192.168.0.21 solomon-1

nslookup: can't resolve 'solomon-1.bld.local'

root@vuka:~#

Nu dezelfde test met aangepaste hosts-file

root@vuka:~# more /etc/hosts

127.0.0.1 localhost.localdomain localhost

192.168.0.21 solomon-1.bld.local solomon-1

root@vuka:~# root@vuka:~# nslookup solomon-1.bld.local

Server: 192.168.0.21

Address 1: 192.168.0.21 solomon-1.bld.local

Name: solomon-1.bld.local

Address 1: 192.168.0.21 solomon-1.bld.local

root@vuka:~#

[Erik Slagter]

Hmmm, waarschijnlijk weer zo'n fijne "aangepaste" busybox-versie van nslookup :-( Nslookup hóórt dat dus niet te doen...

[max-sat]

Ik heb een succesvolle update van mijn dm800 gedaan en bij mij werkt alles qua dns en http gewoon, het is dus niet iets structureels zo te zien.

Maak je daarbij gebruik van een eigen dns-server? En raadpleeg je daar dan ook een host in jou eigen gedefinieerde domain?
Als ik een forward-lookup doe naar een willekeurig www adres gaat het bij mij met OpenPLi-2.1-beta-vuduo-20120101 ook goed.

root@vuka:~#

root@vuka:~# nslookup openpli.org

Server: 192.168.0.21

Address 1: 192.168.0.21 solomon-1

Name: openpli.org

Address 1: 85.17.88.86 www.openpli.org

root@vuka:~#

[Erik Slagter]

in de resolv.conf staat dit:


search ipv6.slagter.name ipv4.slagter.name slagter.name
nameserver 10.1.1.7

Die 10.1.1.7 is een linux server, die forward z'n requests naar de firewall (ook linux) op 10.1.1.1 en die gaat opzoeken. Ik weet dus niet of dat erg representatief is ;-)

Het is in ieder geval niet zo'n goed idee om in de resolv.conf een hostname te zetten, of die wel of niet in de hosts file staat (ik weet niet of je dat probeert...)

[max-sat]

Die 10.1.1.7 is een linux server, die forward z'n requests naar de firewall (ook linux) op 10.1.1.1 en die gaat opzoeken. Ik weet dus niet of dat erg representatief is ;-)

Wel als je in 10.1.1.7 nog eigen entries hebt staan en die probeert te raadplegen.
Wil je dat eens proberen?

Het is in ieder geval niet zo'n goed idee om in de resolv.conf een hostname te zetten, of die wel of niet in de hosts file staat (ik weet niet of je dat probeert...)

Mee eens.
resolv.conf heb ik dan ook niet aangepast...

[Erik Slagter]

Die 10.1.1.7 is een linux server, die forward z'n requests naar de firewall (ook linux) op 10.1.1.1 en die gaat opzoeken. Ik weet dus niet of dat erg representatief is ;-)

Wel als je in 10.1.1.7 nog eigen entries hebt staan en die probeert te raadplegen.
Wil je dat eens proberen?

Je bedoelt in de hosts file? Die gaat-ie niet raadplegen. DNS gebruikt geen hosts files. De 10.1.1.7 is wel master van slagter.name en antwoordt dus zelf op slagter.name queries. En dat werkt gewoon.

[max-sat]

Die 10.1.1.7 is een linux server, die forward z'n requests naar de firewall (ook linux) op 10.1.1.1 en die gaat opzoeken. Ik weet dus niet of dat erg representatief is ;-)

Wel als je in 10.1.1.7 nog eigen entries hebt staan en die probeert te raadplegen.
Wil je dat eens proberen?

Je bedoelt in de hosts file? Die gaat-ie niet raadplegen. DNS gebruikt geen hosts files. De 10.1.1.7 is wel master van slagter.name en antwoordt dus zelf op slagter.name queries. En dat werkt gewoon.

Nee sorry, ik was niet zo duidelijk ;-) Ik wil uberhaupt geen entries in welke hosts-files dan ook. Daar is nou juist m'n dns-srv voor. Ik stel enkel vast dat het werkt als workarround.
Je geeft al aan wat ik zoek: query op hosts in jouw domain.
Dus als je een box hebt met naam: DM8000 in jou domain slagter.name dan bijv.:

# nslookup DM8000.slagter.name

Ben ik benieuwd naar dat resultaat.

[WanWizard]

Werkt hier ook gewoon:

root@vuduo:~# nslookup alfred
Server:	172.16.1.31
Address 1: 172.16.1.31 penguin.gotham.local
 
Name:	  alfred
Address 1: 172.16.1.183 Alfred.gotham.local
root@vuduo:~#

waarbij penguin mijn (linux) DNS server is, die authoritive is voor "gotham.local", en "Alfred" een Windows PC die zich via dyn-dns bij die server heeft aangemeld.

resolv.conf

root@vuduo:~# cat /etc/resolv.conf
search gotham.local
nameserver 172.16.1.31

hosts is default en bevat alleen localhost.

[Erik Slagter]

Zoiets?

root@dm800:~# nslookup nemesis
Server:    10.1.1.7
Address 1: 10.1.1.7 artemis.ipv4.slagter.name
 
Name:      nemesis
Address 1: 2001:980:5fef:1::1 nemesis-eth0.ipv6.slagter.name

[Erik Slagter]

Misschien een beter voorbeeld.

root@dm800:~# nslookup db1.ipv4
Server:	10.1.1.7
Address 1: 10.1.1.7 artemis.ipv4.slagter.name
 
Name:	  db1.ipv4
Address 1: 10.1.1.13 db1.ipv4.slagter.name

resolv.conf:

 
 
search ipv6.slagter.name ipv4.slagter.name slagter.name
nameserver 10.1.1.7

Edited by Erik Slagter, 3 January 2012 - 16:27.

[Erik Slagter]

@WanWizard: ik heb dus inderdaad geen gesplitste dns zoals jij, vind ik niet nodig, hoewel het op zich conceptueel wel mooier is. Met ipv6 wordt de grens zowiezo als erg arbitrair.

Edited by Erik Slagter, 3 January 2012 - 16:29.