DLink G604T to Routertech

[DarkWolf]

Originariamente inviato da rdefalco

non vi dimenticate il supporto al 624

dovrei mandare in Sicilia un registratore di cassa ad una softwarehouse per farlo certificare con un programma ci allego un 624T per DarkWolf e le sue prove?

Se lo fai... sarà un dono parecchio gradito - PS nell'ultima mia beta c'è pure (giustamente il tuo nome)
Ma forse ti conviene mandarne uno anche a jack

[rdefalco]

Originariamente inviato da DarkWolf

nell'ultima mia beta c'è pure (giustamente il tuo nome)

"un ringraziamento immorale a rdefalco, l'utente che ci ha negato la compatibilità col G624T (shame on him)"

tornerò a betatestare nel finesettimana, non temete

[DarkWolf]

Originariamente inviato da rdefalco

"un ringraziamento immorale a rdefalco, l'utente che ci ha negato la compatibilità col G624T (shame on him)"
tornerò a betatestare nel finesettimana, non temete

- hai risolto più bug dell'interfaccia tu che lo stesso theChieff

[DDNS]

Originariamente inviato da JackTheVendicator

Ho applicato le patch ad un pacchetto "pulito" (scompattato mezz'ora fa)... si sono applicate tutte senza problemi
Ora sto preparando un pacchetto pre-patchato in modo che non bisogna fare ogni volta lo stesso pallosissimo lavoro... poi inserisco nel tree le mie patch di lusso (quelle per le quali non rilascio i sorgenti - scherzo ovviamente )


Che fortuna

--EDIT--
Che chiavetta wi-fi mi consigliate (moderna 802.11g possibilmente) che supporti l'AP mode, magari anche da linux?

non ho capito bene la domanda......


qualunque chiavetta supporta l'ap mode
io uso la g122 sia su ubuntu, mandriva e black track

[JackTheVendicator]

Originariamente inviato da DDNS

non ho capito bene la domanda......


qualunque chiavetta supporta l'ap mode

Uhm... solo wep max 128 bit o anche wpa? (si sono paranoico ma sai in pieno centro...)

Originariamente inviato da DDNS

io uso la g122 sia su ubuntu, mandriva e black track

Bene... grazie per l'info

[Vathek]

OK, ho montato oggi pomeriggio la nuova mod di DarkWolf...

Per quanto riguarda la temperatura mi sa che la mia sonda non funziona

Mi segna sempre una temperatura di 25°C... anche ora che ho ben appiccicato la sondina sopra al chip AR7...

Quindi lasciate perdere le mie rilevazioni di temperatura... almeno per il momento, finché non riesco a misurare decentemente le temperature...

[cicala]

due bug
1) probabilmente gia discusso... i mac in wireless -> management sono nella forma

xx-xx-xx-xx-xx-xx

mentre in Advanced -> Lan Clients sono nella forma

xx:xx:xx:xx:xx:xx

2) dando il comando in System -> Run Command

cat /proc/ticfg/env

non restituisce nulla... mentre

cat /proc/ticfg/*

mostra la env ... questo sembra valido solo per il file env

Originariamente inviato da MisteroX

sul firmware finale è possibile nella Sez. Advanced - Access Controll dare la possibilità di settare le porte per alcuni servizi diversi dallo standard ?
es. aggiungendo un campo con il default e dare la possibilità di modificarlo per le proprie necessità.
Es. http://img180.imageshack.us/my.php?...immagineuc6.jpg con il default dei servizi.
Oppure se puoi indicarmi dove poter modificare la porta del server ssh presente sul router, grazie.

lo puoi fare editando a mano il file config.bin e riuppandolo...

[DarkWolf]

Originariamente inviato da cicala

due bug ....mostra la env ... questo sembra valido solo per il file env

no non mi sembra ne avessimo discusso...
Mo non sono a casa... controllerò più tardi!
In merito alla env è strano! prova con l'altro percorso "proc/sys ecc...
comunque vedi anche cosa ti da con il getenv

[cicala]

Originariamente inviato da DarkWolf

no non mi sembra ne avessimo discusso...
Mo non sono a casa... controllerò più tardi!
In merito alla env è strano! prova con l'altro percorso "proc/sys ecc...
comunque vedi anche cosa ti da con il getenv

dunque:
dando il comando da interfaccia web... sia
cat /proc/ticfg/env che /proc/sys/dev/adam2/environment non restituiscono nulla...
mentre /proc/ticfg/* e /proc/sys/dev/adam2/* si
getenv va ok ...

ps. dark io ho modificato il config.bin di tiupgrade prima di fare l'aggiornamento... ho aggiornato con tiupgrade ma mi ha resettato le modifiche... ma allora a che serve il config all'interno del pacchetto?? solo per chi vuole procedere via web o da altre parti??

pps. che cos'e' la variabile "modulation"? la mia era differente..

[DarkWolf]

Originariamente inviato da cicala

dunque:...

Il config del pacchetto serve per sovrascrivere quello precedente! E dovrebbe farlo se aggiorni da tiupgrade
modulation è la variabile per il tipo di modulazione! 0x1=multimode

[Vathek]

Originariamente inviato da cicala

dunque:
dando il comando da interfaccia web... sia
cat /proc/ticfg/env che /proc/sys/dev/adam2/environment non restituiscono nulla...
mentre /proc/ticfg/* e /proc/sys/dev/adam2/* si
getenv va ok ...

ps. dark io ho modificato il config.bin di tiupgrade prima di fare l'aggiornamento... ho aggiornato con tiupgrade ma mi ha resettato le modifiche... ma allora a che serve il config all'interno del pacchetto?? solo per chi vuole procedere via web o da altre parti??

Io ho upgradato usando ciclamab, ho messo sia il singleimage che il config.

Al termine ho rifatto la config a mano... e a me il "cat /proc/ticfg/env" mostra l'effettivo contenuto della env...

(a questo punto non vorrei fosse un problema di tiupgrade che resetta la env, o per lo meno non la rende visibile al firmware... )

Hai provato a fare la vecchia procedura che avevo postato? (Mi pare che l'avessi già fatta con la vecchia versione del fw..)

[DarkWolf]

Originariamente inviato da Vathek

...Hai provato a fare la vecchia procedura che avevo postato? (Mi pare che l'avessi già fatta con la vecchia versione del fw..)

Comunque il filesystem fa riferimento al percorso alternativo, difatti getenv la mostra quindi nessun problema - PS da tools system diagnostic è presente vero?
Edit se non erro la super adam2 ha i comandi fixenv, prova con quello - io quando ebbi questo problema lo feci da seriale

[cicala]

mi spiego meglio:
il bug e' solo da interfaccia web... da telnet tutto ok!!

vathek prova a dare i comandi (da interfaccia web)
cat /proc/ticfg/env
cat /proc/ticfg/*
il primo non mi restituisce nulla... il secondo mi da la env...
lo stesso vale per /proc/sys/dev/adam2/environment...
quindi e' solo un bug dell'interfaccia...

lo stesso se faccio
ls -l /proc/ticfg/env -> non mi da nulla
ls -l /proc/ticfg/* -> mi da "-rw-r--r-- 1 0 0 0 Jan 19 01:59 /proc/ticfg/env"

[DarkWolf]

Originariamente inviato da cicala

mi spiego meglio:
il bug e' solo da interfaccia web... da telnet tutto ok!!...

Ok ricevuto! Non so magari è per questo che è stato inserito lo script getenv... - comunque proverò a rimediare
Edit!
Se creo due link simbolici allo script getnev cone nome cat /etc... pensi che funzionerà? Mi chiedo se possa accettare il nome cat/proc/ticfg/env
-
@cicala!
provato...
per i mac è vero! Ma esce anche un bell'avviso di inserire i mac col trattino... se hanno inserito l'avviso penso sia dovuto al fatto che non sono riusciti a metterlo con i ":"! Altro esempio è il log che ti chiede nel caso sia assente di inserire il mac 00.11.22... (con i punti) gli ho chiesto di riparare ma mi ha detto che ci provò in passato senza successo in quanto quella funzione appartiene a qualcosa nel kernel...
Comunque domani metterò mani al filesystem per provare a risolverli entrambi

[misteroX]

Ciao DarkWolf ,
ok inserito nuova config ora vedo molte opzioni in più rispetto a prima.
Per quanto riguarda l’env: la mantiene senza problemi ed anche i mac e mac_ap senza dare errori nel log.
NO-IP aggiorna regolarmente.

@DarkWolf @cicala
Modifiche alla config:
Con ciclamab si può inviare solo il config.bin senza riscrivere ogni volta il filesystem+kernel+config?

Perchè se invio dall'interfaccia web il config.bin modificato o non modificato mi si blocca il router e devo resettarlo per farlo ripartire.
Una cosa simile mi capita anche con ciclamab se invio firmware+kernel+config-modificata il router lavora male e dopo un pò devo resettare nuovamente.
Come Ciclamab uso la . ver. 4.3.5 - 11/01/2007


modifiche effettuate al config:

- <remote_mgmt>
- <wan>
....
....
- <remote_ssh>
<description>Secure Shell (SSH)</description>
<state>0</state>
- <protocolport1>
<portstart>443</portstart>
<portend>443</portend>
<portmap>443</portmap>
<protocol>tcp</protocol>
</protocolport1>
</remote_ssh>

Per motivi di tunneling che effettuo da alcune realtà devo impostare l'ssh del mio router sulla porta 443 così i firewall+proxy di queste realtà non mi bloccano la connessione.

Premetto dopo aver effettuato le modifiche salvo il config.bin sempre come .bin

Dove sbaglio ?
Il router può accettare ssh sulla porta 443 o ci sono impostazioni interne che lo vietano perchè la 443 è riservata al traffico internet per l'https ?

Normalmente ho un server linux con openssh-server impostato sulla 443 e non ho mai avuto problemi, l'unica differenza è data dal fatto che il server è in DMZ protetto da iptables.

Ciao
MisteroX

[DDNS]

Originariamente inviato da JackTheVendicator

Uhm... solo wep max 128 bit o anche wpa? (si sono paranoico ma sai in pieno centro...)


Bene... grazie per l'info

io mi collego a una rete esclusiva per radioamatori via wirelless che dista da me 40 di km
non si usano assolutamente wep o wap, viene abilitato il mac_ad
che ho fornito, piu un indirizzo IP che appartiene al mio call
del dominio "1.it.ampr.org"

sfido qulunque hacker wardriving a bukare il sistema

[Jacker]

In mera sintesi, quando non c'è codifica dei dati trasmessi, attraverso comuni apparati wireless è possibile intercettare qualunque tipo di traffico.

Visto che l autenticazione avviene proprio tramite l invio di alcune celle riguardanti mac_address, ora io che dovessi intercettare il tuo traffico apparentemente senza senso, sono in grado di individuare questo e repricarlo riuscendo quindi ad ottenere il tuo ip o un leasing dal dhcp e clonare quindi il tuo accesso.

Nel caso di una trasmissione cifrata, anche se intercetto il traffico prima lo devo decrifrare e per farlo devo individuare la chiave rendendo tutto più complesso.
Nel caso della wep, in estrema sintesi, la chiave viene inviata in prestabiliti limiti di tempo oltre che nei preamboli di connessione ed è facile dopo aver sniffato molti accessi o una sufficiente quantità di traffico, individuarla. Ma questo e' un problema intrinseco di wep e del iv che usa per la cifratura.
Nella wpa/2-psk ci sono gli stessi problemi ma la lunghezza delle chiavi è aumentata oltre al fatto che si utilizzano più chiavi e il problema delle iv collision passa per il mic ed eventualmente per tkip . Quindi è ancora più difficile.

In sostanza sempre meglio proteggere qualunque comunicazione wireless, meglio se con il wpa temporal key integrity protocol. Oltre al mac_address filter da settare sempre.

Ovviamente non so se nel caso delle trasmissioni radioamatoriali vi sia un qualche tipo di cifratura hardware. Ma anche supponendo sia presente non saresti comunque al sicuro poichè una volta acquistato il medesimo tipo di harware sarebbe facile replicarla.

Per avere sicurezza assoluta servono dei tunneling come ip security o virtual private network, purtroppo per noi.

Non credo di essere off topic anche perche questo può riguardare le opzioni presenti nei nuovi firmwares.

[erpalma]

Originariamente inviato da DarkWolf

Non me ne intendo di ping ecc... ma che ne pensate di questo @ maya.ngi.it?

Cioè tu fai 30ms di ping? Ma con che adsl??

[erpalma]

Originariamente inviato da DDNS

io mi collego a una rete esclusiva per radioamatori via wirelless che dista da me 40 di km
non si usano assolutamente wep o wap, viene abilitato il mac_ad
che ho fornito, piu un indirizzo IP che appartiene al mio call
del dominio "1.it.ampr.org"

sfido qulunque hacker wardriving a bukare il sistema

Beh il mac lo puoi sniffare per cui non serve, poi non ho capito bene la storia dell'ip...

[DarkWolf]

Originariamente inviato da erpalma

Cioè tu fai 30ms di ping? Ma con che adsl??

Tiscali 4 Mega