Menu
▾
▴
USB sniffer log entrys from windows driver (was: Re: Fw: Re: [Eciadsl-devel] pppoatm plugin and eci module)
|
From: Pekka S. <pek...@ko...> - 2002-04-01 15:15:26
|
Hmm, actually when these two cells are looked inside, first one is not icmp ehco request and second is not icmp echo recieved, but anyway, this is how traffic in windows looks like in usb snoopy point of view. 1st packet is http request and 2nd is http recieved. Sorry for wrong info in previous mail. -Pekka On Mon, 1 Apr 2002 17:41:55 -0200 Pekka Sakara <pek...@ko...> wrote: > forget CC to ML > > Begin forwarded message: > > Date: Mon, 1 Apr 2002 17:40:35 -0200 > From: Pekka Sakara <pek...@ko...> > To: "Eric Bardes" <bar...@wa...> > Subject: Re: Fw: Re: [Eciadsl-devel] pppoatm plugin and eci module > > > Damn, Eric, you were right... I used usb sniffer in windows and here is what I got: > > First packet is icmp echo request sent by my windows box 10.104.11.194 to my default gateway 10.99.25.1 and second is icmp echo reply recieved from 10.99.25.1!!! > > The recieved cell has only 3 octet header... and still everything works just fine under windows! Data is sent and recieved just fine! Under linux recieved header is 4 octets long... > > One remarkable thing in sent packet, there is no HEC calculation or checking in Windows driver. > > And now my question is that how in hell windows driver handles 3 octet header in incoming frames?!?!? > > UsbSnoop - MyDispatchInternalIOCTL(C18B78B7) : fdo=C144A028, Irp=C16B9C50 > >>> URB 300196 going down >>> > -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER: > PipeHandle = C1665214 [endpoint 0x2] > TransferFlags = 00000000 (USBD_TRANSFER_DIRECTION_OUT, ~USBD_SHORT_TRANSFER_OK) > TransferBufferLength = 00000080 > TransferBuffer = c161da70 > TransferBufferMDL = 00000000 > 0000: 00 00 06 40 00 aa aa 03 00 00 00 08 00 45 00 00 > 0010: 28 3a 14 40 00 80 06 74 4e 0a 68 0b c2 d8 1b 5e > 0020: 28 04 b9 00 50 00 5e 6a 87 c6 fa ef 3a 50 11 fd > 0030: 85 3f bc 00 00 ff ff ff ff ff ff ff ff ff ff ff > 0040: 00 00 06 42 00 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 > 0050: c0 c0 c0 c0 c0 c0 c0 c0 c0 00 00 00 00 00 00 00 > 0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0070: 44 81 97 81 73 ff ff ff ff ff ff ff ff ff ff ff > UrbLink = 00000000 > UsbSnoop - MyInternalIOCTLCompletion(C18B7708) : fido=00000000, Irp=C16B9C50, Context=C2A241E0 > <<< URB 300196 coming back <<< > -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER: > PipeHandle = C1665214 [endpoint 0x2] > TransferFlags = 00000000 (USBD_TRANSFER_DIRECTION_OUT, ~USBD_SHORT_TRANSFER_OK) > TransferBufferLength = 00000080 > TransferBuffer = c161da70 > TransferBufferMDL = d45a88d0 > UrbLink = 00000000 > UsbSnoop - MyInternalIOCTLCompletion(C18B7708) : fido=00000000, Irp=C16E3B90, Context=C2A24000 > <<< URB 300086 coming back <<< > -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER: > PipeHandle = C16651F8 [endpoint 0x88] > TransferFlags = 00000003 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK) > TransferBufferLength = 00000073 > TransferBuffer = c1654000 > TransferBufferMDL = d45aa070 > 0000: 0c 06 40 aa aa 03 00 00 00 08 00 45 00 00 28 74 > 0010: bc 00 00 68 06 92 dd cc fd 68 0f 0a 68 0b c2 00 > 0020: 50 04 b6 24 77 76 2a 00 5e 69 5f 50 10 43 1c 18 > 0030: 1d 00 00 81 d3 e9 ca fd c2 4b b6 35 fe 7b d9 ff > 0040: 02 06 42 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a > 0050: 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a > 0060: 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a 6a 00 00 00 30 43 > 0070: 36 76 03 > UrbLink = 00000000 > UsbSnoop - MyDispatchInternalIOCTL(C18B78B7) : fdo=C144A028, Irp=C16E3B90 > > > > > On Sun, 31 Mar 2002 13:12:34 +0200 > "Eric Bardes" <bar...@wa...> wrote: > > > To be sure ! could you get some logs of a session under windows ! To compare > > the data received ??? > > > > Eric. > > > > ----- Original Message ----- > > From: "Pekka Sakara" <pek...@ko...> > > To: <eci...@li...> > > Sent: Sunday, March 31, 2002 2:51 PM > > Subject: Fw: Fw: Re: [Eciadsl-devel] pppoatm plugin and eci module > > > > > > > > > > > >Things haven't change with 1.32 version of eci module. > > > > > > > > > >Headers are corrupted. Data after corrupted header looks pretty good. > > > > > > > > > >Here is example from my syslog: > > > > > > > > > >ping request to my linux box from linux box at internet: > > > > > > > > > this seem very odd to me. > > > > It sem that your peer send orupted frame to you ! > > > > Are all the cell droped this way ? > > > > Are the VPI/VCI correct in th cell header ? > > > > > > All cells are dropped by this way. All recieved headerers are corrupted > > after eci have read them. > > > > > > I don't beliewe that DSLAM sends me corrupted packets as other CPEs are > > working just great in my adsl line. > > > > > > In eci recieved header VCI is wrong but VPI is correct. > > > > > > The same thing happens at my home line where these tests are run, and also > > in my work place where I had that DSLAM. In both scenarios recieved cell > > headers are corrupted. > > > > > > > >In both packet capture we can find same octets and IP-addresses are in > > correct place and so on... only thing that I don't understand is bunch of > > 6a's that came after ping request..? > > > > > > > > > May be padding from the router that buils atm cells > > > > > > > > could you tell us the network topology used for your test > > > > > > At my home, network topology is: > > > > > > linux-box--eci---//---DSLAM---//---ISP-NAT---//---internet---> > > > > > > Where: > > > > > > Linux-box has IP provided by ISP, 10.104.11.194 netmask 255.0.0.0 > > > > > > DSLAM does RFC1483/Routed/LLC, IP 10.99.25.1. Provides routing and is > > Default Gateway for my connection. VPI=0, VCI=100. > > > > > > ISP-NAT is huge NAT-box doing transparent 1:1 NAT for all customers > > connected to this ISP. > > > > > > And these are settings that work in Windows enviroment with this same usb > > adsl modem, and other 'out-of-the-box' CPEs work with these settings. So > > everything is configured properly and DSLAM is working. Eci-module is not > > working properly, yet :) > > > > > > -Pekka > > > > > > > > > _______________________________________________ > > > Eciadsl-devel mailing list > > > Eci...@li... > > > https://lists.sourceforge.net/lists/listinfo/eciadsl-devel > > > > > > > > > > _______________________________________________ > Eciadsl-devel mailing list > Eci...@li... > https://lists.sourceforge.net/lists/listinfo/eciadsl-devel |