Hi,
I am developing network adapter to transfer TCP/UDP packets from the
ip layer
(through the ndis driver) to the com port to other remote PC and vice-
versa
under the WM5 using the VS2005 and Windows Mobile 5.0 Pocket PC SDK.
Before sending/receiving data, I set the ARP entries of the remote PC
statically.
The problem is when the remote PC is sending data and the PDA receive
it and pass
it to the NDIS driver through the function NdisMEthIndicateReceive and
the function
NdisMEthIndicateReceiveComplete, the data didn't pass to higher
protocols above
the ip layer and the applications whic uses the tcp/udp which wait for
the data,
didn't receive any of it.
I have a little application which displays all the adapter installed
on the PDA
and the binding to the relevant Protocols and i notice there is no
problem of
binding, since the adapter is bind to the TCPIP, TCPIP6 and NDISUIO
protocols.
I checked several posts of that problem and notice about the
OID_GEN_CURRENT_PACKET_FILTER
I checked that value and it gave me the value 11 (0x0000000B), my
tries to change that
value didn't suceed, so maybe that the problem, or maybe not since i
can see that
the adapter is binding to the TCPIP protocol.

Anyway, I would _really_ appreciate if some can help me solving that
problem.

Best regards,
ligal

RE: Problem with NdisMEthIndicateReceive - not receiving data by AntonBassov

AntonBassov
Wed Jul 11 03:28:00 CDT 2007

Judging from the description of a problem, TCPIP is just not interested in
data that you indicate to it with NdisMEthIndicateReceive(), so that its
PtReceive() does not do anything about it. The most obvious reason for this
is that data that you pass to it is just not formatted properly. Please note
that if you want TCPIP to recognize your data, you should supply properly
formatted MAC, IP and protocol headres in lookahead buffer - otherwise, TCPIP
will just ignore it. Apparently, this is what is happening here.....


Anton Bassov

"ligal" wrote:

> Hi,
> I am developing network adapter to transfer TCP/UDP packets from the
> ip layer
> (through the ndis driver) to the com port to other remote PC and vice-
> versa
> under the WM5 using the VS2005 and Windows Mobile 5.0 Pocket PC SDK.
> Before sending/receiving data, I set the ARP entries of the remote PC
> statically.
> The problem is when the remote PC is sending data and the PDA receive
> it and pass
> it to the NDIS driver through the function NdisMEthIndicateReceive and
> the function
> NdisMEthIndicateReceiveComplete, the data didn't pass to higher
> protocols above
> the ip layer and the applications whic uses the tcp/udp which wait for
> the data,
> didn't receive any of it.
> I have a little application which displays all the adapter installed
> on the PDA
> and the binding to the relevant Protocols and i notice there is no
> problem of
> binding, since the adapter is bind to the TCPIP, TCPIP6 and NDISUIO
> protocols.
> I checked several posts of that problem and notice about the
> OID_GEN_CURRENT_PACKET_FILTER
> I checked that value and it gave me the value 11 (0x0000000B), my
> tries to change that
> value didn't suceed, so maybe that the problem, or maybe not since i
> can see that
> the adapter is binding to the TCPIP protocol.
>
> Anyway, I would _really_ appreciate if some can help me solving that
> problem.
>
> Best regards,
> ligal
>
>

Re: Problem with NdisMEthIndicateReceive - not receiving data by ligal

ligal
Wed Jul 11 04:15:28 CDT 2007

Hi
Thanks for the post.
I've forgot to mention important information:
When i work in the PDA with the ActiveSync Mode: RNDIS Sync Mode,
i succeed to receive the data only if the PDA ActiveSync cable is
connected to the remote PC,
otherwise when the ActiveSync cable is disconnected, i receive that
data problem.
It seems to be a security problem? or do I miss something and it is
something else?

ligal




> On Jul 11, 11:28 am, Anton Bassov <AntonBas...@discussions.microsoft.com> wrote:
> Judging from the description of a problem, TCPIP is just not interested in
> data that you indicate to it with NdisMEthIndicateReceive(), so that its
> PtReceive() does not do anything about it. The most obvious reason for this
> is that data that you pass to it is just not formatted properly. Please note
> that if you want TCPIP to recognize your data, you should supply properly
> formatted MAC, IP and protocol headres in lookahead buffer - otherwise, TCPIP
> will just ignore it. Apparently, this is what is happening here.....
>
> Anton Bassov
>
>
>
> "ligal" wrote:
> > Hi,
> > I am developing network adapter to transfer TCP/UDP packets from the
> > ip layer
> > (through the ndis driver) to the com port to other remote PC and vice-
> > versa
> > under the WM5 using the VS2005 and Windows Mobile 5.0 Pocket PC SDK.
> > Before sending/receiving data, I set the ARP entries of the remote PC
> > statically.
> > The problem is when the remote PC is sending data and the PDA receive
> > it and pass
> > it to the NDIS driver through the function NdisMEthIndicateReceive and
> > the function
> > NdisMEthIndicateReceiveComplete, the data didn't pass to higher
> > protocols above
> > the ip layer and the applications whic uses the tcp/udp which wait for
> > the data,
> > didn't receive any of it.
> > I have a little application which displays all the adapter installed
> > on the PDA
> > and the binding to the relevant Protocols and i notice there is no
> > problem of
> > binding, since the adapter is bind to the TCPIP, TCPIP6 and NDISUIO
> > protocols.
> > I checked several posts of that problem and notice about the
> > OID_GEN_CURRENT_PACKET_FILTER
> > I checked that value and it gave me the value 11 (0x0000000B), my
> > tries to change that
> > value didn't suceed, so maybe that the problem, or maybe not since i
> > can see that
> > the adapter is binding to the TCPIP protocol.
>
> > Anyway, I would _really_ appreciate if some can help me solving that
> > problem.
>
> > Best regards,
> > ligal- Hide quoted text -
>
> - Show quoted text -


Re: Problem with NdisMEthIndicateReceive - not receiving data by Maxim

Maxim
Wed Jul 11 15:24:57 CDT 2007

For me, PPP is the proper way to run IP over com port, and PPP has no
notion of ARP.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"ligal" <ehudfl@gmail.com> wrote in message
news:1184139380.822226.174900@o61g2000hsh.googlegroups.com...
> Hi,
> I am developing network adapter to transfer TCP/UDP packets from the
> ip layer
> (through the ndis driver) to the com port to other remote PC and vice-
> versa
> under the WM5 using the VS2005 and Windows Mobile 5.0 Pocket PC SDK.
> Before sending/receiving data, I set the ARP entries of the remote PC
> statically.
> The problem is when the remote PC is sending data and the PDA receive
> it and pass
> it to the NDIS driver through the function NdisMEthIndicateReceive and
> the function
> NdisMEthIndicateReceiveComplete, the data didn't pass to higher
> protocols above
> the ip layer and the applications whic uses the tcp/udp which wait for
> the data,
> didn't receive any of it.
> I have a little application which displays all the adapter installed
> on the PDA
> and the binding to the relevant Protocols and i notice there is no
> problem of
> binding, since the adapter is bind to the TCPIP, TCPIP6 and NDISUIO
> protocols.
> I checked several posts of that problem and notice about the
> OID_GEN_CURRENT_PACKET_FILTER
> I checked that value and it gave me the value 11 (0x0000000B), my
> tries to change that
> value didn't suceed, so maybe that the problem, or maybe not since i
> can see that
> the adapter is binding to the TCPIP protocol.
>
> Anyway, I would _really_ appreciate if some can help me solving that
> problem.
>
> Best regards,
> ligal
>


Re: Problem with NdisMEthIndicateReceive - not receiving data by AntonBassov

AntonBassov
Wed Jul 11 16:08:01 CDT 2007

> For me, PPP is the proper way to run IP over com port, and PPP has no
> notion of ARP.

Judging from the fact that the OP uses NdisMEthIndicateReceive() here, I
think he tries to emulate Ethernet-based adapter - apparently, his driver
deals with COM port on its lower edge, and presents itself as Ethernet-based
adapter on the upper one, so that his packets must have ARP header. I may be
wrong - probably, he just misuses NdisMEthIndicateReceive(), i.e. his design
is wrong in absolutely all respects......


Anton Bassov
"Maxim S. Shatskih" wrote:

> For me, PPP is the proper way to run IP over com port, and PPP has no
> notion of ARP.
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>
> "ligal" <ehudfl@gmail.com> wrote in message
> news:1184139380.822226.174900@o61g2000hsh.googlegroups.com...
> > Hi,
> > I am developing network adapter to transfer TCP/UDP packets from the
> > ip layer
> > (through the ndis driver) to the com port to other remote PC and vice-
> > versa
> > under the WM5 using the VS2005 and Windows Mobile 5.0 Pocket PC SDK.
> > Before sending/receiving data, I set the ARP entries of the remote PC
> > statically.
> > The problem is when the remote PC is sending data and the PDA receive
> > it and pass
> > it to the NDIS driver through the function NdisMEthIndicateReceive and
> > the function
> > NdisMEthIndicateReceiveComplete, the data didn't pass to higher
> > protocols above
> > the ip layer and the applications whic uses the tcp/udp which wait for
> > the data,
> > didn't receive any of it.
> > I have a little application which displays all the adapter installed
> > on the PDA
> > and the binding to the relevant Protocols and i notice there is no
> > problem of
> > binding, since the adapter is bind to the TCPIP, TCPIP6 and NDISUIO
> > protocols.
> > I checked several posts of that problem and notice about the
> > OID_GEN_CURRENT_PACKET_FILTER
> > I checked that value and it gave me the value 11 (0x0000000B), my
> > tries to change that
> > value didn't suceed, so maybe that the problem, or maybe not since i
> > can see that
> > the adapter is binding to the TCPIP protocol.
> >
> > Anyway, I would _really_ appreciate if some can help me solving that
> > problem.
> >
> > Best regards,
> > ligal
> >
>
>