ugrás a tartalomhoz

Hogyan kapjak el ARP broadcast-et?

inf · 2017. Jún. 22. (Cs), 17.29
Ezzel próbálkozok: https://github.com/mscdex/cap, de egyelőre nem állt még össze a kép, hogy hogyan kéne beállítani ahhoz, hogy ARP broadcast-eket fogjon. Minden tippet szívesen fogadok. Úgy tudom, hogy elég ismeretlen lokális IP-vel pingelni a router-t, hogy kiküldjön egy ARP broadcast-et, szóval a tesztelés nem gond, viszont az elkapás nem igazán megy. Szerintem maga a cucc működhet, csak a beállításaimmal lehet a gond. A példakóddal próbálkoztam, csak az IP-t írtam át benne, az se volt világos, hogy mire kell átírni, de gondolom mást is át kéne állítani még ezen kívül, hogy menjen. Ma jobban beletúrok majd a dokumentációba, meg talán az elméleti részébe is, tegnap csak ennyire futotta.
 
1

Egyelőre addig jutottam, hogy

inf · 2017. Jún. 22. (Cs), 19.30
Egyelőre addig jutottam, hogy ez a fajta példakód nem jó ARP elkapására:
var c = new Cap(),
    device = Cap.findDevice('192.168.0.10'),
    filter = 'tcp and dst port 80',
    bufSize = 10 * 1024 * 1024,
    buffer = new Buffer(65535);

var linkType = c.open(device, filter, bufSize, buffer);

c.setMinBytes && c.setMinBytes(0);

c.on('packet', function(nbytes, trunc) {
  console.log('packet: length ' + nbytes + ' bytes, truncated? '
              + (trunc ? 'yes' : 'no'));

  // raw packet data === buffer.slice(0, nbytes)

  if (linkType === 'ETHERNET') {
    var ret = decoders.Ethernet(buffer);

    if (ret.info.type === PROTOCOL.ETHERNET.IPV4) {
      console.log('Decoding IPv4 ...');

      ret = decoders.IPV4(buffer, ret.offset);
      console.log('from: ' + ret.info.srcaddr + ' to ' + ret.info.dstaddr);

      if (ret.info.protocol === PROTOCOL.IP.TCP) {
        var datalen = ret.info.totallen - ret.hdrlen;

        console.log('Decoding TCP ...');

        ret = decoders.TCP(buffer, ret.offset);
        console.log(' from port: ' + ret.info.srcport + ' to port: ' + ret.info.dstport);
        datalen -= ret.hdrlen;
        console.log(buffer.toString('binary', ret.offset, ret.offset + datalen));
      } else if (ret.info.protocol === PROTOCOL.IP.UDP) {
        console.log('Decoding UDP ...');

        ret = decoders.UDP(buffer, ret.offset);
        console.log(' from port: ' + ret.info.srcport + ' to port: ' + ret.info.dstport);
        console.log(buffer.toString('binary', ret.offset, ret.offset + ret.info.length));
      } else
        console.log('Unsupported IPv4 protocol: ' + PROTOCOL.IP[ret.info.protocol]);
    } else
      console.log('Unsupported Ethertype: ' + PROTOCOL.ETHERNET[ret.info.type]);
  }
});
Létezik uARP, ami 219-es porton megy, de olyan nincs az én rendszeremben a teszt szerint. A normal ARP meg egy réteggel lentebb megy, nem port-hoz kötött. A 80-as porton viszont elég jól elkapja a TCP kommunikációt a fenti kód.
3

Problema

janoszen · 2017. Jún. 22. (Cs), 20.06
Itt a problema:

if (ret.info.type === PROTOCOL.ETHERNET.IPV4) {


Az ARP csomag nem IP csomag.

Raadasul arra is erdemes figyelni, hogy az ethertype 1500 alatti ertekekre nem a csomagtipust, hanem a csomagmeretet jeloli.
6

Na

janoszen · 2017. Jún. 23. (P), 08.33
Na, akkor innen probalkozz tovabb:

var Cap = require('cap').Cap,
    decoders = require('cap').decoders,
    PROTOCOL = decoders.PROTOCOL;

var c = new Cap(),  
    device = Cap.findDevice('192.168.0.10'),
    //Ez fontos, ez parameterezi a libpcap/winpcap filtereit.
    filter = 'arp',  
    bufSize = 10 * 1024 * 1024,  
    buffer = new Buffer(65535);  
  
var linkType = c.open(device, filter, bufSize, buffer);  
  
c.setMinBytes && c.setMinBytes(0);  
  
c.on('packet', function(nbytes, trunc) {  
  console.log('packet: length ' + nbytes + ' bytes, truncated? '  
              + (trunc ? 'yes' : 'no'));  
  
  // raw packet data === buffer.slice(0, nbytes)  
  
  if (linkType === 'ETHERNET') {  
    var ret = decoders.Ethernet(buffer);  
  
    //Ez is fontos, kulonben nem a megfelelore matchelsz.
    if (ret.info.type === PROTOCOL.ETHERNET.ARP) {  
      console.log('Decoding ARP ...');  
    } else {
      console.log('Unsupported Ethertype: ' + PROTOCOL.ETHERNET[ret.info.type]);  
    }
  }  
});
Ez elkapja neked az ARP csomagot, mar csak dekodolni kell. Nekem Linuxon rootkent inditva mukodik. Windowson tudtommal nem kell a rendszergazda jog, a winpcap anelkul is mukodik.
9

Köszi! Nem sokára lesz egy

inf · 2017. Jún. 23. (P), 19.30
Köszi! Nem sokára lesz egy kis időm tesztelni. Kíváncsi vagyok összejön e Windows alatt is.
10

Úgy néz ki működik, bár csak

inf · 2017. Jún. 24. (Szo), 01.57
Úgy néz ki működik, bár csak mac address-eket látok a console.log(JSON.stringify(ret));-el, helyi ip címeket nem.

Az normális, hogy néhány perc alatt több, mint 100 ilyen kérés jön-megy a hálózaton? Sokkal kevesebbre számítottam, meg arra, hogy csak a connect box felől és felé mennek ezek, de nagyjából minden küld mindennek ilyen ARP request-eket, broadcasteket. Ez lehet a neighbor discovery? Mindig ki akartam próbálni a neurális hálókat, hogy mire képesek, azzal tervezem, hogy elkülönítem az automata és emberi kéréseket. Kíváncsi vagyok mire jutok vele. Egyik ismerősöm ilyesmikkel dolgozik, és azt mondja olyat is el tudott már érni velük, hogy független változókat megmond a program, pl hogy milyen szögből fényképezték a kocsit, anélkül, hogy tudná milyen típusú kocsiról van szó.

Ami még érdekes, hogy egy eszközt nem tudtam beazonosítani MAC alapján. Gondolom a connect box lehet, mert az első 3 szám ugyanaz benne, mint amit az admin oldalán látok, de a többi mégis más.
11

Ami

janoszen · 2017. Jún. 24. (Szo), 07.50
Amit sztem kicsit felreertesz az az, hogy az ethernet keret forras es celcimenek semmi koze az ARP csomagban hirdetett cimhez. Barki hirdethet barkinek a neveben. Ahhoz, hogy megkapd a szukseges informaciokat, dekodolnod kell az ARP csomagokat amik az ethernet keretben vannak. A fenti peldaban ezek meg binaris formaban vannak, szoval nem fogod latni a kimenetben.

Ami a tanulast illeti, igen, teljesen normalis hogy percenkent tobb szaz ilyen keres megy a halozaton, kulonosen ha tobb eszkozod van. Irhatsz erre a feladatra neuralis halot vagy genetikai tanulo algoritmust, de ez egyreszt agyuval verebre, masreszt az ARP csomagban onmagaban nincs elegendo informacio egy ilyen dontes meghozatalara, akarmilyen AI-t is teszel moge. Egy layer 3 proxy a megfelelo megoldas itt.

Ami a Neighbor Discoveryt illeti, nem, az IPv6 ONLY, IPv4-es halozatnal CSAK ARP van. Az elso harom szam a MAC addressekben a vendor prefix, vagyis nagyreszt azonos gyartotol szarmazo chipeid vannak
13

Ja, éreztem, hogy hiányos ez

inf · 2017. Jún. 24. (Szo), 08.57
Ja, éreztem, hogy hiányos ez így. Megpróbálom majd dekódolni, úgysem sűrűn játszok bináris dolgokkal.

Tudnál ajánlani olyan TCP, UDP proxy-t, amivel megoldható mindez? Gondolom azért bele kell valahogy fejleszteni az esemény kezelést.

Esetleg van rá mód, hogy ehhez az ismeretlen, de gyaníthatóan a connect box-hoz tartozó MAC address-hez IP címet rendeljek? Én is azért gondoltam, hogy a connect box lehet, mert ugyanaz a gyártója a chip-nek.

Érdekes, pedig nem tűnik IPv6-nak az itthoni háló a modem info, ipconfig, stb. alapján. Mellékelek egy részletet, amiből kiszűrtem minden felesleges sallangot, nagyjából ilyen a forgalom 2-3 perc alatt:
{"destination":"{##kukac##inf3rno-PC.mac}","source":"{@connect-box?.mac}", "length": "42 bytes"}
{"destination":"{@connect-box?.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "42 bytes"}
{"destination":"{@connect-box?.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "60 bytes"}
{"destination":"{##kukac##inf3rno-PC.mac}","source":"{@connect-box?.mac}", "length": "42 bytes"}

$ ping {##kukac##nem-letezo.ip} -->

{"destination":"{##kukac##broadcast-ff*.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "42 bytes"}
{"destination":"{##kukac##broadcast-ff*.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "42 bytes"}
{"destination":"{##kukac##broadcast-ff*.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "42 bytes"}
{"destination":"{##kukac##broadcast-ff*.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "42 bytes"}
{"destination":"{##kukac##broadcast-ff*.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "42 bytes"}
{"destination":"{##kukac##broadcast-ff*.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "42 bytes"}
{"destination":"{##kukac##broadcast-ff*.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "42 bytes"}
{"destination":"{##kukac##broadcast-ff*.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "42 bytes"}
{"destination":"{##kukac##broadcast-ff*.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "42 bytes"}
{"destination":"{##kukac##broadcast-ff*.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "42 bytes"}
{"destination":"{##kukac##broadcast-ff*.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "42 bytes"}
{"destination":"{##kukac##broadcast-ff*.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "42 bytes"}
{"destination":"{##kukac##broadcast-ff*.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "60 bytes"}

<-- ping end

{"destination":"{##kukac##inf3rno-PC.mac}","source":"{##kukac##Laci-PC.mac}", "length": "60 bytes"}
{"destination":"{##kukac##inf3rno-PC.mac}","source":"{##kukac##Laci-PC.mac}", "length": "42 bytes"}
{"destination":"{##kukac##Laci-PC.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "60 bytes"}
{"destination":"{##kukac##inf3rno-PC.mac}","source":"{@connect-box?.mac}", "length": "42 bytes"}
{"destination":"{@connect-box?.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "42 bytes"}
{"destination":"{@connect-box?.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "60 bytes"}
{"destination":"{##kukac##inf3rno-PC.mac}","source":"{@connect-box?.mac}", "length": "42 bytes"}
{"destination":"{@connect-box?.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "60 bytes"}
{"destination":"{##kukac##inf3rno-PC.mac}","source":"{@connect-box?.mac}", "length": "60 bytes"}
{"destination":"{##kukac##inf3rno-PC.mac}","source":"{@connect-box?.mac}", "length": "42 bytes"}
{"destination":"{@connect-box?.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "42 bytes"}
{"destination":"{@connect-box?.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "60 bytes"}
{"destination":"{##kukac##inf3rno-PC.mac}","source":"{@connect-box?.mac}", "length": "60 bytes"}
{"destination":"{##kukac##inf3rno-PC.mac}","source":"{@connect-box?.mac}", "length": "42 bytes"}
{"destination":"{@connect-box?.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "42 bytes"}
{"destination":"{@connect-box?.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "60 bytes"}
{"destination":"{##kukac##inf3rno-PC.mac}","source":"{@connect-box?.mac}", "length": "60 bytes"}
{"destination":"{##kukac##inf3rno-PC.mac}","source":"{@connect-box?.mac}", "length": "42 bytes"}
{"destination":"{@connect-box?.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "60 bytes"}
{"destination":"{##kukac##broadcast-ff*.mac}","source":"{##kukac##Laci-PC.mac}", "length": "60 bytes"}
{"destination":"{##kukac##broadcast-ff*.mac}","source":"{##kukac##Laci-PC.mac}", "length": "60 bytes"}
{"destination":"{##kukac##broadcast-ff*.mac}","source":"{##kukac##Laci-PC.mac}", "length": "60 bytes"}
{"destination":"{##kukac##broadcast-ff*.mac}","source":"{##kukac##Laci-PC.mac}", "length": "42 bytes"}
{"destination":"{##kukac##broadcast-ff*.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "60 bytes"}
{"destination":"{##kukac##broadcast-ff*.mac}","source":"{##kukac##Laci-PC.mac}", "length": "42 bytes"}
{"destination":"{##kukac##broadcast-ff*.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "60 bytes"}
{"destination":"{##kukac##inf3rno-PC.mac}","source":"{##kukac##Laci-PC.mac}", "length": "60 bytes"}
{"destination":"{##kukac##inf3rno-PC.mac}","source":"{##kukac##Laci-PC.mac}", "length": "42 bytes"}
{"destination":"{@connect-box?.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "60 bytes"}
{"destination":"{##kukac##inf3rno-PC.mac}","source":"{@connect-box?.mac}", "length": "60 bytes"}
{"destination":"{##kukac##inf3rno-PC.mac}","source":"{@connect-box?.mac}", "length": "42 bytes"}
{"destination":"{@connect-box?.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "60 bytes"}
{"destination":"{##kukac##inf3rno-PC.mac}","source":"{@connect-box?.mac}", "length": "42 bytes"}
{"destination":"{@connect-box?.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "42 bytes"}
{"destination":"{@connect-box?.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "60 bytes"}
{"destination":"{##kukac##inf3rno-PC.mac}","source":"{@connect-box?.mac}", "length": "60 bytes"}
{"destination":"{##kukac##inf3rno-PC.mac}","source":"{@connect-box?.mac}", "length": "42 bytes"}
{"destination":"{@connect-box?.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "60 bytes"}
{"destination":"{##kukac##inf3rno-PC.mac}","source":"{@connect-box?.mac}", "length": "42 bytes"}
{"destination":"{@connect-box?.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "42 bytes"}
{"destination":"{@connect-box?.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "60 bytes"}
{"destination":"{##kukac##inf3rno-PC.mac}","source":"{@connect-box?.mac}", "length": "60 bytes"}
{"destination":"{##kukac##inf3rno-PC.mac}","source":"{@connect-box?.mac}", "length": "42 bytes"}
{"destination":"{@connect-box?.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "42 bytes"}
{"destination":"{@connect-box?.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "60 bytes"}
{"destination":"{##kukac##inf3rno-PC.mac}","source":"{@connect-box?.mac}", "length": "60 bytes"}
{"destination":"{##kukac##inf3rno-PC.mac}","source":"{@connect-box?.mac}", "length": "42 bytes"}
{"destination":"{@connect-box?.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "42 bytes"}
{"destination":"{##kukac##broadcast-ff*.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "60 bytes"}
{"destination":"{##kukac##inf3rno-PC.mac}","source":"{@connect-box?.mac}", "length": "60 bytes"}
{"destination":"{##kukac##inf3rno-PC.mac}","source":"{@connect-box?.mac}", "length": "42 bytes"}
{"destination":"{@connect-box?.mac}","source":"{##kukac##inf3rno-PC.mac}", "length": "42 bytes"}
Úgy nézem kétféle csomag mehet, az egyik 42, a másik 60 bájtos, a csomagok nagy része nem broadcast (ff:ff:ff:ff:ff:ff), szóval viszonylag jól szűrhető. Így is bizonytalan, hogy egy tanuló algoritmus el tudja különíteni az emberi használatot a gépitől ez alapján. Nyilván nem számítok ezzel kapcsolatban 100%-os eredményre, inkább olyasmire, hogy azért az esetek 90%-ában nem kapcsol be este a gép teljesen feleslegesen. A tuti biztos megoldás tényleg a TCP/UDP figyelése egy proxy-val és az alapján történő kapcsolgatása a szervernek, de azért ezzel is tök jól el lehet játszani szerintem. Még annyiból is inkább a proxy a jó megoldás, hogy a VPN szervert külön akarom rakni a szerver géptől, szóval vagy a routeren kell helyet kapnia, vagy a proxy szerver mellett az Odroidon. Ez a connect box bár egész jó minden más szempontból, de nem támogatja a VPN-t.
15

Wireshark

janoszen · 2017. Jún. 26. (H), 10.29
Nezd meg wiresharkkal a forgalmat, nezd meg hogy milyen csomagok mennek, abbol tobbet fogsz tudni.
16

Közben már rájöttem, hogy a

inf · 2017. Jún. 26. (H), 10.49
Közben már rájöttem, hogy a "raw packet data === buffer.slice(0, nbytes)" lehet a nyers csomag. Nem tudom hogy nem tűnt fel elsőre. :D Majd utánanézek, hogy hogyan épülnek fel pontosan ezek a csomagok, aztán dekódolom.

Okés, kipróbálom wiresharkkal is, talán fent is van még a gépen.
2

ARP

janoszen · 2017. Jún. 22. (Cs), 20.04
Mielott nekilatok kiserletezni, tisztazzuk az elmeleti reszt: Az ARP csomag egy layer 3 csomag, vagyis az IP-vel vagy egy szinten. A helyi halozatban arra hasznalatos, hogy egy IPv4-es cimhez tartozo MAC address-t feloldja.

Mint olyan, leggyakrabban egy Ethernet frameben fordul elo, viszont a benne talalhato informacio nemileg fuggetlen az ethernettol, igy erdekes mahinaciokat lehet vele csinalni.

A protokoll ugy kezdodik, hogy kimegy egy kerdes ("Kie ez az IP cim?", opcode 1) amire jon egy valasz ("Az enyem!", opcode 2). A kerdes broadcast formajaban megy ki, tehat a cel MAC address 00:00:00:00:00:00. A valasz viszont konkret geptol megy konkret gepre.

Mivel az ARP protokoll az IP szint alatt van, csak akkor fersz hozza, ha a tudsz raw socketre listenelni, vagyis Linux rendszereken legalabb NET_ADM capabilityvel kell rendelkezned, amit legegyszerubben rootkent indulva erhetsz el. Azt remelhetoleg mondanom sem kell, hogy nagyon rossz otlet netrol elerheto szolgaltatast rootkent futtatni, szoval itt egy kicsit izzadni kell majd.

Ezen felul a halozati interface mar hardver szinten szuri a nem neked erkezo csomagokat, tehat ha mindent latni akarsz, akkor az interface-t un. promisc modba kell kapcsolni, illetve ha switched van, nem hubod, akkor adott esetben port mirrort is kell confolni.

Szo mi szo, szerintem a NodeJS nem a legalkalmasabb eszkoz erre a feladatra, de megoldhato, majd ha lesz egy kis idom, kiprobalom hogy hogy van ez gondolva.
4

Egyelőre csak Windows-al

inf · 2017. Jún. 22. (Cs), 21.41
Egyelőre csak Windows-al kísérletezek, de ezek szerint nem lesz ez olyan egyszerű, mint elsőre gondoltam. Nagyjából annyi a cél most, hogy elkapjam az ARP broadcastet, ami kimegy a routerről, és ha úgy néz ki, hogy alszik a szerver gép és keresi a router, akkor automatikusan küldjek neki WOL packet-et. Most egyelőre egy UPC connect box van itthon, nincs normális routerem, amire itthon kell, arra nagyjából ez is jó. Később még ez változhat, ha sikerült eladnom az Odroid XU4-em, akkor van rá esély, hogy veszek egy normális router-t az árából. Szóval még nem világos, hogy min fog futni a kód, de az tuti, hogy valamilyen Linux disztrón, vagy OpenWRT jellegűn vagy Ubuntu-n. Esetleg úgy nem lehet megoldani, hogy csak egy REST API-t biztosítok helyi hálóra, amiről GET-el le lehet rántani, hogy milyen broadcastek voltak? Így elindulhat root-ként a cucc, és nem különösebben tudják felhasználni támadásra. Egyébként max egy OpenVPN lesz kintről elérhető, minden más csak belső hálón vagy ezen a VPN szerveren keresztül, úgyhogy talán olyan hatalmas veszély nincsen. Kösz a segítséget! Kíváncsi vagyok mire jutsz! :-) Közben próbálkozom azért én is.

Kis adalék még, hogy elvileg 4 óránként is van automatikus broadcast, hogy frissítse az ARP cache-t a router-en, úgyhogy ezeket majd ki kell szűrnöm. Kíváncsi vagyok, hogyha összejön, akkor vajon megoldható e, hogy feláll a szerver és még timeout előtt kiszolgálja a kérést, ami az ARP broadcastet kiváltotta.
7

Sztem

janoszen · 2017. Jún. 23. (P), 08.44
Sztem rossz iranyba indultal el, mert az ARP nem nyilatkozik arrol, hogy miert kell. Onmagaban megtehetned azt is, hogy NodeJS-bol kuldesz egy ARP valasz is ami megmondja a gep IP-jet, de ezzel nem sokra mesz, a 4 orankenti dolgokat nem tudod ertelmesen kiszurni. Raadasul IPv6-nal nincs ARP, hanem neighbor discovery, ami teljesen maskepp mukodik.

En ehelyett azt csinalnam, hogy amelyik gepen futtatod ezt a kis izet, legyen egy mini tcp proxy is, ami szukseg eseten kikuldi a WOL-t. Ennek az is az elonye, hogy bufferelni is tudod az adatokat amig felebred a gep.

Off: toljatok az ilyen nehez kerdeseket, szeretem oket. :)
8

Én is gondoltam már a

inf · 2017. Jún. 23. (P), 19.29
Én is gondoltam már a proxy-ra, nagyjából ezek a megoldások jöttek elő így laikusként a témában:
– a router + a managed switch with traffic monitoring + open firmware on the router / arduino
– a router which supports port mirroring + an arduino
– a router with some kind of debug interface or IP traffic export + open firmware on the router / arduino
– a raspberry proxy server with sleep proxy feature and a router which can deliver 1Gb/s speeds on 2 parallel connections
– catching ARP broadcasts sent by the router looking for the sleeping server + open firmware on the router / arduino


Ha nem megy el az Ordroidom, akkor abból lehetne egy jó kis proxy.
12

Odroid

janoszen · 2017. Jún. 24. (Szo), 07.52
Manapsag barmiben van eleg CPU ahhoz hogy ~100 MBit forgalmat proxyzzon, mert gyakorlatilag csak at kell lapatolni a biteket. Odroid, rPi teljesen jo erre a feladatra.
14

Gigabites hálóról van szó, és

inf · 2017. Jún. 24. (Szo), 08.59
Gigabites hálóról van szó, és ténylegesen menne is annyi Samba-n, HTTP-n keresztül legalább a helyi fájl streameléseknél. Jó lenne legalább a 85MB/s-et elérni, amit Odroiddal mértem USB3 HDD-ről.
17

Felreertesz

janoszen · 2017. Jún. 26. (H), 12.04
Felreertesz, nem az odroidnak kell kiszolgalnia, neki csak at kell lapatolnia a halozaton a biteket. A weboldal tenyleges kiszolgalasat vegezze az a gep ami most vegzi.
18

Nem értettem félre. Én HTTP

inf · 2017. Jún. 26. (H), 16.28
Nem értettem félre. Én HTTP proxy-ra is gondoltam, ha már ezért egy külön gépet járatok, nem csak TCP proxy-ra. Az Ordroid bőven elég erős mindkettőhöz, és egyelőre nem nagyon érdeklődnek utána csak nevetséges áron.
5

Sub

sly · 2017. Jún. 22. (Cs), 21.55
Sub