2016-02-21 2 views
1

Я возиться с Libpcap, и работает этот тестовый код:Действительно ли '/' действительно подходящее устройство для поиска с помощью pcap?

char* device, errbuff[PCAP_ERRBUF_SIZE]; 

printf("Looking for device...\n"); 
device = pcap_lookupdev(errbuff); 

if (device == NULL) 
{ 
    fprintf(stderr, "Couldn't find default device: %s\n", errbuff); 
    return 1; 
} 

printf("Device found: %s\n", device); 

Он работает, но он выдает следующее:

Looking for device... 
Device found: \ 

Я на Windows (10), а код, который следует за этим, продолжает работать (я могу отправить сообщение в случае необходимости), поэтому кажется, что это допустимое устройство, но для меня это кажется странным. Я иду из linux, поэтому я привык видеть ethX и т. Д.

Если это не нормально, что я должен видеть?

+0

Если pcap использует особенно необычную номенклатуру, это не допустимое имя устройства. Лучше всего предположить, что pcap_lookupdev возвращает строку UTF-16 (которая является родной кодировкой для Windows), поэтому, когда вы печатаете ее как узкую строку, вы видите только первый символ. Попробуйте '% ws' в вызове printf() и посмотрите, не имеет значения. –

+0

'% ws' действительно изменили ситуацию. Он выводит: '\ Device \ NPF_ {BF9D6116 -...}' – galois

ответ

0

This appears to be a bug, design limitation, or perhaps just poor documentation in winpcap.

pcap_lookupdev функция объявлена ​​вернуться char *, но на самом деле возвращает wchar_t *. Мне не ясно, относится ли это также к связанным функциям, например, действительно ли pcap_open_live ожидает строку UTF-16 для имени устройства. Если ваш код работает (без явного преобразования строки в ASCII), то предположительно все аргументы имен устройств равны фактически UTF-16.

Это довольно парадоксальная практика, но, возможно, это было сочтено необходимым злом, чтобы обеспечить кросс-платформенную совместимость.