run=>cmd [enter]=>nslookup xxx.xxx.59.xxx

Ik denk dat het gewoon een van je andere netwerkapparaten is die activiteit genereert bijvoorbeeld in het kader van bestands- en printerdeling voor netwerken?
Sowieso zijn die inkomende activiteiten die automatisch geblokt worden meestal niet interessant. Gewoon een ping-verzoek over het algemeen.

Dit heb ik uitgevoerd. Als antwoord krijg ik:

*** Sitecom.router kan xxx.xxx.59.xxx niet vinden: non-existentie domain
Viel mij op dat er nog een andere ip is geblokkeerd welke in xxx.xxx.62.xxx zit maar daarvoor geldt hetzelfde als ik deze bij run invoer

Wel vond ik opvallend: ik maakte een typefouten waarbij ik twee cijfers in het ip adres omwisselde wat opleverde

*** Sitecom.router kan xxx.xxx.59.xxx niet vinden: query refused


Ik maak gebruik van bestand- en printerdeling, maar mijn router deelt de ip adressen op xxx.xxx.0.xxx uit en niet op xxx.xxx.59.xxx daarom vind ik dit opvallend (als dit niet zo raar is hoor ik het natuurlijk graag. Heb daar namelijk niet heel verstand van). Maar daarom wil ik dus weten waarvan het ip adres afkomstig is

Tsja, dan moet je het niet verstoppen met xxxx.xxxx.59.xxx .

Zomaar een gok : 169.254.59.xxx ?
Dat is een adres(reeks) [169.254.x.y] wat een apparaat zelf neemt als het geen dhcp antwoord krijgt.

Zijn het wellicht multicast adressen?
Of iets van BlueTooth?

Sorry ik was iets Te veel bezig met dat mijn router de ip adressen op wen andere waarde uitdeeld. Het gehele up adres is inderdaad 169.254.59.219.

Zou dat kunnen betekenen dat de router niet helemaal correct werkt/ of iets als bijvoorbeeld de firewall Te streng heb ingesteld
waardoor wen apparaat geen dhcp antwoord krijgt? De printer zal het denk ik niet zijn aangezien die via de USB port op de betrefende pc zit aangesloten en van daaruit is gedeeld met de rest van het netwerk.

Het betreft wen desktop PC welke geen BlueTooth ondersteund. Of her iets van multicast adressen is weet ik niet. Daar moet ik me eerst even in verdiepen wat dat inhoudt.

Dat adres betekent dat je een device op je netwerk hebt dat ingesteld staat op DHCP maar geen ip nummer kan bemachtigen; Het kan bv. zijn dat je range erg klein is en dus geen nummers beschikbaar zijn. Firewall settings gelden niet op een router die DHCP intern doet, daar zal het niet aan liggen.

Dat zijn idd dhcp poblemen.
Loop de settings even na op je router.

Als een pc geen ip adres krijg van de dhcp server van je router (of andere dhcp server), zal die zelf een ip adres genereren.
Die ligt dus in de range 169.254.0.1 t/m 169.254.255.254.
De laatste 2 "delen" van je adres wijzigt iedere keer. Vervolgens broadcast die pc dat ip adres idd om anderen in de gehele range te vinden.

Overigens is deze range niet routeerbaar. Er zullen nooit verbindingen vanaf het internet zijn met deze ipadressen.

De ip range gaat van 196.168.0.100 tot 196.168.0.200. 100 ip adressen is ruim voldoende (zoveel apparaten die verbinden kunnen Worden met wen netwerk heb ik nog niet eens). De ik heb de PC welke doormiddel van WiFi verbonden wordt een vast ip adres gegeven. Voor de rest staat bij DHCP informatie in de router het ip adres van de andere PC. In totaal zijn er dus drie ip adressen uitgegeven. 1 voor de router zelf en twee voor de twee computers. Weet niet of een van de andere apparaten welke ik noemde in mijn startpost een ip adres zou moeten krijgen van de router?

Wel opvallend is dat de vermeldingen van inkomende geblokkeerde verbindingen in het logboek van de firewall op de PC stopte nu ik de PC die via WiFi verbinding maakt een vast ip adres heb gegeven.

Ik weet niet of het zin heeft als ik morgen middag/ avond eens uitprobeer wat er gebeurd als ik de router naar fabrieks instellingen reset en geen static ip meer instel

Mijn bericht van 00:15 uur was ik aan het schrijven terwijl die van jouw geplaatst werd mcb.

Ik zal morgen middag/ avond de instellingen van de router in het betreffende netwerk nalopen, en eventueel een reset uitvoeren naar de fabrieks instellingen van de router.

Ook bedankt voor de achtergrond informatie. Nog een tweede reden begrijp ik waarom het ip adres niet vanaf internet kan zijn aangezien deze in een range valt welke niet routeerbaar is.

Ha kraai,
Het dhcp-antwoord komt normaalgesproken van de router. Kan het zijn dat de router (tijdelijk?) heeft uitgestaan?
Bijv. om daarmee de internetconnectie te onderbreken?

Als je een apparaat op het netwerk aanzet terwijl de router (die ook als dhcp-server werkt) nog uitstaat of nog niet helemaal is opgestart, dan zullen de op het netwerk aangesloten apparaten eerst uit zichzelf een 169.254.xxx.xxx adres aannemen, omdat er niet snel genoeg een dhcp-antwoord komt.

Je kunt dit verschijnsel voorkomen door eerst je router aan te zetten en rustig helemaal op te laten starten,
en pas daarna je andere apparaten aanzetten.
Of anders een vast IP-adres gebruiken i.p.v. dhcp. (dus waarschijnlijk heb je het al opgelost nu? ;-)

Mvg cluc-cluc

Inmiddels een herstel naar de fabrieksinstellingen van router uitgevoerd en opnieuw ingesteld maar de laptop dit keer geen statig ip adres gegeven. en ja hoor 169.254.59.219 wordt weer door de firewall op mijn andere pc geblokkeerd. Vreemd maar het is mij nu wel duidelijk dat het door de laptop komt. Bedankt voor jullie informatie, zonder was ik er zelf niet uitgekomen, of had het een stuk langer geduurd.

Nu heb ik nog wel de vraag, mijn pc krijgt dus geen ip van de DHCP server toegewezen begrijp ik/ ontvangt geen antwoord. Tenzij er een statig ip adres in ingesteld. Ik ga nog op zoek of ik kan vinden hoe dit kan, maar mogelijk dat iemand hier al op deze vraag een antwoord kan geven. Eventueel een defect bij de router?


Hoi cluc-cluc

De router heeft even uitgestaan maar het blokkeren van het ip adres geen zo'n 3 uur lang door, en zo lang doet mijn router er hoop ik toch niet over om op te starten. Overigen heb ik ook even gewacht met de PC aansluiten.

Bij sommige providers (ik meen Tele2) krijg je dit adres op het moment dat je router niet kan/mag verbinden met internet. Dit heb ik ook wel eens gehad toen ik mijn rekening niet op tijd had betaald.

Kijk even of de firewall op je laptop niet verkeer op UDP poorten 67 en 68 tegenhoudt.
Over deze poorten gaat dhcpverkeer.

Het betreft bij mij een eigen router welk in een netwerk wordt gebruikt welke niet met internet is verbonden, dus daar zit het probleem niet.


De poorten 67 en 68 staan niet weergeven in de lijst bij McAfee firewall dus als het goed is staan ze gewoon open. Opvallend is overigens dat in het firewall log op de laptop nu ook staat dat een inkomende verbinding is geblokkeerd van het ip adres 169.254.59.219. Vreemd lijkt wel alsof dat wanneer mijn PC op de switch zit en de laptop via WiFi met de router verbinding maakt ze elkaars ip adres niet herkennen.(hoort dit misschien gewoon zo) De PC heeft wel gewoon een ip adres gekregen van de DHCP server en geeft deze zelf ook weer. Als de laptop ook op de switch zit aangesloten via kabel gaat de onderlinge communicatie wel goed en wordt er niet 169.254,59.219 weergeven als geblokkeerd inkomend ip adres.

Ok, dan zal er waarschijnlijk een andere oorzaak zijn waarom je laptop het contact met de "router-dhcp-server" kwijtraakt
en daardoor dus zelf een IP-adres in de 169.154-range gaat verzinnen.
(WiFi-storingen misschien?... Zijn er bijv. meer WiFi-netwerken in de buurt die kunnen storen?)

En wat als je PC en laptop allebei eens op vaste IP-adressen zet? Is dat geen oplossing?
Mocht je daarna nog steeds die 169.154 etc. zien, dan moet het haast wel van buitenaf komen. Dus dat weet je dan.

Mvg, cluc-cluc

Hoi _Kraai_, dacht laat ik toch maar even kijken waar het over gaat, & daardoor herinnerde ik me iets.

Zie dit onderwerp alhier, volgens het concept "College gemist..." van o.a. Bitwiper, SirDice & Thasaidon:

https://www.security.nl/posting/26012#posting217781

Mijn mening na eigen onderzoek is dat de IP-range 169.254.x.x doorgaans duidt op een configuratie-fout of conflict. Wat alhier in weer een ander onderwerp onderuit gehaald is door volgens mij Bitwiper, maar dat kan ik natuurlijk weer even niet terug vinden... ;-)

heh :) Firewall wordt pas actief als de IP stack geinitialiseerd is.. Guess what :P

McAfee Virtual Technician doet er ongeveer twee minuten over om uw McAfee-producten te scannen. Na die eerste scan kan het nog enkele minuten duren voor alle eventuele problemen zijn opgelost.
McAfee Virtual Technician installeren => http://mvt.mcafee.com/mvt/mvtinstaller.asp

Ik denk dat het nodige al is gezegd over APIPA. Ik vraag me wel af of je in de logs niet kunt zien welk MAC adres hangt aan het geblokkeerde adres. Aan de hand van het MAC adres kun je vrij snel je eigen apparatuur uitsluiten.

Niet altijd.
Ik heb comodo firewall (gelukkig zonder privdog :-) maar dat ter zijde) en heb expliciet een rule voor de dhcp poorten moeten maken. Specifiek voor svchost.exe.
Comodo firewall is al actief voordat de wifi-verbinding is opgebouwd.

Doe even een test met Wireshark (https://www.wireshark.org).
Installeer wireshark op je laptop, start een capture (selecteer de juiste netwerkkaart) en controleer of je verkeer ziet.
Verwijder de netwerkkabel indien je dit nog niet gedaan had. Geef vanuit de command prompt opdracht ipconfig /release.
Begin een nieuwe wiresharkcapture. Om alleen dhcpverkeer te zien moet je dit invullen in het veld filter: udp.port==67 en klik Apply.
Geef nu vanuit de command prompt de opdracht: ipconfig /renew.
Er zou nu 4 regels tekst moeten verschijnen:(aub de _underscores_ negeren, kan in dit forum geen tabel weergeven)
Adress 0.0.0.0 is die van je laptop omdat er nog geen ip adres is toegewezen.
Adres 192.168.0.1 is die van de dhcp server. In dit geval je router.

Geeft jouw capture verkeer weer afkomstig van de dhcp server als je wifi gebruikt?
Ik vermoed dat dit niet het geval is.
Als test kan je de capture ook doen met de laptop aangesloten op de netwerkkabel zodat je kan zien wat ik bedoel.


/edit 16:10:
Heb je mss een smartphone of tablet die je met wifi zou kunnen verbinden? Als extra test.

Hallo, ik heb vandaag nog even wat test uitgevoerd

Op de laptop netwerk instellingen gewist, router gereset en weer opnieuw verbinding gemaakt. Nu wordt er slechts alleen in het begin een inkomende verbinding vanaf het ip adres 169.254.59.219 weergeven, zowel in het logboek van de firewall op de laptop als die op de PC. Zo'n 1 minuut later gaat dit over op gewoon de ip adressen van de laptop of pc. Vreemd is leek het niet te werken en nu half?

Viel mij wel op dat op de laptop in het logboek nu ook de laptop zijn eigen ip adres staat weergeven als geblokkeerde inkomende verbinding. Iemand enig idee? het blokkeren van de laptop zijn eigen ip als inkomende verbinding komt overigens slechts 2 keer in het logboek voor.

Wifi netwerken genoeg in de buurt, maar de meeste zitten gezelig op hettzelfde kanaal ;-) dus het kanaal weklke ik op de router heb ingesteld gebruik ik zo'n beetje als enige
Ben er nu eerlijkgezeg ook nog niet helemaal van overtuigd of het geen vreemd apparaat is welke op het netwerk zit.


Bedankt Ilja. _v v. Ik heb het topic gelezen en onderandere dat jouw switch verbinding maakte met ip adres 169.254.x.x. (al was dat wel in 2009)

Ik denk niet dat de problemen bij de McAfee software liggen. Ik heb alleen doormiddel van de firwall van McAfee gezien dat het ip 169.254.59.219 op het netwerk rondspookt. Verder staan de poorten die open moet staan voor het ontvangen van een ip van de DHCP serverook open dus daar zijn geen problemen


Het logboek van McAfee alleen het ipadres weer welke geblokkeerd is, maar helaas geen MAC adres.

Bedankt mcb. Ik ga proberen of het lukt om vandaag nog te testen met wireshark. Nu lijkt het netwerk wat betreft de ip adressen half te werken dus ik hoop dat het testen hierdoor niet mislukt. Ik heb een smartfone welke ik ook met het netwerk kan verbinden dus ga ook daarmee uittesten

Inmiddels wireshark geïnstalleerd en de test van mcb uitgevoerd.

Er loopt verkeer via WiFi.

inconfig /release levert in op dat ik een tijdje in wiresharkcapture het ip 169.254.59.219 voorbij zie komen.

ipconfig /renew levert niet de vier regels text op

:
Inplaats daarvan een lange text

Hierin staat onderandere het IPv4 en IPv6 adres, default Gateway en subnetmask.

Ook de volgende twee berichten

No operation van be performer on LAN-verbindingen while it has its media disconected

En

No operation van be performer on Ethernet while it has its media disconected

In de firewall op mijn pc levert het overigens weer een paar meldingen op van inkomende verbinding geblokkeerd van ip adres 169.254.59.219.

P.s.

Ik zie in wireshark verkeer voorbij komen met bestemming 192.169.0.255. Is dit normaal zou niet weten well apparaat dit IP heeft.

Inmiddels ook telefoon en een 3ds (leuk voor puzzels zo nu en dan) aan het WiFi netwerk gehangen maar ik krijg ze niet zover dat ze met mijn pc gaan communiceren. Hierdoor kan ik ook niet in het firewall logboek een ip zien.

Verwijderd. Reactie was dubbel gepost.

Hebben die telefoon en 3ds wel internetverbinding via wifi?
Zo niet, lijkt het er op dat je router wel ipadressen uitdeelt aan op lan aangesloten apparaten maar niet aan wifi.
Loop je settings nog een keer na. (Hoewel na 2 fabriekresets het uit zichzelf toch goed zou moeten staan).
Kijk ook in router of er een wifi-setting is dat heet "AP isolation". Zo ja, uitzetten. Als je ook op je pc wireshark runt, zou je de dhcp requests (is immers broadcast) van je laptop en alle andere apparaten moeten kunnen zien.

Adressen die eindigen op .255 zijn broadcast adressen en behoren niet toe aan een apparaat.
Niet iets om je druk over te maken.

De laatste (media disconnected) geeft aan dat wireshark ook de lan-aansluiting wil monitoren maar de kabel is niet aangesloten.
Je kan wireshark instellen dat 'ie slechts 1 netwerkkaart monitort (screendump): http://i20i.imgup.net/wireshark1251f.JPG
De lange lap tekst komt omdat je geen displayfilter had ingesteld waardoor je ieder bitje dat over de lijn (over the air) gaat te zien krijgt.
Stel zo de filter in (screendump): http://r02i.imgup.net/wireshark28b14.JPG

Bedoel je als ze gewoon normaal met internet zijn verbonden en niet met het netwerk welke losstaat van internet? ja dan hebben gewoon internetverbinding. Ook in mijn netwerk hebben ze wel verbinding en de router geeft aan dat er een ip adres is uitgedeeld.

Ik heb gekeken voor de wifi-setting "AP isolation", maar die is niet aanwezig.

Ik heb hier een afbeelding geplaatst van wiresharkt als ik met de Nintendo 3ds de inlogpagina van de router bezoek. (daadwerkelijk inloggen op de router via draadloos doe ik niet bezoek slechts de pagina).

http://uploadpie.com/QBSep de source is 0.0.0.0 die wireshark meld, terwijl de router zegt dat de nintendo 3ds ip 196.168.0.102 heeft gekregen.


Ah, had bij de vorige test de verkeerde filter te pakken (die via de knopjes). heb de test opnieuw uitgevoerd met de filter goed ingesteld. er verschijnen nu drie regels tekst waarvan de laatste pas na ongeveer 1 minuut in beeld kwam. deze zijn totaal aders als die jij beschrijft, en je zou denken dat de laptop een ipadres heeft gekregen.

Heb hier een afbeelding geplaatst van wat wireshark laat zien
http://uploadpie.com/ubZqx

Echter laat de firewall van McAfee weer gewoon ip adres 169.254.59.219 als geblokkeerd zien.
http://uploadpie.com/OnGWC

Normaalgesproken zie je na "ipconfig /release" meteen in Wireshark het huidige IP-adres voorbijkomen van de PC waarop je IPconfig uitvoerde. Dit IP-adres wordt met "ipconfig /release" namelijk vrijgegeven aan het netwerk. Eventueel zou een ander apparaat het dan dus weer mogen gebruiken. Daarom moet een DHCP-server (meestal je router) dat IP dus weten, want de dhcp-server organiseert het. En dáárom moet dat oude IP-adres even over de lijn om het aan de dhcp-server te vertellen. Maar dit zou in normale situaties slechts éénmalig na het commando "ipconfig/release" moeten zijn.

Dus als jij in Wireshark constateert dat direct na het commando "ipconfig/release" het IP-adres 169.254.59.219 wordt vrijgegeven, dan had dus de machine waar jij die "ipconfig /release" op intikte kennelijk op dat moment dat IP-adres?

Afijn, het problem zal er mee te maken hebben dat een apparaat niet via WiFi goed dhcp-contact met je router kan maken, en dat kan verschillende oorzaken hebben. Om te beginnen moet je router natuurlijk dhcp via WiFi aankunnen,
inclusief juiste instellingen en zo. Dat zijn misschien nu eerst de belangrijkste vragen: 1. staat alles wel correct ingesteld
(ik weet bijv. niet of jouw router misschien een aparte dhcp instelling heeft voor wireless LAN, en staat die dan wel aan?)
en 2: Ondersteunt deze router überhaupt wel dhcp op zijn WiFi?

En die smartphone, welk IP-adres krijgt die dan? Als die ook een IP in de 169.254.x.x-range krijgt, dan kun je je PC waarschijnlijk niet bereiken omdat 169.254.x.x buiten de normale netwerkrange van je lokale netwerk valt.
(maar internet zou je wel kunnen bereiken met de smartphone, want dat valt buiten jouw lokale netwerk)
Maar lukt het je om bijv. een vast IP in te stellen op je smartphone binnen jouw lokale netwerkrange, dán zou het wel mogelijk moeten zijn om met de smartphone je PC te bereiken.

Houd er trouwens rekening mee dat de router in reactie op een bericht van 169.254.x.x iets terug kan sturen naar die 169.254.x.x. Dit wordt dan waarschijnlijk zichtbaar in je firewall log als verdacht inkomend verkeer.
Maar het begint er meestal mee dat je apparaat zichzelf een 169.254.x.x-adres heeft toegekend omdat de dhcp-server niet (of niet snel genoeg) een IP verstrekte. Dat kan tijdelijk zijn, en zich later oplossen als dhcp naderhand toch weer werkt. Dus incidenteel kan het wel eens in de log voorkomen. Bijvoorbeeld als de PC eerder is opgestart dan de router/dhcp-server. Maar blijft dhcp falen, dan blijft het apparaat dat 169.254.x.x-adres houden, en herhaalt het zich mogelijk urenlang in de log.

Je kan proberen het verder uit te zoeken. Behalve bij de router zou het (ook) op andere plekken fout kunnen gaan.
En dan denk ik: is zoals eerder gezegd een vast IP-adres instellen in jouw situatie niet veel gemakkelijker?... ;-)
Als je toch verder wilt onderzoeken, misschien vind je dan ook hier nog wat tips:

http://answers.microsoft.com/en-us/windows/forum/windows_7-networking/problem-to-connect-internet-using-wireless-network/62120f0f-0738-41b0-8abc-f2a4503091f2
http://www.pctechbytes.com/networking/169-254-address/
http://superuser.com/questions/610474/keep-getting-invalid-ip-via-wifi
http://support2.microsoft.com/default.aspx?scid=kb;nl;811259

Mvg, cluc-cluc

Vanochtend heb ik als test (om een heel andere reden) een network-capture van het booten van een notebook gemaakt. Op de notebook is Windows 7 (64) geïnstalleerd, en deze is lid van een AD domain. Captures heb ik een Fritz!Box modem/router laten maken (http://fritz.box/html/capture.html, zie de tweede helft van https://www.security.nl/posting/395530/Fritz!Box+7360+Security+config#posting395643).

Tijdens het opstarten zie ik dat de notebook eerst een drietal ICMPv6 broadcast pakketjes verstuurt, en daarna drie ARP requests voor 169.254.181.244 (met telkens 1 seconde tussen die pakketjes). Weer een seconde later verzendt de notebook een Gratuitous ARP Request met als afzender IP-adres 169.254.181.244 - waarmee de notebook dat IP-adres feiteijk "geclaimd" heeft.

Iets minder dan 2 seconden later verzendt de notebook, van 169.254.181.244 naar 255.255.255.255, een DHCP Discover pakket. Onmiddellijk daarna zie ik de router een ARP request (broadcast) uitzenden voor het 192.168.x.y adres dat hij aan mijn notebook toe wil kennen.

Na nog meer pakketjes met afzenderadres 169.254.181.244 en wat DHCP verkeer tussen die notebook en router (waaronder een DHCP request afkomstig van de notebook, met 0.0.0.0 als afzender IP-adres), neemt de notebook het aangeboden IP-adres 192.168.x.y over.

Kortom, ik vermoed dat Windows computers (indien ze voor DHCP geconfigureerd zijn), direct na opstarten, 169.254.*.* gebruiken tot ze via DHCP een ander adres gekregen hebben.

Dat is niet per definitie juist, het hangt af van de grootte van het subnet en van het netwerkadres. Bij 192.168.0.0/23 is 192.168.0.255 een geldig host adres (en bij 192.168.0.0/25 is 192.168.0.127 het broadcast adres).

Aanvulling 27-02-2015, 14:02: een nslookup van dns.msftncsi.com geeft mij momenteel als IPv4 IP-adres: 131.107.255.255 (host adressen kunnen dus ook op .255.255 eindigen).

Ik had daar idd volledigheidshalve bij moeten zetten dat dat geldt voor subnetten met een subnetmask van /24.
Zo ver ik weet hebben de meeste thuisgebruikrouters standaard 192.168.0.0/24 ingesteld en is het in dat geval wel zo.
Maar je hebt gelijk voor grotere en kleinere subnetten.

/edit: 14:44
Dat is dan wel weer vaag. Volgens http://whois.domaintools.com/131.107.255.255 is het een 131.107.0.0/16.
Dat adres zou niet moeten kunnen.

Vanaag opnieuw getest nadat de router een tijdje uit heeft gestaan en stroom eraf is geweest. (als is dit al eerder al het geval geweest.

Na ipconfig /release zie ik nu netjes in wireshark het toegeweze ipadres van de laptop voorbijkomen. Hierna neemt de PC ipadres 169.254.59.219 aan, maar dat lijkt me vrij logisch als ie het ipadres vrijgeeft. Na ipconfig /renew krijgt de laptop een nieuw ipadres en zie ik ook in wireshark


Ik heb wel het idee dat dat ipadres verkrijgen nog redelijk lang duurt, maar weet niet precies wat normaal is. Als ik met de notebook contact zoek met mijn desktop PC geeft ie eerst nog aan dat het verkeer van ipadres 169.254.59.219 afkomstig is en een paar seconden later geeft ip wel het ipadres van mijn notebook weer. Dit duurt zo'n 6 seconden. Lijkt alsof soms wel goed gaat en soms niet. Ik heb de router nu weer uitgezet en test zo dadelijk nog een keer opnieuw.

Maar goed vorige week vrijdag had mij notebook kennelijk na 3 uur nog geen ipadres van de router weten te bemachtigen.
Ook het blokkeren van de notebook zijn eigen ipadres als inkomende verbinding vind ik nog vreemd, al is dat niet meer voorgekomen.


Waar kan ik dit precies vaststellen? kan ik dit gewoon op de router pagina zien? Mijn via wireshark zie ik zo'n 3 verschillende IP-adressen voorbijkomen welke de bestemming zijn. alle drie bestaan ze voornamelijk uit het cijfer 5.

Zojuist weer getest. Met de laptop lijkt het ontvangen van een ipadres nu goed te gaan. Maar met andere netwerk apperatuur niet. Zo weer uitgetest met de nintendo. Eerst word er vanuit 0.0.0.0 een discover verzonden en request verzonden. Daarna begrijp ik er niet veel meer van

Er word gevraagd wie heeft 192.168.0.1

vervolgens wordt opnieuw in discover en request verzonden.

dan verschijnt er broadcast 192.168.0.102 (request) waarna meteen weer de vraag komt wie heeft 192.168.0.1 hierna weer opnieuw broadcast en request. Ook word er een aantal maal gevraagd wie 192.168.0.103 heeft (mijn notebook via de kabel) mijn notebook gaat dan weer vragen wie 192.168.0.102 heeft.

En zo gaat het tot in het oneindige door met discover, request broadcast en Who has IP xxx.xxx.0.xxx vragen. Weet niet of dit normaal is. Ga nog een test met de smartfone uitvoeren.

Daar kon je wel eens gelijk in hebben. Ik heb ook geen idee of achter dns.msftncsi.com daadwerkelijk een server zit.

Windows gebruikt http://www.msftncsi.com/ncsi.txt om te testen of een computer internet connectiviteit heeft, het zou kunnen dat Windows een nslookup naar 131.107.255.255 gebruikt om te testen of DNS werkt, en het helemaal niet de bedoeling is dat er met 131.107.255.255 gecommuniceerd wordt. In dat geval wordt in elk geval geen IPv4 adres verspild!


Het subnet mask gebruiken computers om vast te stellen of een IP-adres lokaal is en direct (via ethernet) te bereiken is, of dat het om een niet-lokaal IP-adres gaat dat via de router verstuurd moet worden.

Door het subnet mask ontstaat een reeks lokale IP adressen. Het laagste daarvan is het "network address" en het hoogste is het lokale "broadcast address" (op IP niveau, niet te verwarren met ethernet multicast en broadcast adressen).

Zoals mcb schreef, bij home routers is het gebruikelijk om "class C" netwerken te gebruiken, oftewel een /24 subnet: ipconfig zal dan 255.255.255.0 als subnet mask laten zien. Bij een netwerkadres van 192.168.0.0 zal het hoogst mogelijke lokale adres dan 192.168.0.255 zijn (het broadcast adres).

Zie bijv. https://en.wikipedia.org/wiki/Subnetwork voor meer details.

DHCP werkt als volgt:
Een netwerk apparaat (pc, laptop, telefoon, nest-thermostaat, nas) heeft in eerste intantie geen ip adres en stuurt een aanvraag het netwerk op (broadcast) in de hoop dat iemand zo lief is om hem een adres te geven. Dit is de discover.
Als een dhcp server reageert, geeft 'ie een suggestie voor een ip adres, tezamen met wat andere settings zoals de default gateway, dns server(s) en wat andere zaken. Dit is de offer.
Het netwerkapparaat ontvangt dit en als 'ie er wat mee kan, doet hij een nieuwe aanvraag dit maal met de zojuist gekregen gegevens er in. Dit is de request.
Tenslotte bevestigd de dhcp server dat alles correct is. Dit is de ack. Vervolgens markeert de dhcp server in zijn database dat het ip adres in gebruik is zodat deze later niet nog een keer wordt uitgegeven.
Hiermee is de dhcp procedure klaar. (even simpel gezegd).

Binnen een subnet wordt veelal niet op basis van ip adressen gecommuniceerd maar op basis van mac adressen.
Switches bijvoorbeeld weten niet welk ipadres een apparaat heeft dat aan een poort hangt maar ziet wel het mac adres.
Om ip adressen aan mac adressen te koppelen wordt het het ARP protocol gebruikt (niet alleen door/voor switches maar door/voor alle apparaten).

De pc stuurt een broadcast uit met daarin zijn ip adres en mac adres. Dit noemen ze een gratuitous arp.
In feite kondigt die pc zijn aanwezigheid aan zodat anderen hem kunnen vinden.
Ook wil hij een lijstje hebben met andere apparaten. In eerste instantie de dns server en de default gateway omdat hij daar als eerste mee communiseert.
Dit gaat via een arp request en ziet er uit als "who has 192.169.0.1, tell 192.169.0.101".
De pc met ip 192.168.0.101 wil dus weten wat het mac adres is van de default gateway met ip 192.168.0.1.
De default gateway reageert met: "192.168.0.1 is at 7c:e9:d3:xx:xx:xx (zijn mac adres).
Het lijstje met gevonden ip- en mac adressen wordt dan in die pc zijn arp cache opgeslagen.
Ieder netwerk apparaat doet dit. Het is dus niet iets om je zorgen over te maken.

Overigens ga je met wireshark veel meer verkeer zien dan je in eerste instantie zou verwachten.


/edit: typo's en herformuleringen.

Bedankt Ik heb gekeken en 255.255.255.0 lijkt inderdaad bij mij ook de subnet mask te zijn. De router geeft dit namelijk aan bij de dhcp instellingen. Eventueel (als je zin en tijd hebt) kun je even de afbeelding kijken die ik zojuist heb geplaatst (zie link verderop in deze post) daar staan de anderen adressen.


Bedankt voor de vele informatie. Op zich werd het mij redelijk duidelijk hoe het aanvragen van een ip adres gebeurd door wat er in wireshark allemaal voorbij komt. Ik heb alleen het idee dat bij mij er niet echt een einde komt aan de dhcp procedure, maar dat het steeds weer opnieuw begint van voor af aan. heb hier een afbeelding geplaatst van een volledig capture scherm. Hierbij is tezien hoe de gehele procedure wordt doorgelopen, en vervolgens naar mijn idee weer opnieuw begint (kan best zijn dat ik het fout heb.)

http://uploadpie.com/Tdf5a

het ip 0.0.0.0 is de Nintendo 3ds heb dit gecontroleerd aan de hand van het
MAC adres. (ik heb wel over IPv6 adressen en de MAC adressen een balkje geplaatst.

Dat kan wel kloppen ja.
In windows worden arp caches gemiddeld iedere halve minuut ververst. Dit staat overigens los van dhcp.
Dhcp requests worden opnieuw gedaan zodra de helft van de lease tijd (max dhcp duur ingesteld op de dhcp server) is verstreken. Of eerder na reboots, connection losses (kabeltje er uit gevallen), handmatige release/renew commando's.

Oké dan denk ik dat de arp caches gewoon ververst worden. Viel mij op dat de Nintendo 3ds nog al vaak een request en discover verstuurd terwijl mijn notebook en desktop dit niet doen. (valt op als de filter udp.port==67 is ingesteld) ongeveer een keer per halve minuut komen er 2 van die lichtblauwe balkjes bij. Maar goed ik denk dat het dan wel goed zit met mijn offline netwerkje.

Heb nog een vraagje betreffende wireshark namelijk ik heb verder geen ervaring met het programma. Alleen het verkeer bekijken wat er wordt verzonden de bron en waar naartoe. Kan ik de installatie van wireshark en wincpap beter ongedaan maken, of kan ik deze gewoon laten staan mocht ik er nog een keer gebruik van willen maken (weet niet of er risico's aan zitten aan het gebruik van wireshark wanneer de pc op een netwerk zit welke wel gewoon met internet is verbonden of andere beveiliging risico's).

Verder aan alle bijdragers van dit topic bedankt voor jullie hulp!

Goeie posts! Zo komen we ergens.


Of het altijd in iedere windows met zo'n hoge frequentie plaatsvindt betwijfel ik. Deze ervaring heb ik niet.
Maar je ziet wel ieder apparaat even de dhcp-procedure volgen. Dus bij drie apparaten is dat drie keer in korte tijd...
Ik heb trouwens uPnP altijd uitstaan. Kraai zo te zien niet. 'k Weet niet of dat ook nog invloed heeft.

Verder vindt er volgens mij regelmatig een controle/verificatie plaats (kan er misschien uitzien als een herhaling, maar niet exact hetzelfde). Bijv. elke tien minuten of zo. Zou eventueel o.a. afhankelijk van de Windows-versie kunnen zijn.
Als de dhcp leasetijd is verstreken, heb je wel te maken met een herhaling van de hele dhcp procedure.

@ mcb: Is dat trouwens ergens gedocumenteerd dat het officieel al na een halve leasetijd moet gebeuren?
Die halve leasetijd heb ik ook eens op een router meegemaakt, maar heb gedacht dat het een firmware bug was.
Want waarom een halve leasetijd? Wat voor zin heeft dat? Al je netwerkverbindingen worden op zo'n moment verbroken,
en dat kan best irritant zijn. Sommige routers staan default op een uur leasetijd, en dat wordt dan dus ieder half uur.
Maar een volle leasetijd van 24 uur lijkt mij wel zo gerieflijk?... ;-)

@Kraai: En wat denk je dat er gebeurt met het IP-adres van je laptop als je WiFi-signaal op zo'n dhcp verificatie- of verversingmoment teveel verstoort of verzwakt is?... ;-)
Maar als je vaste IP adressen op je Wifi-apparaten instelt, zou je je hiervan geen last moeten hebben. Dus???... ;-)

Mvg, cluc-cluc

Het apparaat welke steeds een nieuwe request uitvoert is een Nintendo 3ds. Maar goed deze stuurt inderdaad erg vaak een request. uPnP staat in het desbetreffende netwerk inderdaad niet uitgeschakeld, maar aangzien deze niet met internet is verbonden, zal dat neem ik aan geen beveiliging risico zijn. (tenminste uPnP is toch juist bedoeld voor interne netwerken die niet aan het internet hangen?) Voor het netwerk die wel met internet is verbonden heb ik uPnP wel uit staan.

Als ik overigens in wireshark de filter instel op udp.port==67 dan komen er regelmatig (ga nog eens meten hoeveel tijd precies) twee blauwe balkjes bij met een discover en een request. (hoef niet lang te wachten voordat het scherm ermee vol staat). steeds wordt dit vanuit het ipadres 0.0.0.0 uitgevoerd.


De leasetijd van een ip adres staat ingesteld op 1 week, dus die verstrijkt niet vaak.


Ah... op de momenten dat mijn laptop dat wil uitvoeren zal het signaal teveel verstoord of verzwak is, zal die wel op ipadres 169.254.59.219 overgaan. Ik zal morgen een test uitvoeren waarbij ik wat verder met mijn laptop van de router af ga staan.

Kan inderdaad ook nog heel apparaat afhankelijk zijn.

Mogelijk kan uPnP er soms aan bijdragen dat een virus/worm zich automatisch door het hele lokale netwerk verspreidt als je op één apparaat een virus oploopt. Daarom zet ik het liever uit in situaties waarin het voor mij toch geen toegevoegde waarde heeft. Ook kan via uPnP in routers volgens mij automatisch een poort worden opengezet naar internet toe. (port forward) Dat kan handig zijn in gevallen waar dit is bedoeld (hoef je niet zelf in de configuratie van de router zitten "te peeken en te poken"), maar een malware programmaatje zou dat dan natuurlijk ook stiekem kunnen doen.
Dus laat mij dan maar lekker "peeken en poken" in de routerconfiguratie wanneer dat nodig is. ;-)
Ik ben me graag bewust van wat er precies gebeurt.

Mooi zo.

Yes, lijkt me een prima idee. Succes, en laat a.u.b.nog even weten of deze theorie klopt met de praktijk.
(toevallig net weer appeltaart meegenomen vanmiddag... ;-)

Mvg, cluc-cluc

Ik heb het vandaag eens gemeten. eerst worden er drie in 16 seconden tijd gestuurd. Daarna om de 25 seconden.


Ah bedankt voor de info cluc-cluc. In zet uPnP uit in min router. Kan ik gewoon ook zelf peeken en poken in de router configuratie. :-) Een poort open zetten naar internet heeft weinig zin, aangezien er dan nog met een internetkabel mijn huis moeten worden ingeslopen en op de WAN poort van de router moet worden aangesloten ;-) Maar goed een virus of worm kan inderdaad nog wel een risico zijn.

Hmm appeltaart ik stop een appeltaart zelf meestal nog eventjes in de oven als ik hem heb meegebracht, heerlijk :-) Maar ik denk dat dat nog even moet wachten.

Een slecht signaal krijgen is nog niet zo gemakkelijk. Heb Tx power ingesteld op 10% maar dat hielp niet. Vervolgens de rol aluminiumfolie erbij gehaald en de router gedeeltelijk ingepakt maar er wordt nog aangegeven dat de sterkte van het signaal 3 a 4 streepjes is als ik verder weg ga staan met mijn laptop. Nog tips?

Grappig als ik de recensies van mijn router op internet lees wordt er veel geklaagd zal het signaal slecht is.

Dat staat o.a. hier: http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#Reliability
Het idee erachter is dat al de dhcp server even niet bereikbaar is op het moment dat een lease verstrijkt, dit geen problemen hoeft op te leveren omdat de lease tussentijds verlengd is.
Is de dhcp server halverwege de leasetijd niet bereikbaar, maakt dat ook niet uit omdat er nog steeds leasetijd over is.

off topic:
Een bijdrage aan de security.nl community wordt natuurlijk altijd op prijs gesteld ;-)
/off topic

Heeft jouw laptop geen knop of schuifje waarmee je antenne (dus niet de netwerkkaart) kan uitzetten?
In feite is dit hetzelfde als de kabel er uit trekken.

Ik kan WiFi wel uit zetten op de laptop maar goed dat zou resulteren in geen verbinding, en niet in een slechte verbinding. Een hardwarematige schuifje is Ger niet. Alleen via Windows is het op de laptop mogelijk WiFi uit te zetten.

P.s. Ben nog altijd benieuwd wat ik het beste met de installatie van wireshark op mijn pc en laptop kan doen. Zie mijn post van gisteren 27-02-2015 20:10 uur.

Mischien is de oplossing waar cluc-cluc ook al een paar naar wees gewoon de gemakkelijkste static ip instellen zoals eerder gedaan en klaar. Wel nog in de gaten houden of er nog vreemde ip adressen voor komen in de log van de firewall.

Als je router verwijderbare externe antennes heeft: antennes verwijderen.
En afstand uiteraard voldoende groot maken. Zo mogelijk niet in dezelfde kamer blijven. (muren ertussen)
Aluminiumfolie schermt Wifi flink af, maar dan moet je het apparaat wel grondig inpakken.
Dus niet gedeeltelijk, en liefst ook meerdere lagen alu. Microgolven ontsnappen door de kleinste openingen.
Misschien kun je ook de laptop erbij inpakken. (voorzichtig: niet al te lang i.v.m. oververhitting!
Maar tien minuten en daarbij begonnen met een geheel afgekoelde laptop zal geen probleem zijn, tenzij je laptop
zoveel energie verbruikt dat het bijna een oven is. ;-) Gelukkig geleidt alu-folie wel vrij goed warmte,
zodat je aan de buitenkant wel merkt wanneer het warm begint te worden.

Voor hoe je Wifi-signalen nog meer kunt hinderen zie http://www.wifi-masters.nl/interferentie/
Zie ook https://en.wikipedia.org/wiki/Electromagnetic_interference_at_2.4_GHz

Vraag is wel of je op de 2.4 GHz frequentieband zit of op de 5 GHz band.
Op 2.4 GHz zitten meestal meer storingsbronnen dan op 5GHz.
Ik denk dat je inventief genoeg bent om iets bruikbaars te pikken uit de hierboven genoemde URL's?

@mcb: dank voor de verduidelijking over vernieuwing van het IP na de halve leasetijd.

b.t.w.: inmiddels op voorhand maar een stuk appeltaart (mét slagroom!) genomen, want je weet maar nooit. ;-)

Mvg, cluc-cluc

Wireshark en de winpcap driver staan niet in de weg. Anders dan schijfruimte nemen ze geen resources in beslag, je kan ze rustig laten staan.

Of je alles op dhcp laat staan of toch liever een vast ip hebt, tja dat is je eigen keus.
Het is wel rustiger in je logs maar voor de hoeveelheid netwerkverkeer hoef je het niet te laten.

Oeps... vergeten.
Zie http://www.winpcap.org/misc/faq.htm#Q-7 (zie Q-7 dus)
Eenmaal geïnstalleerd kan iedere user (en dus ook onbevoegde users... of malware...) op ieder moment alle netwerkpakketten op je netwerk sniffen. Dus niet automatisch installeren is het veiligst. Vooral aan te bevelen als je Wireshark maar weinig gebruikt.

Daarentegen is wel automatisch installeren iets gemakkelijker als je Wireshark wél vaak gebruikt en als je dit stukje security er wilt opofferen voor ietsje meer gemak, of als je andere applicaties gebruikt die ook winpcap nodig hebben.

(misschien ook een optie: gebruik maken van herstelpunten om evt terug te kunnen gaan naar vóór de winpcap installatie?)

Daarnaast is het aan te raden dat je wel de laatste versie van winpcap gebruikt. (momenteel versie 4.1.3)
Deze versie wordt gelukkig al meegeleverd in recente Wireshark-versies.

Mvg, cluc-cluc

WinPcap is ook prima gewoon te deïnstalleren:
http://www.winpcap.org/misc/faq.htm#Q-1

De afstand had ik al zo groot mogelijk maakt door op een andere etage te gaan staan. Voor de aluminiumfolie moet ik eerst even naar de winkel heb niet genoeg meer op de rol zitten om de router een paar keer te kunnen inwikkelen, laat staan een laptop.


Als er nog een lade aan de onderkant van de laptop zit is het wel multifunctioneel als de laptop net een oven is. Kun je er mischien ook nog een appeltaart inschuiven ;-)


Smakelijk eten :-)

@mcb 28-02-2015 17:42 uur, cluc-cluc 28-02-2015 17:58 uur en Spiff 28-02-2015 19:27 uur

Wat betreft wireshark en wincpap verwijder ik deze maar gewoon. Ik weet niet hoe wireshark werkt zonder wincpap (nog iets misschien wat ik kan uit zoeken). Ik heb voor de installatie een herstelpunt gemaakt. Ik verwijder Wincpap eerst gewoon via de manier die Spiff gaf en daarna ga ik terug na een herstelpunt. Vervolgens nog een QuickClean uitvoeren met de McAfee software voor de tijdelijke bestanden, verloren bestands fragmenten en zo, en dan zal wireshark en winPcap wel goed verwijderd zijn ga ik vanuit.

Met m'n reactie van 19:27 uur ging ik daar bewust aan voorbij.
Ik heb weinig kennis betreffend Wireshark, maar ik verwacht dat WinPcap essentieel is voor het gebruik van Wireshark.
Met het deïnstalleren van WinPcap wordt Wireshark dan onbruikbaar.
Echter, WinPcap is simpel weer even te herinstalleren wanneer je Wireshark weer nodig hebt, en vervolgens naar wens weer te deïnstalleren.
Aan al dat ging ik voorbij.
Het enige dat ik wilde aangeven is dat WinPcap eenvoudig te deïnstalleren is, en dat het mij niet nodig lijkt daarvoor Systeemherstel uit te voeren (een herstelpunt terug te zetten).
Was er een nadrukkelijke reden waarom cluc-cluc Systeemherstel noemde, in plaats van 'gewoon' het deïnstalleren vanWinPcap?

Zekers Spiff. Maar dat lag zo voor de hand dat ik het niet heb durven noemen. ;-)

Er zat ook nog wel wat meer achter:
Puur en alleen de optie "programma verwijderen" wil nog wel eens wat rommel achterlaten, vooral in het register.
Hoe erg dat met winpcap is weet ik niet, maar even het zekere voor het onzekere genomen:
bij een systeemherstelpunt wordt o.a. ook een backup van het register gemaakt, nog zonder die rommel.
Lijkt me handig. Heb je dus altijd zeker weten een register achter de hand zonder die eventuele vervuiling.
(http://windows.microsoft.com/nl-nl/windows/back-up-registry)

Er bestaat ook software waarmee je grondig programma's kunt verwijderen.
Bijvoorbeeld http://www.groovypost.com/howto/windows-completely-uninstall-software/
Hier heb ik overigens verder geen ervaring mee, dus slechts bedoeld ter bevestiging van wat ik in de vorige alinea noemde.

Ik lees nu net hoe Kraai het heeft gedaan. Lijkt me wel goed genoeg.
Trouwens Kraai, wat me nu te binnen schiet: als je een magnetron hebt, zou je je router daar (zo nodig ook nog ingepakt in alufolie) in kunnen zetten. Of anders de laptop als dat past, aangezien er dan geen stroomkabel klem zit tussen de deur als hij op de accu loopt. Want die deur moet wel goed dicht. Maar de magnetron dan niet aanzetten natuurlijk!
Een goede magnetron houdt microgolven in de 2.4GHz Wifi band immers grotendeels binnen. Daar is hij op gebouwd.
Misschien ook een bak water erbij (dus niet eroverheen...;-P) om de microgolven van de router of laptop te absorberen.

Voor nu: laten we nog maar een keertje inschenken voor het slapen gaan. ;-)

Mvg, cluc-cluc.

Dank je, cluc-cluc, ik begrijp je overweging.
Zelf heb ik eerder WinPcap op mijn systeem gehad als onderdeel van Freemake Video Downloader.
Deïnstalleren van Freemake Video Downloader gebeurt standaard slordig, je vind dan nog allerlei resten terug.
Deïnstalleren van WinPcap echter, dat lijkt keurig te gaan, ik heb er geen resten van teruggevonden. Maar dat sluit uiteraard niet uit dat er wat achtergebleven kan zijn dat ik niet gevonden heb. Jouw tip aan _kraai__ om door middel van Systeemherstel terug te gaan naar een punt vóór de Wireshark plus WinPcap installatie geeft meer zekerheid.

Gerelateerd:
Installeert Wireshark tegenwoordig de meest recente WinPcap versie, 4.1.3, of nog steeds een oudere WinPcap versie?
Hier http://wiki.wireshark.org/WinPcap wordt nadrukkelijk steeds WinPcap 4.1.2 als Latest Stable Release genoemd, terwijl de laatste stable WinPcap versie toch werkelijk 4.1.3 is, en 4.1.3 zelfs een versie is die een aantal security issues oplost, zie http://www.winpcap.org/news.htm en http://www.winpcap.org/misc/changelog.htm

Het teruggaan naar een herstelpunt heeft niet alleen met winPcap te maken maar ook dat ik wireshark weer wil verwijderen. Zonder winCpap heb ik daar immers niets aan. In elk geval bedankt voor het meedenken en de informatie Spiff. Ik zal ook nog even kijken welke versie van winCpap is mee geïnstalleerd met wireshark.


Ik heb wireshark nog niet verwijderd maar zo ga ik het wel uitvoeren cluc-cluc. Ik had wireshark voor de test van vandaag nog nodig.

De laptop past niet in de magnetron, maar ik heb nu gewoon die ene wikkel aluminiumfolie om de router heen gedaan en ben vervolgens met de laptop naar buiten gelopen. Dit was genoeg voor een signaal strekte van 1 a 2 streepjes. Wat mij opviel is dat bij de slechte verbinding 4 keer een request vlak achter elkaar werd ingedient met een ARP als antwoordt, daarna ben ik maar weer naar binnen gegaan dus mogelijk werden het er anders nog meer. Als ik zowat neven de router zit, dan wordt er 2 keer een request verzonden met een ARP al antwoord. Bij elke request werd steeds ip adres 0.0.0.0 aangegeven door wireshark. Uiteindelijk krijgt ie wel een ip adres. Wat nu het antwoord is op die keer dat drie uur lang meldingen in de firewall stonden van verdacht inkomend ip adres geblokkeerd 169.254.59.219 weet ik dus niet.

Ik nog de links die je gisteren gaf over interferentie gezien. Ik heb daar een tijdje terug ook een post over geschreven (ongeveer in het midden) in het topic https://www.security.nl/posting/404991/%5BVerwijderd%5D (ging ook over magnetrons en mobiele telefoons).

p.s. zag dat mijn post van gisteren 28-02-2015 22:11 uur best slordig was geschreven dus die pas ik nog even aan.

Vandaag nog appeltaart? :-)

Winpcap is een packet capture driver dat netwerkverkeer opvangt en een kopie daarvan beschikbaar houdt voor verwerking door andere programma's.
Standaard wordt netwerkverkeer door de protocol-stack verwerkt en wordt de inhoud daarvan (de daadwerkelijke data dus zonder headers) aan het OS en onderliggende programma's beschikbaar gesteld.
Voor netwerktrafficanalyse is dit natuurlijk niet handig.
Winpcap leest al het verkeer (incl headers) uit voordat de netwerkkaartdriver dit doet en (een deel van) de headers er uit sloopt.

Ik heb zelf nooit problemen ondervonden met het verwijderen van winpcap.
Gewoon via controlpanel\uninstallprograms.
En als je wireshark deinstalleert, vraagt de uninstaller of winpcap ook verwijderd moet worden (geloof ik).
Systeemherstel is dus niet nodig.

Mss is het een idee om wireshark te deinstalleren en alleen de portable versie te gebruiken.
Winpcap wordt dan geinstalleerd bij het starten van wireshark en verwijderd zodra je wireshark af sluit. Dit laatste is overigens instelbaar.

Nu dag ik dat het probleem verholpen was maar nee hoor nu staat er weer verdacht inkomend ip adres geblokkeerd dit keer 169.254.62.172. Om gek van te worden. Ook stond mijn laptop op dat moment uit dus daar kan het niet van zijn.

Ik heb hier een afbeelding geplaatst van het McAfee logboek

http://uploadpie.com/N8Qjl

Iemand enig idee? Ik wil toch wel echt weten waar dit vandaan kan komen en of ik wel veilig gebruik kan maken van mijn netwerk.

Op dat moment was alleen mijn desktop en de switch aangesloten. Mocht het van buitenaf komen moet het in de buurt zijn. Het netwerk zit namelijk nog altijd niet op het internet aangesloten.

Ik heb gekeken maar de portable versie is begrijp ik alleen beschikbaar voor 32 bits systemen. Wel had ik geprobeerd wireshark op een USB-stick te installeren, maar WinPcap wordt dan toch op de PC zelf geïnstalleerd en niet op de USB-stick erbij helaas. Wireshark en winPcap nu maar verwijderd.

Wireshark portable is idd niet helemaal portable.
Het is meer een temp install die zichzelf verwijderd na gebruik.
Eenmalig uitpakken op een stick, vanaf de stick runnen, d.w.z. temp install die zich laten weer verwijderd van de pc maar wel op de stick blijft staan voor volgend gebruik.

Er zijn overduidelijk devices die niet zo vlot zijn met dhcp.
De vraag luidt: hoe erg is dat?
Kijk met wireshark wat de mac adressen zijn en inventariseer de mac adressen van al je devices.
Staat er niets onbekend bij, zou ik zeggen laten zo en geen energie meer in steken.

WinPcap 4.1.3 is zo te zien geïntroduceerd vanaf Wireshark versie 1.10.0.
Zie https://www.wireshark.org/docs/relnotes/wireshark-1.10.0.html
(geverifieerd: ook portable versie van Wireshark versie 1.10.0 heeft WinPcap 4.1.3)
Hoogste tijd dat ze hun wiki op dit punt eens wat bijwerken Spiff. ;-)

Heeft die ene aangesloten PC soms twee netwerkadapters? Bijv. kabel en wireless? (check eens ipconfig /all)

Mvg, cluc-cluc

@Spiff, wireshark installeert momenteel winPcap 4.1.3 bij de installatie

Oke bedankt voor de info mcb.


Hmm... het geblokkeerde ipadres is van de desktop en kennelijk blokkeert die dus zijn eigen ipadres als inkomend als ie geen antwoord krijgt van de DHCP server. \Goed geen idee hoed dat precies in elkaar steekt maar het is de desktop in ieder geval, en blijkbaar speelt het probleem zich dus ook af asl er gewoon via kabel met het netwerk wordt verbonden

Ik denk dat inderdaad de conclusie gemaakt kan worden dat de DHCP server niet altijd even snel is.

Misschien moet ik hem soms maar een bakkie koffie geven werkt ie wat sneller ;-)

Aan de bijdragers in dit die mij in dit topic hebben geholpen, Bedankt voor de hulp!

Ha, dankjewel, allebei.
Mooi dat Wireshark wel degelijk WinPcap 4.1.3 meelevert, en niet de oude 4.1.2.
En ja, inderdaad hoogste tijd dat ze hun wiki op dat punt dan eens wat bijwerken ;-)

169.254.x.x is een reeks die Microsoft gebruikt in meerdere Windows versies voor als de client op DHCP staat, maaar er geen DHCP adres is. Dit kan komen doordat de DHCP server geen adres uitgeeft, maar ook omdat de client het adres niet accepteert. In dit geval zal de client een adres aannemen in deze reeks. Hierdoor kunnen clients toch nog met elkaar communiceren in een laag 2 netwerk.

Dus kijk de DHCP server na op het vollopen van de scope of de leasetijden. Meestal zit het probleem daar. Mocht je netwerk wat groter zijn kan het ook komen doordat de DHCP relay niet goed staat.

Nee, er is maar een netwerkadapter aangesloten


De DHCP server heeft de leasetijd op 7 dagen staan, volgen mij begint deze leasetijd steeds opnieuw als de pc heeft uitgestaan en weer wordt opgestart. Het netwerk is niet heel groot en er zijn ruim voldoende ip adressen beschikbaar.

Vraag me nog wel af als de pc geen ip adres heeft kunnen krijgen hij het daarna ook niet meer probeert of hoe dat in elkaar zit, maar goed dat valt denk ik via een zoekmachine wel te vinden

Okee.
Dus zoals je het vertelt, wek je de indruk dat die ene PC via twee ethernetkabels en via de switch met je router verbonden was, en deze PC (desktop) heeft verder geen wireless aan boord. Dat weet je heel zeker, want ipconfig /all geeft jou maar informatie over één netwerkadapter, en niet over twee netwerkadapters. Klopt dat?

Zo ja probeer dan eens het volgende: router (=dhcp-server) UITzetten. Switch ook uitzetten. Desktop opstarten.
Dan als de desktop helemaal is opgestart de switch aanzetten, maar NIET de router (=dhcp-server).
De desktop zal nu vanwege de aangezette switch detecteren dat er een netwerkverbinding aanwezig is.
Daarom zal de desktop proberen contact te maken met een dhcp-server.
Maar omdat de router nog uitstaat, krijgt hij geen contact. En dus neemt de desktop een 169.254-adres aan.
Laat dat eens een kwartiertje of zo staan.
En dan ben ik benieuwd of er nu ook "verdachte inkomende verbindingen" in de McAfee log zijn gekomen.

Mvg cluc-cluc

_kraai_, zover ik begrepen heb betreft het alleen één desktop, & ik bedenk me opeens iets:
Wat voor AV of IS heb je daarop geinstalleerd?..

Het betreft een desktop en een laptop (laptop heeft overigens wel 2netwerk kaarten), gisteren was het mijn desktop die geen ip adres kreeg toegewezen maar de laptop heeft er ook last van. Ik heb McAfee als beveiligings pakket geinstalleerd op zowel de desktop als de laptop. (Bevat ook inbraak detectie firewall en zo).

Dit is wat de originele maker van zijn software vindt.
https://www.youtube.com/watch?v=bKgf5PaBzyg

Ik heb er net even naar gezocht, maar voor McAfee kan ik het niet 123 vinden, hier gaat het om:

Verschillende AV/IS maken gebruik van een virtuele netwerkkaart om internet/netwerkverkeer te scannen, etc.., van bv. Avast! & EmiSoft weet ik dat zeker.
Dat is normaal niet zichtbaar, maar in Veilige modus is dat te vinden in Apparaatbeheer onder Netwerkkaarten. Die krijgen een APIPA.

Als dat niet het probleem is, kan ter uitsluiting dat het netwerk in de war is ook nog eens een keer het Netwerk-Installatie-Protocol opnieuw uitgevoerd worden, & dat betekend dat je al je apparaten aansluit & aanzet, van laatste naar eerste op ieder apparaat de Wizard Netwerk instellen uitvoert, herstart, volgende, etc.., dan hub's/switches/routers herstart, dan de modem/router herstart.
Daarna zet je van laatste naar eerste alles uit, tot slot de modem/router 2 minuten uit (of om de router te laten "doorlopen" een echt kwartier).
Daarna eerst de modem/router weer aan & wachten tot die volledig is opgestart.
Daarna idem een voor een aan vanaf de eerst naar de laatste, ook wachten tot elk apparaat is opgestart alvorens de vogende te starten.

Je bedoelt waarschijnlijk: dit is wat de originele maker van de software vindt die nog altijd zijn naam draagt. ;-)
Want "Mr. McAfee" staat allang niet meer aan het roer van dit product.
Zie: http://www.unit4.nl/over-unit4/nieuws/nieuwsbericht/aid/3823

Ilja omschrijft inderdaad mijn verdenkingen over McAfee, en mijn bericht van gisteren 22:29 was de eerste stap in een
poging om er achter te komen of zoiets de oorzaak is. Je zult moeten "troubleshooten", d.w.z. door systematisch en slim uitproberen en door zaken uit te sluiten er achter zien te komen welk onderdeel in het netwerk nu precies de problemen veroorzaakt. Er zijn in een troubleshooting traject meestal "verschillende wegen die naar Rome leiden".
En details zijn bij hardnekkige problemen erg belangrijk, dus probeer duidelijk en volledig te zijn in je omschrijvingen.
Maar ik probeer altijd voorzichtig te zijn om al bij voorbaat een schuldige component aan te wijzen, want aan één en hetzelfde verschijnsel kunnen vaak verschillende oorzaken ten grondslag liggen. Als je van te voren té gefixeert bent op wat je denkt dat het is, dan kun je in de verleiding komen om te druk te zoeken naar bevestiging van je vermoedens i.p.v. te zoeken naar de werkelijke oorzaak van het probleem.

De tip van Ilja om in Veilige modus te kijken kan een belangrijke indicatie zijn, dus ik zou zeggen: doe dat maar eerst.
(ik wist dit niet, dus van mij bij deze ook een bedankje Ilja ;-)

Mvg, cluc-cluc

De PC zit via een internetkabel op de switch aangesloten. Vervolgens zit de switch weer met een kabel op de router aangesloten. De PC Zit dus maar met een kabel aangesloten. Sorry daarin was ik nogal onduidelijk.


Als ik de switsh van de router loskoppel en de PC loskoppel van de switch, vervlogens de PC het netwerk laat vergeten, en weer opnieuw aansluit op de switch gaat de PC gebruik maken van IP adres 169.254.62.172 als ik ga kijken in het netwerkcentrum, maar goed dit was te verwachten want geen DHCP server. Er verschijnen ook snel genoeg de vermeldingen in het logboek van McAfee van verdacht inkomend IP-adres geblokkeerd.
Als ik de switch met de PC nog aangekoppeld weer aansluit op de router krijgt de PC nu wel weer meteen een IP-adres. Wisselt nog al wat er dus gebeurd.
Verder misschien even om een duidelijk beeld te scheppen hoe mijn netwerk in elkaar zit
Router: waarop aangesloten 1 USB-stick, 1 switch en 1 laptop (draadloos verbonden)
Switch: waarop aangesloten 1 desktop PC via kabel, en soms de zelfde laptop als welke draadloos met de router wordt verbonden. Maar deze is nooit met de router als via kabel met de switch tegelijk verbonden.

Bedankt Ilja _V V
Heb zojuist de PC in veilig modus zonder netwerkmogelijkheden opgestart, Onder apparaat beheer bij netwerkadapters gekeken, maar er staat niet tussen van McAfee.


Ik ben hier mee bezig. Heb momenteel de router van het desbetreffende netwerk uitstaan voor een kwatier. Ik verwacht zo dadelijk te kunnen melden wat het resultaat is, al moet ik voor een goed beeld of het probleem verholpen zal zijn mijn netwerk toch enkelen dagen of misschien zelfs weken in de gaten houden.

[offtopic]
Eerst gebruikte ik KPN PC veilig maar goed daar werd bij een update een tijdje geleden de firewall eruit gesloopt en werd Windows firewall gebruikt. Daar was ik al niet zo tevreden mee, ook omdat de prijs hetzelfde bleef, maar er na mijn idee een stuk van de functionaliteit eruit werd gesloopt. Best jammer.

Daarna kwam ik er ook achter dat KPN PC veilig DeepGuard en EMET zeer waarschijnlijk met elkaar conflicteren, tenzij Bij EMET bij elke applicatie het vinkje bij EAF weghalen of DeepGuard in de compaliteits modus zetten loste het probleem op.

Meer info zie https://www.security.nl/posting/408206/EMET+5_1+is+beschikbaar

Als laatste was ik ook niet echt te spreken over de siteadviseur gedeelte (de groene vinkjes en zo weet niet de precieze naam) en het ouderlijk toezicht. Beide werkte op mijn PC niet helemaal soepel. Ik zag alleen via de zoekmachine bing groene vinkjes staan, maar niet bij andere zoekmachines. Ook als ik een website bezocht kon ik nergens een beoordeling van de veiligheid van de website ontdekken. Bij ouderlijk toezicht werd niet alles goed geblokkeerd wat geblokkeerd moest worden. Ook weer jammer.

Van die laatste twee weet ik niet of er meerdere problemen mee hebben ondervonden maar ik had er de buik van vol en ben een ander beveiliging pakket gaan zoeken. Ik meende overigens wat betreft het conflicteren van EMET en DeephGuard er nog iemand hier op security.nl er iets over vermelde.

Ik vond KPN PC veilig wel makkelijk in gebruik geen onnodige meldingen en de PC wordt ook niet ernstig vertraagt. En instellingen kunnen met en wachtwoord worden vergrendeld. (ook wel de positieve dingen benoemen).

Jammer, en dan ga ik toch wat anders zoeken.McAfee bevalt mij prima. Verder wil ik niet mee doen aan het antivirus flammen of hoe je het ook pressies noemt. Naar mij idee iedereen gewoon het antivirus pakket laten gebruiken welke ie fijn vindt
[/offtopic]

Inkomende desktopverbindingen op afstand staat hier op één van de pC4s in BitDefender Firewall 'algemene regels' op weigeren.

Ook bij systeemeigenschappen (Windows) Verbindingen van Hulp op afstand staat daar uitgevinkt en bij Extern bureaublad 'geen verbindingen met deze computer toestaan'

Als je dat niet echt nodig hebt?

Kan je nog gaan klooien in de 'services' maar dat is iets voor de echte fans.

Inmiddels de router weer opgestart en de rest. Er worden IP-adressen uitgedeeld, maar goed het probleem met het niet krijgen van een IP-adres deed zich ook niet elke keer voor, maar hoop dat het nu is opgelost.

Denk dat ik het nu maar een aantal dagen in de gaten moet houden. Of iemand moet nog andere inzichten hebben na aanleiding wat ik nog gepost heb?

Bedankt voor de info cluc-cluc. Ik zal voortaan iets minder snel mijn conclusies maken. Zal voortaan ook deuidelijkere omschrijvingen geven

Dank voor de informatie Kraai!
Dit is inderdaad normaal en naar verwachting.

Kijk, daar heb je het: wat hier m.i. normaalgesproken over het netwerk zou moeten gaan, is een uitgaand
"dhcp discover"-bericht dat uitgaat van je desktop. Maar McAfee spreekt over een verdacht inkomend adres,
terwijl alleen de switch is aangesloten en verder niets"... En dat is raar.
Want van welk apparaat zou er op dat moment nou een inkomend bericht in je desktop moeten komen?
Er zijn immers helemaal geen apparaten die iets naar je desktop zouden kunnen sturen. Alleen de switch.
Maar een simpele gewone switch geeft alleen maar netwerkpakketten door, en heeft niet eens een IP-adres.
Dus dat de switch iets zou sturen lijkt me uitgesloten tenzij je een heel bijzondere switch hebt.

Dit betekent dus ook dat het 169.254-adres in dit geval onmogelijk van een indringer afkomstig kan zijn, want de switch heeft zelf geen WiFi, en de desktop ook niet, er hingen geen andere apparaten aan en de router stond nog uit...
(nou ja de printer misschien. Maar dat lijkt me sterk. Desnoods trek je die ook nog even los aan het begin van de test)

Het lijkt er sterk op dat we dus inderdaad op het verkeerde been worden gezet door de melding van McAfee
die het uitgaande verkeer van je desktop hier als "inkomend verkeer" meldt i.p.v. als uitgaand verkeer.
Je zou dit m.b.v. Wireshark op je desktop voor de zekerheid nog eens gedetaileerd kunnen meten. (meten is weten)
Inkomend netwerkverkeer zijn netwerkpakketten waar het 169.254-adres van je desktop is vermeld in de kolom "destination" in Wireshark. Dus daar dan eventjes op letten of dat in de Wireshark capture voorkomt.

Mocht je desktop IP-adres in de Wireshark capture nooit als destination zijn vermeld, dan is er ook geen inkomend netwerkverkeer geweest. Als McAfee desondanks dan iets als "verdacht inkomend verkeer" heeft opgevat terwijl jij dit nergens in Wireshark ziet, dan is dat wat mij betreft een mankement in McAfee.

Meten is weten. Test is best (én appeltaart met slagroom bij een lekker bakkie koffie). ;-)
Denk je dat hiermee het hele verschijnsel voldoende is verklaard en daarmee opgelost, omdat er in feite bewezen is dat er niets gevaarlijks aan de hand is? Of heb je nog twijfels?

Mvg, cluc-cluc

Ook bedankt voor de informatie cluc-cluc


Weet niet of het mogelijk is, maar de PC verstuurd verkeer naar de switch, maar de switch kan hier dus niet mee. Ik weet niet of het mogelijk is dat de switch het verkeer maar retour afzender stuurt omdat hij er niet mee kan, en vervolgens de firewall van McAfee dit niet zo leuk vindt?


De printer stond op het moment van testen uit dus in princiep kan daar niets van afkomstig zijn.


Ik zal de test nog een keer opnieuw uitvoeren met wireshark geopend. Mogelijk hebben we dan een antwoord.


Alleen het verschijnsel van mijn laptop blijft nog over die via Wi-Fi geen ip adres kreeg aangeleverd. Opvallend was ook dat McAfee het IP-adres van de laptop als inkommend blokkeerde als deze met kabel was aangesloten, Maar dat dit verkeer op op mijn desktop als inkomend werd geblokkeerd. Daar heb ik helaas geen antwoord op. Het wordt echter lastig om dat nog te onderzoeken aangezien het niet meer is voorgekomen. In principe kun je daar dan ook niet helemaal uitsluiten dat het verkeer niet van buiten kwam, maar goed helaas is daar momenteel denk ik nog maar weinig aan te doen.

Mogelijk is dat probleem nu verholpen nadat ik het Netwerk-installatie protocol opnieuw heb uitgevoerd waar Ilja _V V mij op wees. Ik hou het in de gaten.

Ik ga overigens meer voor de warme chocomelk met appeltaart ;-)

Inmiddels gekeken maar met alleen de PC op de switch aangesloten is wel uitgaand verkeer. Volgens netwerkcentrum zijn er geen ontvangen pakketten.

aanpassing: correctie.

M.a.w: Test succesvol?

Even terugkomend op mijn McAfee zoektocht: Ik vond er wel bedrijfsmatige hardware oplossingen zoals FW's die van virtuele netwerkkaarten gebruik maken, & ik neem aan dat de software daarvan (deels) is toegevoegd aan de consumenten produkten.
Behalve Avast! & EmiSoft, weet ik ook zeker dat Kaspersky soortgelijke technieken gebruikt, & vast wel andere AV-boeren.

Probleem daarmee is dat het behoorlijk agressief is, want het scant dus het hele netwerk, inclusief tot in de modem/router van de ISP, gegeven de gelegenheid.
Als die dan een eigen FW heeft, dan kan dat een conflict opleveren, want dan kan de een of de ander blokkeren, & dat is daarna dus weer terug te vinden in de logs.

Uiteraard is dat door de AV-boer goed beveiligd, vandaar dat het normaal niet zichtbaar is in Apparaatbeheer, maar wel in Veilige modus, alhoewel afhankelijk van de maker er dan zelfs alsnog eerst "Verborgen apparaten tonen" ingeschakeld dienen te worden.
Verwijderen lukt overigens ook niet via Apparaatbeheer, alleen Systeem heeft daar het recht toe. Zelfs na uitschakelen in de configuratie van de AV/IS.FW, wat, evident, de bedoeling is. Alleen de AV/IS/FW in het geheel verwijderen zal ook de virtuele netwerkkaart verwijderen.

Wat betreft het Netwerk-Installatie-Protocol, heb ik hetzelf vaak meegemaakt na een uitbraak van het een of ander & de daarop volgende tsunami aan buurt-reparaties, dat mijn best wel overbemeten huiskamerlaboratoriumnetwerk daarna compleet zo in de war was dat zowel de modem/router, switches, WiFi & Windows niet meer wisten wie nou wat of waar waren. Op zo'n moment is het Netwerk-Installatie-Protocol (niet eens zelf bedacht) handig.
Na executie daarvan werkt alles weer normaal, tenzij er echt iets vreemds aan de hand is, & zelfs "losse" apparaatjes kunnen probleemloos weer verbinden.

Ik zag verder nog iemand hierboven in dit lange onderwerp iets schrijven in de orde van "Niet aannemen dat de oorzaak dat is" o.i.d. & alhoewel ik het even niet kan terug vinden, ben ik het daar wel mee eens.
Ik geef alleen maar aan dat een netwerk op hol kan slaan & daardoor in de war kan raken, & dat heden ten dage AV/IS/FW's virtuele netwerkkaarten gebruiken die van binnenuit het netwerk onder een APIPA scannen, met alle gevolgen van dien.

Bedankt voor de erg interessante informatie Ilja _V V Wat betreft test succesvol, bij mijn desktop is de oorzaak nu bekend.


Heb even gekeken nog een, er zijn wel stuurprogramma's vam McAfee te vinden onder niet compitable met Plug an Play maar niet onder netwerkadapters.

Ik heb na uitvoeren van het Netwerk-Installatie-Protocol geen problemen meer ondervonden op mijn laptop hoop dat dit zo blijft.



Ik heb het topic een bekeken maar ik kan nergens een reactie vinden waarin dat wordt gezegd. Mogelijk in een ander topic?

Ik ben eens in het logboek van Windows op mijn laptop gaan zoeken, of ik iets zag staan

Ik kwam het volgende tegen

De volgende activiteiten vonden kort achter elkaar plaats:

Bron DHCP client
Adres 192.168.0.101 dat voor adapter 4 wordt gekoppeld bestaat al.

Bron DHCP-client
Er is een fout opgetreden bij het initialiseren van de interface 4. De foutcode is: 0x1392.

Bron DHCP client
"Deze computer kan het netwerkadres (van de DHCP server) niet vernieuwen voor de netwerkkaart met netwerkadres ... (Een MAC adres van de laptop). De volgende fout is opgetreden: 0x1392. De computer zal blijven proberen om zelf een adres van de server met netwerkadressen (DHCP server) te verkrijgen.

Deze gebeurtenissen vonden plaatst toe mijn laptop draadloos was verbonden met de router en geen IP-adres kreeg. Mogelijk dat iemand aan de hand van de bovenstaande logboek registraties iets kan vertellen wat er mis is gegaan?

Niets is onmogelijk (ook al was het alleen maar met het oog op ontwerpfouten/firmwarefouten). Maar het is voor zover ik weet niet gebruikelijk dat een simpele switch een dhcp discover gaat beantwoorden. Maar als het in dit geval toch zo mocht zijn, dan zou je dit in de Wireshark capture moeten zien als een inkomende verbinding (zoals in 03-03-2015, 22:59 uitgelegd: als er een inkomende verbinding via het netwerk is binnengekomen, dan moet in de kolom "destination" van de Wireshark capture ergens het 169.254.x.x IP-adres staan dat je desktop op dat moment had).

Is dat dan niet hetzelfde verschijnsel als je nu op je desktop ziet? Of bedoel je misschien dat het toen urenlang doorging,
terwijl de router (met Wifi) toen gewoon aanstond? Tja, daar moet lijkt mij toch iets aan de hand zijn geweest dat communicatie met de dhcp-server blokkeerde, zodat je laptop steeds geen detecteerbaar antwoord ontving op zijn uitgezonden dhcp discover. Wat toen de exacte oorzaak is geweest, is misschien niet meer met 100% zekerheid te achterhalen. Misschien was er inderdaad iets in de war en heeft N.I.P dat herstelt.
Maar de optie van een indringer met een 169.254.x.x adres lijkt mij niet zo groot. Bij een network mask van 255.255.255.0
zou je router alle netwerkcommunicatie naar aangesloten apparaten op jouw lokale 192.168.0.x netwerk immers moeten blokkeren, omdat het IP 169.254.x.x geen deel uitmaakt van jouw lokale netwerk.
Eerder lijkt (in alle voorzichtigheid gesproken) het probleem nu iets te maken te hebben met je McAfee.

Waarschijnlijk bedoel je https://www.security.nl/posting/419643#posting420563

Duidelijk. Iets om rekening mee te houden, en dat aanleiding zou kunnen geven tot "fascinating anomalies". ;-)

Hieruit is op te maken dat er inderdaad problemen waren om een dhcp-adres te verkrijgen, zoals we in feite steeds proberen uit te leggen.
Een ander voorbeeld van iemand met een "pseudo-netwerkinterface" (waar volgens de informatie van Ilja ook jouw McAfee waarschijnlijk gebruik van maakt?) die helemaal gek wordt van soortgelijke problemen:
http://hardware.forumsee.com/a/m/s/p12-31690-0754767--internet-drops.html
Mij valt op dat hier de "pseudointerface" kennelijk gewoon met het commando ipconfig (of: ipconfig /all) zichtbaar werd.

Zonder al te stoute conclusies te trekken, rijst steeds meer het vermoeden dat het daar dus wel eens mee te maken zou kunnen hebben, zoals Ilja aangaf. Maar om exact de vinger op de zere plek te leggen kon wel eens ondoenlijk worden.
Kun je tevreden zijn met de conclusie dat jouw waarnemingen hoogst hoogst waarschijnlijk niets met een indringer te maken hebben, en met de aangereikte "workarounds" om het probleem te laten verdwijnen als het weer op zou treden?
(waaronder natuurlijk ook nog steeds de optie: kijk eens of het definitief helemaal weg blijft met instellen van vaste IP-adressen, en of dat dan niet een werkbare oplossing voor je is?)

Yummie... Laat het je goed smaken zodra je de kans krijgt! ;-)

Mvg, cluc-cluc

Daar kan ik prima mee leven cluc-cluc. Ik zal de komende tijd mijn netwerk in de gaten houden. En ach misschien ben ik gewoon iets te (hm ben even het wordt kwijt iets met een P ;-) )

Bedankt voor de goede hulp en info cluc-cluc.

Ja, die bedoelde ik! :-)

Even nog een aanvulling op de vraag over de identiteit & intelligentie van de moderne switch (wel of geen ip, re-routeren e.d.), waar de Engelse Wikipedia overigens al redelijk uitgebreid uitsluitsel over geeft.
Wat ik gisteren vond, & tot nu verloren op een vergeten tab stond, is een compleet Cisco college, wat aangeboden word in zowel direct HTML als download PDF, & dan zelfs het hele boek of per hoofdstuk.
Waarschuwing: Dit is wel Hogere Vak School Netwerkkunde! (Vroeger heette dat HTS, blijkbaar is tegenwoordig Techniek niet meer altijd een Vak.)
Voor de liefhebbers:

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2950/software/release/12-1_9_ea1/configuration/guide/scg/swipaddr.html

Woord met een P & 2 glurende oogjes op de I?.. ;-)

Bedankt wat leesvoer. Ik kom er denk ik wel uit als ik het lees, en hier en daar wat opzoek.


Yep :-)
Kan er alleen nog steeds niet opkomen.
Nog een hint misschien?

Verder ook jij bedankt voor jouw hulp in dit topic Ilja _V V.

Met genoegen, Kraai. :-)

Wablief? Iets met een P? Ehhhhh... ff denke......Nog ff denke...... ff denke nog...................te Professïoneel? :-)

Die Cisco catalyst2950 is wel een zgn. "managed" switch, en heeft de nodige extra's aan boord die simpele (unmanaged) huis, tuin en keuken-switches niet hebben. Maar evengoed leerzaam natuurlijk, zolang je je er van bewust blijft dat het simpele switchje zoals we die meestal in thuisnetwerken aantreffen waarschijnlijk veel van die functionaliteit zal missen.

Mvg, cluc-cluc

off topic
Dankjewel nog voor die verwijzing.
Op die pagina die je noemde wordt onder meer Revo Uninstaller besproken, de meesten hier zullen die wel kennen.
Maar daarnaast wordt ook Voidtools "Everything" genoemd. http://www.voidtools.com/ Die kende ik niet.
Bijzonder handig tooltje. Fijn om te ontdekken, vond ik.
Daarom bij deze alsnog bedankt voor je verwijzing.

/off-topic

Nee nee, niet Professïoneel, maar ik weet het inmiddels weer, (met een beetje hulp van een synoniemen lijst)). namelijk paranoïde :-).

Ach ja, zo zou je het ook kunnen noemen.
Sinds kort worden "té professïoneel" en "paranoïde" in de ICT-wereld door elkaar heen gebruikt voor hetzelfde ding. ;-)

Mvg, cluc-cluc