A mérnök nagyon korrekt a D-Linknél

Hálózatok általános

 +---+                +---+           +---+
 | P |                | H |           |H2 |
 +---+                +---+           +---+
   | 192.168.0.10       | 10.0.0.41     | 10.0.0.42
   |                    |               |
 --------------------------------------------------------LAN

Mi a legegyszerűbb módja, hogy H hoszt kommunikálni tudjon P D-Link printerszerverrel?
A node-ok interfészeinek IP-címeiben nem történhet változás!

Természetesen gatewayt lehet állítani bármelyik node-on; alapesetben nincs egyiken sem beállítva. Elképzelhető azonban, hogy H2 hoszt is szeretne majd a későbbiekben kommunikálni a printerszerverrel, ezért olyan egyszerű megoldást kellene alkalmazni, ami ezt lehetővé fogja tenni.

  • 7952 megtekintés

( trey | 2010. 08. 09., h – 14:26 )

Van a printszervernek default gw opciója?

(topik címnek legközelebb olyat válassz légy szíves, aminek köze van a topikban olvashatókhoz)

--
trey @ gépház

No de ha a host a 10.akármi címtartományban van, akkor ki fog menni az ethernetjén 192.akármi című csomag? Nem vagyok nagy hálózati zseni, de nekem ez furcsa...mi mindig használunk valami eszközt - pl. bridge :) - ha két eltérő címtartomány között kell átjárni.

Két eltérő címtartomány közé bridge? Ezt nem vágom.

A router meg pont azt csinálja, hogy az egyik hálózatból érkező csomagot átküldi a másik hálózatba. A "H" hoston felveszi a "P" szerver címét, a printerre küldött csomag elkocog a def. gw-ig, ott kap egy gellert és ráesik a printerszerverre.

Vagy nagyon félreértem a problémát.

Miért változna meg az IP címe? 


"P" 192.168.0.10                                               "H" 10.0.0.41
(def. gw: 192.168.0.254)                                       (gw: 10.0.0.254)
|                                                                         |
|                         192.168.0.254          10.0.0.254               |
|--------------------------------- |     router     | ---------------------

"Mondjuk debianon - nem tudjuk, hogy a host mit futtat - lehet virtuális if-t definiálni és akkor annyi az egész."

Igen, ezt jelenti a "felveszel egy IP-t". Működik Windows-on is.

--
trey @ gépház

Win-n nem kell külön "interface", egy meglévőhöz több IP-t is hozzá lehet rendelni.

Kiválasztod a kapcsolatot, properties, kiválasztod az IPv4 protokolt, annak properties, és az advanced fülön több IP címet is hozzá tudsz adni minden további nélkül.

Anno koliban volt egy külső és még néhány belső hálós IP címem, a belső hálós címet általában felhúztam a külsős mellé, hogy ugyan ne vánszorogjanak már el a tanulói mellett lévő 24x100+1G uplinkes switchig és onnan egészen a központi routerig a packet, hanem ugyan menjen már a gigabit a szobai switchen belül.

----------------
Lvl86 Troll

Szia!

A topik címe nem egyértelmű, de arra utal, hogy a D-Link mérnökei frappánsan oldottak meg egy problémát.

Ennek eredményeként a printerszerveren nem is kell állítani semmit, ha a kommunikáló node-ok egy linken vannak. Ezért gondolom, hogy a D-Link mérnökei nagyon korrektek.

Nem, nem irónia, valóban megemelem a kalapom a D-Linkesek előtt, meg minden cég mérnöke előtt, akik így járnak el, pl. egy printerszerver esetén.

A D-Link mérnökei nem oldottak meg semmit, a megoldást neked kell megtalálnod. A D-Link mérnökei csak biztosítanak valamit az eszközön futó IP frappáns programozásával.

Printerszerverről van szó, és egy ilyen eszköznél, jól jön, ha könnyű használatba venni. Ebbe segítenek a D-Link mérnökei.

A kérdés pedig arra vonatkozik, hogy ki tudod-e használni ezt a lehetőséget, azaz ismered-e a D-Link printerszerverek sajátosságát. (Lehet, hogy más gyártó is implementálta ezt a "viselkedést", én azonban még csak a D-Link printerszervereinél tapasztaltam, és tényleg nagyon jó.)

Fogod a notebook-od, akármid, egy hálózatba rakod, ip címet váltasz.

Ha neked kell megoldanod, akkor KELL legyen jogod ahhoz, hogy a munkádat végezd, lásd ip cím váltás azon a gépen, melyről konfigurálsz. Alternatíva sorosport, bár ezt dlink-nél kevésbé játszik.

( pepelopez | 2010. 08. 09., h – 14:28 )

felveszel még egy ip címet a hoston a print server tartományban, de ha van mind a kettőn dgw akkor a gw beállítod a route táblát ha lehet

( HalfDemon v | 2010. 08. 09., h – 15:16 )

Es valojaban mi a feladat?
Ugy ertem, miert kellene _ezt_ megoldani?
Hogy is fejezzem ki magam... Szoval, egy nyomorult alhalozat valami 250 gepbol biztos allhat, es hat 300 gepenkent csak telik egy uj printszerverre, nem?

Ugyhogy en ezt ugy latom, ez egy olyan problema, amit meg lehet oldani, de nem biztos, hogy akkor teszunk jot valojaban, ha megoldjuk.
Mert igy, nekem valami kokanyolas - koltseghatekony ganyolasi szuksegletnek tunik, ugy, hogy ha valami gixer van, arra lehessen fogni hogy a hibas, aki megoldotta ezt a "vegyel meg egy nyomtatot" dologgal megoldando (tisztessegesen) problemat.

--
"Biztos én vagyok a béna, de csak azt sikerül elérnem, hogy kikapcsol a monitor."

Igazából nem történik semmilyen gányolás.

Arra próbálok rávilágítani, hogy a D-Link esetében magán az eszközön nem kell semmit állítani ahhoz, hogy elérjem, és nekem sem kell beállnom egy másik hálózatba, tehát nem kell IP-címet módosítanom, ill. a meglévő mellé felvenni egy továbbit.

Általában a hosztok DHCP-n keresztül kapnak IP-címet, gw-t, DNS-szuffixet, stb.-t, tehát pl. Windows hosztoknál nem lehet csak úgy beállni egy újabb hálózatba, azaz fel kell venni egy statikus IP-címet a meglévő egyetlen interfészhez. Ilyenkor azonban minden elveszik (dns, dns-szuffix, gw, stb.).

Nagyon egyszerű eset:
Hoznak egy printerszervert, amit be kell állítani.
A D-Link alján ott van a gyári IP-cím; ennyit tudsz, és megkér a kollegád, hogy állítsd be az eszközt az X-telephelyen történő használatra.

Én viszont a céges hálón vagyok, több dokumentum nyitva van, megy az Exchange-kliens (Outlook), épp egy levélre válaszolok, stb. Thehát nem akarok semmit megszakítani, a gépem DHCP-től kapott minden paramétert.

Akkor most hogyan fogok tudni kommunikálni a printerszerverrel a lehető legegyszerűbb módon, és úgy, hogy egyik nyitott kapcsolatom/doksim se vesszen el, vagy sérüljön meg, azaz nem tudok IP-címet állítani és a meglévő mellé sem felvenni újat.

Tehát ami biztos: a printerszerver D-Link és az IP-címe ismert, én viszont IP-címet nem állíthatok a aját gépemen.

(És persze nincs másik gép a kéznél, és a default gatewayen nincs jogom beálításokat eszközölni.

Csak a saját gépemet használhatom!
Nagyon fontos, hogy D-Link a printerszerver, és tényleg le a kalappal a D-Linkesek előtt!

Bemész a raktárba és leemelsz a polcról egy 1500 Ft-os Ethernet kártyát és egy cross-link kábelt.

Ez jóval olcsóbb, mint a kommentekkel töltött informatikusok órabére (és bármikor tudod használni más tesztelendő eszközhöz is). ;) Kapok csokit?
--
http://www.naszta.hu

Ez most egy D-Link reklám??

Egyébként apple gépeknél figyeltem meg azt a viselkedést, hogy tök mindegy, hogy mi az ip-címük, bonjour-ral simán meglátják egymást, és mehet a móka. (fájlmegosztás, stb.)
Gondolom itt is valami hasonló lehet, a printserver driver-e elküld mondjuk egy broadcast upd packetet "printerszerver, hool vaaagy??", kérdéssel, a printserver meg válaszol "itt vagyok, ip cimem: xxx.xxx.xxx.xxx, mac cmem: xxx.xxx.xxx.xxx". Talán küld még egy arp reply packetet is, "xxx.xxx.xxx.xxx ip == ff:ef:af:.... mac" tartalommal.

Innentől kezdve nem tudom, hogy mekkora őrdöngősség a dolog, ha a gépemen egy process ip csomagot küld az xxx.xxx.xxx.xxxip-címre, akkor, mégha az nem is velem azonos alhálózatban van, akkor is kiküldi a default gw-n az ip csomagot. Namármost, mivel az ip alatt ethernet van, ki fog menni egy arp "who-has" kérés az xxx.xxx.xxx.xxx címre, amit ugye a printszerver érzékelni fog, mivel egy etherneten vannk, és válaszol, hogy "xxx.xxx.xxx.xxx has .xxxxxxx mac-address", vagy ha a printserver már előtte küldött egy arp-reply-t, akkor az benne van az arp cache-ban.

Az ip layer meg egyszerűen be fogja tenni az ip csomagot egy ethernet keretbe, aminek cél-címnek megadja az arp-reply által megkapott mac-címet.

Szerintem simán működhet, még csak különleges hack sem kell hozzá, pusztán az ISO/OSI layert ott csapja pofán a "protokoll", hogy számít arra, hogy az ip alatt ethernet van, és majd az arp-protokoll megoldja, hogy a nem azonos ip-alhálózaton levő gép mac címét is meg tudjuk szerezni, és csomagot tudju k küldeni neki ezéltal.

Nagy hülyeséget mondok?

( shiki | 2010. 08. 09., h – 15:21 )

Ez a cím hogy sikeredett? Mit jelent?

A printerszervernek tudsz adni másik IP-címet, de előbb kapcsolódnod kell hozzá.

Mint írtam, nincs másik gép kéznél, csak a sajátod, de azon IP-címeket meg nem tudsz állítani az ismertetett okok miatt.

Úgy kell tehát elérned a printerszervert, hogy más megoldást alkalmazol.

( battila | 2010. 08. 09., h – 16:06 )

Hali,

3 megoldas kozul valogathatsz izles es igeny szerint:

1, router berakasa a halozatba. Ehhez nem kell nagy magia. Eleg bele egy ethernet interface, mind a ket halozatot arra az egy interfacere kell iranyitani es kalap kabat. Ha a router cisco, akkor az nem igenyel a halozatbol ip-t, ha linux alapu, akkor pl.: eth0 10.0.0.0/255.0.0.0 es eth0:1 192.168.x.x/a.b.c.d, routing, nat, ... tetszes szerint


+---+ +---+ +---+
| P | | H | |H2 |
+---+ +---+ +---+
| 192.168.0.10 | 10.0.0.41 | 10.0.0.42
| | |
--------------------------------------------------------LAN
|10.0.0.222
192.168.0.222 |
+---+
| R |
+---+

2, az gepre amirol nyomtatni akarsz virtualis interface-t felhuzni, mint a router eseteben. Az ip a nyomtato tartomanyabol legyen, akkor mukodni is fog.

3, atallitod a netmaskokat 0.0.0.0-ra:) Akkor az egesz egyetlen egy halozatba fog esni. Ehhez viszont allitgatnod kell az interface-ken. Valojaban nem teszteltem ezt soha, de elkepzelheto, szoval elvi sikon megoldas is lehet:)

3+1, raraksz egy masik nyomtato szervert

A rúter jó megoldás, de nem a legegyszerűbb, merk kell hozzá egy külön eszköz; a rúter.

A virtuális interfész teljesen jónak tűnik, de ilyent még nem csináltam Windows alatt. De azt gondolom, ha van is rá lehetőség, hogy ez sem a legegyszerűbb megoldás.

A netmaskot a printerszerveren nem tudsz állítani, mivel előbb el kell érni az eszközt. A gépeden megint nem fogsz tudni állítani, mer akkor le kell vállnod a DHCP-szerverről, és a megnyitott dokumentumok és programok adataiban adatvesztés keletkezhet; nem feltétlenül, de keletkezhet, és nem akarsz kockáztatni, stb. (Amúgy a 0.0.0.0-ás netmask teljesen jó megoldás, igaz Windows alatt csak a netshval kivitelezhető; bár ez utóbbi a normális, nem a kattingatos módszer.)

Na akkor a 3+2. megoldas:

fogsz egy virtualboxot. Felraksz ra egy minimal linuxot. A virtualboxba beallitasz egy interface-t a 192.168.xxx.yyy-ra.

Magabol a linuxbol racsatlakozhatsz a dlink printerszerverre, es atallitod, amit at kell allitani.
Vagy hasznalod a virtualboxot routernek.

Ehhez nem kell a windowsban raolvasast elvegezned, valoszinuleg egy virtualboxot fel tudsz ra installalni (van hozza jogod).

( zeller | 2010. 08. 09., h – 16:03 )

Esetleg a RARP-pal lehet kapcsolatban a megoldás?

( dj | 2010. 08. 09., h – 16:20 )

A D-Link Clink’n Connect szoftverrel megy a bűvészkedés nem? Be kell írni a print szerver MAC address-ét és úgy kommunikál vele.

de ha nem férsz hozzá a gépedhez rendszergazdai jogokkal, - hálózati beállítások, v. akár telepítés - akkor esélytelen.

a legegyszerűbb az lenne, ha a Hx gépekhez, és a P szerverhez hozzáadnál egy, a másik hálózatára mutató routot.

ha a P szerverhez egyáltalán lehet valamilyen módon - mondjuk html beállító oldal - routot hozzáadni.

ha hozzáférsz, akkor egyszerűen csinálsz egy virtuális interfecet a Hx gépekre 192.akármi ipvel, és még routolni sem kell.
vagy vindows esetén alternatív ip-t adsz hozzá a tcp/ip beállításoknál. - vagyhol:) -

szerk.: bár ez elég gány megoldás:)

szerk1.: bocsi window$:) és nem vindows

( opaque | 2010. 08. 09., h – 16:47 )

a 255.255.255.255 broadcast használata :)
de ha valóban korrektek, akkor multicast.

( azbest | 2010. 08. 09., h – 17:08 )

Azt hiszem megértettem, mit szeretne közölni a kérdező... nem volt egyszerű :S

Van egy 10.0.0.x-es címen futó céges hálózat.
Hoznak egy dlink printszervert, amit akkor vesznek ki a dobozából és a gyárilag alapértelmezett címe 192.168.0.10.
A kérdező problémája az, hogy nem szeretné újraindítani a gépét, hogy átírja olyanra (192.168.0.x) a címét, amelyből kapcsolódni tudna a printszerverhez, hogy azt beállítsa.

a) A kérdező nem tudja, hogy ezért nem kellene újraindítani a gépét (bezárni a nyitott dokumentumokat), mert menet közben változtatható a címe.
b) valamiért muszáj online lennie a megnyitott programjai miatt.

Namost, megnéztem direkt Win7 alatt, ott is hozzá lehet adni több ip címet egy hálózati eszközhöz is. De korábbi windows rendszereken is működik ez (ahogy linux alatt is).
http://www.webnms.com/simulator/help/sim_network/netsim_conf_virtual_ip…

Csupán a tcp/ip v4 -nél ahol az ip címet kézzel is meg lehet adni, a speciális gombra kell kattintani és ott felvinni a másik címet. Ennyi az egész, azt hiszem más is írt már ilyet. Ha van jogosultsága ezt változtatni, akkor képes rá, a másik ip címe attól megmarad. Nem értem miért írja, hogy nem változtathat rajta. Ha a helyi rendszergazda/policy miatt, akkor ezt a rendszergazdával beszélje meg.

Szerintem nem tudja megfogalmazni, hogy mit akar :)

Előbb már nem tudtam szerkeszteni, hogy azért írja a dhcp cimkiosztást, mert olyan beállítás mellett nem engedi a windows hogy felvegyen több alternatív ip címet is a hálókártya. Persze a dhcp kiosztás is nyugodtan lehet fix ip című, erről a rendszergazdát kell kérdeznie. Ha az engedi neki, hogy fixen beírja a címét, akkor fel tud venni alternatív címet is.

Ha pedig a rendszergazda megkerülésével szeretne ügyeskedni, akkor vegyen egy usb hálókártyát, ahhoz a gépet sem kell megbontani és azzal azt köt a gépére pluszban, amit csak akar.

Egyedül azt nem értem, hogy ha a céges háló része a printeszerver, akkor miért nem írja át 10.x.x.x akárhanyasra vagy szintén dhcp-re annak a beállítását... ja azért nem mert nem tudja átírni a gépe címét, hogy hozzáférjen a 192-es címen elérhető printszerverhez :)

Kattingatós módszernél is csak akkor lehet további IP-címeket hozzáadni egy interfészhez, ha elválsz a DHCP-szervertől, tehát letiltod a DHCP-t, és megadsz egy vagy több új IP-címet.

A feladat azonban pont az, hogy nem változtathaszt az interfészed IP-címén, és hozzá sem adhatsz.

"Azt hiszem megértettem, mit szeretne közölni a kérdező... nem volt egyszerű :S

Van egy 10.0.0.x-es címen futó céges hálózat.
Hoznak egy dlink printszervert, amit akkor vesznek ki a dobozából és a gyárilag alapértelmezett címe 192.168.0.10."

Aha! Nekem ez nem jött át, én a kérdés elolvasása után arra asszociáltam, hogy így akarja üzemeltetni, amit megerősített azzal, hogy ha új host gép kerül be a körbe, az is lássa a megoldás alapján. Kissé félrevezető volt, bár engem a "A doboz" című film kötött le és az is eléggé bezavart, mert orbitális ökörséget kezdtem fejtegetni, amíg vissza nem térítettek a valóság talajára. :)

( Polesz v | 2010. 08. 09., h – 18:03 )

Transport Protocols
• TCP/IP
• NetBEUI
• AppleTalk/EtherTalk
TCP/IP Protocols Supported
• BOOTP
• SNMP
• Telnet
• TFTP
• FTP
• LPD
• RARP
• DHCP
Management
• SNMP
MIBs
• MIB-II (RFC 1213)

Ezt tudja az összes D-Link PrintServer. Ebből kell kiválasztani a szimpatikus megoldást, szerintem a Management SNMP-n történő megvalósításáról és a MIB-II használatáról vitatkozunk ;-)

--
falura el megy, városban meg úgy sem nézik...

( uid_17784 | 2010. 08. 09., h – 19:00 )

A legegyszerűbb megoldásnak a következőt gondolom a poszt indulási ábrájánk és az ott leírt körülményeknek megfelelően (windowsos környezetben):

A hoszton ki kell adni a következő parancsot: 

route add 192.168.0.10 mask 255.255.255.255 10.0.0.41

Kész.
Normál esetben ez kevés, ugyanis a printeszerveren is ki kellene adni egy hasonló parancsot, hogy a tudjon kommunikálni a hoszttal, de a D-Link printerszerverek esetében nem kell, és ez az, ami szerintem egy nagyon korrekt megoldás a D-Link mérnökeitől.

A megoldás egyszerűsége tehát abban áll, hogy a hoszton egyetlen útvonalbejegyzés hozzáadásával kommunikálhatóvá tettünk a két, teljesen független IP-hálózatban lévő eszközt.

A hoszton szerintem egyértelmű hogy mi történt, bár bizonyára sokan vannak, akik azt feltételezik, hogy rúter közbeiktatása nélkül, vagy anélkül, hogy a hoszt újabb lábat növesztene, amivel beleáll a printerszerver hálózatába, nem folyhatna kommunikáció.

Tehát
- nem kell rúter,
- nem kell interfész, ami azonos hálózatban van a másik eszközzel.

(Régen ez nem volt így, de 1993-ban bevezetésre került a CIDR, és onnantól csak az számít, ami az útvonaltáblábn van, azaz az IP nem osztályalapon rútol, vagyis mindegy neki, hogy milyen lábakon áll a hoszt, és melyik lavórba (by Fóti Marcell) lógatja bele azt.)

Volt, aki rögtön azt mondta, hogy nem folyhat kommunikáció, a hozzáértők, ők sokan vannak, tudták, hogy nincs ezzel gond, de szinte mindenki rútert (gw-t) akart betenni, ha már nem lehet változtatni a hoszt IP-címén sem.

Amitől pedig működik, azaz hogy elég a hoszton azt az egyetlen útvonalat felvenni, az a D-Link frappáns megoldásának köszönhető.

Az IP normál esetben, csak és kizárólag az útvonaltábla alapján rútol. Ennek következtében nincs esélye olyan csomagnak, amelyik olyan célcímet visel magán, amelyikhez nincs útvonal beállítva.

Ezekből az következik, hogy ha a printerszerveren nincs útvonal a 10-es hálózat irányába, és mivel default gateway sincs felvéve rajta, így egy normál implementálású IP ilyenkor eldobja a csomagot, mert nem tudja, hogy mit kezdjen vele.

A printerszerver nem rúter, tehát nem is kell neki úgy viselkednie, mint egy rúternek. Ezt ismerhették fel a mérnökök, amikor úgy döntöttek, hogy olyan esetben, amikor egy IP-csomagot olyan címre kell küldeni, ami nincs benne az útvonaltáblába, egyszerűen kiküldik a linkre!

Ez lehetővé teszi, hogy a printerszerveren semmit ne kelljen módosítani, ahhoz, hogy kapcsolódni tudjunk hozzá egy teljesen másik hálózatba konfigurált, de vele azonos linken lévő hosztról, és ráadásúl úgy, hogy a hosztot sem kell eltávolítani abból a hálózatból, amiben éppen van.

Összefoglalva a D-Link printerszerver egyediségét (bár gondolom, hogy ezt msá eszközgyártók is bevetették, csak én nem ismerem azokat): ARP-ol minden csomagot. Ha van default gateway, akkor azért, ha nincs, akkor meg azért.

Természetesen nem arról van szó, hogy egy printerszervert a megadottak szerint kell vagy célszerű üzemeltetni.

Ez csak amolyan gyakorló feladat, hogy mennyire vagy tisztában a lehetőségekkel. Minél jobban ismered a lehetőségeket ill. az IP-t, annál egyszerűbb megoldást tudsz a feladatra megoldásként kitalálni.

Szerintem nagyszerű dolog, hogy a D-Link esetében a hoszton egy egyszerű útvonalbejegyzés hozzáadásával meg lehet oldani a feladatot/problémát.

Ez azért érdekes, mert az ethernet keretnek a célcímébe (MAC) mi is fog kerülni? A célcím nincs vele egy hálózaton, jöhet a route tábla, ott megleli, hogy a 10.x.y.z felé kell küldeni, rájön, hogy az a saját Ethernet interfésze, az a MAC kerül célként a keretbe... Ha ki is megy a drótra, a switch látja, hogy az a MAC azon a lábon van, ahonnan hallja, ergo nem kell vele semmit sem csinálnia.

Kérdés: Hol hibás a fenti eszmefuttatás?

Szét kell választani a IP réteget az adatkapcsolati rétegtől!

Az adatkapcsolati réteg egyáltalán nem foglalkozik azzal, hogy milyen IP-címmel rendelkező node-ok kommunikálnak felette.

Tehát egyáltalán nem érdekli az adatkapcsolati réteget, hogy ki milyen IP-hálózaton "lakik".

A switch, de nevezzük inkább bridge-nek, mert valójában olyan, hogy switch nem létezik, az csak egy marketingnév, layer 2 rétegbeli eszköz, tehát megint nem nagyon érdekli, hogy az IP-csomagogban mi utazik. A bridge ethernetkereteket lát, és az alapján dobálja a kereteket a megfelelő irányba.

Az ARP-kérés broadcast címre van címezve, tehát minden node, aki azonos datalinken van, megkapja; a bridge tehát nem gondolkodik egyáltalán, hanem minden portjára kitolja a keretet.

Az ARP-ben van query, ekkor egy IP-cím van a keretben, ami ff:ff:ff:ff:ff:ff-ra megy, ezt mindenki hallja, és csak az küld rá arp reply-t, akinek a címét tartalmazza, ez stimmt. De nem ezt kérdeztem :)
A kérdés az volt, hogy a Windows ebben az esetben a printerszervernek szóló, IP-ben unicast csomagot tartalmazó keretbe milyen célcímet (MAC) rak, és miért? Ha ide kerül ff:ff:ff:ff:ff:ff, akkor az picinyt durva, hiszen ezzel valamennyi host látja azt, hogy mi megy a printerszerverre, mindenki látja a nyomtatásodat...

Uhh, te most hülyéskedsz?

Megpróbálom megfejteni, ill. leírom neked, hogy mi történik, az után hogy a rout add ... paranccsal bekerült az printerszerver felé egy útvonal a hoszt rúttáblájába:

Pingeljük a printerszervert

A ping összeállít egy ICMP Echo Request csomagot, és kiküldeti az IP-vel a 192.168.0.10-es célcímre.

Az IP kikeresi a célcím alapján a megfelelő útvonalbejegyzést.

Az útvonalbejegyzés szerint átadja az ARP-nak
- a csomagot,
- célcímként a 192.168.0.10-et,
- és megadja, hogy melyik interfészen kell kiereszteni.

Az ARP (tegyük fel üres a tára) megarpolja a célcímet, azaz a 192.168.0.10-et.

Az arp összeállít egy ARP Requestet, és szól a datalinknek, hogy küldjön ki egy körözvényt a "mindenki" címére, azaz ffffffffffff-re.

A keretben a
- Sender MAC Address a hoszt hardvercímét
- Sender IP address a hoszt IP-cymét, 10.0.0.41
- Target MAC address a broadcast címet (ffffffffffff)
- Target IP pedig, a 192.168.0.10-et fogja tartalmazni

Erre a keretre egyetlen node fogja felütni a fejét, mégpedig a printerszerver.
Válaszol rá, és jól megjegyzi közben a hoszt IP-címát és MAC-címét, azaz bekeseli.
A válaszban megadja a saját MAC-címét és IP-címét.

A hoszton futó ARP is jól megjegyzi, azaz lekeseli a printerszerver MAC címét.

Ekkor a hoszton futó ARP utasítja a datalinket, hogy a printerszerver immár ismert MAC-címére küldjön egy Eternet keretet, payloadként meg menni fog a ping request.

A printerszerver tehát célzottan megkapja a ping request csomagot.

A printerszerver ezután válaszolni fog a csomagra.
Pontosan az fog történni, minta amit most itt leírtam, csak az irány fordított, ill. a printerszerveren futó ARP már kesből fog dolgozni, hiszen épp az imént mentette el a hoszt MAC-és IP-címét.

Kicsit későre jár, ezért a gépelési és esetleg egyéb hibákért elnézést, de szerintem érthető, hogy miért jön tud visszajönni a pinre a válasz a printerszervertől.

Azt meg már le lett írva, hogy a printerszerveren futó IP hogyan talál útvonalbejegyzést a hoszt felé.

Ugyanezt mondom én is, csak ICMP nélkül - elég lesz az első tcp syn csomag ahoz, hogy az l2 broadcast kimenjen a route add-dal az adott ip-tartományhoz rendelt interfészen (route add 192.168... dev eth0), az unicast válasz is vissza fog találni l2-n, megvan, hogy a keret célcímébe mit kell írni (jó kérdés, hogy ha adott mac-re, de más célip-vel dobnék ki csomagot a drótra, arra válaszolna-e a D-link kütyü...), és innentől már l2-n megy a móka. A túlvég meg a syn csomagból kiszedi az l2 meg az l3 címét a feladónak, és tud rá válaszolni.

"Mindig a gatewayen mennek át..."

Hát nem éppen így működik az IP; CIDR bevezetésétől, azaz 1993-tól biztosan nem.

Pont erről beszélek, hogy csak felületesen ismeri a legtöbb renfdszergazda az IP-t.
Az is érdekes, hogy a legtöbben attól, hogy elolvasnak egy-két rfc-t, azt hiszik, hogy mindent értenek.

Elképzelhetőnek tartom, hogy egy korábbi IP-vel foglalkozó rfc-be olvastál bele, vagy csak felületesen olvastad végig akármelyiket.

Hello!

Szerintem az IP, meg az Ethernet nincs összekötve, bár leggyakrabban az IP tényleg Ethernet felett megy (de ez egyáltalán nem szükségszerű (pl. ATM, ...)). Szóval amit írsz, az nem csak IP tudás, inkább Ethernet, meg inkább a Windows IP-stackjének megvalósítása (lehet, hogy a Linux is így kezeli).

Viszont a CIDR-et nem kell túlmisztifikálni, egyszerűen azt jelenti, hogy nem csak classful-(IP-)subneteket tudnak az IP-routerek kezelni, hanem lehet osztani a subnetet. De a CIDR-nek és az Ethernetnek semmi köze egymáshoz.
Szvsz.

Üdv.

Ki mondta, hogy a IP meg az Ethernet össze van kötve?
Az IP a datalinkkel van "összekötve".

A CIDR-t ki misztifikálja túl?
Azonban nem pont arról szól, hogy "lehet osztani a subnetet"; azt ugyanis lehetett a CIDR előtt is.

Nagyon tömören osztály nélküli rútolás.
Konkrétan arról szól, hogy az útvonaltábla 3 oszlopró 4 oszlopra bővült, a rútolásnál pedig a genmask által legjobban illeszkedő útvonal nyer.

CIDR előtt: 

  <network, gateway, flags>

CIDR után: 

  <network, netmask, gateway, flags>

A netmask inkább genmask, ahogy a linuxos rendszerekben megjelenik; ez ugyanis a működésére jobban utal.

Te érted amit leírsz? :D
CIDR előtt: A osztályú IP: 255.0.0.0, B osztályú IP: 255.255.0.0, C osztályú IP: 255.255.255.0
CIDR után: A, B, C osztály: olyan mask amilyet akarsz.
Ezért is kell a + mező a táblába, mert már nem következik a címből közvetlenül a netmask is.

Azt hiszem, igen. :)

CIDR-bevezetésével megszűntek az osztályok.
A CIDR bevezetésével nem szűntek meg azok a node-ok, amelyek olytályalapon rútolnak.
Szerintem ennyiről van szó.

Az a node, amelyik CIDR előtti IP-t futtat, osztályalapon rútol, tehát az ő számára léteznek osztályok.

Ha egy node CIDR szerint működik, akkor az azon futó IP számára nincsenek osztályok.
Tehát "CIDR után" nincs olyan, hogy A-, B-, C osztály.

Olyan, hogy maszk nincs.
Subnet mask van és network mask.

CIDR előtt a kettő azonos volt, helyesebben csak subnet mask létezet, azonban network masknak is hívták.

CIDR után a kettő nem azonos, helyesebben a subnet maskot már nem lehet network masknak hívni, mert bejött a network mask az útvonaltáblába, mint új oszlop.

Jobb helyeken a network maskot (CIDR után vagyunk) genmask-nak hívják, ill. jelölik, hogy ne keverdjenek meg a rendszergazdák. Ilyen jobb hely pl. a Linux!

Tehát CIDR után az alábbi maskok vannak:

A subnet mask az interfészhez rendelt IP-címhez tartozik, és azt határozza meg, hogy az interfész melyik alhálózatba tartozik, nem pedig azt, hogy az IP-cím milyen osztályba.

A net(wokrk)mask az útvonalhoz tartozik, és a célcím illeszkedését határozza meg, nem azt, hogy akármi milyen osztályba tartozik. Az osztályalapú rútolás a CIDR-rel megszünt.

Subnetmask = netmask = genmask = kiskutyamask...

CIDR előtt nem létezett *mask, mert maga az IP cím (azzal, hogy milyen oszályba tartozik) hordozta a hozzá tartozó *mask-ot is. A CIDR bevezetésével viszont már te választhattad meg a *maskot így muszáj volt a routing táblában ezt is figyelembe venni, de ennek továbbra sincs semmi köze az adott problémához.

Az adott problémához nagyon köze van.

CIDR előtt nem volt olyan, hogy egy datalinken logó node-ok különboző hálózatba tartozhattak.
Nem volt rá lehetőség, muszáj volt őket azonos hálózatcímmel ellátni.

CIDR bevezetésével ez a korlátozás megszűnt, egyszerűen nincs jelentősége, hogy az egy datalinken lévő node-ok azonos hálózatban vannak-e.

Természetesen nincs értelme egy datalinken lévő node-okat úgy konfigurálni, hogy külön hálózatba legyenek.

A topik egyik lényege pontosan az, hogy rávilágítson, hogy a rendszergazdák döntő többsége azt hiszi, hogy ha két node nem azonos hálózatba van konfiguráva, akkor csak segíttséggel tudnak kommunikálni. A segítség itt azt jelenti, hogy kell egy közbülső node, aki a gateway szerepét betölti.

Vannak rendszergazdák, akik meg olyanról beszélnek, hogy saját maga gatewaye. Ezt nem is értem! Nyilván ők sincsenek tisztában a CIDR által "kapott" IP algoritmus működésével.

Az IP nem az a protokoll, amire túl nagy figyelmet szentelnek általában egy node esetében.

A windows routing táblájában, meg a route parancsában csak ip-címet tudsz megadni, device-t nem, tehát első ránézésre a saját ip-címe a gw címe. Értelmesebb rendszernél ez úgy néz ki, hogy a gw helyén 0.0.0.0 van, a megadása meg például route add -host 192.168.1.2 dev eth0, ennyi az egész.

Nem ismered jól a Windows route parancsát; természetesen lehet interfészt megadni. 


C:\TMP>route /?

A hálózati útvonaltáblák kezelése.

ROUTE [-f] [-p] [-4|-6] parancs [cél]
                  [MASK hálózati_maszk]  [átjáró] [METRIC metrika]
                  [IF kapcsolat]

  -f              Az összes átjáróbejegyzés útvonaltáblájának törlése. Ha
                  ezt egy paranccsal együtt használja, a táblázatok
                  a parancs futása előtt törlődnek.
  -p              Az ADD paranccsal együtt használva a rendszerbetöltésektől
                  független állandó útvonal jön létre. Alapértelmezés
                  szerint az útvonalak nem őrződnek meg, ha a rendszer
                  újraindul. Ezt a kapcsolót nem veszi figyelembe a rendszer
                  a többi parancs esetében, mert azok mindig a megfelelő
                  állandó útvonalakra érvényesek. Ezt a kapcsolót a Windows 95
                  nem támogatja.

  -4           Az IPv4 használatának kényszerítése.

  -6           Az IPv6 használatának kényszerítése.

  parancs         A következők egyike:
                    PRINT     Útvonal nyomtatása
                    ADD       Útvonal hozzáadása
                    DELETE    Útvonal törlése
                    CHANGE    Létező útvonal módosítása
  cél             Az állomás megadása.
  MASK            Annak megadása, hogy a következő paraméter a 'hálózati_maszk'
                  érték.
  hálózati_maszk  Az adott útvonalbejegyzés alhálózati maszkjának megadása.
                  Ha ez az érték nincs megadva,  a rendszer alapértelmezés
                  szerint a 255.255.255.255. értéket használja.
  átjáró          Az átjáró megadása.
  kapcsolat       A megadott útvonal kapcsolatszáma.
  METRIC          A metrika, azaz a cél költségének megadása.

A célként megjelölt szimbolikus neveket a program a NETWORKS hálózati
adatbázisfájlból keresi ki. Az átjárók szimbolikus neveit a program a HOSTS
hálózati adatbázisfájlból keresi ki.

PRINT vagy DELETE parancs esetén a cél vagy az átjáró helyére helyettesítő
karakter is írható (ennek jele a csillag '*'), de az átjáró megadása ki is
hagyható.

Ha a cél * vagy ? jeleket tartalmaz, akkor azokat a rendszer behelyettesítő
mintaként kezeli, és csak a mintával egyező útvonalakat nyomtatja ki. A '*'
bármely karakterláncot, a '?' egy karaktert helyettesíthet.
Példák: 157.*.1, 157.*, 127.*, *224*.

A mintamegfeleltetés csak a PRINT parancs estében engedélyezett.
Diagnosztikai megjegyzések:
    Az érvénytelen MASK érték hibát okoz, azaz amikor (DEST & MASK) != DEST.
    Példa> útvonal ADD 157.0.0.0 MASK 155.0.0.0 157.55.80.1 IF 1
             Az útvonal hozzáadása nem sikerült: A megadott maszkparaméter
             érvénytelen. (cél & maszk) != cél.

Példák:

    > route PRINT
    > route PRINT -4
    > route PRINT -6
    > route PRINT 157*          .... Csak a 157* mintával egyező útvonalak
                                     nyomtatása.


    > route ADD 157.0.0.0 MASK 255.0.0.0  157.55.80.1 METRIC 3 IF 2
                     cél^      ^maszk     ^átjáró     metrika^    ^
                                                         kapcsolat^
      Ha az IF paraméter nincs megadva, a program az adott átjáróhoz
      a legmegfelelőbb kapcsolatot keresi meg.
    > route PRINT
    > route ADD 3ffe::/32 3ffe::1


    > route CHANGE 157.0.0.0 MASK 255.0.0.0 157.55.80.5 METRIC 2 IF 2

      A CHANGE csak az átjáró és/vagy a metrika módosítására használható.
    > route DELETE 157.0.0.0
    > route DELETE 3ffe::/32

Akkor most már világos, hogy mit értek az alatt, hogy a "route van annyira imtelligens"?

Pontosan ezt írtam korábban, hogy intelligens:

A route add 192.168.0.10 mask 255.255.255.255 10.0.0.41 a következőt jelenti:

A 192.168.0.10-es hálózatba a 10.0.0.41-es interfészen keresztül visz az út.

Vedd észre, hogy a 10.0.0.41-es IP-címmel rendelkező gépen adod ki a fenti parancsot. A route van annyira intelligens, hogy rájön, hogy a 10.0.0.41 az egyik (jelen esetben az egyetlen) interfészéhez rendelt IP-cím.

Másképp fogalmazva pontosan arról szól a fenti útvonalbejegyzés a 10.0.0.41-es gépen, hogy a 192.168.0.10-es hálózat felé a 10.0.0.41-es interfészen kell kieregetni a csomagokat.

A pirossal szedett rész a route szintaktikai ismertetőjében erre utal.

És ezt értettétek jól félre, azaz néhány embernek úgy jött le, hogy saját maga gatewaye...
És még a microsoftos programozók próbáljanak segíteni a rendszergazdákon!

Felületesség, semi más.
Az ember lát valamit, aztán onnantól azt hiszi, hogy mindent ért.
Láttál valamit, magadtól "megfejtetted", és okosakat próbáltál írni vele kapcsolatban, meg persze butaságokat állítottál a Windowsrról a látott route parancs alapján.
Gratulálok!

Mindegy, a fenti szintaktika magáért beszél; tanulmányozd!

De tartozhattak, mivel a nem az ő MAC address-ükre érkező csomagokat - normál esetben - figyelmen kívül hagyják a hálózati kártyák, így max. az ARP csomagok egy részéből kaphattak a többi hálózattól amivel szintén nem foglalkoztak/foglalkoznak, mert az IP alapján meg kiderül, hogy szintén nem nekik szól.

Van amikor van értelme különböző hálózatba rakni a gépeket. (Pl. ha egy olyan konfigurációt akarsz tesztelni ahol VLAN-ok lennének, de a switch még nincs meg.)
---
Ha a géped a 10.0.0.2/8-as IP címmel rendelkezik és el kell küldenie egy csomagot a 192.168.0.5-nek akkor neki KÖTELESSÉGE a default gateway-nek adni a csomagot, mert nincsenek egy hálózatban. Ha azt akarod, hogy a 192.168.0.0/24-es hálózattal is kommunikáljon a géped közvetlenül akkor nem elég egy L2-es hálózaton lógnotok, hanem a gépednek rendelkeznie kell egy IP címmel abból a tartományból is. Ha megkerülöd ezt akkor az nem szabványos működés. Persze, működhet olyan, hogy mind a két géped megpróbálja ARP-pal kideríteni a másik hálózatba tartozó gép MAC address-ét és a gateway helyett neki címezni azt (másik IP tartományból származó forrás IP-vel), de nem szabadna így viselkedniük!
Rengeteg hibát jelenthet.

Nyilván tartozhattak, csak a mondatot nem fejeztem be; lazulok én is...

Tehát pontos megfogalmazásban:

CIDR előtt nem volt olyan, hogy egy datalinken logó node-ok különboző hálózatba tartozhattak, ha közvetlenül kommunikálni akartak egymással. (Közvetlen kommunikáció alatt azt kell érteni, hogy nincs köztük semmi, csak a datalink.)
Ez akkor tisztázva van, ugye?

Vegyük akkor most a CIDR bevezetése utáni állapotot!

Ha a két node azonos datalinken van, akkor közvetlenül tudnak kommunikálni akkor is, ha egyik nodenak sincs olyan interfésze, amelyik a másik hálózatába "lógna".

Semmi más nem kell a kettőjük kommunikációjához, pontosan elég, ha van egy-egy útvonal mindegyik útvonaltáblájában a másik hálózat felé.

Ez nem szabványtalan!
Nagyon szabványos működés, ugyanis az IP nem hálózati interfészek alapján rútol, hanem útvonaltábla alapján!

Ezt úgy látom, elég nehezen emészti meg az itteni társaság; bevallom, tudni nem tudtam, csak sejtettem, hogy így lesz, és bejött. De majd mostantól mindenki tisztában lesz ezzel is, és ez jó dolog.

Amúgy ez a kötelessége dolgot honnan veszed?
Idézlek:
Ha a géped a 10.0.0.2/8-as IP címmel rendelkezik és el kell küldenie egy csomagot a 192.168.0.5-nek akkor neki KÖTELESSÉGE a default gateway-nek adni a csomagot, mert nincsenek egy hálózatban

Ki mondta ezt neked, vagy hol olvastad?

Melyiket?
Hirtelen ezeket találtam a gépemen:
RFC 1467 - Status of CIDR Deployment in the Internet
RFC 1517 - Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR)
RFC 1518 - An Architecture for IP Address Allocation with CIDR
RFC 1519 - Classless Inter-Domain Routing (CIDR) an Address Assignment and Aggregation Strategy
RFC 1817 - CIDR and Classful Routing
RFC 4632 - Classless Inter-domain Routing (CIDR) The Internet Address Assignment and Aggregation Plan

Ooooo. A CIDR az pontosan a Classless INternat Domain Routing-ra vonatkozik. Ami valojaban azt jelenti, hogy az elotte hasznalt A,B,C osztalyu halozatok helyett tetszoleges netmaskot megadhatsz. Tehat szakit a hagyomanyos oldschool filozofiaval, mivel az osztalyozott halozatok mennyisege es a keletkezett igenyek mennyisegeben mar szignifikans kulonbsegek mutatkoztak.
Szoval a nem osztaly alapon routolaskor a netmask meg igenis szamit! Csak mostmar nem hivjuk a 10.xxx.ccc.vvv-t A osztalynak.
De attol meg illik nem egy halozatban levo eszkozzel nem kommunikalni;)

Ezt inkabb hivjuk bugnak, de ha dokumentalva van, akkor felolem lehet ficsor is.

A netmask nem szerencsés elnevezés a rútolás esetén.

Ketté kell választani a hálózati maszkot és az útvonalbejegyzésnél használt maszkot. A két maszk ugyanis teljesen független egymástól.

A hálózati interfészeknél megadott maszk azt határozza meg, hogy egy interfész IP-címéből mennyi jut a hálózatra, és mennyi jut a node azonosítására. Igazi jelentősége az alhálózatok kialakításánál van, egyébként majdnem semmi, ezért hívják alhálózati maszknak.

A CIDR előtt feltétel volt hogy az azonos linken lévő node-ok azonos hálózatcímmel rendelkezzenek.
Ez azért volt így, mert az akkori IP-rotokoll csak a hálózatcím alapján rútolt. Ez egyszerűsítette a rútolási algoritmust, azonban kötelezően az azonos datalinkre kapcsolt node-oknak azonos hálózatcímmel kellett rendelkezniük.

A routing table pontosan így nézett ki: 

<network, gateway, flags>

Sehol egy maszk, csak hálózatcím, és gateway, meg egy flags-oszlop. Fantasztikus és frappáns algoritmus épül rá, és az a fantasztikus benne, hogy ennyi információból + pár soros algoritmussal meg volt oldva az IP-protokol.

A CIDR bevezetésével ez a korlátozás teljesen megszünt; az IP csak és kizárólag az útvonalbejegyzés alapján végzi az útválasztást. Az útvonaltábla az OSPF mintájára ki lett egészítve egy maszkkal, amit a linuxos rendszereken helyesen generátormaszknak hívnat, windowsos rendszerekben egyszerűen netmasknak.

Az a kijelentésed, hogy De attol meg illik nem egy halozatban levo eszkozzel nem kommunikalni;) teljesen hibás a CIDR bevezetésétől tekintve, a CIDR előtt pedig nem lehetett más hálózatban lévő géppel kommunikálni azonos linkre kötött gépek esetén, tehát ott sem az illem határozta meg.

Bugról tehát egyáltalán nem lehet szó.

Azt kell megérteni, hogy az IP semmi mást nem néz a CIDR bevezetésétől, csak és kizárólag az útvonalbejegyzéseket. Ha talál illeszkedő útvonalat vagy útvonalakat, akkor azt, több esetén a legjobban illeszkedőt kiválasztja. (További is van, de most lényegtelen.)

Ennyi. Az IP csomagot továbbít, és ebben csak és kizárólag az útvonaltáblára támaszkodik. Pont.

Sajnos sokan nem jutottak el eddig az IP-vel kapcsolatban, és ezért korlátozásokat gondolnak olyan "helyeken", ahol nincsenek is korlátok. Ezért működik az, amit én a legegyszerűbb megoldásnak gondolok a megadott feladatra.

"ARP-ol minden csomagot"
Ez alatt mit értesz? Én úgy vettem észre, hogy az ARP request/reply csak egyszer játszódik le (mivel a statik route next-hop címe a sajátja ezért ARP-ol). Miután ez megvan és mindkét ARP táblában benne van a másik IP és MAC címe, már csak döntés kérdése, hogy engedi-e a kommunikációt az adott implementáció. A D-link printszerver és a Cisco engedi, Windows nem. Feltételezem amelyik nem az csak az "egy broadcast domain egy IP subnet" elvet követi, így növelve az átláthatóságot.
Ha nem így van javítsatok ki!

Az ARP-ol mindent alatt azt értem, hogy az ARP mindent csomagot megpróbál célba juttatni.

Persze arpolás alatt szigorúan lehet csak azt érteni, hogy egy ARP-kérés fog kimenni a linkre, de most arra használtam, hogy az arp megkap minden csomagot az IP-től, hogy próbálja meg célba juttatni.

A kérdés arról szólt, hogy mi a legegyszerűbb módja annak, hogy elérd a felvázolt környezetben a printerszervert. Ezért a gányolás nem állja meg a helyét ez esetben.

Ennél egyszerűbbet én nem tudok: 

   route add 192.168.0.10 mask 255.255.255.255 10.0.0.41

Természetesen, ha a feladat része, hogy kikapcsoláskor ne vesszen el az útvonal akkor is marad ilyen egyszerű a megoldás. 

   route  -p add 192.168.0.10 mask 255.255.255.255 10.0.0.41

Most komolyan, téged fizet vki ezért a jó témákért? Vagy pont hogy nem fizetnek és ráérsz nagyon? Hála Istennek a Wifis kérdésed kifulladott, de most nyomok neki egy up-ot, ha vki colléga nem elég fáradt, akkor ezt a kettőt olvassa el, garantáltan guru meditation lesz :)!

ki is próbáltad és működik?

http://www.microsoft.com/resources/documentation/windows/xp/all/proddoc…
To add a route to the destination 10.41.0.0 with the subnet mask of 255.255.0.0 and the next hop address of 10.27.0.1, type:
route add 10.41.0.0 mask 255.255.0.0 10.27.0.1

Ez alapján, ha jól értem a
route add 192.168.0.10 mask 255.255.255.255 10.0.0.41
azt jelenti, hogy a 10.0.0.41-es gépre küldje a 192... csomagokat és majd az routolja tovább. Namost, ha a saját ip címemre routoltatom a csomagokat, akkor hogy fog odakeveredni a megfelelő helyre?

Természetesen nem össze-vissza beszélek; működik.

A route add 192.168.0.10 mask 255.255.255.255 10.0.0.41 a következőt jelenti:

A 192.168.0.10-es hálózatba a 10.0.0.41-es interfészen keresztül visz az út.

Vedd észre, hogy a 10.0.0.41-es IP-címmel rendelkező gépen adod ki a fenti parancsot. A route van annyira intelligens, hogy rájön, hogy a 10.0.0.41 az egyik (jelen esetben az egyetlen) interfészéhez rendelt IP-cím.

Másképp fogalmazva pontosan arról szól a fenti útvonalbejegyzés a 10.0.0.41-es gépen, hogy a 192.168.0.10-es hálózat felé a 10.0.0.41-es interfészen kell kieregetni a csomagokat.

érdekes minden esetre.. szóval a dolog reprodukálásához elvileg egy switchre kell kötni a gépet és a prinsztszervert, beállítani két különböző ip tartományba őket s a routing által lehet böngészni a a gépen a másik ip tartományban lévő webes felületet.

vmware bridge módban nem működik ez (nem látta a host gépet hiába adtam meg route szabályt)

a gépeden nem ugye nem fut semmilyen szoftver ami natola... mert attól hogy a hop címe az enyém, még nem kéne hogy natolja a forgalmat, hanem meg kéne hogy akadjon. Ugyanezt a routing bejegyzést (tehát a te géped címét használva hopnak) egy másik gépen lefuttatva az is látja a webes felületet? Ha igen, akkor fut valami router szolgáltatás a gépeden :S

Kipróbáltam VMware-rel, és működik; természetesen a guestnek adott hálózati adapter bridge-módban kapcsolódik a fizikai hálózathoz, és semmilyen szoftver nem fut a gépen, ami befolyásolná a dolgot, továbbá nincs engedélyezve a Windowson a rútolás.
Tehát teljesen mezei, normál környezet, mind a VMware-es virtualizált, mind pedig a fizikai.

(Arról volt szó, hogy a printerszerver és a hoszt azonos linken (szegmensben) vannak, tehát eleve csak akkor működik a dolog. Ha NAT-olást belekeverjük, akkor már nincsenek azonos linken, hiszen egy rúter került közéjük, ezért nem fogják megtalálni egymást a layer2-es kommunikáció során.)

Ugye D-Link printerserverrel próbálod?!

sorry a nat-ot nem kellett volna ide kevernem.

Amúgy route add nélkül is kipróbáltad? Az is lehet, hogy a titok nyitja az, hogy van route a hálózatban (gw) a 192-es tartományra. Az itteni hálózatunkon pl van routolás 10... címekre, mert van néhány eszköz aminek nem jutott már a normál tartományból ip.

Természetesen az új útvonalbejegyzés csak akkor kell, ha nincs más, a 192.0.0.0-es hálózat felé vezető direkt kapcsolt hálózati út.

Ha van, akkor kitalál a csomag.
De nonszensz lenne, mert minek lenne direkt ataccsolt hálózat az útvonaltáblában, csak úgy?

Tehát ha lenne legalább a 192.0.0.0-es hálózatba útvonalbejegyzés, akkor az nyilván egy gateway felé mutatna, tehát nem segítene semmit.

Végkövetkeztetés: "route add" nélkül nem működne.

Komoly teljesítmény amit itt előadsz.

Azt tudtad, hogy a nevetés a szégyenérzet egyik megnyilvánulási formája?
Bizony!

Mert gondolom, hogy nem a boldogsághormon teng túl benned, amikor ezt a szálat olvasgatod.

Szóval még mindi a leégéstől félsz, vagy tudsz valami érvet is írni?

Mi az hogy saját IP használata?

Az IP, az egy protokoll, és általában minden node-on jelen van, azaz minden node futtat IP-t.

Szóval nem kellene öasszekeverni az IP-címmel, mert nagyon nem azonos a jelentésük. Vagyis az IP-címet nem lehet IP-nek rövidíteni.

Ha azt írod, hogy IP, akkor az nem tud mást jelenteni, mint az IP-t, ami a node-on fut.
Remélem, nem értettelek félre!

Amúgy az előző válasz alapján már érthető, hogy miként folyik az oda-vissza kommunikáció?
És a broadcast cím érthető így már?

Saját IP-cím, csak álmosan nem ír ki mindenki mindent olyan részletesen, mint egyes tudálékos alakok.
Köszönjük, hogy rávilágítottál a Windows-os route parancs egy érdekes, a "származási helyétől" eltérő működésére, ismét nagyon-nagyon okosnak tarthatod magad. Az "okosnak tartja magát" egyébiránt nem keverendő össze az okossal, ugyanis a kettő mást egészen mást jelent. Okos az, aki tudja, hogy mit nem tud - itt a kollégák nemtudták/tudtuk, hogy a windows-on a route parancs így működik, de legalább most tőled (Oh, mester!) megtudhattuk, és végre fény gyúlhatott setét agyhelyünkön a windows-os "route print" kimenetének értelmezésével kapcsolatban.

A fentiek ellenére az egész macera elkerülhető lene, ha a D-Link szappantartója rugalmasan állna hozzá a hálózathoz, ahova berakják: Hogy most a rarp meg a dhcp milyen sorrendben, az elején, az lényegtelen, ha egyik sem megy, no akkor tessen kitalálni, hogy hogyan tud egyszerűen a beüzemelést végző által megadott (!) ip-címre beállni úgy, hogy semmiféle extra, az általánostól eltérő parancsot ne kelljen kiadni, ne kelljen semmit sem telepíteni - egyszerűen csak kiadni egy parancsot egy tetszőleges, hálózatba kapcsolt gépen.

Nagyon jó kérdés, de tényleg, ha a kérdésed arra vonatkozik, hogy a printerszerverről hogyan jön vissza a csomag!

Pontosan ezért bátorkodtam elindítani ezt a posztot, hogy dícsérjem a D-Linkes mérnökök eszét, mert visszajön.

Tehát a printerszerveren nincs felvéve default gateway, és teljesen más IP-hálózatba van kötve, mint a hoszt.

A hosztról a csomag eljut a printerszerverig, hiszen felvettünk egy útvonalat a printerszerver hálózatának irányába. Ezért az IP átadja a hoszton futo ARP-nak a csomagot, az meg megarpolja a 192.168.0.10-es IP-címet. Az arpolás sikerrel fog járni, hiszen a printerszerver és a hoszt azonos datalinken vannak; vagyis azonos szegmensben.

A visszaút érdekesebb, mert azt gondolnánk, hogy a printerszerveren is kell lennie egy útvonalnak a hoszt irányába, azaz a hoszton végzettekkel analóg beállítást kellene elvégeznünk a printerszerveren. Csakhogy printerszerveren futó IP útvonaltáblájához nem nagyon férünk hozzá, ill. egy bejegyzést tudunk bele erőltetni a default gateway mező kitöltésével. De most nem ér kitölteni a default gatewayt, mégis visszajön a csomag a D-Link printerszerverről.

Azért talál vissza, mert a D-Linken futó IP, ha nem talál útvonalat a továbbítandó csomag számára az útvonaltáblában, akkor is átadja az ARP-nak a csomagot, hátha tud vele valamit kezdeni!

Tehát útvonalbejegyzés nélkül is megkapja a printerszerveren futo ARP az IP-től a csomagot.
Ez van!
És ez nagyon jó, mivel úgy lehet kommunikálni egy eszközzel, hogy nem kell az eszközön semmit állítani, mégis visszajönnek tőle a csomagok! Persze az eszköz IP-címét tudni kell.

Lehet, hogy így van, és ha nincs megadva default gateway, akkor is felvesz az eszköz beállítóprogramja egy 0.0.0.0-ás célcímet, a gateway oszlopot viszont üresen hagyja ez esetben.

Sőt, azt hiszem pontosan így van, mivel ez esetben az IP-n semmit sem kell módosítani!!!

Megadtad a hiányzó láncszemet!
Köszönöm ezt a hozzászólást! Meg persze a többit is mendenkienk!

"Ezt ismerhették fel a mérnökök, amikor úgy döntöttek, hogy olyan esetben, amikor egy IP-csomagot olyan címre kell küldeni, ami nincs benne az útvonaltáblába, egyszerűen kiküldik a linkre!"

Ezek szerint nem nagyon forgatták az idevágó RFC-ket :)

És ha van switch/router a host és a ps között? elhal, ráadásul martian packetként logolódik...

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

Azért fussunk egy kört - nem annyira gázos az implementáció, csak érdekes. A printerszerver nem fog kapcsolatot kezdeményezni, ő csak válaszol. L2: jön egy keret, az ő mac-címe, mint cél. Felszedi. A saját címe utáni 48 biten a küldő mac található, azaz megvan, hogy a válasznak hova kell visszamennie: ip cím, mac, interfész (ez csak egy van) összerendelés kész.
A switch azt fogja látni, hogy van egy keret, aminek a forrása x, a célja y, az adott porton, ahol az x van, ott jött be, és ki fogja tenni arra a portra, ahol az y-t legutóbb hallotta/látta. ha sehol, akkor persze mindenhova. Router esetén persze más a helyzet, ott "illik" eldobálni azokat a csomagokat, amiknek a forráscíme a router ismeretei szerint nem arra van, ahonnan a csomag érkezett, de nem ez volt a kérdés.

Csak azért válaszolok, mert nagyon teccik, ahogyan csípőböl tüzelsz. Tipikus.

Ha nem ismeresz valamit, akkor inkább maradj csenben, mert akkor bölcsebbnek látszól; a te esetedben, ahogy észrevettem, fontos, hogy mit gondolnak rólad mások.
Ezért inkább maradj csendben, ha valamit csak érintőlegesen ismersz!

Az egyszerűen kiküldi egy költői túlzás; félre szerintem csak az értette, aki nincs tisztában a IP működésével.

Az IP természetesen ez esetben is az ARP-nak adja a virágcsokrot (a három szál virággal).

Vagyis: nem fog kerineni semmilyen csomag, mert az ARP küldi ez esetben is, ki mint minden esetben.

Állati okos vagyok, nem?!

Mi az, hogy az arp küldi...? Az ARP egy protokoll, az nem küld semmit. A keretet a mac alapján juttatjuk célba az ethernet hálózaton, ez igaz, amiket meg az ARP protokollal lehet begyűjteni, ha kapcsolatot akar valaki kezdeményezni, illetve a beérkező IP-csomag keretének fejlécéből lehet kibányászni a forrás mac-címét, az ip-fejlécből meg az ip-címét.

Az nem lényeges, hogy én mit gondolok arról, hogy mennyire nem értesz az IP körüli dolgokhoz, mivel nem igazából vagyok tagja az itt lévő társaságnak; én csak amolyan betérő alak vagyok.

Viszont az itteni "haverjaid" előtt nagyon lejáratod magad; azok előtt, akik hozzáértők az itt elhangzottakhoz.

Amiket hozzászóltál, az alapján ugyanis jól látszik, hogy azt a látszatot akarod kelteni, mint aki ehhez is ért, de nem, nem értesz hozzá, és akkora ökörségeket írkáltál itt össze-vissza, hogy aki a haverod, az nyilván fogta a fejét, hogy zeller nem hiába kapta a nevét egy zöldségről.
Bocs, de ez nagyon ül; az, hogy zeller a nikneved.

Amit ajánlani tudok: nézd át az IP működését, és nézz körül, hogy egyes implementációkban az IP hogyan műküdik együtt az ARP-pal! (A Windowsban pl. az ARP küldi ki a csomagot; persze a datalinken keresztül.)

Nem mintha zeller a legkisebb mértékben is rászorulna arra, hogy bárki is védelmébe vegye, sőt. Valóban lehet, hogy féreértelmez dolgokat itt-ott, de muszáj megjegyeznem, ez a hozzászólásod ha lehet, még nagyobb öngól, mint a múltkori "önimádós".

Valaki 1x felébreszthetne, csak nehogy fájjon.
Tényleg szánnivaló vagy az egész topicoddal, aki itt óriási tévedésben leledzik, az sokkal inkább te vagy.

Tanulj még.

Nem tudtam, hogy a topikindítás tekintéllyel jár.

Ez a baj a linuxosokkal, az hogy tekintélyelvűek vagytok.
Ez nyilván abból fakad, hogy sokan attól, hogy Linuxhoz nyúlnak, már egyfajta felsőbbrendűséget éreznek, mivel nem a szokásos rendszert noszogatják. Ez egyszerű pszichológia: a linuxhoz kevesebben értenek, mint a Windowshoz, tehát ha én Linuxozni kezdek, akkor olyan dolgokat tanulok, amiket a szomszéd Jóska nem tud. Tehát okosabb lettem a Jóskánál. Ha Jóskánál okosabb vagyok, akkor Pistánál is, mert ő is csak a Windowshoz ért.

Érdekes, de tényleg.

Aki meg IBM kábelek rakosgat egyik polczról a másik polczra, az meg pláne nagy szakértő!
(Hátha valaki nem érti: az IBM az még különlegesebb, mint a Linux, még kevesebben értenek hozzá.)

Ugyan nem végeztem közvélemény kutatást, de az a sejtésem, hogy 1000-10000 D-Link printerszerver felhasználó közül 1-2 ember kerülhet olyan helyzetben, hogy 5-10 percre sem bezárható dokumentumokkal kell dolgozni. Számukra ez a megoldás nyilván nagyon fontos. Pláne, ha -- valamilyen aljas indokból kifolyólag -- még resetelni sem tudják a szervert.
Ha vállalkozásom lenne, akkor az ilyen fontos emberek számára legalább két számítógépet biztosítanék.
Egyébként tudok féllábon állva fütyülni, és közben kacsintok is. De még csak bal szemmel megy a kacsintás.

-----
"Fontosabb egy jó szomszéd, mint egy távoli rokon." (Árvízkárosult, 2010)

Nem érted a lényeget.

A D-Link mérnökei felismerték azt, hogy semmi különlegeset nem kell csinálni ahhoz az eszközükön, hogy ha nincs a gateway mező kitöltve az eszköz beállító képernyőjén, akkor is képes legyen az eszközük egy másik hálózatban lévő eszközzel kommunikálni, ha az eszköz azonos szegmensben van az ő eszközükkel.

Ők úgy gondolták, gondolom, hogy ez jó dolog, és amúgy semmilyen szabványtalan működéssel nem ruházza fel az eszközt.

Mindössze arról van szó, hogy egy teljesen szabályos útvonalbejegyzést raknak az útvonaltáblába, ha a felhasználó nem tölti ki a gateway mezőt. Ennyi.
A többi az IP dolga, és az IP totál ugyanúgy működik, mint minden más node-on.

Hidd el, értem a lényeget. Sok-sok ezer ember közül egy olyan van, aki nem képes resetelni a nyomtatószervert. Neki(k) ez egy jó megoldás. A többiek rácsodálkoznak: Jéééé, így is lehet. (Jééé, szakállas nő.)

-----
"Fontosabb egy jó szomszéd, mint egy távoli rokon." (Árvízkárosult, 2010)

"A D-Link mérnökei felismerték azt...", "A mérnök nagyon korrekt a D-Linknél"

Nos, ledokumentálták ezt a működést?
Beszéltél/leveleztél a d-link-es mérnökökkel erről?
Tudatos cselekmény volt a részükről kivitelezni ezz a működést? Netán egy bug a windows hálózatkezelésében?

Érzésem szerint találtál valami bugot, ami tetszik neked és néha tényleg hasznos lehet, erre nyitottál egy topicot, hogy megmutasd milyen buták a többiek, akik nem ismerik a bugot és tudásuk szerint más az elvárt normális működés tcp/ip hálózaton.

De ez erősen szvsz.

A Windows hálózatkezelésében miért jelentene bugot a leírt működés?
H hosztra nincs korlátozva, hogy Windowst kell rajta futtatni; gondold azt, hogy Linux futa rajta!

A topik többek közt arra is irányult, hogy megmutassa, hogy ha két eszköz azonos datalinken van, akkor nem kell közéjük egy 3. node, hogy kommunikálni tudjanak.
A legtöbb rendszergazda azt hiszi, hogy kell.
Ettől ők nem buták, nem ezt állítom, csak felületesen ismerik az IP-t.

Kistökös, lehet hogy a zellerkrémlevest szereted, de idetévedőként nem kéne kóstolgatnod. A Júingokat a Dallas óta rühellem. Köszi.

Ja, és köze nincs a nicknevemnek a zöldséghez, még akkor sem, ha elsőre úgy néz ki. Mint ahogy az Address Resolution Protocol-nak (rfc 846) a csomagok kiküldéséhez - legalábbis normális esetben...

Kiborult a KV-m vazzz... legalábbis kiborult volna, ha éppen lett volna előttem, de mivel már nem KV-zok.... na mind1. Fáradt vagyok, már. Eddig is szétröhögtem ezt a szálat, de ez végkép betett.

------------------------------------------
"Nincs ez el**szva, csak másra lesz jó!"

Te nagyon hiú ember vagy, ugye?

Attól, hogy rfc 846-kkal fűszerezed a hozzászólásod, mit vársz?
Elismerést, hogy a sok zöldség ellenére azért te mégsem vagy sárgarépa.

Ezzel már nem érdemes erőlködni; aki végigolvasta, az úgyis elkönyvelte, hogy csak elképzeléseid vannak, a többit meg a wikipédiáról szedted össze.

A hozzászólások közt valóban volt szó a "routing módosításáról", csak az nem volt egyértelmű, hogy ez mit jelent a hozzászóló szerint.

Ugyanis betett egy rútert a két node közé; ezt rajzolta pl. trey.
Ez valóban rútolás, de nem a legegyszerűbb.

Az a helyzet, hogy topik jelenlegi állapota szerint már mindenki rávágja, hogy igen, semmi különleges nics ebben a topikba, hiszen mindenki ismeri az IP-t.

Cdsak az a baj, hogy a topikon végigmenve egyértelmű, hogy senki sem gondolt elsőre arra, amire a topik rávilágít az indulásnál.

( arpi_esp v | 2010. 08. 10., k – 00:14 )

ize miota van mernok a dlinknel? :)
amiket az utobbi evekben lattam soho dlink fw-ket az mind a chip (SoC) gyartotol szarmazott (realtek,broadcom,trendchip), a dlinkesek csak a webdesignt modositottak, meg ekozben neha beleraktak 1-2 bugot.

A'rpi

( gergov | 2010. 08. 11., sze – 21:34 )

Aha. Szóval ez nem bug, hanem feature.
Megmondom őszintén, szerintem ez nem zsenialitás, hanem gusztustalanság. Képzeld el ezt egy olyan hálóban, ahol van egy vékonyka vpn, aminek kutya kötelessége áttolni az összes broadcast csomagot a linkje másik végére is, akkor mi van? Ezt a viselkedést semilyen szabvány nem írja elő, sőt...
Emlékeztet arra, mikor még messze nem létezett a soho routerekben ppoe passtrough, vett egy haverom egy olyan routert, aminek a wan portja simán bridgelve (is) volt a lan portokkal (meg voltak egyéb érdekes dolgai, például az msn protokoll csomagjait előszeretettel küldte szét az összes bekapcsolt gép címére), aztán a srác bedugta a gépre, tárcsázta az ADSL-t, mint régen, és baromira örült magának, hogy "jé, némá', there I fixed it". Aztán rettentően csodálkozott, hogy mikor a másik gépről is megpróbált fellépni a netre, az elsőn ledobta, és a jó életnek nem tudtam neki megmagyarázni, hogy baromságot csinált. Egyszerűen nem értette meg, hogy a router nem olyan, mint a 220-as elosztó, hogy bedugdossuk, aztán folyik a net mind a két gépbe, mert "há' az előbb még működött, akkor most mé' nem jó?".

Ha a felhasználó kitölti a def.gw mezőt a ps-en, akkor a szegmensen kívüli csomagokra tud válaszolni a ps.
Ebben mi a gusztustalan?

Ha a felh. nem töl. ki a d.gw mezőt, akkor a szeg. kiv. csomagokra nem fog tudni v.szolni a ps.
Minden ps így működik, ebben mi a gusztustalan?

Segmensen belül minden eszköz képes egymással kommunikálni.
Mi ebben a gusztustalan?

Az a baj, hogy a legtöbb rendszergazda nem ért az IP-hez.
Nem tudják, hogy az IP miként "tolja" ki a "kábelre" a csomagokat.
Elképzelik, mint zeller, aki IBM-mérnök, de az elképzelésük általában messze van a valóságtól.

Attól gusztustalan, hogy a class B privát hálódat telefossa broadcast csomagokkal, s 64ezer gépet floodol folyamatosan a discovery-je egy alhálón. de ha kisebbre van csinálva, akkor is 253 gépet szopat folyamatosan.

ezt ugy szoktak elkerulni, hogy switchen a ps kulon vlan, csak egy szerver eri el, s a szerver csinal smb-s printer share-t. igy a nyomtato is transzparensen cserelheto, nem kell 8ezer embernek uj ps-t felvennie nyomtatonak.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

1) a 192.168... az class b
2) céges hálókon általában sok gép van (most ne az otthoni hálózatodra gondolj)
3) az ilyen bonjour jellegű broadcast cuccoknak az a lényege, hogy presence-t sugároz, aminek - nomen est omen - rendszeres időközönként meg kell történnie

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

gondolmo most CCNA-ztál, mert még bekavar a CIDR-nem CIDR dolog. De tuti vizsgáztál az osztályos ip kiosztásból, úgyhogy vedd elő az internetet. de ne a windowst, ahol a /24 a default miden ip-re az ipconfigban, amíg át nem írod...

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

A mask?
Melyik, csak hog tudjam, hogy miről folyik a disputa!

Subnet maszk?
Az az alhálózatot határozza meg, nem az osztályt!

Akkor maradt a netmask.
Az meg CIDR-rel lett bevezetve, tehát osztályt nem igazán tud meghatározni, mert el lett törölve az osztály. Amit a netmask meghatároz, az az illeszkedés, nem az osztály.

Több maszkról nem tudok.

Úh bazmeg.
Mesterem, akor mondd meg, mi a külömbség a subnet mask és a netmask között.
Mire való a subnet mask, és mire való a netmask?

Azért ezeket fusd át:
http://en.wikipedia.org/wiki/Subnetwork
http://www.computerhope.com/jargon/n/netmask.htm

(Egyébként sehol nem használok linuxot.)

Arra nem vagy képes, hogy leírd, hogy mi az, ami nem klappol, mert nyilvál nem értesz hozzá.

Elképzeléseid vannak; burkoltan, de azért jól érzékelhetően jelezted, hogy félsz a leégéstől, gondolom ezért inkább megkíméled magad, és nem koczkáztacc meg leírni pár nagy ökörséget.

Amúgy miért félsz ennyire a leégéstől?
A psc mit árul el belőled?
Nekem semmit, szóvál bátran kezgy bele!

Ostba, öntelt és barom.
Ez lennék én?

Tényleg nem akarom senki idegeit borzolni, de ha már ilyen kedves jelzőket használsz, akkor talán nem gond, ha ezzel kapcsolatban is írok egyet.

Azt figyeltem meg az embereknél, ha egy baromnak azt mondod, hogy te barom!, akkor nagyon zokon veszi.

És rájöttem, hogy mi ennek az oka!
Hát mert tényleg az!

Ha egy rusnya dögnek azt mondod, hogy te rusnya dög!, akkor minimum megsértődik; ha nem, akkor még barom is szerencsétlen. De az is lehet, hogy benned van a hiba, tehát nem rusnya, csak nincs izlésed.

Ezek nagyon érdekes dolgok!

Szerkesztve:

Ja, a mosoly lemaradt a végéről...
Pótlom: :)
(Még valaki azt hiszi, hogy tényleg barom vagyok!)

Jockey, mondod itt a f*sszágaidat, nem tudok vele mit kezdeni.

Nem tudom, hogy te játsszod-e a hülyét, vagy tényleg az vagy-e, minden esetre nagy örömömre szolgál, hogy most már válaszolsz a postjaimra, merthogy az elmúlt hónapban nyitott topicjaidban az értelmes, szakmai kérdéseimet megválaszolatlanul hagytad.
Megtisztelve érzem magam, hogy egy ekkora nagy szagember most már leglább válaszra, sőt diskurzusra méltat, komolyan!

Csak ismételni tudom magam: Taníts, Mester!

Üdv:
régi barátod,
Cliff
http://www.whenmoviesweremovies.com/Kercheval01.jpg

ui.: ne idegeskedj, nem tudsz az olajtársaságodra koncentrálni!

Jockey, nem válaszoltál a kérdésemre. Ne terelj.
Nem érzed rém cikinek egy tizen-x éve lefutott szappanopera főgeci zereplője után elnevezni magad?
Ennyi erővel lehetne a nicked mondjuk ckent - mondjuk az nem annyira gáz, mint a dallas után nicket adni magadnak. :D

Vagy ez ilyen kissebbségi komplexus-komplenzálása dolog? Tehát hogy nem sikerülnek a dolgaid, pénzed se nagyon van, nők se nagyon állnak szóba veled, és ezért beleképzeled magad jockey ewing bőrébe, és akkor neked jobb lesz?
Elképzeled, hogy gazdag olajmágnás vagy, dörzsölt üzletember, és napi 4 különböző muffot szúrsz meg?

Légyszives válaszolj a kérdésre, ne terelj folyton.
Nem érzed cikinek egy tizen-x éve lefutott szappanopra főgeci szereplője után elnevezni magad?
Esetleg a fentebb vázolt komplexus áll a háttérben?
Te vagy most a nagy Dzsoki Júing, a pénzes olajmágnás, aki begurul a mercédesével és megszúr minden muffot a bárban?

( bambano | 2010. 08. 12., cs – 02:10 )

Szoktak csinálni arp huntingot egyes eszközökben, azaz el kell kezdeni pingelni egy ip címet a hálózatban, ami biztosan nincs ott, és az eszköz figyeli, hogy van-e válasz. Ha x arp/ping kérésre nincs válasz, akkor felveszi magának azt az ip címet.

( dj | 2010. 08. 12., cs – 10:45 )

Engem egy érdekel. Mennyire megbízhatóan működik ez a print szerver. Normál működés közben, gányolás nélkül. Egy típust is írhatnál, mert éppen most akarok venni egyet és hallottam, hogy a print szerverek nem éppen megbízhatóak.

( kukukk v | 2010. 08. 16., h – 13:28 )

Egyszer faraszto egy topic...

Sic Transit Gloria Mundi

Még mindig nem értem, amit írtál: "Egyszer faraszto egy topic..."

Mit állítunk?
Fárasztó.

Mi fárasztó?
Egy topik.

Hányszor fárasztó?
Egyszer.

Lehet, hogy rosszul elemzem, azért nem értem?
Vagy csak lazán használtad a nyelvet, és azt akart írni, hogy Fárasztó egy topik, és az egyszer valahogy ott maradt ez elején. De hogyan került oda, az rejtély.

Tokeletesen elemezted. Egyszeri olvasas utan, farasztonak talaltam a topicot. De mivel nem szandekozom tobbszor atolvas, igy nem lehet tudomasom arrol, hogy masodszori olvasasra milyen hatast valt ki. Igy meglehet, hogy igazad van, es masodszorra mar feludules. De mivel en ezt soha nem fogom megtudni, ezert irtam azt, hogy egyszer faraszto. Ugyanis nem szeretnek felrevezetni masokat olyan altalanos kijelentessel, hogy tobbszori olvasas utan is faraszto a topic.
Remelem most mar eleg erthetoen fogalmaztam, es elnezest kerek korabbi felreertheto kijelenteseimert.

Sic Transit Gloria Mundi

Kezdem érteni, hogy a linuxosok közt a menőzés a divat.

Hozzászoltok valamihez, de amikor konkrétumokat kellene mondani/írni, akkor megáll a tudomány.

Leszólni, beszólni, röhögni.
Végül is, fiatalság bolondság; aki meg öregebb, és még mindig ezt műveli, az meg megragadt egy szinten.

Hogy az itteni szakemberek rávilágítsanak arra, hogy mi az, ami nem "klappol", vagy ha renben van minden, akkor mondják azt, hogy ok.

Eddig azonban csak annyi jött, hogy baromságokat írogatok, vagy jobb esetben szabványtalan, az amit bemutattam.

De konkrétumot senki nem mond, pl. egy adott dokumentum adott bekezdése, stb, hogy ez és ez a működés nem elfogadott, stb.

A célom egyszerű: tanulni.

( azbest | 2010. 08. 16., h – 22:17 )

no, csak hogy tisztábban lássunk pár dolgot, kérlek hogy másold be ide (vagy ha hosszabb, akkor pastebinre) a következő parancsok kimenetét:

tracert 192.168.0.10

route PRINT