struct utmraw {
unsigned int tv; // unixtime
unsigned int null_0; // +4
unsigned int null_1; // +8
unsigned int src; // source address
unsigned int dst; // destination address
unsigned int null_2; // +20
unsigned int null_3; // +24
unsigned int null_4; // +28
unsigned int bytes; // bytes transferred
unsigned int null_6; // +36
unsigned int null_7; // +40
unsigned short sport; // source port
unsigned short dport; // destination port
unsigned int null_9; // +48
unsigned int null_10; // +52
unsigned int null_11; // +56
unsigned int null_12; // +60
unsigned int null_13; // +64
unsigned int null_14; // +68
unsigned int null_15; // +72
}; // 76
Вопросов 2:
1. Что в остальных полях (null_*) ?
2. Почему первая запись размером 68 байт? Куда "делись" ещё 8?
---
Для чего? Нужно эти логи траффика считывать, аггрегировать и подбивать статистику (с записью в БД). Делать это методом get_nf_direct|читать вывод в формате очень долго и некрасиво.
Поясните, если не тяжело.
# 1-4 Device ID
# 5-8 Src IP
# 9-12 Dst IP
# 13-20 Next Hop IP
# 17-18 In interface ID
# 19-20 Out interface ID
# 21-24 Packets
# 25-28 Bytes
# 29-32 Start Time
# 33-36 End Time
# 37-38 Src Port
# 39-40 Dest Port
# 41 Pad
# 42 TCP Flag ID
# 43 Protocol ID
# 44 ToS
# 45-46 Src AS
# 47-48 Dest AS
# 49 Src Mask Bits
# 50 Dest Mask Bits
# 51-52 Pad
# 53-56 ???
# 57-60 UTM account_id
# 61-64 ???
# 65-68 UTM tclass
# 69-72 UTM timestamp
# 73-76 ???
Подскажите, формат файла менялся или нет? А может есть заголовок, который надо отбрасывать?
Билинг на Салярке, версия 5.2.1-007
Пытаюсь разобрать файл скриптом Rupreht & Magnum72.
Похоже есть смещение, т.к. IP адреса не корректные, файлов сформировалось 150тыс. а пользователей всего несколько тыс. и т.д.
Ничего не менялось по крайней мере с 002 по 007. Похожая картинка с кучей IP и нереальными трафиками была один раз, когда накрывался винт и побились файлы.
Ну и ещё на всякий случай, .utm и .dbs -- разные форматы
Причину нашел. Теперь надо думать как с ней бороться.
В общем, судя по полю "дата (69-72)", 4 байта данные в файле записываются в обратной последовательности:
4B FC 8F 48 - дата 26.05.2010, а в результате перл выдает 48 8F FC 4B - что соответствует 30.07.2008... там ещё минуты секунды... Надо полагать все остальные поля тоже перевернуты.
Сервер у нас на Спарке, а разбор в Интеле, может в этом проблема... а у Вас то как в файле?
nvi93 писал(а):Причину нашел. Теперь надо думать как с ней бороться.
В общем, судя по полю "дата (69-72)", 4 байта данные в файле записываются в обратной последовательности:
4B FC 8F 48 - дата 26.05.2010, а в результате перл выдает 48 8F FC 4B - что соответствует 30.07.2008... там ещё минуты секунды... Надо полагать все остальные поля тоже перевернуты.
Сервер у нас на Спарке, а разбор в Интеле, может в этом проблема... а у Вас то как в файле?
Разные форматы, на спарке big-endian, интел little-endian. Соответственно, стоит учитывать это при распаковке (вместо %32I принудительно задать нужный формат).
Получилось.
Помогла перлвская reverse(). После чтения из файла переменных "реверсирую" каждую, дальше уже сохраняется в "нормальной" последовательности. Можно и во внутрь unpack вставить, например:
в место $bytes = unpack ( "%32I" , $bytes ); использовать $bytes = unpack ( "%32I" , reverse($bytes) );
Может кому пригодится...
nvi93 писал(а):Получилось.
Помогла перлвская reverse(). После чтения из файла переменных "реверсирую" каждую, дальше уже сохраняется в "нормальной" последовательности. Можно и во внутрь unpack вставить, например:
в место $bytes = unpack ( "%32I" , $bytes ); использовать $bytes = unpack ( "%32I" , reverse($bytes) );
Может кому пригодится...
Вместо $bytes = unpack ( "%32I" , $bytes ) использовать $bytes = unpack ( "%N" , $bytes ) -- всё уже придумано...