Inlägg

Om du ställer in IP manuellt på 360:n (inte DHCP alltså) och inte fyller i default gateway (eller DNS) så kommer den inte åt internet. Det är med andra ord bara ip-adress och nätmask som behöver fyllas i.

Ja, det gör det. Uppenbarligen inte med alla kontrollers, men med ICH5 funkar det iaf.

Jo, men problemet är att www.google.com egentligen inte finns. Det är bara ett alias. Och DNS-servrarna för zonen l.google.com är bara auktoriserad att svara på frågor som rör domäner i just den zonen. Även fast www.google.com är ompekat dit. Det vet inte dom. Men lyckligtvis är det ju bara resolvern som behöver brottas med sånt här. (Och en och annan dåre som gör det manuellt )

Om du tittar i näst sista svaret så står det:

www.google.com  canonical name = www.l.google.com.

Det är en omdirigering (på dns-nivå) till en annan domän vars IP du får gräva vidare efter.
Nästa fråga blir alltså: nslookup -debug www.l.google.com 64.233.167.9.

Angående rekursion. -norecurse anger att du inte vill att dns-servern ska utföra en rekursiv förfrågning åt dig. RD-flaggan (Recursion Desired) är inte satt i paketet. Som default brukar den dock vara det. Det är alltså bara instruktioner till servern, nslookup kan inte fås att själv sköta en rekursiv förfrågning. Root-servrarna och många andra "höga" dnser är konfigurerade att inte utföra rekursiva förfrågningar åt folk som efterfrågar det, endast "enkla". Därför påverkar det inte svaren du får i det här fallet.

NP

Ja, det där är exakt samma svar. Då är det din router som är skurken. Vad är det för någon?

Proxyn skickar vidare frågan till den server som förfrågan är adresserad till om svar saknas i cachen. Proxyn ställer till det genom att den utgår ifrån att svaret är fullständigt, att det innehåller IP:t till www.sis.se. Så är ju inte (nödvändigtvis) fallet. När vi då skickar andra frågan till en av .se-dnserna så tror proxyn att den har ett korrekt svar i cachen och skickar tillbaka det (fast maskerat med IP:t för mål-DNSen.). Frågorna vi skickar ser ju precis likadan ut, dom gäller www.sis.se, det enda som skiljer är vilken dns-server dom är adresserade till.

Kan väl tillägga att det här beteendet gäller just i ditt fall, det är en taskig implementation av dns-proxy helt enkelt. Det är inte så svårt att göra den lite smartare så dessa problem inte uppstår.

När det gäller google.com finns det exempelvis en massa text-reklam över hela nätet som hämtas från google. Kan mycket väl vara från .com-domänen. Eller nån bild på google.se som hämtas därifrån. Finns massvis med möjligheter.

Angående edit2: Nej, det ska inte påverka. Dns-adressen anges ju direkt i nslookup så OS:ets inställningar används inte. (Om nu inte vista har någon inbyggd dns-proxy funktion, men det känns ytterst osannolikt.)

EDIT:
Jo, taskig implementation som sagt. Den verkar lagra alla svar för en domän, oavsett innehåll. Starta om routern. Och försök stänga av fuktionen.

[/b] Jag svara ja på allt.
Ett rekurisvt uppslag går till så att man arbetar sig nedåt från rooten (.) till sitt mål. Man kan göra det mauellt om man vill:
(192.228.79.201 = 201.79.228.192.in-addr.arpa. = b.root-servers.net.)

frysern@ws2:~$ nslookup -norecurse -debug www.sis.se 192.228.79.201
Server:         192.228.79.201
Address:        192.228.79.201#53

------------
    QUESTIONS:
        www.sis.se, type = A, class = IN
    ANSWERS:
    AUTHORITY RECORDS:
    ->  se
        nameserver = A.NS.se.
    ->  se
        nameserver = B.NS.se.
    ->  se
        nameserver = C.NS.se.
    ->  se
        nameserver = D.NS.se.
    ->  se
        nameserver = E.NS.se.
    ->  se
        nameserver = F.NS.se.
    ->  se
        nameserver = G.NS.se.
    ->  se
        nameserver = H.NS.se.
    ->  se
        nameserver = I.NS.se.
    ADDITIONAL RECORDS:
    ->  A.NS.se
        internet address = 192.36.144.107
    ->  B.NS.se
        internet address = 192.36.133.107
    ->  C.NS.se
        internet address = 192.36.135.107
    ->  D.NS.se
        internet address = 81.228.8.16
    ->  E.NS.se
        internet address = 81.228.10.57
    ->  F.NS.se
        internet address = 192.71.53.53
    ->  G.NS.se
        internet address = 130.239.5.114
    ->  H.NS.se
        internet address = 199.7.49.30
    ->  I.NS.se
        internet address = 194.146.106.22
    ->  A.NS.se
        has AAAA address 2001:698:9:301::53
    ->  F.NS.se
        has AAAA address 2a01:280:1:53::53
    ->  G.NS.se
        has AAAA address 2001:6b0:e:3::1
------------
Non-authoritative answer:
*** Can't find www.sis.se: No answer

...och sen fråga nån av dom dnser i svaret:

frysern@ws2:~$ nslookup -norecurse -debug www.sis.se 192.36.144.107
Server:         192.36.144.107
Address:        192.36.144.107#53

------------
    QUESTIONS:
        www.sis.se, type = A, class = IN
    ANSWERS:
    AUTHORITY RECORDS:
    ->  sis.se
        nameserver = nic2.sis.se.
    ->  sis.se
        nameserver = ns.bahnhof.se.
    ->  sis.se
        nameserver = nic.sis.se.
    ADDITIONAL RECORDS:
    ->  nic.sis.se
        internet address = 195.178.163.100
    ->  nic2.sis.se
        internet address = 195.178.163.130
------------
Non-authoritative answer:
*** Can't find www.sis.se: No answer

...och igen...

frysern@ws2:~$ nslookup -norecurse -debug www.sis.se 195.178.163.100
Server:         195.178.163.100
Address:        195.178.163.100#53

------------
    QUESTIONS:
        www.sis.se, type = A, class = IN
    ANSWERS:
    ->  www.sis.se
        canonical name = www4.sis.se.
    ->  www4.sis.se
        internet address = 195.178.163.109
    AUTHORITY RECORDS:
    ->  sis.se
        nameserver = ns.bahnhof.se.
    ->  sis.se
        nameserver = nic.sis.se.
    ->  sis.se
        nameserver = nic2.sis.se.
    ADDITIONAL RECORDS:
    ->  nic.sis.se
        internet address = 195.178.163.100
    ->  nic2.sis.se
        internet address = 195.178.163.130
------------
www.sis.se      canonical name = www4.sis.se.
Name:   www4.sis.se
Address: 195.178.163.109

...tills man hittar slutgiltiga svaret. Du kan ju testa. Hoppas att syntaxen är likadan i windowsversionen. Om du har en dns-proxy nånstans kommer du nog bara att få samma svar (det första) hela tiden. Du kan även efter det testa en icke-dns-server, får du svar därifrån oxå är det inget att snacka om (Ex. nslookup -norecurse -debug www.sis.se 195.178.163.100 ).

Förklaring av intercepting dns-proxy: Mjukvara som avlyssnar all utgående trafik efter dns-frågor. När det kommer en tittar den i sin cache om svaret finns där. Om det inte gör det utförs förfrågningen och svaret skickas till ursprungliga frågeställaren och sparas i cachen. Om svaret på en fråga redan finns i cachen skickas svar direkt till frågeställaren med spoofad avsändare. Det ser alltså ut att komma från den dns-server man frågade.
Fördelar: Snabbare surfning, mindre internettrafik.

Det skulle förklarar dom tre märkliga sakerna i ditt fall:
1. Fullständiga svar från root-server. www.google.com fanns helt enkelt i proxyns cache. Det såg bara ut att komma från root-servern.
2. För stora paket. Någon manipulering har skett av proxyn med paketen som inneburit att storleken knuffats över maxgränsen.
3. Rekursiva förfrågningar funkar inte. Proxyn sparar helt enkelt svaret från första förfrågningen och skickar det igen när nästa dnsserver får samma fråga. Tyvärr är den inte smart nog att fatta att svaret bara är ett delsvar.

Telia kör inte nån sån proxy, så det kan eventuellt finnas i routern eller (osannolikt) i vista. Men om du har bryggat det virtuella nic:et så passeras inte vista. Det borde gå att stänga av i router om det nu finns där.

Den sista rekursiva testloggen tyckte jag inte var så meningsfull. Den verkade bara fråga efter (och få) root-servrarna.

Hmmm, intressant. Först frågar server 192.228.79.201 (b.root-servers.net.) och får som svar dnserna för .se. Alles gut. Sen frågar den en av dom (194.146.106.22), rekurseringen fungerar alltså :). Som svar får den dock (igen) dnserna för .se. Processen upprepas sen för alla andra .se-dnser. Du får samma svar hela tiden. Så ska det (förstås) inte vara. Ställer jag samma fråga till samma server:

frysern@ws2:~$ dig www.dfkompetens.se @194.146.106.22 +norecurse

; <<>> DiG 9.4.1-P1 <<>> www.dfkompetens.se @194.146.106.22 +norecurse
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24323
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;www.dfkompetens.se.            IN      A

;; AUTHORITY SECTION:
dfkompetens.se.         86400   IN      NS      dns1.tim.se.
dfkompetens.se.         86400   IN      NS      dns2.tim.se.

;; ADDITIONAL SECTION:
dns1.tim.se.            86400   IN      A       80.72.0.29
dns2.tim.se.            86400   IN      A       80.72.0.30

;; Query time: 1143 msec
;; SERVER: 194.146.106.22#53(194.146.106.22)
;; WHEN: Sun Jan  6 14:48:00 2008
;; MSG SIZE  rcvd: 110

...så får jag ett helt annat (korrekt) svar.

Vad har du för internetanslutning till servern? Det råkar inte finnas någon intercepting dns-proxy uppströms? Det skulle förklara allt. Det är ju inte första gången din server får märkliga svar som den inte borde få.

[/b]
Ja, så verkar det vara.
Att du får rätt svar direkt beror nog på att svaren till www sidorna (pga popularitet) finns cachade i root-servrarna. Hur dom hamnat där tänker jag inte försöka svara på, när dom inte stödjer rekursiva förfrågningar. Jag har även (igen) misslyckats med att få annat än .se-dnserna som svar, trots rd-flaggan satt, vilket stödjer cache-hypotesen.
Men om du testar med www-frågor som inte tillhör dom största, tex:
www.blackwalnut-gh.com
www.dfg.se
www.dfkompetens.se
www.tim.se
Fungerar det fortfarande?
Min gissning är nej.

Vilken mjukvara kör du? Windows inbyggda eller bind?
Den tycks ju iaf oförmögen att själv utföra rekursiva förfrågningar. Det luktar forwarding trots dina nekanden.

Angående för stora paket. Dns-paket via udp "får" bara vara 512byte, är dom större ska dom skickas via tcp. Så din server ska nog inte ges hela skulden för det. Om den inte misstolkar läget på något vis.

(1) Klienten vill veta vilken namnserver den pratar med, (2) testar om sökta maskinen finna på lokala domänen (borde gå att slippa, titta i inställningarna).

[/b]Ja, det är onekligen märkligt. Det var åtminstone bara tillfälligt, jag testade att fråga samma server igen men får bara .com-servrarna som svar.

[/b]Svaret innehåller bara dns-servrarna för .com (som väntat alltså). Märkligt att svaret är för stort dock.

[/b] Ja, allt ser bra ut. Svaren innehåller dns-serna för .se, din server verkar dock inte gå vidare med förfrågningarna utan verkar förvänta sig att någon uppströms sköter det. Den returnerar heller inte delsvaret (.se-dnserna) till klienten och låter den gör jobbet.
Jag har aldrig mixrat med dns-servrar under win, men inställningarna rörande sådana saker borde du titta närmre på.

EDIT: Förtydligande
Den verkar vara inställd på att vara en forwarding-dns, men dom inställda dnserna (root-servrarna i ditt fall) stödjer inte rekursiva förfrågningar. Resultat = dåligt.

Du ska han antingen GVC - Driver eller Intel - Driver beroende på vilket nätverkskort som sitter i din.

Icke. CRT är totalt överlägsen på både färgåtergivning och (speciellt) svärta. Putsa glasögonen.

Edit: Jaha, här postas det samtidigt. Sist som vanligt

Kör du server eller desktop? Om du kör desktop så monteras minnet automatiskt vilket gör att inte vmware kan "ta" enheten. Avmontera det isf.

Kör:
glxinfo | grep vendor
Det borde vara SGI.

glxinfo | grep "direct rendering"
Borde vara Yes

Testa om glxgears fungerar.

Vad är det för skrivare? Jag var med om något liknande när jag skulle få igång min söta Laserjet (dock bara lokalt). Allt tycktes fungera perfekt, med det lilla undantaget att inget skrevs ut. Utskriftsjobben hamnade i något bottenlöst hål någonstans.
Efter att ha slitit mitt hår en stund tittade jag igenom loggarna nogrannare. Där hittade jag faktiskt ett mycket försynt meddelande om att lämplig firmware-fil saknades. Efter att den var införskaffad funkade det förstås. Titta igenom loggarna med andra ord, om du inte redan har gjort det.

Jag skulle även rekommendera att du verifierar att det fungerar lokalt innan du blandar in nätverksutskrifter, med alla extra felkällor det innebär.

Jag kan besvara min egen fråga. Det fungerar.

Mina förutsättningar:
Ubuntu 7.10 med öppna Radeon-drivrutinen (xrandr stöd)
Vanliga skärmen på DVI-porten
TV:n på VGA-porten

Från min fungerande PowerStrip-konfiguration fick jag ut:

Linux modeline parameters:
"720x576" 15,060 720 738 890 976 576 580 587 607 interlace +hsync +vsync

Den justerades till (förändringar feta (notera punkten)):

xrandr --newmode "720x576" 15.060 720 738 890 976 576 580 587 607 Interlace +HSync +Vsync CSync

Gör mode:et tillgängligt för VGA-portsskärmen:

xrandr --addmode VGA-0 "720x576"

För att förhindra att alla gnome-paneler flyttar till TV:n:

xrandr --output DVI-0 --crtc 0 --output VGA-0 --crtc 1

Lägg till TV:n till höger (utöka skrivbordet):

xrandr --output VGA-0 --mode 720x576 --right-of DVI-0

Woohoo, det fungerar (Utan en endaste omstart av X, utvecklingen går framåt )

Notera att inställningarna förloras när xservern startas om, för mer permanant bruk, lägg till i xorg.conf.

Hur funkar det egentligen i linux med den här kabeln? Det borde ju gå men har nån fått det att fungera? Kan vara bra att veta så jag inte bränner massa tid i onödan.

Enklast är nog att lägga till lokala IP:t i hosts-filen på klienten. Placering i osx är (väl?) /private/etc/hosts

Exempel:

192.168.1.11   skorpion.se

Blir dock lite jobbig om du släpar med dig datorn till andra ställen ofta. Men det går väl att göra något litet script som lägger till / tar bort isåfall.

Men kan du inte pinga med en statisk adress från virtuella datorn till dom övriga fysiska så fungerar inte nätverkstrafiken öht därimellan (om inte pingande är blockerat i nån brandvägg). Då är det helt naturligt att inte heller dhcp funkar.

Jag kör en liknande dator (vmware server på ubuntu 6.06) med diverse bryggade virtuella datorer som får ip via dhcp. Funkar utmärkt. Jag får dock samma problem som du (dvs virtuella kommer åt varandra och fysisk host, men inga andra fysiska, alla fysiska kommer åt varandra) om jag bryter strömmen till switchen och sen kopplar in den igen.

Jag har aldrig orkat felsöka så mycket man jag antar att det beror på att vmware sätter nätverkskortet i promiscuous mode (för att bridgingen ska fungera) och den inställningen "tappas" när länken går ner. (Samma sak händer inte om jag bara drar ut nätverkskabeln.)
Vad jag försöker svamla mig fram till är att det kanske är något problem med promiscuous mode för dig. Titta i loggarna.

Dubbelkolla även att inställningarna för virtuella maskinen verkligen säger bridged.

Har du nån livecd som ligger och skräpar kan du ju dra igång den i vmware (och testa dhcp) för att utesluta problem i din virtuella dator.

CF-kortet kommer inte att hålla speciellt länge om du installerar ett vanligt OS på det. Vanliga flashminnen håller bara för ett begränsat antal skrivningar.