[elmad]

@livingsilver94, complimenti per il tuo lavoro. Come ho già detto nell'altro thread i nuovi wdr3600 che mandano hanno una versione 6 del firmware che ancora non esiste in remoto.

Io vorrei ripetere il tuo lavoro per la versione 6, puoi mandarmi il tuo .config che hai usato così lo uso come base? Per ora ho usato il . config del source che hanno nel loro sito, ma si riferisce ad una versione vecchia, e dato che la tua già funziona... .

Inoltre, ti sei basato sulla trunk o sulla 14.07 aggiungendo le patch specifiche che servivano?

Un po' alla volta mi sto leggendo gli script del firmware samknows, ma ancora non ne ho una comprensione completa.

Per quanto riguarda il tuo script dell'snmp client, in particolare

Codice: [Seleziona]

echo -n 1 > /tmp/threshold_pcap

Come l'hai determinato il valore 1? Sai a cosa si riferisce? Io ho notato che per la maggior parte del tempo è settato ad 1, ma qualche volta l'ho trovato settato a 2.

[livingsilver94]

Grazie! E grazie anche per l'interessamento tecnico

Il .config te lo passo volentieri, però la mia build è "update proof" perché lo script che si occupa di aggiornare la build confronta la versione installata con una remota. Il confronto è in maggiorazione. Allora ho impostato la mia build con un numero di versione pari al massimo valore rappresentabile da un int32 con segno. SamKnows non aggiornerà mai la build, a meno di cambiare l'algoritmo dello script
Mi pare inoltre di capire che, secondo te, ad ogni nuova versione di SamKnows la mia build va aggiornata. Ho capito male?

Mi sono basato sull'ultima review (alla data di compilazione) della 14.07, a cui ho aggiunto il fix del driver dello switch e modificato 2 makefile: uno del kernel e uno di curl. Piuttosto che passarti il .config, dovrei passarti l'intero ambiente di compilazione. Ci sono anche dei file aggiuntivi.

quell'1 è... assolutamente messo a casaccio lo script threshold.sh guarda il valore di /tmp/threshold_pcap e, se è a zero, lo script termina. In tutti gli altri casi, lo script va a confrontare i dati misurati con i valori di soglia. 1 l'ho messo perché è l'intero più facilmente ricordabile che non sia zero

[elmad]

Grazie! E grazie anche per l'interessamento tecnico

Il .config te lo passo volentieri, però la mia build è "update proof" perché lo script che si occupa di aggiornare la build confronta la versione installata con una remota. Il confronto è in maggiorazione. Allora ho impostato la mia build con un numero di versione pari al massimo valore rappresentabile da un int32 con segno. SamKnows non aggiornerà mai la build, a meno di cambiare l'algoritmo dello script
Mi pare inoltre di capire che, secondo te, ad ogni nuova versione di SamKnows la mia build va aggiornata. Ho capito male?

Mi sono basato sull'ultima review (alla data di compilazione) della 14.07, a cui ho aggiunto il fix del driver dello switch e modificato 2 makefile: uno del kernel e uno di curl. Piuttosto che passarti il .config, dovrei passarti l'intero ambiente di compilazione. Ci sono anche dei file aggiuntivi.

quell'1 è... assolutamente messo a casaccio lo script threshold.sh guarda il valore di /tmp/threshold_pcap e, se è a zero, lo script termina. In tutti gli altri casi, lo script va a confrontare i dati misurati con i valori di soglia. 1 l'ho messo perché è l'intero più facilmente ricordabile che non sia zero

Diciamo che l'obiettivo sarebbe quello di verificare se l'aggiornamento samknows ha introdotto qualche miglioria nell'ambito delle misurazioni e applicarle anche qui. Più che altro il fatto è anche che, inviandomi una versione 6 che ancora non esiste nei loro "repository", probabilmente stanno facendo pure qualche verifica e non gliela vorrei falsare.

Il .config mi serve solo per le dipendenze dei pacchetti e degli scripts samknows, così da andare sul sicuro. I file di samknows da aggiungere in /overlay o in /rom li prenderò dalla mia versione. Il fix per lo switch lo applicherò pure io dalla trunk. Il makefile del kernel per cosa l'hai modificato? Per le ottimizzazioni sulla cpu? Nel caso io pensavo di non applicarle. Per la modifica su curl invece sono curioso: che modifica hai fatto?
 

[livingsilver94]

Ovviamente sei libero di fare tutte le prove del caso, ma gli script vengono recuperati da remoto ad ogni riavvio, per cui non dovrebbe cambiare niente. Al limite possono modificare il binario dcsclient, ma anche quello potrebbe essere scaricato dai loro server.

Il makefile del kernel sì, solo per l'ottimizzazione del codice compilato. Mentre la modifica al curl è d'obbligo: siccome la connessione a SamKnows viene via HTTPS, bisogna dire a curl dove risiedono i certificati. Ho aggiunto l'opzione "--with-ca-path=/etc/ssl/certs/". Avevo provato a risolvere la cosa, a suo tempo, con le variabili d'ambiente, ma non sono stato capace di renderle disponibili agli script lanciati non a mano ma in automatico.

[proniuzelo]

----------

[livingsilver94]

Sono abbastanza sicuro che dipenda dalla configurazione della VS2... infatti se stai connesso al WDR tutto fila liscio. Hai idea del perché, se sei connesso alla VS2, l'indirizzo 192.168.2.1 redirige a 192.168.1.1?

[proniuzelo]

---------

[varma]

La Vodafone station fa delle cose molto strane.
Non so se anche la VS2, ma la VS che ho in ufficio ha richiesto che ogni PC connesso navigasse sulla sua pagina di configurazione affinché lei (VS) memorizzasse il mac address al fine di riconoscere i pc della rete e sbloccare tutte le porte di comunicazione. Se il PC non esegue lo script su browser, può solo accedel alle porte di hhtp e HTTPS (80, ecc).

Vedi se dipende da questo e in caso cerca online cose del tipo:
"Sbloccare ubuntu/linux server su Vodafone station"

[proniuzelo]

---------

[lugibor]

ciao living, ti chiedo scusa ma la parte finale della guida per correggere le misurazioni la potresti rendere pro niubbo? non so con che prog dare i comandi...scusami.
grazie mille per il tuo lavoro.

[livingsilver94]

Ho capito.
Se voglio accedere all'indirizzo 192.168.2.1 mentre sono connesso alla VS2 (con indirizzo 192.168.1.1) devo impostare una regola sul gateway (in questo caso la VS2) per cui tutte le richieste per la rete 192.168.2.x vanno instradate all'indirizzo WAN del 3600, cioè 192.168.1.2 ma questa regola sulla VS2 non posso metterla perché non ho accesso alla configurazione completa.

L'unico indirizzo che potrei raggiungere è 192.168.1.2, ma purtroppo posso solo pingarlo perchè se provo a navigare mi esce la pagina "Connessione non riuscita". Quindi credo che il WR3600 non sia configurato per avere l'accesso a Luci dalla WAN.

Non credo sia un problema di LuCI. uhttpd è accessibile da qualunque rete... piuttosto perché parli del WDR come se fosse nella WAN? Nella gerarchia della tua rete la VS2 viene prima della Whitebox, no?
Non so come procedere. Facciamo delle prove: riesci a connetterti alla Whitebox da telnet/SSH?

@lugibor, i comandi li puoi inserire con PuTTY. Appena ho del tempo provo a inniubbare la guida

[proniuzelo]

--------

[lugibor]

@lugibor, i comandi li puoi inserire con PuTTY. Appena ho del tempo provo a inniubbare la guida

l'ho fatto ma mi trova problemi...dice unable to download packages.gz

[livingsilver94]

Anche tu hai la Whitebox senza accesso a internet. Ho appena verificato che ogni repository è funzionante.
Come hai configurato il WDR3600? Router, AP..?

@tro69, la guida consigliata è sempre da seguire se volete fare le cose per bene, perché va a appunto a correggere le misurazioni. Per la guida facoltativa invece hai ragione

[varma]

Io riprovo a dirlo.
Chi ha una Vodafone station guardi questo link e veda se il problema è paragonabile a quello di questo link

https://www.artifex.it/informatica/vodafone-station-2-e-server-linux-senza-gui-sblocco-del-reindirizzamento-iniziale-delle-pagine-web/

Dovete far riconoscere il mac address di ogni dispositivo nella LAN alla VS, o rompe le palle sulle altre porte