PING -palvelimen ohjelmointi?

PING_dataaja

PING -palvelimen ohjelmointi?

Miten voisi tehdä oman PING -palvelimen a) windowsille b ) linuxille ?

Koska ICMP -protokollassa ei ole porttinumeroita, niin jotta oma ICMP -palvelin voisi toimia, se tarkoittaa, että käyttöjärjestelmään kuuluva ICMP -palvelin täytyisi saada kytkettyä pois päältä ja saapuvat ICMP echo request -pyynnöt täytyisi saada ohjattua omalle ICMP -palvelimelle.

Mieluiten tuon toteuttaisi Windowsille (käytettävissä olisi: Win98SE, Win2000, WinXP tai Win7), mutta jos se Windowsille onnistu, niin toinen vaihtoehto olisi sitten Linuxille toteutus Windowsin sijasta.

Onnistuuko tuollaisen kirjoittaminen ns "userland" moodissa, eli Windowsissa joko EXE tai DLL, ja vastaavasti Linuxissa (mahdollisesti ROOT -oikeuksin) ajettava ohjelma?
Vai meneekö väkisin laiteajurin ohjelmoinniksi ?

Miksikö?

No, tarkoitus olisi hieman vääärinkäyttää PING -paketin sisältöä käyttäjän datan siirtoon.

Syynä se, että eräissä maissa teleoperaattori (joka toimii ISP:nä) kusettaa asiakkaitaan näin:

JOS/KUN verkossa syntyy ruuhkaa, niin PING -paketeille annetaan etuoikeus, eli siinä missä TCP ja UDP -paketteja pudotetaan jo rajusti kun verkon kapasiteetti loppuu kysyntään verrattuna kesken, niin ICMP -paketit saattavat vielä mennä läpi (toki niitäkin voidaan pudottaa, jos kaikkien TCP ja UDP -pakettien pudottaminenkaan ei auta verkon ruuhkautuneisuuteen).

Miksikö?

Noh, ilmeisesti siksi, että operaattori (joka tietää, että PING on verkon testityökalu) voi näin näyttää verkon laatuna parempaa (kun sitä PINGillä testataan) kuin laatu tosiasiassa on.

Eli operaattori käyttää rahat mieluummin ylimääräisten osinkojen maksamiseen ja yritysjohdon lisäpalkkioihin kuin siihen, että verkon kapasiteettia lisättäisiin kysyntää vastaavaksi.

Olisi tarve siirtää dataa Suomen ja tuollaisen maan välillä, jossa paikallinen operaattori toimii epärehellisesti.

20

148

    Vastaukset

    Anonyymi (Kirjaudu / Rekisteröidy)
    5000
    • Parempi ratkaisu olisi optimoida siirrettävän datan määrää ja siirtää dataa kaiken aikaa, vuorokauden ympäri ja tarvittaessa lataa valmiiksi.

      • nettiongelma

        "Parempi ratkaisu olisi optimoida siirrettävän datan määrää ja siirtää dataa kaiken aikaa, vuorokauden ympäri"

        Eipä paljon auta.

        ko. maassa on testattu: yritys ladata vaikkapa jonkun linux -jakelun ISO image, niin siinä missä Suomessa laajakaistalla tuo kestää 1-5 tuntia, ko. maassa ADSL -yhteyttä käyttäen Opera ilmjoitti arvioiduksi latausajaksi n. 14 vuorokautta.
        Ja tämä myöhään illalla, jolloin muu nettiliikenne on todennäköisesti keskimääräistä vähäisempää.

        HUOM: tarpeessa EI ole kysymys ISO imge:jen siirrosta, vaan tämä mainittiin vain esimerkkinä paikallisesta "palvelun" surkesta laadusta.

        Eli siirrettävät datamäärät eivät ole valtavia, vaan ongelma on nimenomaan operaattorin halu maksimoida voittonsa ja olla välittämättä siitä, että asiakkaan kokoma palvelun laatu on luokattoman huono.

        Ja kun maassa kaikki operaattorit toimivat samalla epäreilulla tavalla, ei operaattorin vaihto auta asiassa yhtään.

        Se, mikä voisi auttaa, olisi kahden eri operaattorin nettiyhteyden samanaikainen käyttö.

        Mutta, onnistuisiko tuo näillä välineillä:

        1) kannettava tietokone, Windows 7.

        2) D-Link DWM-156 nettitikku (tämä siis on vain 3G)

        3) Android -puhelin, jossa 4G -verkkoyhteys.

        Android -puhelin osaisi jakaa 4G -yhteytensä WLAN -tekniikalla tietokoneelle.

        Mutta, miten saisi windowsin käyttämään sekä Wi-Fi että nettitikkuyhteyttä samanaikaisesti ?


      • nettiongelma kirjoitti:

        "Parempi ratkaisu olisi optimoida siirrettävän datan määrää ja siirtää dataa kaiken aikaa, vuorokauden ympäri"

        Eipä paljon auta.

        ko. maassa on testattu: yritys ladata vaikkapa jonkun linux -jakelun ISO image, niin siinä missä Suomessa laajakaistalla tuo kestää 1-5 tuntia, ko. maassa ADSL -yhteyttä käyttäen Opera ilmjoitti arvioiduksi latausajaksi n. 14 vuorokautta.
        Ja tämä myöhään illalla, jolloin muu nettiliikenne on todennäköisesti keskimääräistä vähäisempää.

        HUOM: tarpeessa EI ole kysymys ISO imge:jen siirrosta, vaan tämä mainittiin vain esimerkkinä paikallisesta "palvelun" surkesta laadusta.

        Eli siirrettävät datamäärät eivät ole valtavia, vaan ongelma on nimenomaan operaattorin halu maksimoida voittonsa ja olla välittämättä siitä, että asiakkaan kokoma palvelun laatu on luokattoman huono.

        Ja kun maassa kaikki operaattorit toimivat samalla epäreilulla tavalla, ei operaattorin vaihto auta asiassa yhtään.

        Se, mikä voisi auttaa, olisi kahden eri operaattorin nettiyhteyden samanaikainen käyttö.

        Mutta, onnistuisiko tuo näillä välineillä:

        1) kannettava tietokone, Windows 7.

        2) D-Link DWM-156 nettitikku (tämä siis on vain 3G)

        3) Android -puhelin, jossa 4G -verkkoyhteys.

        Android -puhelin osaisi jakaa 4G -yhteytensä WLAN -tekniikalla tietokoneelle.

        Mutta, miten saisi windowsin käyttämään sekä Wi-Fi että nettitikkuyhteyttä samanaikaisesti ?

        Tai sitten kyseessä on joku banaanivaltio missä kaistaa ei yksinkertaisesti ole ulkomaailmaan niin paljoa.

        Heikkojen kaistojen maahan ladataan vaikka Debianin DVD-imaget talteen ja webistä löytyvä olennainen materiaali ladataan talteen muualla, lähetetään etanapostilla perille ja sitten asentelee siellä. Lähiverkkoon sitten toki joku oma päivityspalvelin, proxy, SMTP satelliittipalvelin jne.


      • Karvapersepaviaanille
        M-Kar kirjoitti:

        Tai sitten kyseessä on joku banaanivaltio missä kaistaa ei yksinkertaisesti ole ulkomaailmaan niin paljoa.

        Heikkojen kaistojen maahan ladataan vaikka Debianin DVD-imaget talteen ja webistä löytyvä olennainen materiaali ladataan talteen muualla, lähetetään etanapostilla perille ja sitten asentelee siellä. Lähiverkkoon sitten toki joku oma päivityspalvelin, proxy, SMTP satelliittipalvelin jne.

        Et siis taaskaan halua ymmärtä mistä on kyse ? Kyse EI ole mistään Debianin imagetiedostoista vaan kysyjä käytti niiden latausaikoja esimerkkinä yhteyksien hitaudesta.

        Kysyjän teksteistä käy varsin selvästi ilmi että tarve on kohtuullisella nopeudella pienehköjen tiedostojen tai tietojen siirrosta kohtuullisen "reaaliaikaisesti" jolloin etanapostilla lähettely ei ole toimiva vaihtoehto. Tarve on nimenomaan saada tiedot siirrettyä NETIN kautta kohtuullisella nopeudella ja keinoista toteuttaa se.

        Voisitko lopettaa tuon aivoripuleidesi levittelyn täällä kun et kerran edes halua ymmärtää mistä on kyse. Noissa soperteluissasi on usein sama ilmiö, et ole edes halunnut ymmärtää mistä on kyse vaikka kysyjän kirjoituksista selviää se ihan selvästi.


      • Karvapersepaviaanille kirjoitti:

        Et siis taaskaan halua ymmärtä mistä on kyse ? Kyse EI ole mistään Debianin imagetiedostoista vaan kysyjä käytti niiden latausaikoja esimerkkinä yhteyksien hitaudesta.

        Kysyjän teksteistä käy varsin selvästi ilmi että tarve on kohtuullisella nopeudella pienehköjen tiedostojen tai tietojen siirrosta kohtuullisen "reaaliaikaisesti" jolloin etanapostilla lähettely ei ole toimiva vaihtoehto. Tarve on nimenomaan saada tiedot siirrettyä NETIN kautta kohtuullisella nopeudella ja keinoista toteuttaa se.

        Voisitko lopettaa tuon aivoripuleidesi levittelyn täällä kun et kerran edes halua ymmärtää mistä on kyse. Noissa soperteluissasi on usein sama ilmiö, et ole edes halunnut ymmärtää mistä on kyse vaikka kysyjän kirjoituksista selviää se ihan selvästi.

        Ei ole, mutta tuolla ongelma ratkeaa tehokkaasti. Parin vuoden välein lähettää etanapostilla datat ja sitten vaan se sisäverkon cachetietokone vuorokauden ympäri päälle siirtämään dataa.

        Sellaisia etukäteen kopioitavia asioita voi olla esim. juurikin ohjelmistot kaikessa laajudessa, erilaiset dokumentaatiot, wikipedia jne. ja sitten tosiaankin sisäverkkoon se SMTP, proxy, päivitysten jakelu ja tosiaankin voidaan taustalla myös laittaa käytetyille webbipalveluille esilatauksen päälle, että täytetään datat sinne proxyyn etukäteen.


      • Karvaperseidiootille
        M-Kar kirjoitti:

        Ei ole, mutta tuolla ongelma ratkeaa tehokkaasti. Parin vuoden välein lähettää etanapostilla datat ja sitten vaan se sisäverkon cachetietokone vuorokauden ympäri päälle siirtämään dataa.

        Sellaisia etukäteen kopioitavia asioita voi olla esim. juurikin ohjelmistot kaikessa laajudessa, erilaiset dokumentaatiot, wikipedia jne. ja sitten tosiaankin sisäverkkoon se SMTP, proxy, päivitysten jakelu ja tosiaankin voidaan taustalla myös laittaa käytetyille webbipalveluille esilatauksen päälle, että täytetään datat sinne proxyyn etukäteen.

        Et siis todellakaan ymmärrä...

        "Kysyjän teksteistä käy varsin selvästi ilmi että tarve on kohtuullisella nopeudella pienehköjen tiedostojen tai tietojen siirrosta kohtuullisen "reaaliaikaisesti" jolloin etanapostilla lähettely ei ole toimiva vaihtoehto. "

        Ja karvapersepaviaani lässyttää "Ei ole, mutta tuolla ongelma ratkeaa tehokkaasti. Parin vuoden välein lähettää etanapostilla datat"

        Etkö todellakaan kykene ymmärtämään termiä REAALIAIKAISESTI ?? Ilmeisesti et kun edelleen lässytät tuosta etanapostista. Tosin et tunnu juuri muulloinkaan ymmärtävän mitään joten voisitko poistua sotkemasta palstaa aivoripuleillasi.


      • Karvaperseidiootille kirjoitti:

        Et siis todellakaan ymmärrä...

        "Kysyjän teksteistä käy varsin selvästi ilmi että tarve on kohtuullisella nopeudella pienehköjen tiedostojen tai tietojen siirrosta kohtuullisen "reaaliaikaisesti" jolloin etanapostilla lähettely ei ole toimiva vaihtoehto. "

        Ja karvapersepaviaani lässyttää "Ei ole, mutta tuolla ongelma ratkeaa tehokkaasti. Parin vuoden välein lähettää etanapostilla datat"

        Etkö todellakaan kykene ymmärtämään termiä REAALIAIKAISESTI ?? Ilmeisesti et kun edelleen lässytät tuosta etanapostista. Tosin et tunnu juuri muulloinkaan ymmärtävän mitään joten voisitko poistua sotkemasta palstaa aivoripuleillasi.

        "Etkö todellakaan kykene ymmärtämään termiä REAALIAIKAISESTI ??"

        Ymmärrän oikein hyvin. Pienehkö tiedosto käytännössä reaaliaikaisesti kun kaista on vapaa, vaikka sitä kaistaa olisi vähän. Ja se taas onnistuu kaistan käytön optimoinnilla.


      • Karvperseidiootille
        M-Kar kirjoitti:

        "Etkö todellakaan kykene ymmärtämään termiä REAALIAIKAISESTI ??"

        Ymmärrän oikein hyvin. Pienehkö tiedosto käytännössä reaaliaikaisesti kun kaista on vapaa, vaikka sitä kaistaa olisi vähän. Ja se taas onnistuu kaistan käytön optimoinnilla.

        Eli siis et halua tai et kykene ymmärtämään.

        Aloittaja kertoi selkeästi että yhteys ei toimi riittävän hyvin normaaleilla protokollilla. Eli lopeta tuo urpoilusi ja YRITÄ edes ymmärtää mistä on kyse, jos et kykene ymmärtämään niin pidä pääsi kiinni äläkä sotke palstaa noilla aivopieruillasi.


      • Karvperseidiootille kirjoitti:

        Eli siis et halua tai et kykene ymmärtämään.

        Aloittaja kertoi selkeästi että yhteys ei toimi riittävän hyvin normaaleilla protokollilla. Eli lopeta tuo urpoilusi ja YRITÄ edes ymmärtää mistä on kyse, jos et kykene ymmärtämään niin pidä pääsi kiinni äläkä sotke palstaa noilla aivopieruillasi.

        "Aloittaja kertoi selkeästi että yhteys ei toimi riittävän hyvin normaaleilla protokollilla."

        Ja minä kerroin kuinka saa sen kaistan riittämään paremmin. Eli kun on kaista tyhjätty, että kaiken kaistan saa varattua tiedonsiirrolle ettei mene esim. päivityksiin tai sähköposteihin niin sitten voin kertoa lisää miten data kompressoidaan pienemmäksi.

        Eli laittaa ne normaalit protokollat riittämään, käy paljon helpommin niin.

        YRITÄ edes ymmärtää, että jos nettiyhteys on hidas niin poistaa sieltä kuormasta 90% vaikka pois, että saa täydet 100% vapaaksi ja kutistaa sen 2Mt tiedoston vaikka 100kt niin homma käy 200x nopeammin sen jälkeen.


    • MS_Info
    • älämietiturhia

      Lähetä data USB-tikussa paperisena kirjeenä.

    • wZRVJC7

      Operaattorin palomuuri tulkitsisi hyvin nopeasti tuon ping floodiksi ja löisi yhteyden poikki.

      • PING_dataaja

        "Operaattorin palomuuri tulkitsisi hyvin nopeasti tuon ping floodiksi ja löisi yhteyden poikki."

        Siis kumman/minkä operaattorin?

        Jos ulkomailta lähetetään ICMP echo request -paketteja minun Suomessa hallitsemaan laajakaistaliittymään, jossa itse ohjelmoimani PING -palvelin vastaa niihin, niin kumman operaattorin uskot sensuroivan nettiliikennettä:

        ulkomaisen operaattorin lähtöpäässä, johon vastapuoli on yhteydessä vai oman laajakaistaoperaattorini Suomessa, vai kenties jokin kolmas taho noiden kahden maan välillä?

        Kyseinen muu maa on Aasiassa, ja tietojeni mukaan Aasian ja Euroopan välillä ei ole suoraa tietoliikenneyhteyttä, vaan kaikki data ko. välillä kiertää USA:n kautta, ikävä kyllä.

        Tai sitten paikalliset liikemiehet eivät viitsineet asentaa omaa valokaapeliyhteyttä, vaan mieluummin vuokrasivat kansainväliset internet -siirtopalvelut esim. AT&T Global Services -yhtiöltä.

        Mikäli oma laajakaistaoperaattorini alkaa paketteja sensuroimaan, voin toki Suomessa valittaa ko. yhtiölle aiheettomasta sensuroinnista, ja jos se ei johda toimenpiteisiin, niin viestintävirastolle.

        Tosin valitettavasti viestintävirastolle valittaminen ei aina johda toimenpiteisiin, heillä kun on ikävä tapa olla operaattorin puolella, jos asiakkaan ja operaattorin välille syntyy ristiriitatilanne.

        Kerrottakoon nyt vielä lisää:

        Tarkoitus olisi siirtää digitoitua puhetta reaaliajassa, hieman vastaavaan tapaan kuin esim. Skype toimii.

        Jos puheen pakkaa esim. GSM -koodekilla (joka on sisäänrakennettuna kaikissa windowseissa aina Win98:sta alkaen, ehkä jopa Win95ssa) niin siirtonopeustarve on 13 kbps.

        Eli ei tämä ole nopeudesta kiinni, vaan luotettavuudesta.

        Hitainkin laajakaista riittäisi paremmin kuin hyvin, jos vain datapaketteja ei katoaisi matkalla.

        Mutta jos packet loss rate heiluu 50%-100% välillä, niin TÄMÄ on se ongelma, ei suinkaan nopeus.

        Jo lankapuhelinmodeemien aikakaudella: jopa 28800 bps modeemiyhteys saattaisi riittää 13 kbps käyttäjän datan siirtoon.

        14400 bps modeemi siirtää 14400 linjabittiä sekunnissa, mutta noista jokainen 8 bitin tavu kuluttaa linjalla 10 bittiä, kun 8 databittiin lisätään start -bitti alkuun ja stop -bitti loppuun. Eli 14400 bps modeemi tosiasiassa siirtää 11520 bittiä sekunnissa, eli eipä riitä 13000 bps pakatun puhedatan siirtoon. Tästä syystä siis 28800 bps modeemiyhteys on se hitain, joka riittäisi tarkoitukseen.


        HUOM: Tässä EI ole tarkoitus alkaa lankapuhelinmodeemilla leikkimään, ei ole enää lankapuhelinliittymääkään.

        lankapuhelinmodeemi mainittiin vain sen korostamiseksi, että kyse ei ole niinkään nopeudesta, vaan siirron luotettavuudesta.

        Eli, jos paketeista osa katoaa matkan varrelle, niin tätä varten pitäisi joku vastalääke keksiä.

        No, PING -palvelimen lisäksi asiaan saattaisi kuulua esim. Galois Field -matematiikan opettelu. Saattaisi olla mainio vastalääke pakettien katoamiseen, mutta haittapuolena tuosta on siirtoviiveen kasvaminen.


      • PING_dataaja kirjoitti:

        "Operaattorin palomuuri tulkitsisi hyvin nopeasti tuon ping floodiksi ja löisi yhteyden poikki."

        Siis kumman/minkä operaattorin?

        Jos ulkomailta lähetetään ICMP echo request -paketteja minun Suomessa hallitsemaan laajakaistaliittymään, jossa itse ohjelmoimani PING -palvelin vastaa niihin, niin kumman operaattorin uskot sensuroivan nettiliikennettä:

        ulkomaisen operaattorin lähtöpäässä, johon vastapuoli on yhteydessä vai oman laajakaistaoperaattorini Suomessa, vai kenties jokin kolmas taho noiden kahden maan välillä?

        Kyseinen muu maa on Aasiassa, ja tietojeni mukaan Aasian ja Euroopan välillä ei ole suoraa tietoliikenneyhteyttä, vaan kaikki data ko. välillä kiertää USA:n kautta, ikävä kyllä.

        Tai sitten paikalliset liikemiehet eivät viitsineet asentaa omaa valokaapeliyhteyttä, vaan mieluummin vuokrasivat kansainväliset internet -siirtopalvelut esim. AT&T Global Services -yhtiöltä.

        Mikäli oma laajakaistaoperaattorini alkaa paketteja sensuroimaan, voin toki Suomessa valittaa ko. yhtiölle aiheettomasta sensuroinnista, ja jos se ei johda toimenpiteisiin, niin viestintävirastolle.

        Tosin valitettavasti viestintävirastolle valittaminen ei aina johda toimenpiteisiin, heillä kun on ikävä tapa olla operaattorin puolella, jos asiakkaan ja operaattorin välille syntyy ristiriitatilanne.

        Kerrottakoon nyt vielä lisää:

        Tarkoitus olisi siirtää digitoitua puhetta reaaliajassa, hieman vastaavaan tapaan kuin esim. Skype toimii.

        Jos puheen pakkaa esim. GSM -koodekilla (joka on sisäänrakennettuna kaikissa windowseissa aina Win98:sta alkaen, ehkä jopa Win95ssa) niin siirtonopeustarve on 13 kbps.

        Eli ei tämä ole nopeudesta kiinni, vaan luotettavuudesta.

        Hitainkin laajakaista riittäisi paremmin kuin hyvin, jos vain datapaketteja ei katoaisi matkalla.

        Mutta jos packet loss rate heiluu 50%-100% välillä, niin TÄMÄ on se ongelma, ei suinkaan nopeus.

        Jo lankapuhelinmodeemien aikakaudella: jopa 28800 bps modeemiyhteys saattaisi riittää 13 kbps käyttäjän datan siirtoon.

        14400 bps modeemi siirtää 14400 linjabittiä sekunnissa, mutta noista jokainen 8 bitin tavu kuluttaa linjalla 10 bittiä, kun 8 databittiin lisätään start -bitti alkuun ja stop -bitti loppuun. Eli 14400 bps modeemi tosiasiassa siirtää 11520 bittiä sekunnissa, eli eipä riitä 13000 bps pakatun puhedatan siirtoon. Tästä syystä siis 28800 bps modeemiyhteys on se hitain, joka riittäisi tarkoitukseen.


        HUOM: Tässä EI ole tarkoitus alkaa lankapuhelinmodeemilla leikkimään, ei ole enää lankapuhelinliittymääkään.

        lankapuhelinmodeemi mainittiin vain sen korostamiseksi, että kyse ei ole niinkään nopeudesta, vaan siirron luotettavuudesta.

        Eli, jos paketeista osa katoaa matkan varrelle, niin tätä varten pitäisi joku vastalääke keksiä.

        No, PING -palvelimen lisäksi asiaan saattaisi kuulua esim. Galois Field -matematiikan opettelu. Saattaisi olla mainio vastalääke pakettien katoamiseen, mutta haittapuolena tuosta on siirtoviiveen kasvaminen.

        Rakenna softa niin, että puheenlähetys tapahtuu nappia painamalla. Vähän niinkuin LA-puhelimissa. Ääntä voidaan lähettää vaikka sekunnin palasissa TCP:nä ja niitä lähetetään sitä tahtia miten pystytään. Kun napista päästetään irti, loppuu äänen lähetys.

        Homman juju se, että puhe voidaan aloittaa toisessa päässä kesken lähetyksen kun ensimmäisiä paketteja tullut kun niitä voidaan puskuroida. Toki siinä on latenssia se pari sekuntia tms.

        Noita parametreja voi kyllä sitten säätää niin mikä toimii optimaalisesti.


    • Dkfkfkdkdkkdf

      Hanki parempi liittymä ja tee mittaukset tcp/udp:llä äläkä icmp:llä.

    • japsus

      Hei!

      Itse olen törmännyt samaiseen ongelmaan ulkomailla, koska palveluntarjoaja asettaa siirtorajoja, joiden ylittymisestä seuraa yhteyden hidastaminen. Muutamia kertoja olen hotelleissa törmännyt myös maksulliseen wifiin, joka on avoin verkko, mutta vaatii maksulliset tunnukset. Joskus näitä on myös lentokentillä, jotka haluaisivat luottokorttitiedot.

      Näissä tapauksissa usein pingaaminen on sallittua, minkä vuoksi rajoitus on kohtalaisen helppo kiertää juurikin käyttömällä eri protokollaa.

      Jos todella haluat muokata ping servicen koodeja, sanoisin sen onnistuvan Linuxissa lataamalla kernelin lähdekoodit ja muokkaamalla sieltä käsin vastauspaketta. Tämä ei kuitenkaan mielestäni ole paras ratkaisu ongelmaan. Sen sijaan sinun tulisi käyttää tcp/udp-pakettien icmp-tunnelointia.

      Tälle on olemassa jo valmiit ohjelmat. Esimerkiksi Linuxissa olen käyttänyt joskus ptunnel-ohjelmaa. Sen voit ladata esim. täältä:
      http://pkgs.repoforge.org/ptunnel/

      Toinen vaihtoehto on käyttää esim. ohjelmaa nimeltä icmptx. Asentuu ubuntuu yhdellä lauseella kätevästi. (apt-get install icmptx)

      Tokihan Linux luonnostaa pyrkii vastailemaan pingeihin. Itse olen yksinkertaisesti vain kieltänyt kerneliä vastaamasta icmp-pingeihin käskyllä:
      echo 1 > /proc/sys/ten/ipv4/icmp_echo_ignore_all
      Tämän jälkeen on ollut aika simppeliä vain antaa ohjelman hoitaa kommunikointi ja uudelleen ohjauksen minun puolestani.

      Jos tosiaan haluaa alkaa itse koodata ohjelmaa, en näe toki mitään estettä siihen. Minun mielestäni siinä voit käyttää esim. pythonia tai C -kieltä. Ohjelmaan tarvinnee koodata server- ja client-puoli ohjelmaan. Client voi toimia ikään kuin proxyna, ottaa vastaan tcp-liikenteen ja lähettää sen kohteeseen icmp-paketteina. Siellä palvelimella, jossa server-puoli on käytössä, pitää tosiaan tuo icmp-pingeihin vastaaminen ottaa pois päältä, jottei se client saa turhia vastauksia. Sitten server-puolen pitää purkaa paketit ja välittää eteen päin.

      Pythonille löytyy valmiita kirjastoja verkkokäyttöön melko hyvin, eikä tuollainen softa taida ihmeitä vaatia, jos sen itsekin haluaa tehdä. Taitaapi tuollaiseen ohjelmaan riittää ihan koodin alkuun: import socket.

      Toivottavasti tämä nyt auttoi vähän ja vastasi aloittajan kysymykseen edes jokseenkin.

      • ping_as_transfermedia

        muuten hyvä, MUTTA:

        JOS asetuksella hoidan asian niin, että KERNEl EI vastaa ping -pyyntöihin, niin:

        Kun Ping (eli ICMP) protokollassa EI ole porttinumeroita, niin miten saan KERNELin tajuamaan, että juuri minun omatekemä ohjelma on se, jolla on oikeus vastaanottaa tulevat "ICMP ECHO REQUEST" -pyynnöt, ja miten vastaan niihin "ICMP ECHO REPLY" -vastauksella ?

        Olisit nämä voinut mainita, esim. sitten C -kielen syntaksin mukaisesti ?

        JOS viittaat API -kutsuihin, niin laita funktioista:

        funktion nimi, missä DLL:ssä (windows) tai .so :ssa (linux) funktio on exportoitu

        sekä

        funktion prototyyppi.


    • envastaileturhiin

      ICMP- palveluna on avain tietomurtoon, ainakin hakkeri niin kehui. Ubuntussa vastaaminen kyseisiin kaikuitteliuhin loppuu kun korjaa tiedostossa /etc/ufw/before.rules näyttämään tuolta:
      # ok icmp codes for INPUT
      -A ufw-before-input -p icmp --icmp-type destination-unreachable -j DROP
      -A ufw-before-input -p icmp --icmp-type source-quench -j DROP
      -A ufw-before-input -p icmp --icmp-type time-exceeded -j DROP
      -A ufw-before-input -p icmp --icmp-type parameter-problem -j DROP
      -A ufw-before-input -p icmp --icmp-type echo-request -j DROP
      Eli tuossa on tuo DROP se muutos ;)

    • kaikkipois
    • notuopaoliavuliasta

      Mitenkä ihmeessä tietomurrot ja icmp-pakettien droppaus liittyy aloittajan kysymykseen? Mitenkä ajattelit saada aloittajan ohjelman toimimaan ja siirtämään tietoa, jos juuri blokkaat sen väylän?

      Sama kuin koodaisi internetpalvelinta, sanoisi se olevan avain tietomurtoon ja käskisi kirjoittaa: iptables -A INPUT -p tcp --destionation-port 80 -j DROP

    Ketjusta on poistettu 0 sääntöjenvastaista viestiä.

    Luetuimmat keskustelut

    1. Baaritappelu

      Hurjaksi käynyt meno Laffassa. Jotain jätkää kuristettu ja joutunu teholle...
      Kokkola
      67
      6519
    2. Tappo Kokkolassa

      Päivitetty tänään Iltalehti 17.04.2024 Klo: 15:23..Mikähän tämä tapaus nyt sitten taas on.? Henkirikos Kokkolassa on tap
      Kokkola
      27
      4203
    3. Miksi tytöt feikkavat saaneensa orgasmin, vaikka eivät ole saaneet?

      Eräs ideologia itsepintaisesti väittää, että miehet haluavat työntää kikkelinsä vaikka oksanreikään, mutta tämä väite ei
      Sinkut
      270
      2607
    4. Poliisit vaikenee ja paikallinen lehti

      Poliisit vaikenee ja paikallinen lehti ei kerro taposta taaskaan mitään. Mitä hyötyä on koko paikallislehdestä kun ei
      Kokkola
      26
      2030
    5. MAKEN REMPAT

      Tietääkö kukaan missä tämmöisen firman pyörittäjä majailee? Jäi pojalla hommat pahasti kesken ja rahat muisti ottaa enna
      Suomussalmi
      30
      1548
    6. Mitä ihmettä

      Kaipaat hänessä
      Ikävä
      97
      1397
    7. Itämaisesta filosofiasta kiinnostuneille

      Itämaisesta filosofiasta kiinnostuneille. Nämä linkit voivat auttaa pääsemään niin sanotusti alkuun. https://keskustel
      Hindulaisuus
      304
      1107
    8. Kuntoutus osasto Ähtärin tk vuode osasto suljetaan

      5 viikkoa ja mihin työntekijät, mihin potilaat. Mikon sairaalan lopetukset saivat nyt jatkoa. Alavudelle Liisalle tulee
      Ähtäri
      55
      1101
    9. Välillä käy mielessä

      olisiko sittenkin ollut parempi, että emme koskaan olisi edes tavanneet. Olisi säästynyt monilta kyyneleiltä.
      Ikävä
      77
      1046
    10. Mulla on kyllä

      Järkyttävä ikävä sua. Enkä yhtään tykkää tästä olotilastani. Levoton olo. Ja vähän pelottaa..
      Ikävä
      39
      1031
    Aihe