[@Home]Bijeenkomst Vught / Den Bosch

[MrEdge_]

Kon er niets over vinden op GoT, vandaar een nieuw topic:
Voor iedereen die uit de omgeving Den Bosch komt (Vlijmen, Rosmalen, Vught etc.) en problemen heeft mijn zijn/haar @Home verbinding is er vanavond een bijeenkomst in Vught. Er zullen woordvoerders van @Home aanwezig zijn om een en ander uit te leggen.
Zie ook hier en hier op de site van T@H.

Datum: woensdag 19 maart
Aanvang: 20.00 uur
Locatie: Vijverhof, Djalakstraat, Vught

Dit is _niet_ alleen voor de mensen uit Vught maar voor iedereen uit omgeving Den Bosch die problemen heeft met de verbinding.

[ Voor 2% gewijzigd door MrEdge_ op 19-03-2003 12:50 . Reden: dubbele ontkenning ]

[iets]

Heb jij problemen met je @home verbinding dan? Hier in Vlijmen heb ik niks te klagen hoor .

[Paulum]

Ik ben hier in St Michielsgestel ook dolgelukkig.

[Pindkaas]

Ik zit in Den Bosch, het enige dat ik af en toe ondervind is dat de verbinding wegvalt en dan meteen weer oppakt. Kan er wel mee leven eerlijk gezegd

[Knightwolf]

Pindkaas schreef op 19 March 2003 @ 17:54:
Ik zit in Den Bosch, het enige dat ik af en toe ondervind is dat de verbinding wegvalt en dan meteen weer oppakt. Kan er wel mee leven eerlijk gezegd

Ik zit ook in Den Bosch.
Ik heb al bijna een half jaar (sinds oktober of zo) dat heel vaak (soms erg vaak op een avond) de verbinding ineens geheel dood is, en meestal een minuut later weer werkt. Soms duurt het zelfs 5 tot 10 minuten voor ik weer online ben Ik kan hier dan ook simpelweg niet langer mee leven. Kben ook al aan het zoeken geweest naar een ADSL-vervanger die minstens mijn @home downloadsnelheden evenaart (mijn minimale eis over te stappen op ADSL).

Ik denk niet dat ik kan/ga komen, maar het initiatief vind ik wel goed.

[ Voor 3% gewijzigd door Knightwolf op 19-03-2003 18:47 ]

[MrEdge_]

In dit topic zijn er genoeg die erover mee kunnen praten. Het is zelfs nog bij Kassa op tv geweest.
In Vught en delen van Den Bosch, Vlijmen en Rosmalen ondervinden veel abonnees hinder van een verbinding die erg vaak wegvalt. Downloads worden afgebroken, online gamen is gewoon onmogelijk. Maar goed, mocht je er last van hebben dan kun je vanavond dus de woordvoerders van @Home vragen stellen.

[luckyme_]

Nou, ik ben net terug. Heb wat verontrustende sniffer traces laten zien aan ze. Hoop binnenkort wat meer te horen van ze.

[Verwijderd]

Ik ben inmiddels overgestapt, maar ben wel benieuwd wat er gezegd is gisteren... voelt iemand zich geroepen een verslag te posten?

[MrEdge_]

Nou ja, ik voel me wel geroepen dan

Er waren zo'n 50 mensen aanwezig die allemaal klachten hadden over de wegvallende verbinding. Ik meen Luckyme_ ook gezien te hebben
Er waren van @Home 4 mensen aanwezig: Willy Verweij, die andere woordvoerder die ook bij Kassa was en twee "tier 2,5" medewerkers (de link tussen de tweedelijns helpdesk en het netwerkbeheer van @Home).
De heer Verweij heeft uitgelegd dat de problemen van november vorig jaar te herleiden waren naar een bug in de Com21 software. Die bug zorgde ervoor dat gare netwerkkaarten en foutief ingestelde routers met MAC adres 0 steeds een nieuwe poging tot verbinding kregen net zolang totdat er 32000 "verbindingen" open stonden. Ik ben geen netwerkspecialist maar misschien dat Lucky dat nog kan toelichten.
De patch daarvoor is vorige week door Com21 geinstalleerd. Er zijn nog andere problemen geweest zoals uitgebrande verdeelstations etc. wat de verbindingen ook niet echt ten goede is gekomen.

Van het publiek uit was er vooral onvrede over de manier waarop de helpdesk elke keer weer ontkent dat er een probleem is en dat je niet wordt doorverbonden met de tweedelijns. Om dit op te lossen krijg je de komende 3 weken meteen de tweedelijns helpdesk als ze zien dat je uit Vught komt.
Ook veel onvrede over de tariefsverhoging, maar daar konden zij natuurlijk niets aan doen. Verder veel onvrede over de klachtenafhandeling, maar ook daar gingen deze mensen niet over. Wel betreurden ze de gang van zaken en zouden ze actie ondernemen.
Dan nog een hoop gezeur over de nieuwe motorola modems. Men wilde allemaal zo'n ding "want die zijn sneller" en men voelde zich achtergesteld omdat nieuwe klanten wel zo'n ding krijgen en oude niet. Tja, een hoop geblaat om niets, omdat mensen met een motorola dezelfde problemen hebben.

Verder heeft @Home afgelopen weekend bij 5 mensen met aanhoudende problemen de verbinding gecheckt en er bleek dat 1 persoon gewoon "www" als startpagina had en dat werkt dus niet meer. Iemand anders had een gare netwerkkaart met MAC 0 en de rest had instellingen verkeerd staan op hun pc's. Dat is voor mensen die echt problemen hebben natuurlijk geen fijne conclusie want dit soort gevallen draagt bij aan het beeld dat @Home van zijn gebruikers heeft: Ze knoeien met instellingen en zeuren vervolgens dat het niet werkt. Natuurlijk ook groot ongenoegen bij de stemmingmakers van de avond die zeurden dat @Home niet telkens naar de gebruiker moet wijzen. (maarja, wat wil je als bij 4 van de 5 het probleem bij de gebruiker ligt...)

Gelukkig waren er ook mensen met verstand van zaken aanwezig die nog steeds problemen hebben. Luckyme_ heeft met een netwerksniffer extreem veel arp requests geconstateerd. Normaal zijn het er 20 per seconde, maar bij @Home 200. Het zijn ook requests uit Groningen en Arnhem die normaal gesproken niet op "ons" netwerk terecht zouden moeten komen. De bron van de requests blijkt de Com controller bij @Home zelf. Het verhaal werd door nog iemand uit de zaal onderkend. Hij had precies hetzelfde geconstateerd.
De twee techneuten van @Home waren enigszins verbaasd en zeer geinteresseerd in de logfiles. Er zijn dan ook afspraken gemaakt dat er bij de technische thuisgebruikers gaat worden getest. De kans is groot dat er een instellingsfout ergens bij de controller zit waardoor het netwerk helemaal dichtslibt.

Ik vond het in ieder geval een nuttige bijeenkomst, afgezien van de loze Jerry Springer opmerkingen die door sommige mensen werden ge-uit. De woordvoerders van @Home kwamen oprecht over en ook de techneuten leken te weten waarover ze het hadden. Maar het blijft een raadsel waarom zij de abnormaal hoge requests niet eerder hebben opgemerkt. Het excuus daarvoor heb ik gemist maar misschien dat iemand me daarop kan aanvullen?

link naar bericht uit het Brabants Dagblad op T@H: http://www.troublesathome...ion=pers&page=item&id=414

Wel jammer dat er niets wordt geschreven over de nieuwe ontdekking, maar dat zaldan wel te technisch zijn geweest. Persoonlijk vind ik het bericht veel te negatief. Op die manier kun je het als @Home zijnde toch nooit goed doen...

[ Voor 6% gewijzigd door MrEdge_ op 20-03-2003 12:36 . Reden: linkje ]

[GambitRS]

Knightwolf schreef op 19 March 2003 @ 18:46:
[...]

Ik zit ook in Den Bosch.
Ik heb al bijna een half jaar (sinds oktober of zo) dat heel vaak (soms erg vaak op een avond) de verbinding ineens geheel dood is, en meestal een minuut later weer werkt. Soms duurt het zelfs 5 tot 10 minuten voor ik weer online ben Ik kan hier dan ook simpelweg niet langer mee leven. Kben ook al aan het zoeken geweest naar een ADSL-vervanger die minstens mijn @home downloadsnelheden evenaart (mijn minimale eis over te stappen op ADSL).

Ik denk niet dat ik kan/ga komen, maar het initiatief vind ik wel goed.

Als je een vervanger zoekt, probeer dan Demon ADSL. 2048/512 voor 65 euro geloof ik. Omdat je als normale @homaar eigenlijk 400kbyte/sec downt lijkt dit natuurlijk weinig, maar als je omdat de verbinding hiero zo bagger is de laatste tijd toch niet sneller kan downloaden dan 200kbyte/sec zie je dat het op alle fronten een verbetering is (behalve de prijs ). Dit is het goedkoopste abbo dat ik kon vinden wat een beetje in de buurt van de @home snelheid kwam.

Als je een grote downloader bent en gigabytes per dag moet binnenhalen kan je beter bij @home blijven. Dan maken die disconnects niet uit, tuurlijk duurt het ietsje langer maar daar heb je niet zo heel veel last van. Als je echter een gamer bent zoals ik en maar casual (= af en toe) wat download (bestanden van +-300MB zoals America's Army (gratis == goed ) gaat best met ADSL) dan is ADSL natuurlijk stukken beter. Lagere ping, geen disconnects meer en hopelijk een wat stabielere snelheid (Mijn linkmonitor status window ziet meestal groen/orange/rood, alle kleuren door elkaar, met @home DenBosch).

Dus: Download je veel, niks aan de hand, blijf bij @home. Game je veel, stap dan over.

Gaming in ClanBase in officiele wedstrijden is leuk, maar niet als je verbinding elke 5 minuten wegvalt Ben je ook zo het team uitgetrapt

[elsegre]

MrEdge_ schreef op 20 March 2003 @ 12:32:
Nou ja, ik voel me wel geroepen dan

Een heel verhaal ...

Kijk met jouw instelling kom je ergens.

Bij troubels lopen veel schreeuwers rond die vanalles blaten zonder enige onderbouwing.
Er is er een bij die roept dat zero-nicmac's geen probleem zijn op een COM21 netwerk. Nou als je er zo-een op je netwerk hebt kan je lachen.

Maargoed, dit is nog zoiets vaags; Router + @Home COM21 modem : geen internet*
Ik snap dus niet hoe het kan dat routers van klanten uit b.v. Assen in Braband opduiken in de logs!?

En dan de mailserver, de newsserver en de memberserver
Of zijn het de loadbalancers die ervoor staan

Zulke dingen zijn alleen maar leuk als ze opgelost worden en dat lukt als klanten goede info over het probleem geven zoals Luckyme_ .

_{Psst dit soort dingen worden gelogd als "incident" --> cursusje ITIL}

[Verwijderd]

Ze mogen wel is een bijeenkomst in Deventer geven , word helemaal gek van @home hiero...

S'avonds kun je geen eens normaal met zijn 2en cs'en aangezien de upload hier na 18:00 5kb/sec bedraagd (Ping 80-400ms , flush enity packet en connection failed)

En als je bijv tweakers.net of een andere site pinged dan heb je 5 v/d 10 x een timeout.....

Daar betaal je 47€ voor.....

Ga dus overstappen naar Adsl als het niet verbeterd, heb ze al zovaak berichten gestuurd maar het enige wat ik terug krijg ik zon stom standaard mailtje , Stap over op Tweakdsl denk ik.

[MrEdge_]

elsegre schreef op 20 maart 2003 @ 17:40:
[...]
Kijk met jouw instelling kom je ergens.

Bij troubels lopen veel schreeuwers rond die vanalles blaten zonder enige onderbouwing.
Er is er een bij die roept dat zero-nicmac's geen probleem zijn op een COM21 netwerk. Nou als je er zo-een op je netwerk hebt kan je lachen.

Ja, diezelfde gozer was denk ik ook op de bijeenkomst aanwezig. Hij deed alsof ie het internet eigenhandig had uitgevonden... Zegt ie tegen die @Home techneuten dat ze er niets van begrijpen. "Weten jullie eigenlijk wel hoe een tcp/ip pakketje eruit ziet?" zegt ie dan. Allemaal blaten dat het niet aan de 0-MAC adressen kon liggen...

Maargoed, dit is nog zoiets vaags; Router + @Home COM21 modem : geen internet*
Ik snap dus niet hoe het kan dat routers van klanten uit b.v. Assen in Braband opduiken in de logs!?

En dat is dus precies het probleem: je modemlampjes staan de hele tijd aan vanwege die 200 arp requests per seconde. Dat routers uit Assen opduiken in Den Bosch is het hele probleem, dat zou helemaal niet mogen. Wat ik ervan heb begrepen is dat normaal gesproken een arp request niet buiten het subnet komt als beide computers zich in hetzelfde subnet bevinden. Maar op de een of andere manier komen gewoon _alle_ arp requests langs. 200 per seconde, terwijl 20 tot 40 normaal is. En ze worden in Den Bosch allemaal verzonden door: ... de com controller. (te controleren door het MAC adres).

En dan de mailserver, de newsserver en de memberserver
Of zijn het de loadbalancers die ervoor staan

Tja, laten we het daar maar niet over hebben

Zulke dingen zijn alleen maar leuk als ze opgelost worden en dat lukt als klanten goede info over het probleem geven zoals Luckyme_ .

Psies. Ik was ook blij dat ie er was.

_{Psst dit soort dingen worden gelogd als "incident" --> cursusje ITIL}

Hoezo dan?

[himlims_]

ik woon in megen (gemeente oss) maar ben ook aangesloten in d'bosch (als 't goed is )
moet zeggen dat alles hier perfect werkt

[Verwijderd]

Bedankt voor het verslag
Het is prettig dat het probleem nu eindelijk serieus genomen lijkt te worden.

[luckyme_]

Even een korte samenvatting dan, Mredge_ heeft al goed zijn best gedaan

Als een machine een ander probeert te benaderen zal hij het packet adresseren met een ip adres en een mac.
Om te bepalen of een pakket bedoeld is voor een machine wordt altijd een stuk van de header ingelezen. Hierbij wordt gekeken of het mac-adres wat erin staat overeenkomt met dat van de machine. Uiteraard staat er ook een ip in het pakket, maar ook altijd een mac. Het ip zal altijd het ip van de geadresseerde machine zijn, het mac in het pakket is het mac-adres van de volgende hop. (Bijvoorbeeld van de default gateway, de geadresseerde host kan immers veel verder weg zitten, valt wel op ip te vinden maar natuurlijk niet op mac).

Om uit te vinden wat het mac adres van een machine is zal een zogenaamde arp worden gedaan. Hierbij wordt eigenlijk geroepen: welk mac hoort bij de machine met ip w.x.y.z? Deze arp is een zogenaamde broadcast, hij wordt opgepakt door _alle_ machines op het netwerk (is gericht aan mac adres ffffffffffff). Uiteraard zal normaal gesproken alleen een arp worden gedaan voor machines die binnen het subnet zitten. Als je in het 213.51.60.0 netwerk zit hoor je dus ook geen arps voor 212.blaaa te zien.

Na het doen van een arp zal een machine deze gegevens gedurende een bapaalde tijd bijhouden in een zogenaamde arp-cache.

Wat is nou het probleem dat ik (oa) heb geconstateerd? Er vinden mega veel arp broadcasts plaats op het netwerk, afkomstig van de @home router. 20 broadcast per seconde op een netwerk zou nog wel te doen zijn, het spiket hier echter op 200, met een gemiddelde van 140 per seconde. Dit verklaart de traagheid en het wegvallen van de verbindingen, het netwerk zit gewoon "vol". Je machine staat alleen maar die arps te beluisteren.
Die router van @home doet zoveel arps dat de arp cache van dat ding blijft overlopen, vol is immers vol...
Ook komen er arps binnen die je helemaal niet moet kunnen zien, voor heel andere subnetten en, wat nog kwalijker is, voor private ranges, die horen niet eens gerouteerd te worden.

@home heeft (of krijgt) in ieder geval heel veel netwerkcaptures van me en ze zijn er druk mee bezig. Ik heb er ALLE vertrouwen in dat we het met ze op kunnen lossen.

Verder wil ik nog wel even kwijt dat ik de toonzetting van de bijeenkomst op momemten wel wat ongelukkig vond. Als je het er eenmaal over eens bent dat de helpdesk af en toe wat lastig te bereiken is of matig communiceert moet je daar niet over door blijven zeuren denk ik.

[ Voor 14% gewijzigd door luckyme_ op 21-03-2003 15:23 ]

[Xandrios]

MrEdge_ schreef op 20 March 2003 @ 12:32:


Gelukkig waren er ook mensen met verstand van zaken aanwezig die nog steeds problemen hebben. Luckyme_ heeft met een netwerksniffer extreem veel arp requests geconstateerd. Normaal zijn het er 20 per seconde, maar bij @Home 200. Het zijn ook requests uit Groningen en Arnhem die normaal gesproken niet op "ons" netwerk terecht zouden moeten komen. De bron van de requests blijkt de Com controller bij @Home zelf. Het verhaal werd door nog iemand uit de zaal onderkend. Hij had precies hetzelfde geconstateerd.
De twee techneuten van @Home waren enigszins verbaasd en zeer geinteresseerd in de logfiles. Er zijn dan ook afspraken gemaakt dat er bij de technische thuisgebruikers gaat worden getest. De kans is groot dat er een instellingsfout ergens bij de controller zit waardoor het netwerk helemaal dichtslibt.

Verbaast? Wat een onzin. Ik heb 2 weken terug al contact opgenomen met @home over deze problemen. Sniffer logs toegemailed, welke ze geanaliseerd hadden. En toen waren ze ookal zo 'verbaast'

Het zijn bij mij btw geen ARP requests, maar SYN, ACK packets. Voor de techneuten: Dat zijn bevestigingspakketjes.
In grote hoeveelheden worden deze mijn netwerk op gegooid, waardoor de verbinding volloopt.
http://crew.tweakers.net/Cutebritney/troep/attack.JPG

Het vreemde is, dat het ip & mac adres van de distination NIET mijn gegevens zijn. Oftewel: Ik krijg verkeer op m'n WAN poort dat niet voor mij bedoeld is.
Dit moet haast wel een fout zijn in de comcontroller. Ook omdat er nog vanalles meer mis is aan de packet: over het internet wordt een packet als dit al veel eerder tegengehouden; die komt er echt niet door.

Hoe zit dat bij jou, luckyme_ ? Zijn de mac/ip/sequence gegevens wel correct ?
(Bij broadcasts is dit natuurlijk niet helemaal van toepassing...)

Zou het mogelijk zijn dat wij eens wat logs uitwisselen? Want mischien heb jij toch een totaal ander probleem als dat ik dat heb.
Mijn pa is btw een van de mensen geweest die het hele Com21 gebeuren gestart heeft bij @home. Dus systeem keuze maken, testen etc etc. Die weet er ook nog vrij veel vanaf ( ) en heeft overigens ook nog alle documentatie liggen.
(Documentatie heb ik btw zelf ook wel. Als je interesse hebt, geef maar een gil. Is +/- 100MB aan PDF files )

Dit is wat @home te zeggen had over mijn logs:

- De TCP pakketjes hebben allemaal de SYN/ACK bytes gezet. Zo'n pakketje
is het eerste pakketje wat een machine terugstuurt op een TCP connectie
verzoek.
- De sequence numbers zijn voor beide kanten gelijk. Bij een TCP
connectie wordt door beide partijen een willekeurig bitpatroon van 32
bit gekozon, wat gebruikt wordt als referentiepunt van de hoeveelheid
bits die verzonden/ontvangen zijn. De kans dat die twee bitpatronen
identiek zijn, is zeer gering (1 op 2^32, ongeveer 1 op 4 miljard).
- Als we kijken naar de NIC MACs, dan zie we dat de flood vanaf 17
verschillende NIC MACs zijn verstuurd, naar 9 verschillende NIC MACs,
waaronder 7 multicast adressen.

Het is dan ook goed te begrijpen waarom u dit zag: de switch krijgt
pakketjes voor NIC MACs die die niet kent, en gaat dan de pakketjes naar
iedere andere poort binnen het VLAN copieren.

Het is ook een merkwaardige aanval. Deze aanval zal namelijk alleen een
stordvloed aan RST (reset) TCP pakketjes opleveren, als er al wat terug
gestuurd wordt.

Klopt niet helemaal, maar voor 't grootste deel wel geloof ik. Mijn pa had hier btw erg grote twijfels bij. Die dacht aan het volgende:
ARP / MAC adressen worden in een tabel op de comcontroller opgeslagen. Op een gegeven moment is deze vol, en dan zal hij gaan 'swappen'. Hij verwacht dat hier een flink probleem in zit / het probleem is.

Het zou btw heel goed kunnen zijn dat het Com21 systeem heel wat minder aankan dat daadwerkelijk in de specs vermeld staat....

[ Voor 27% gewijzigd door Xandrios op 21-03-2003 17:06 ]