Perché / proc / net / tcp6 rappresenta :: 1 come :: 100: 0


13

Stavo scrivendo un'utilità per controllare / proc / net / tcp e tcp6 per le connessioni attive poiché è più veloce dell'analisi dell'output netstat.

Poiché in realtà non ho abilitato ipv6, utilizzavo principalmente localhost come punto di riferimento. Ecco una copia di my / proc / net / tcp6

sl  local_address                         remote_address                        st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode
 0: 00000000000000000000000000000000:006F 00000000000000000000000000000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 19587 1 ffff880262630000 100 0 0 10 -1
 1: 00000000000000000000000000000000:0050 00000000000000000000000000000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 22011 1 ffff880261c887c0 100 0 0 10 -1
 2: 00000000000000000000000000000000:0016 00000000000000000000000000000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 21958 1 ffff880261c88000 100 0 0 10 -1
 3: 00000000000000000000000001000000:0277 00000000000000000000000000000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 28592 1 ffff88024eea0000 100 0 0 10 -1

Ecco il netstat -6 -pant corrispondente

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp6       0      0 :::111                  :::*                    LISTEN      -                   
tcp6       0      0 :::80                   :::*                    LISTEN      -                   
tcp6       0      0 :::22                   :::*                    LISTEN      -                   
tcp6       0      0 ::1:631                 :::*                    LISTEN      -      

Le voci 0-3 da tcp6 corrispondono alle :: 's (tutte ipv6), ma la voce 4 è presumibilmente la voce corrispondente per :: 1.

Questo è dove sono confuso ...

00000000000000000000000001000000 => 0000: 0000: 0000: 0000: 0000: 0000: 0100: 0000 => :: 100: 0

Quando eseguo :: 1 attraverso un codice per generare la rappresentazione esadecimale completa ottengo:

import binascii
import socket
print binascii.hexlify(socket.inet_pton(socket.AF_INET6, '::1'))
00000000000000000000000000000001

Non posso allineare programmaticamente questi due valori, perché non corrispondono (ovviamente). Perché non corrispondono? Perché il kernel pensa :: 100: 0 è :: 1?

Risposte:


11

Ciò è dovuto all'ordine dei byte controintuitivo in /proc/net/tcp6. L'indirizzo è gestito come quattro parole composte da quattro byte ciascuna. In ognuna di queste quattro parole i quattro byte sono scritti in ordine inverso.

2001:0db8       :: 0123:4567:89ab:cdef would thus come out as:
B80D 0120 00000000 6745 2301 EFCD AB89 (with spaces inserted for clarity).

Ciò è probabilmente dovuto alle differenze di endianness. La maggior parte dei PC oggigiorno utilizza IA32 o AMD64 che utilizzano l'endianness opposto rispetto a quello con cui è stato progettato IP. Non ho altri sistemi con cui provare per capire se puoi fare affidamento su / proc / net / tcp6 sempre così. Ma ho verificato che è il caso delle architetture IA32 e AMD64.


Buona risposta, ma potrebbe essere meglio fornire ulteriori chiarimenti. La tua seconda frase non è così chiara come potrebbe essere, penso che l'unica ragione per cui aveva senso era che qualcun altro me l'aveva appena spiegato in modo diverso.
Gregregwift,

@gregswift poiché l'OP non ha mai preso provvedimenti, forse potresti modificarlo tu stesso? Questa è una buona risposta a una buona domanda e questa piccola informazione sarebbe preziosa IMO.
André Chalella,

@kasperd lo ha modificato ieri. Ho appena riordinato l'esempio e ho aggiunto un po 'di formattazione per spero di fornire qualsiasi contesto aggiuntivo
gregswift,

3

Trovato questo modulo perl destinato all'analisi / proc / net / tcp http://search.cpan.org/~salva/Linux-Proc-Net-TCP-0.05/lib/Linux/Proc/Net/TCP.pm Cita il documentazione del kernel come mostrato di seguito.

This document describes the interfaces /proc/net/tcp and
/proc/net/tcp6.  Note that these interfaces are deprecated in favor
of tcp_diag.

These /proc interfaces provide information about currently active TCP
connections, and are implemented by tcp4_seq_show() in
net/ipv4/tcp_ipv4.c and tcp6_seq_show() in net/ipv6/tcp_ipv6.c,
respectively.

It will first list all listening TCP sockets, and next list all
established TCP connections. A typical entry of /proc/net/tcp would
look like this (split up into 3 parts because of the length of the
line):

46: 010310AC:9C4C 030310AC:1770 01 
|      |      |      |      |   |--> connection state
|      |      |      |      |------> remote TCP port number
|      |      |      |-------------> remote IPv4 address
|      |      |--------------------> local TCP port number
|      |---------------------------> local IPv4 address
|----------------------------------> number of entry

00000150:00000000 01:00000019 00000000  
  |        |     |     |       |--> number of unrecovered RTO timeouts
  |        |     |     |----------> number of jiffies until timer expires
  |        |     |----------------> timer_active (see below)
  |        |----------------------> receive-queue
  |-------------------------------> transmit-queue

1000        0 54165785 4 cd1e6040 25 4 27 3 -1
|          |    |     |    |     |  | |  | |--> slow start size threshold, 
|          |    |     |    |     |  | |  |      or -1 if the threshold
|          |    |     |    |     |  | |  |      is >= 0xFFFF
|          |    |     |    |     |  | |  |----> sending congestion window
|          |    |     |    |     |  | |-------> (ack.quick<<1)|ack.pingpong
|          |    |     |    |     |  |---------> Predicted tick of soft clock
|          |    |     |    |     |              (delayed ACK control data)
|          |    |     |    |     |------------> retransmit timeout
|          |    |     |    |------------------> location of socket in memory
|          |    |     |-----------------------> socket reference count
|          |    |-----------------------------> inode
|          |----------------------------------> unanswered 0-window probes
|---------------------------------------------> uid

timer_active:
0  no timer is pending
1  retransmit-timer is pending
2  another timer (e.g. delayed ack or keepalive) is pending
3  this is a socket in TIME_WAIT state. Not all fields will contain 
 data (or even exist)
4  zero window probe timer is pending

0

Sto analizzando / proc / net / tcp, anche / tcp6, / udp6 su Android e questi sono i miei semplici metodi per la conversione, in Java. Grazie Kasperd per avermi guidato a questa soluzione.

/**B80D01200000000067452301EFCDAB89 -> 2001:0db8:0000:0000:0123:4567:89ab:cdef
 * */
public static String toRegularHexa(String hexaIP){
    StringBuilder result = new StringBuilder();
    for(int i=0;i<hexaIP.length();i=i+8){
        String word = hexaIP.substring(i,i+8);
        for (int j = word.length() - 1; j >= 0; j = j - 2) {
            result.append(word.substring(j - 1, j + 1));
            result.append((j==5)?":":"");//in the middle
        }
        result.append(":");
    }
    return result.substring(0,result.length()-1).toString();
}
/**0100A8C0 -> 192.168.0.1*/
public static String hexa2decIPv4 (String hexa) {
    StringBuilder result = new StringBuilder();
    //reverse Little to Big
    for (int i = hexa.length() - 1; i >= 0; i = i - 2) {
        String wtf = hexa.substring(i - 1, i + 1);
        result.append(Integer.parseInt(wtf, 16));
        result.append(".");
    }
    //remove last ".";
    return result.substring(0,result.length()-1).toString();
}
/**0000000000000000FFFF00008370E736 -> 0.0.0.0.0.0.0.0.0.0.255.255.54.231.112.131
  0100A8C0 -> 192.168.0.1
*/
public static String hexa2decIP (String hexa) {
    StringBuilder result = new StringBuilder();
    if(hexa.length()==32){
        for(int i=0;i<hexa.length();i=i+8){
            result.append(hexa2decIPv4(hexa.substring(i, i + 8)));
            result.append(".");
        }
    }else {
        if(hexa.length()!=8){return "0.0.0.0";}
        return hexa2decIPv4(hexa);
    }
    //remove last ".";
    return result.substring(0,result.length()-1).toString();
}

/**Simple hexa to dec, for ports 
 * 01BB -> 403
 * */
public static String hexa2decPort(String hexa) {
    StringBuilder result = new StringBuilder();
    result.append(Integer.parseInt(hexa, 16));
    return result.toString();
}

Questo risponde alla domanda?
Andrew Schulman,

Devo cancellarlo? Forse aiuta qualcuno che eseguirà l'analisi ipv6 in futuro o qualcuno può capire meglio guardando il codice reale.
Jan Tancibok,

Nessuno tra il pubblico di destinazione è probabile che stia programmando in Java o in qualsiasi altra lingua.
Michael Hampton

@MichaelHampton È un'esagerazione. Ci sono persone che fanno sia l'amministrazione del sistema che lo sviluppo. Sono uno di loro. (Anche se sono passati 9 anni dall'ultima volta che ho fatto Java.)
Kasperd,

@kasperd Il punto è che la gente non penserà di venire a Server Fault per esempi di codice. Questo è l' altro sito. :)
Michael Hampton
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.