Kan stengte porter forårsake feil checksum i pakker?

[The Stig]

Hepp!

 

Har nettopp fått PC-en på plass i ny studenthybel, dessverre oppdaget jeg til min store forskrekkelse at Battlefield: Bad Company 2 ikke klarer å koble til noen servere. Har undersøkt litt om det er noen restriksjoner på hybelnettet her, og dessverre viser deg seg at "de fleste UDP-porter er stengte". Har forsøkt å bruke Wireshark for å finne ut om stengte porter faktisk er problemet, men alt jeg klarer å lese av Wireshark er at tilkoblinger til servere feiler grunnet 'bad header checksum'. Så, da er spørsmålet: er det stengte porter fra ISP sin side som forårsaker dette?

 

 

Kan forøvrig legge til at det er kun Battlefield som ikke virker ... i hvert fall av de jeg har prøvd hittil.

Endret 17. august 2010 av The Stig

[Stigma]

Vel, kort sagt nei - pakker kan ikke bli korrupt bare fordi en port er blokkert. Enten vil informasjonen komme gjennom helskinnet, eller ikke i det hele tatt. Det sagt så må man ta høyde for at kanskje den feilbeskjeden er litt mer generell enn det du tror - og at du f.eks. kan få dem av andre grunner enn korrupte pakker. Jeg er ikke erfaren med wireshark og hvordan dette programmet fungerer, men jeg ville ikke regnet det som umulig at en slik beskjed også kan dekke et scenario der maskinen forventer et svar på UDP men ikke mottar noe f.eks. Merk at packet headeren er nullstillt som ville indikere at den er tom. Kanskje en UDP pakke aldri kom inn i mottaker bufferet og den bare leser ut det nullstillte bufferet. Dette er dog bare spekulasjon fra min side.

 

Det sagt så om UDP porter er stengt (en merkelig begresning om det er alt som er stengt), så vil en god del spill ikke fungere normalt da de benytter UDP.

 

Merk at en port som ikke er forwardet er noe helt annet enn en port som er stengt/blokkert. Førstenevnte vil ikke ha noe å si ved mindre du skal sette opp en server (for et spill eller annen tjeneste), mens sistnevnte vil som sagt påvirke mange spill og andre real-time interaktive tjenester over nettet.

 

Hvis du er i tvil så er vel det første du bør gjøre å slå opp på nettvet hvilke porter spilet faktisk benytter, og så kontakte ISPen og høre om begrensjingene faktisk gjelder disse portene - slik at du ihvertfall vet om det er noe du kan fikse fra din side eller ikke.

 

-Stigma

Endret 17. august 2010 av Stigma

[sumptrollet]

Feil sjekksum skyldes nok at nettverkskortet ditt kalkulerer sjekksummen på selve kortet. Det er iaff. ikke kritisk.

[Stigma]

Feil sjekksum skyldes nok at nettverkskortet ditt kalkulerer sjekksummen på selve kortet. Det er iaff. ikke kritisk.

 

Checksum error pakker vil vel bli forkastet - så sånn sett er det vel rimelig kritisk i forhold til å kunne fungere normalt i og med at pakkene ikke vil gå gjennom? Jeg forsto ikke helt det du prøvde å forklare der.

 

Forhåpentligvis får vi noen inn her i tråden som har mer erfaring med wireshark enn meg og kan analysere OPs resultater skikkelig. Jeg vil fremdeles annbefale at det er lurt å ringe ISP og avdekke nøyaktige hvilke sperrer det er snakk om. andre og tredjehåndsinformasjon når det gjelder slike ting (når det har gått gjennom forståelsen til mindre datatekniske mennesker) er særdeles lite pålitelig.

 

-Stigma

[The Stig]

Om jeg forstår sumptrollet rett, tenker han nok på at Wireshark kun "operer" på OS nivå. Ergo får man tidvis beskjed om feil checksum ettersom den blir kalkulert av nettverskortet, og ikke OS-et -- noe Wireshark ikke forstår. Men, jeg tror ikke det er derfor jeg får ugyldig checksum i dette tilfellet. Da tror jeg heller du har rett Stigma.

 

Er helt enig i at det er særs merkelig at så å si alle UDP-porter er stengt, men det virker som om det er tilfellet. Har dog funnet at en liten range fra 1000 til 1500 er åpen, og har dermed forsøkt på diverse redirect muligheter -- ønsketenkning antageligvis, har i hvert fall ikke fått det til. Når det er sagt, vil jeg kanskje tro det er mulig med en eller annen Linux-basert brannvegg?

[Stigma]

merkelig sperre om det stemmer... å redirecte er kanskje mulig om du setter opp en software ruter eller noe sånt, men det vil nok ikke være enkelt, og sikkert ikke alltid mulig med alle spill.

 

Hvilken ISP er dette snakk om da? det går ikke ann å kontakte dem og se om de kan unblocke noe fra deres side? forstår ikke helt hva grunnen for en sånn blokkering skulle være i utganspunktet. UDP er ganske kritisk å ha for mange tjenester, og ikke bruker P2P programmer det heller i noen stor grad.

 

-Stigma

[The Stig]

Det er som sagt snakk om såkalt hybelnett, så det er vel driftet av høgskolens IT-avdeling. Skal kontakte de i morgen, men utifra lefsa de serverer på hjemmesidene er jeg mildt sagt tvilsom.

[sumptrollet]

Feil sjekksum skyldes nok at nettverkskortet ditt kalkulerer sjekksummen på selve kortet. Det er iaff. ikke kritisk.

 

Checksum error pakker vil vel bli forkastet - så sånn sett er det vel rimelig kritisk i forhold til å kunne fungere normalt i og med at pakkene ikke vil gå gjennom? Jeg forsto ikke helt det du prøvde å forklare der.

 

 

 

Se http://www.wireshark.org/docs/wsug_html_chunked/ChAdvChecksums.html

 

The checksum calculation might be done by the network driver, protocol driver or even in hardware.

 

For example: The Ethernet transmitting hardware calculates the Ethernet CRC32 checksum and the receiving hardware validates this checksum. If the received checksum is wrong Wireshark won't even see the packet, as the Ethernet hardware internally throws away the packet.

 

Higher level checksums are "traditionally" calculated by the protocol implementation and the completed packet is then handed over to the hardware.

 

Recent network hardware can perform advanced features such as IP checksum calculation, also known as checksum offloading. The network driver won't calculate the checksum itself but will simply hand over an empty (zero or garbage filled) checksum field to the hardware.

[Note] Note!

 

Checksum offloading often causes confusion as the network packets to be transmitted are handed over to Wireshark before the checksums are actually calculated. Wireshark gets these "empty" checksums and displays them as invalid, even though the packets will contain valid checksums when they leave the network hardware later.

 

Checksum offloading can be confusing and having a lot of [invalid] messages on the screen can be quite annoying. As mentioned above, invalid checksums may lead to unreassembled packets, making the analysis of the packet data much harder.

 

You can do two things to avoid this checksum offloading problem:

 

*

 

Turn off the checksum offloading in the network driver, if this option is available.

*

 

Turn off checksum validation of the specific protocol in the Wireshark preferences.

 

 

Forhåpentligvis får vi noen inn her i tråden som har mer erfaring med wireshark enn meg og kan analysere OPs resultater skikkelig. Jeg vil fremdeles annbefale at det er lurt å ringe ISP og avdekke nøyaktige hvilke sperrer det er snakk om. andre og tredjehåndsinformasjon når det gjelder slike ting (når det har gått gjennom forståelsen til mindre datatekniske mennesker) er særdeles lite pålitelig.

 

En enkel løsning er å sjekke om trådstarter har gyldig eller ugyldig UDP-sjekksum på pakker som ruteren hans slipper gjennom, navneoppslag (53/UDP) er et godt eksempel.

[The Stig]

Om det skulle være av interesse

 

Snakket med Høgskolens IT-avdeling, og dessverre viste det seg at absolutt alt av UDP-porter er stengt. Fikk kjørt testen sumptrollet nevner ovenfor, og det viste seg at det var ingenting galt med UDP-pakkene ... de slapp bare aldri ut (eller inn for den saks skyld). Har heldigvis fått ordnet meg med en ny bredbåndsleverandør, så satser på en lykkelig slutt.