Dmitry_177
Участник
Offline
|
|
« : 19-07-2007 07:06 » |
|
Делаю перехват ClientEventReceive.. Но почему-то при вызове оригинальной функции: ntStatus = OldClientEventReceive(pBlockFromPagedLookasideList->EventContext, ConnectionContext, ReceiveFlags, BytesIndicated, BytesAvailable, BytesTaken, Tsdu, IoRequestPacket); выскакивает BSOD.. Подскажите пожалуйста, немогу я разобраться.. анализ дампа показывает следующее: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * *******************************************************************************
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1) An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is usually caused by drivers using improper addresses. If kernel debugger is available get stack backtrace. Arguments: Arg1: ff49a978, memory referenced Arg2: 00000002, IRQL Arg3: 00000001, value 0 = read operation, 1 = write operation Arg4: ffa4d4d7, address which referenced memory
Debugging Details: ------------------
WRITE_ADDRESS: ff49a978 Nonpaged pool expansion
CURRENT_IRQL: 2
FAULTING_IP: +ffffffffffa4d4d7 ffa4d4d7 001400 add byte ptr [eax+eax],dl
DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO
BUGCHECK_STR: 0xD1
PROCESS_NAME: Idle
TRAP_FRAME: 805487d4 -- (.trap ffffffff805487d4) ErrCode = 00000002 eax=ffa4d4bc ebx=00000e20 ecx=ffb84008 edx=80da0200 esi=ffb9b8b8 edi=ffb8ef08 eip=ffa4d4d7 esp=80548848 ebp=8054887c iopl=0 nv up ei pl nz ac pe cy cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010217 ffa4d4d7 001400 add byte ptr [eax+eax],dl ds:0023:ff49a978=?? Resetting default scope
LAST_CONTROL_TRANSFER: from 804f79d7 to 80526fc8
STACK_TEXT: 80548388 804f79d7 00000003 805486e4 00000000 nt!RtlpBreakWithStatusInstruction 805483d4 804f85c4 00000003 ff49a978 ffa4d4d7 nt!KiBugCheckDebugBreak+0x19 805487b4 8053fa73 0000000a ff49a978 00000002 nt!KeBugCheck2+0x574 805487b4 ffa4d4d7 0000000a ff49a978 00000002 nt!KiTrap0E+0x233 WARNING: Frame IP not in any known module. Following frames may be wrong. 80548844 fb051c1f ffa4d4bc ffb84008 00000e20 0xffa4d4d7 8054887c f92a362d 80da0200 ffb84008 00000e20 tdifilter_testdriver!HookedClientEventReceive+0xaf [c:\drv\main.c @ 160] 805488e0 f92a8e39 ffb84008 00001950 80548a00 tcpip!IndicateData+0x225 80548968 f929cef5 80dea670 2201a8c0 9bd03fa6 tcpip!TCPRcv+0x160d 805489c8 f92bae4d 00000020 80dea670 f929f076 tcpip!DeliverToUser+0x18e 80548a7c f929b922 80dea670 fa52d022 000001cc tcpip!IPRcvPacket+0x670 80548abc f929b84d 00000000 80f038f0 fa52d000 tcpip!ARPRcvIndicationNew+0x149 80548af8 fa895c9f ffb73008 00000000 fa717b40 tcpip!ARPRcvPacket+0x68 80548b4c fa71201d 00e61ed8 ffb961f0 00000001 NDIS!ethFilterDprIndicateReceivePacket+0x1c2 80548b60 fa7121b4 ffb586a8 ffb961f0 00000001 psched!PsFlushReceiveQueue+0x15 80548b84 fa7125f9 80e017d8 00000000 ffb586a8 psched!PsEnqueueReceivePacket+0xda 80548b9c fa895d40 80e017d0 80df15d8 80df15e4 psched!ClReceiveComplete+0x13 80548bec fae05387 00e61ed8 80548e0c 00000001 NDIS!ethFilterDprIndicateReceivePacket+0x5a4 80549014 fa88bf09 80df15d8 80551d80 80551b20 vmxnet+0x2387 8054902c 80540f7d 80df1a8c 80df1a78 00000000 NDIS!ndisMDpcX+0x21 80549050 80540ef6 00000000 0000000e 00000000 nt!KiRetireDpcList+0x46 80549054 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x26
STACK_COMMAND: kb
FOLLOWUP_IP: tdifilter_testdriver!HookedClientEventReceive+af [c:\drv\main.c @ 160] fb051c1f 8945f4 mov dword ptr [ebp-0Ch],eax
FAULTING_SOURCE_CODE: 156: BytesIndicated, 157: BytesAvailable, 158: BytesTaken, 159: Tsdu, > 160: IoRequestPacket); 161: 162: DbgPrint("tdi_sniffer -------***OldClientEventReceive Sucefull Executed***-------\n"); 163: 164: return ntStatus; 165: }
SYMBOL_STACK_INDEX: 5
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: tdifilter_testdriver
IMAGE_NAME: tdifilter_testdriver.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 469d23da
SYMBOL_NAME: tdifilter_testdriver!HookedClientEventReceive+af
FAILURE_BUCKET_ID: 0xD1_W_tdifilter_testdriver!HookedClientEventReceive+af
BUCKET_ID: 0xD1_W_tdifilter_testdriver!HookedClientEventReceive+af
Followup: MachineOwner --------- tdifilter_testdriver.sys это и есть мой драйвер.. Никак не пойму почему ошибка на IoRequestPacket???
|
|
|
Записан
|
|
|
|
Ochkarik
|
|
« Ответ #1 : 19-07-2007 07:29 » |
|
почему... агрументы некорректные вестимо!
ЗЫ а что за OldClientEventReceive? в ддк только ClientEventReceive нашел.
ЗЗЫ IoRequestPacket - должен быть УКАЗАТЕЛЕМ на указатель IRP. ЗЗЗЫ BytesTaken - тоже указателем на ULONG. на всякий случай.
|
|
« Последнее редактирование: 19-07-2007 07:33 от Ochkarik »
|
Записан
|
RTFM уже хоть раз наконец! :[ ну или хотя бы STFW...
|
|
|
Ochkarik
|
|
« Ответ #2 : 19-07-2007 07:37 » |
|
PPPS а то стрелочка дебагера показывавет на IoRequestPacket - она просто указывает на твой вызов. точнее на последнюю строчку написанной тобой функции. по крайней мере если обобщать мой опыт работы с отладчиками)
|
|
|
Записан
|
RTFM уже хоть раз наконец! :[ ну или хотя бы STFW...
|
|
|
Dmitry_177
Участник
Offline
|
|
« Ответ #3 : 19-07-2007 07:52 » |
|
ЗЫ а что за OldClientEventReceive? в ддк только ClientEventReceive нашел. Это адрес оригинальной функции ClientEventReceive.. Я делаю именно перехват, т.е. никакой мой объект не аттачится к tcp.. ЗЗЫ IoRequestPacket - должен быть УКАЗАТЕЛЕМ на указатель IRP. ЗЗЗЫ BytesTaken - тоже указателем на ULONG. на всякий случай. Я знаю что это указателя, я из вроде и передаю: typedef NTSTATUS (*OLDCLIENTEVENTRECEIVE)(IN PVOID, IN CONNECTION_CONTEXT, IN ULONG, IN ULONG, IN ULONG, OUT ULONG*, IN PVOID, OUT PIRP*);
NTSTATUS HookedClientEventReceive(IN PVOID TdiEventContext, IN CONNECTION_CONTEXT ConnectionContext, IN ULONG ReceiveFlags, IN ULONG BytesIndicated, IN ULONG BytesAvailable, OUT ULONG *BytesTaken, IN PVOID Tsdu, OUT PIRP *IoRequestPacket) { NTSTATUS ntStatus;
UCHAR *sduBuffer;
PCLIENTEVENTRECEIVECONTEXT pBlockFromPagedLookasideList; OLDCLIENTEVENTRECEIVE OldClientEventReceive;
pBlockFromPagedLookasideList = TdiEventContext; OldClientEventReceive = pBlockFromPagedLookasideList->EventHandler;
sduBuffer = Tsdu; DbgPrint("tdi_sniffer: -------***BEGIN TDI_RECEIVE***-------\n"); DbgPrint(sduBuffer); DbgPrint("\n"); DbgPrint("tdi_sniffer: --------***END TDI_RECEIVE***--------\n");
ntStatus = OldClientEventReceive(pBlockFromPagedLookasideList->EventContext, ConnectionContext, ReceiveFlags, BytesIndicated, BytesAvailable, BytesTaken, Tsdu, IoRequestPacket);
DbgPrint("tdi_sniffer: -------***OldClientEventReceive Sucefull Executed***-------\n");
return ntStatus; }
|
|
« Последнее редактирование: 19-07-2007 10:07 от Dmitry_177 »
|
Записан
|
|
|
|
Dmitry_177
Участник
Offline
|
|
« Ответ #4 : 19-07-2007 07:55 » |
|
У меня в контекст HookedClientEventReceive передается моя структура, в которой содержится оригинальный контекст и оригинальная функция.. А их я задаю при перехвате TDI_SET_EVENT_HANDLER
|
|
|
Записан
|
|
|
|
Dmitry_177
Участник
Offline
|
|
« Ответ #5 : 19-07-2007 09:59 » |
|
Вообще в TDI_SET_EVENT_HANDLER в IrpSp->Parameters содержится структура struct _TDI_REQUEST_KERNEL_SET_EVENT { LONG EventType; PVOID EventHandler; PVOID EventContext; } TDI_REQUEST_KERNEL_SET_EVENT, *PTDI_REQUEST_KERNEL_SET_EVENT; в EventHandler содержится адрес оригинальной ClientEventReceive? Собственно я и задаю в TDI_SET_EVENT_HANDLER адрес своей функции в EventHandler: ((PTDI_REQUEST_KERNEL_SET_EVENT)&irpStack->Parameters)->EventHandler = HookedClientEventReceive; А в EventContext задаю адрес на свою структуру, в которой хранится адрес оригинального контекста и функции: ((PTDI_REQUEST_KERNEL_SET_EVENT)&irpStack->Parameters)->EventContext = pBlockFromPagedLookasideList; Сам перехват проихродит.. данные Tsdu вывожу и все принятые данные показывается в DbgPrint, но при вызове оригинальной ClientEventReceive система падает... Вот никак не могу понять почему...
|
|
« Последнее редактирование: 19-07-2007 10:03 от Dmitry_177 »
|
Записан
|
|
|
|
Dmitry_177
Участник
Offline
|
|
« Ответ #6 : 20-07-2007 11:25 » |
|
Блин!!! Разобрался Я оказывается неправильно адрес передавал.. Подскажите пожалуйста еще про TDI_EVENT_RECEIVE_DATAGRAM, когда это устанавливается? Что за датаграммы? Используются ли они при обычном лазании по сайтам, использования аськи, всяких других программ общения и всяких почтовых программ? Что-то не совсем понимаю что за датаграммы такие..
|
|
|
Записан
|
|
|
|
Dmitry_177
Участник
Offline
|
|
« Ответ #7 : 20-07-2007 18:10 » |
|
перехватываю еще ClientEventChainedReceive сам перехват срабатывает, но данные почему-то из Tsdu немогу вытянуть.. Делаю так: NTSTATUS HookedClientEventChainedReceive(IN PVOID TdiEventContext, IN CONNECTION_CONTEXT ConnectionContext, IN ULONG ReceiveFlags, IN ULONG ReceiveLength, IN ULONG StartingOffset, IN PMDL Tsdu, IN PVOID TsduDescriptor) { UCHAR *sduBuffer;
DbgPrint("tdi_sniffer: -------***BEGIN TDI_EVENT_CHAINED_RECEIVE***-------\n"); sduBuffer = MmGetSystemAddressForMdlSafe (Tsdu, LowPagePriority); DbgPrint(sduBuffer); DbgPrint("tdi_sniffer: --------***END TDI_EVENT_CHAINED_RECEIVE***--------\n");
return ((OLDCLIENTEVENTCHAINEDRECEIVE)((PCLIENTEVENTRECEIVECONTEXT)TdiEventContext)->EventHandler)(((PCLIENTEVENTRECEIVECONTEXT)TdiEventContext)->EventContext, ConnectionContext, ReceiveFlags, ReceiveLength, StartingOffset, Tsdu, TsduDescriptor); } т.к. в Tsdu содержится MDL адрес, вытягиваю данные функцией MmGetSystemAddressForMdlSafe.. и почему-то никакие принятые данные не отображаются..
|
|
|
Записан
|
|
|
|
Dmitry_177
Участник
Offline
|
|
« Ответ #8 : 23-07-2007 06:25 » |
|
неужели никто не знает???
|
|
|
Записан
|
|
|
|
|
Dmitry_177
Участник
Offline
|
|
« Ответ #10 : 23-07-2007 16:31 » |
|
Честно говоря я по той ссылке ничего полезного для себя не нашел...
|
|
|
Записан
|
|
|
|
Ochkarik
|
|
« Ответ #11 : 24-07-2007 17:00 » |
|
я имел в виду то что вначале написано, парень использует все это для дампа UDP портов. и что данные у него тоже терялись, потому что фаервол включен был. и вообще... с чего бы это отображатся данным?( DbgPrint(sduBuffer) вам что специально строковые, отформатированные пакеты отсылают?)))
|
|
|
Записан
|
RTFM уже хоть раз наконец! :[ ну или хотя бы STFW...
|
|
|
Dmitry_177
Участник
Offline
|
|
« Ответ #12 : 24-07-2007 17:07 » |
|
вам что специально строковые, отформатированные пакеты отсылают?))) ну например HTML-страничка.. чем не строки? =) Наверно все дело в том что DbgPrint отображает строку до первого '#0' (нуль-терминанта) но сама строка на этом может и не заканчиваться в принятых данных.. Можно ли как-то отображать полностью всю строку с нуль-терминантами???
|
|
|
Записан
|
|
|
|
aks68
|
|
« Ответ #13 : 24-07-2007 22:30 » |
|
Добрый день! Как всегда начну с вопоросов 1. У Вас нераспечатывается содержимое MDL буфера предположительно содержащего TSDU, только из обработчика ClientEventChainedReceive или из ClientEventReceive тоже? Это я к тому, что ClientEventChainedReceive может вернуть указатель на список MDL буферов по которым будут распределены данные TSDU. 2. К вопросу о сути TSDU. Я так пологаю, что это даттаграмма (IP-datagramm), и в первом блоке MDL могут находиться данные относящееся к заголовку даттаграммы и далее к заголовкам инкапсулированных в нее пакетов - т.е. информация неотображаемая по формату %s . 3. Контроль данных. Вообще-то MmGetSystemAddressForMdlSafe может вернуть и NULL. Вы это непроверяете. 4. Обьективный контроль. Если Вы не пользуетесь генератором сетевого трафика, чтобы быть уверенным в данных проходящих через TDI, то хотя-бы включите к-либо сниффер (например ethereal), дабы была возможность сравнить то, что получилось у Вас с тем, что реально прошло через стек протоколов. С уважением, Акс.
|
|
|
Записан
|
|
|
|
Dmitry_177
Участник
Offline
|
|
« Ответ #14 : 25-07-2007 05:41 » |
|
1. Не распечатывало только ClientEventChainedReceive, ClientEventReceive все нормально.. Но сейчас я сделал в ClientEventChainedReceive так, и все вроде заработало: UCHAR *sduBuffer; sduBuffer = MmGetSystemAddressForMdlSafe (Tsdu, LowPagePriority); sduBuffer += StartingOffset; т.к. в StartingOffset содержится начало буфера данных.. Но, мне еще не понятно одно.. Вот например с использованием моего этого драйвера при открытии странички в браузере, я почему-то вижу только HTTP заголовки, а принятую html-ку(которая по идее должна идти после заголовка) не вижу, иногда, очень редко проскочит какой-нибудь маленький кусочек html-кода.. А еще часто бывает просто абра-кадабра какая-то пишется... 2. я работаю с TCP, перехватываю только ClientEventReceive, ClientEventChainedReceive и TDI_RECEIVE(IRP_MJ_INTERNAL_DEVICE_CONTROL).. а UDP(как я понимаю TDI_EVENT_RECEIVE_DATAGRAM и д.р.) я не перехватываю.. 3. Может глупый вопрос, но все же.. А проверять так надо? UCHAR *sduBuffer; sduBuffer = MmGetSystemAddressForMdlSafe (Tsdu, LowPagePriority); if (sduBuffer != NULL) { .. MmGetSystemAddressForMdlSafe не вернуло NULL, выводим в DbgPrint-е } 4. а что за генератор такой? самому написать надо или есть готовые? И еще, ктобы мог бы объяснить, когда вызывается ClientEventReceive(TDI_EVENT_RECEIVE), когда ClientEventChainedReceive(TDI_EVENT_CHAINED_RECEIVE) и когда TDI_RECEIVE? Не пойму никак из DDK.. Растолкуйте пожалуйста, а то непонятно как-то..
|
|
|
Записан
|
|
|
|
aks68
|
|
« Ответ #15 : 27-07-2007 11:44 » |
|
Добрый день!Под даттаграммой я подразумевал IP-даттаграмму, а не UDP. Это не одно и тоже. Хотя впринципе неважно, просто я хотел сказать, что в буфере лежит весь пакет, а у него имеется заголовок состоящий из полей содержащих неотображаемые символы.Акс.
|
|
|
Записан
|
|
|
|
aks68
|
|
« Ответ #16 : 27-07-2007 11:47 » |
|
Добрый день!По пункту 2:Под даттаграммой я подразумевал IP-даттаграмму, а не UDP. Это не одно и тоже. Хотя впринципе неважно, просто я хотел сказать, что в буфере лежит весь пакет, а у него имеется заголовок состоящий из полей содержащих неотображаемые символы.Акс.
|
|
|
Записан
|
|
|
|
aks68
|
|
« Ответ #17 : 27-07-2007 12:02 » |
|
По пункту 4.
Насамом деле если Вы неиспользуете 2 компютера, то завести входящий пакет непросто. Если Вы пишете для TDI, то наверное надо попробовать послать на 127.0.0.1 Однако насколько я понял Вы пользуетесь WinDBG, а соответственно имеете 2 компа? Из утилит попробуите hping, netcat и tcp reply. Они работают поразному - выберите что Вам подуше. Акс.
|
|
|
Записан
|
|
|
|
Dmitry_177
Участник
Offline
|
|
« Ответ #18 : 27-07-2007 12:46 » |
|
У меня есть второй компьютер Но отладку всеравно через VMware делаю.. aks68, а что вы можете сказать по 1-му пункту? он очень важен для меня, особенно про html-страничку.. и по поводу 3-го?
|
|
|
Записан
|
|
|
|
aks68
|
|
« Ответ #19 : 07-08-2007 22:38 » |
|
Добрый день! Наконец-то починил компьютер - теперь отвечаю. По поводу п1, не являясь специалистом в TDI, все-же рискну предложить проверить полученные данные - Получили ли Вы целый пакет в этом TDSU?
- Если неполучили целый пакет, то почему? (Например NDIS-овский ProtocolReceive колбэк тоже неполучает весь пакет)
- Если получили - стоит обратить внимание на формат вывода - привести его к char*
Что бы облегчить мониторинг стоит пропихивать через стек лишь небольшое к-во пакетов зараз. При этом нечто наподобие EtheReal покажет Вам, что получил NDIS-овый protocol, а он как я понимаю и является Вашим TDI-сервером, или как его там . Таким образом сравнивая переданное и полученное можно попытаться определить в чем дело. Для начала попробуйте убедиться, что полностью проходят "маленькие" пакеты (залогиньтесь например куда-нибудь через telnet или ftp и посмотрите на проходящие при этом пакеты). По поводу п3 - Вы прикалываетесь или как? (Помните шутку про 10 способов измерения высоты здания спомощью барометра? ) С уважением Акс. PS: А как Вы понимаете понятие TDSU в контексте TDI?
|
|
|
Записан
|
|
|
|
Dmitry_177
Участник
Offline
|
|
« Ответ #20 : 09-08-2007 07:00 » |
|
Наконец-то починил компьютер - теперь отвечаю. о.. я уж думал не ответите.. спасибо вам не являясь спецом в написании драйверов некоторые вещи я не очень понимаю... Получили ли Вы целый пакет в этом TDSU? это как? в ReceiveLength и есть длина полученного буфера TDSU.. Если получили - стоит обратить внимание на формат вывода - привести его к char* а как это перевести к char* ведь помоему там нету char-а, там вроде только все в юникоде, т.е. только UCHAR*, но у меня так и сделано.. А может ли это быть из-за того, что DbgPrint выводит строку только до первого '#0', т.е. нуль-терминанта, а на самом деле принятый пакет, который мы выводим в виде строки на этом не заканчивается, и после '#0' может и идет html-ка.. По поводу п3 - Вы прикалываетесь или как? нет, правда нет.. PS: А как Вы понимаете понятие TDSU в контексте TDI? я это понимаю как адрес буфера, в котором находятся принятые данных..
|
|
|
Записан
|
|
|
|
aks68
|
|
« Ответ #21 : 09-08-2007 23:51 » |
|
Привет! Получили ли Вы целый пакет в этом TDSU? это как? в ReceiveLength и есть длина полученного буфера TDSU.. Э, нет... я ведь написал пакет. Подразумевая конечно TCP пакет. А буфер, так это просто буфер. И совсем не факт, что в буфере будет находится весь пакет. TSDU - как я понимаю "Transport Service Data Unit", т.е. по простому законченный кусок данных, которым оперирует транспортный уровень - TDI. Теперь вопрос: Если произошла фрагментация пакета, то должен-ли TDI его собирать, и собирает-ли? Вот это я и предлагаю проверить. Если получили - стоит обратить внимание на формат вывода - привести его к char* а как это перевести к char* ведь помоему там нету char-а, там вроде только все в юникоде, т.е. только UCHAR*, но у меня так и сделано.. А может ли это быть из-за того, что DbgPrint выводит строку только до первого '#0', т.е. нуль-терминанта, а на самом деле принятый пакет, который мы выводим в виде строки на этом не заканчивается, и после '#0' может и идет html-ка.. По поводу char* я имел ввиду преобразовать все "не печатные" символы в буфере в "печатные" (например десятичная "1" это ASCI - 31, если не ошибаюсь) распечатав например их 16ричное представление. По поводу п3 - Вы прикалываетесь или как? нет, правда нет.. Ну коли так, то ответ положительный - да Вы можете так проверять статус. С уважением, Акс.
|
|
|
Записан
|
|
|
|
Dmitry_177
Участник
Offline
|
|
« Ответ #22 : 10-08-2007 15:58 » |
|
Э, нет... я ведь написал пакет. Подразумевая конечно TCP пакет. А буфер, так это просто буфер. И совсем не факт, что в буфере будет находится весь пакет. а как это сделать??? откуда я могу знать сколько пакет весит? Теперь вопрос: Если произошла фрагментация пакета, то должен-ли TDI его собирать, и собирает-ли? Вот это я и предлагаю проверить. Что-то я не понял вопроса честно говоря.. На сколько я знаю: отправляются к примеру какие-то данные, они же разбиваются на пакеты.. а та сторона которая принимает эти пакеты, собирает их(с учетом того, что пакеты могут придти совсем не в последовательном порядке). Что значит фрагментация пакета? Я могу только догадываться.. Это случаянно не отбрасывание tcp заголовка(или еще там чего) пакета, т.е. чтобы были "чистые" данные?
|
|
|
Записан
|
|
|
|
aks68
|
|
« Ответ #23 : 14-08-2007 06:30 » |
|
а как это сделать??? откуда я могу знать сколько пакет весит? Из заголовка пакета. Если у Вас еще нет, то скачайте с этого сайта перевод "TCP-IP Illustrated" ( https://club.shelek.ru/download.php?id=243) и посмотрите гл.17 Что-то я не понял вопроса честно говоря.. На сколько я знаю: отправляются к примеру какие-то данные, они же разбиваются на пакеты.. а та сторона которая принимает эти пакеты, собирает их(с учетом того, что пакеты могут придти совсем не в последовательном порядке). Что значит фрагментация пакета? Я могу только догадываться.. Это случаянно не отбрасывание tcp заголовка(или еще там чего) пакета, т.е. чтобы были "чистые" данные?
Я незнаю насколько это релевантно для TDI, но существует например IP-fragmentation, это когда по ходу следования пакета попадется устройство с MTU < (MTU отправителя). Кроме того в NDIS, Protocol может сабирать фрагменты, а может и несобирать. Так что совсем не факт, что пакет придет целиком враз. Короче - неполенитесь, добавьте возможность более детально смотреть в TSDU. И вот еще. Если мне неизменяет память, то где-то на сайте PCAUSA можно было сгрузить бесплатный сниффер TDI. Посмотрите, может поможет. С уважением, Акс.
|
|
|
Записан
|
|
|
|
Dmitry_177
Участник
Offline
|
|
« Ответ #24 : 29-08-2007 08:56 » |
|
Сравнил я что у меня приходит в ethereal-е и что отображает мой драйвер.. а принципе все тоже самое(по TCP трафику) но у меня все также не полностью высвечиваются данные, вот например: при открытии в IE www-страницы мой драйвер пишет: tdi_sniffer: -------***BEGIN TDI_EVENT_CHAINED_RECEIVE***------- HTTP/1.1 401 Access Denied Server: Microsoft-IIS/5.0 Date: Wed, 29 Aug 2007 08:53:46 GMT WWW-Authenticate: Negotiate WWW-Authenticate: NTLM WWW-Authenticate: Basic realm="WPAD" Connection: close Content-Length: 4431 Content-Type: text/html <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <html dir=ltr> <head> <style> a:link {font:8pt/11pt verdana; color:FF0000} a:visited {font:8pt/11pt verdana; color:#4e4e4e} </style> <META NAME="ROBOTS" CONTENT=" @» tdi_sniffer: --------***END TDI_EVENT_CHAINED_RECEIVE***-------- и все, на этом обрыв данных хотя дальше тоже должно все быть.. а в ethereal-е все тоже самое т.е. начало тоже но там и продолжение есть..
|
|
« Последнее редактирование: 29-08-2007 09:06 от Dmitry_177 »
|
Записан
|
|
|
|
|