none
win 2k3 va fuori rete RRS feed

  • Domanda

  • buongiorno a tutti,

    mi trovo in una situazione quanto meno singolare: 

    ho un win2k3 srv (in dominio ma NON e' un AD controller) che e' tranquillamente in rete.

    Faccio quanto segue:

    1- faccio partire una applicazione java sul srv. w2k3-A

      (l'app-java implementa un servizio sulla porta 4002/TCP)

    2- lancio l'app-java, come client, su d'un altro srv w2k3-B

    3- l'app-java sul srv. B contatta il srv. A e comincia a far traffico TCP

    4- dopo qualche minuto la connessione cade

    5- l'app-java sul srv. B se ne accorge e ricontatta il srv. A

    6- dopo diverse volte che si ripete il tutto il srv. A pone l'interfaccia di rete fuori rete!

    Ovvero: non e' piu' pingabile ma risulta attiva dalla console di w2k3 (via netsh)

     

    Si noti che:

    1- succede anche cambiando il srv. A con altro server

    2- NON vi sono FW attivi sul srv. A

    3- NON vi sono altri programmi, oltre all'app-java, sul srv. A

    4- la stessa app-java, su winXp o Win7 come srv., NON perde mai la connessione

     

    Qualcuno ha una mezza idea?  E' la prima volta che vedo una app-java mettere fuori

    rete un w2k3!

     

    grazie infinite


    Ice72
    giovedì 15 settembre 2011 06:24

Tutte le risposte

  • Dovresti avere qualche segnalazione negli event log.

    Comunque, se cambiando server si ripete il problema, direi che il problema è l'interazione fra questo java e Windows 2003, e non nel sistema operativo in se.


    Fabrizio Volpe
    MVP Directory Services
    MCSE (NT4)(2000)(2003) - MCSA (2003)
    MCTS (SQL 2005)(Exchange 2007)(Windows 2008)
    VMware Certified Professional on vSphere 4
    Fortinet Certified Network Security Professional (FCNSP)
    Fabrizio[_dot_]Volpe[_at_]GMX[_dot_]com
    giovedì 15 settembre 2011 09:31
  • Qualcuno ha una mezza idea?  E' la prima volta che vedo una app-java mettere fuori

    rete un w2k3!


    Prima di tutto bisognerebbe vedere se si tratta, in effetti dell'applicazione in se o di qualche driver/servizio che va in "crash" (un'occhiatina all'eventlog potrebbe essere opportuna); in secondo luogo, come suggerito anche da Fabrizio, sarebbe utile testare la ... anzi LE stesse app su due sistemi diversi per verificare se il problema permanga o meno e magari, visto che i due sistemi potrebbero avere "debug tools", investigare ulteriormente sul problema (ammesso e non concesso che lo stesso si manifesti); oltre a quanto sopra, mi sarei fatto un'idea "a naso" di quella che potrebbe essere la causa del problema, ma non ho alcun indizio in merito; per dirla tutta, sospetto che la connessione di rete tra i due sistemi potrebbe avere qualche tipo di problema; sarebbe opportuno, secondo me, provare a connettere i due sistemi che manifestano il problema con un cavo "cross" (diretto) e verificare se il problema si manifesti ancora o meno, in caso contrario, sarà una buona idea controllare il cablaggio ed i vari apparati posti tra i due sistemi.

     

    giovedì 15 settembre 2011 12:19
  • grazie a tutti.

     

    Vado a precisare:

    - la java-app NON installa alcun driver, e' 100% java

    - la rete NON ha problemi (cambiato switch/cavi/schede rete/... srv!)

    - sui log di windows non compare nulla (altro mistero)

    - sul srv-A, quando e' fuori rete, provando, dalla console di A, a connettersi al java-srv

      via telnet, l'app risponde

    - effettuando sniffing di rete, su srv-B, si nota una ricezione di reset di connessione da A

    - circa java in senso stretto: provate due VM diverse (32 e 64bit) senza esiti positivi.

      Peraltro, cercando in giro, sembra che il problema si manifesti anche con C#/.NET

    - circa l'interazione java/w2k3, essendo w2k3 un sistema operativo moderno,

      una app-java che fa 50KByte/sec, in rete, NON dovrebbe produrne l'off-line di lan!  ;(

      Sopratutto considerando che la app medesima carica poco la CPU e la RAM.

    - la stessa app su WinXP/Win7/Linux/OS-X NON manda in hang la scheda di rete del srv

     

    Grazie ancora.

    Saluti,


    Ice72
    venerdì 16 settembre 2011 06:09
  • - la java-app NON installa alcun driver, e' 100% java
    Non mi riferivo a drivers installati dall'applicazione java ma al fatto che, il traffico generato dalla stessa potesse mandare in crash qualche driver/servizio relativo alla scheda di rete è per quello che ti avevo chiesto di verificare l'eventlog; a proposito... che schede di rete (marca/modello) usano i due servers ?
    - la rete NON ha problemi (cambiato switch/cavi/schede rete/... srv!)
    Per eliminare qualsiasi dubbio relativo ad eventuali congestioni sulla rete, prova a connettere i due servers direttamente tra loro usando un breve tratto di cavo "cross" e verificando se il problema si ripeta o meno

    - effettuando sniffing di rete, su srv-B, si nota una ricezione di reset di connessione da A

    Ecco, questo è strano, sembra quasi che il traffico generato dall'applicazione causi l'attivazione di alcuni dei meccanismi di flood-protection implementati nello stack di rete o che, il traffico, causi la saturazione del buffer backlog del socket; in tal caso lo stack invierà automaticamente un RST alle richieste di connessione sino a che il backlog non sia stato svuotato; una cosa del genere potrebbe essere dovuta alla lentezza del nodo ricevente che non riesce ad elaborare il traffico in ingresso con rapidità sufficiente; se questo fosse il caso, dovresti valutare l'opportunità di ridurre il rateo di trasmissione oppure di implementare una coda sul receiver in modo che i pacchetti in arrivo vengano immediatamente rimossi dal buffer (backlog) ed inseriti nella coda; in questo modo pur non perdendo pacchetti, eviterai che il backlog venga saturato lasciando allo stesso tempo il receiver libero di elaborare gli stessi con la velocità (o la lentezza) desiderata

    Per chiarire (spero); nel codice dovresti avere un paio di threads; il primo si occuperà semplicemente di accettare le connessioni in ingresso ed inserirle in una coda ed il codice eseguito da questo thread sarà approssimativamente qualcosa di questo tipo (pseudo-codice)

    // network service thread
    while (!blnStop) {
      client_socket = accept(server_socket, (struct sockaddr*)&(addr_remote), &len);
      push(&queue, client_socket);
    }

    il secondo thread invece, si occuperà di estrarre dalla coda le richieste e procederà ad elaborarle in sequenza e potrà avere un codice del tipo

    // worker thread
    while (!blnStop) {
      if (!empty(&queue)) {
        client_socket = pop(&queue);
        // ... process ...
      }
    }
    
    con un approccio di questo genere, il codice nel secondo thread avrà tutto il tempo del mondo (ok, si fa per dire) per elaborare le richieste e non avrai problemi di saturazione del backlog, dato che il primo thread si preoccuperà di mantenere la coda di ricezione vuota


    • Modificato ObiWan venerdì 16 settembre 2011 07:46
    venerdì 16 settembre 2011 07:34
  • - schede provate sia HP-native/intel/realtek: comportamento invariato

    - cross cable: provato, comportamento invariato

    - architettura app-java: gia' implementata esattamente come descritta

     

    Info aggiuntive:

    1) l'applicazione e' pesantemente parallela (ovvero: mentre il srv. invia

       pacchetti lo fa anche il client verso il server)

    2) IPSec e' stato disattivato (entrava in blocking-mode)

    3) con "NETSH firewall show opmode" si evidenzia quanto segue:

    =======================================

    Domain profile configuration:
    -------------------------------------------------------------------
    Operational mode                  = Enable
    Exception mode                    = Enable


    Standard profile configuration:
    -------------------------------------------------------------------
    Operational mode                  = Disable
    Exception mode                    = Enable

    lan firewall configuration:
    -------------------------------------------------------------------
    Operational mode                  = Enable

    =======================================

    la cosa mi lascia perplesso due volte, infatti:

    1) il FW di sistema e' DISATTIVATO

    2) precedentemente il srv. era stato gateway di rete (configurato via routing&remote  

      access). Ora, tuttavia, tale funzione e' stata sposta su un srv.linux ed il servizio, sul

      w2k3 fermato.

     

    Mi rimane il timore che il FW di windows sia ancora parzialmente attivo e stia

    generando problemi attivando un qualche meccanismo di self-defence.

    Tuttavia non posso formattare il srv. per rifarlo da capo (ed ho timore, col

    NETSH, a "forzare la mano" ad uno stato apparentemente precario!).

     

    thx

     


    Ice72
    venerdì 16 settembre 2011 07:46
  • Mi rimane il timore che il FW di windows sia ancora parzialmente attivo e stia generando problemi attivando un qualche meccanismo di self-defence.

    Potresti provare a resettare il firewall e poi disabilitarlo, allo scopo basterebbero i comandi

    netsh firewall reset
    netsh firewall set opmode mode=disable
    
    

    che dovrai immettere dalla console del server (occhio, non farlo da RDP dato che rischieresti di "tagliarti fuori"); il primo resetterà il firewall con le impostazioni di default; il secondo disattiverà totalmente il firewall

     

    venerdì 16 settembre 2011 08:17
  • purtroppo il srv. e' accessibile solo da remoto, via RDP. Inoltre, anche se risolvesse,

    su d'una altro srv., su cui andra' messa la java-app, non e' pensabile di revocargli il

    ruolo di GW.

     

    Esiste la possibilita' attivare un qualche log, a livello di network-subsystem,

    che tracci quel che sta accadendo?

     

    Per ora la (folle!) pezza che sta facendo girare il tutto e' uno script che, via NETSH,

    ogni 5min, disattiva e riattiva l'interfaccia di rete (ormai dedicata) all'applicazione.

    Tuttavia il livello di servizio e' inaccettabile (e, peraltro, il srv. dimostra di non gradire

    molto).

     

    grazie


    Ice72
    venerdì 16 settembre 2011 09:31
  • purtroppo il srv. e' accessibile solo da remoto, via RDP.

    [...]

    Per ora la (folle!) pezza che sta facendo girare il tutto e' uno script che, via NETSH, ogni 5min, disattiva e riattiva l'interfaccia di rete (ormai dedicata) all'applicazione.


    Uh... beh ma scusa... crea uno script con le due istruzioni di "reset del firewall" (come già scritto), schedulalo per essere eseguito UNA sola volta, aspetta che l'esecuzione venga avviata e riconnettiti al server verificando se, il tal modo, il problema si sia risolto

     

    venerdì 16 settembre 2011 09:37
  • in teoria e' vero, in pratica il rischio che succeda qualcosa d'impredicibile e' eccessivo (il srv. fa filesharing per molti utenti) e l'impostazione di FW e' globale, non scheda-specifica.

     

    Comunque un update: il programma java, su in una VM-win2k3, gira senza che si manifesti

    alcuni problema. Esclusa, quindi, l'opzione incompatibilita' java/w2k3, a meno che non sia

    ambiente-specifica (in tal caso ... son dolori!  :(  ).


    Ice72
    venerdì 16 settembre 2011 10:18