Current documentation indicates the only VanJAcobson Header compression is
implemented on Windows (in NDISWAN?). Is there a provison for plugging in a
new header compression protocol into windows? If so, how?
TIA,
Giri.
You could write an NDIS intermediate driver. There is documentation
in the DDK and in the Passthru sample. There is also lots of
additional information at www.ndis.com.
This is a bit of a tricky area; it’s not a short project. You will
have to parse IP and TCP headers, handle fragmentation and reassembly
(for tiny frags with huge headers), and so on.
-Steve
On Oct 5, 2006, at 6:11 AM, giri wrote:
Current documentation indicates the only VanJAcobson Header
compression is implemented on Windows (in NDISWAN?). Is there a
provison for plugging in a new header compression protocol into
windows? If so, how?TIA,
Giri.
— Questions? First check the Kernel Driver FAQ at http://
www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
Server section of OSR Online at http://www.osronline.com/page.cfm?
name=ListServer
Before jumping into actual implementation, I am trying to figure out the
kind of support Windows gives for this kind of task. I was under the
impression that, at RAS level we can direct NDISWAN (thru a RAS*.dll) to
negotiate a new header compression type with the peer. But after a lot of
google search I could only figure out a flag in RASENTRY strucuture which
can enable/disable header compression, but couldnt figure out if we can
specify WHAT compression type should be used.
I feel I can implement the header compression functionality in an IM driver
which layers above NDISWAN or in a WAN Miniport driver which receives PPP
frames from NDISWAN. But Iam not sure what becomes of the packet contents
after the packet is processed by NDISWAN. Or in the other case Iam not sure
if a compressed packet can be given to NDISWAN and if NDISWAN treats the
compressed packet as a payload as such or would it need an uncompressed
packet to check out on some fields which can affect its processing of the
packet.
I want to implement TCP/IP header compression if I can layer an IM above
NDISWAN or a TCP/IP/PPP header compression if I can implement it in a Wan
Miniport.
Basically I would like to build a framework (may be modifying passthru.sys)
to implement a new header compression type.
Any suggestions?
TIA,
Giri.
On 10/5/06, Steve Dispensa wrote:
>
> You could write an NDIS intermediate driver. There is documentation
> in the DDK and in the Passthru sample. There is also lots of
> additional information at www.ndis.com.
>
> This is a bit of a tricky area; it’s not a short project. You will
> have to parse IP and TCP headers, handle fragmentation and reassembly
> (for tiny frags with huge headers), and so on.
>
> -Steve
>
> On Oct 5, 2006, at 6:11 AM, giri wrote:
>
> > Current documentation indicates the only VanJAcobson Header
> > compression is implemented on Windows (in NDISWAN?). Is there a
> > provison for plugging in a new header compression protocol into
> > windows? If so, how?
> >
> > TIA,
> > Giri.
> > — Questions? First check the Kernel Driver FAQ at http://
> > www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
> > Server section of OSR Online at http://www.osronline.com/page.cfm?
> > name=ListServer
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
AFAIK you cannot modify the behavior of NDISWAN / RAS in the way you wish.
The negotiated NCPs and in particular IPCP options like header compression
are not to my knowledge exposed for ISV ‘innovation’.
Placing an IM driver above NDISWAN does not get you anything since the
‘interface’ looks like an Ethernet adapter. you will not be able to modify
how NDISWAN encapsulates the packet in PPP.
Placing an IM driver below NDIWAN and above the WAN Miniports (ASYNCMAC,
PPTP, L2TP, ISDN cards, etc.) does allow one to get into the PPP packet
stream but it would very tedious and error prone to attempt to modify the
behavior of the IPCP options negotiation to try and ‘trick’ RAS into
allowing a header compression algorithm for IP other than VJ. Even if it
were attempted, such a technique must necessarily prevent RAS from
negotiating any sort of link compression or encryption otherwise the IM
driver will *not* see IP-in-PPP packets.
Creating your own NDIS WAN Miniport, telling NDISWAN that you want to handle
all of the link protocol stuff (in other words, NDISWAN’s PPP implementation
is not used) and writing your own complete PPP implementation is an option
open to you but not a very good one.
Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of giri
Sent: Thursday, October 05, 2006 3:06 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] New Header Compression Protocols
Before jumping into actual implementation, I am trying to figure out the
kind of support Windows gives for this kind of task. I was under the
impression that, at RAS level we can direct NDISWAN (thru a RAS*.dll) to
negotiate a new header compression type with the peer. But after a lot of
google search I could only figure out a flag in RASENTRY strucuture which
can enable/disable header compression, but couldnt figure out if we can
specify WHAT compression type should be used.
I feel I can implement the header compression functionality in an IM driver
which layers above NDISWAN or in a WAN Miniport driver which receives PPP
frames from NDISWAN. But Iam not sure what becomes of the packet contents
after the packet is processed by NDISWAN. Or in the other case Iam not sure
if a compressed packet can be given to NDISWAN and if NDISWAN treats the
compressed packet as a payload as such or would it need an uncompressed
packet to check out on some fields which can affect its processing of the
packet.
I want to implement TCP/IP header compression if I can layer an IM above
NDISWAN or a TCP/IP/PPP header compression if I can implement it in a Wan
Miniport.
Basically I would like to build a framework (may be modifying passthru.sys)
to implement a new header compression type.
Any suggestions?
TIA,
Giri.
On 10/5/06, Steve Dispensa wrote:
You could write an NDIS intermediate driver. There is documentation
in the DDK and in the Passthru sample. There is also lots of
additional information at www.ndis.com.
This is a bit of a tricky area; it’s not a short project. You will
have to parse IP and TCP headers, handle fragmentation and reassembly
(for tiny frags with huge headers), and so on.
-Steve
On Oct 5, 2006, at 6:11 AM, giri wrote:
> Current documentation indicates the only VanJAcobson Header
> compression is implemented on Windows (in NDISWAN?). Is there a
> provison for plugging in a new header compression protocol into
> windows? If so, how?
>
> TIA,
> Giri.
> — Questions? First check the Kernel Driver FAQ at http://
> www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
> Server section of OSR Online at http://www.osronline.com/page.cfm?
> name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Thanks David , for your response.
I was reading the DDK documentation and I found that ISV’s can pitch in with
their prorietary header compression using OID_WAN_GET_COMP_INFO and
OID_WAN_SET_COMP_INFO.
According to my understanding:
- NDISWAN sends OID_WAN_GET_COMP_INFO to miniport
- miniport fills in its compression capabilities
- NDISWAN notifies protocol driver of the lower miniports capabilities.
- Protocol driver would chose one of the header compression types from the
list given and communicates it using OID_WAN_SET_COMP_INFO
Let me know if my interpretation is correct. Or if someone here has used
these OID’s and have a suggestion for me, I would be grateful.
Thanks,
Giri.
PS: Though Iam not new to windows driver programming, Iam new to NDIS
drivers. The way I present my questions might not be the best.
On 10/6/06, David R. Cattley wrote:
>
> AFAIK you cannot modify the behavior of NDISWAN / RAS in the way you
> wish. The negotiated NCPs and in particular IPCP options like header
> compression are not to my knowledge exposed for ISV ‘innovation’.
>
> Placing an IM driver above NDISWAN does not get you anything since the
> ‘interface’ looks like an Ethernet adapter. you will not be able to modify
> how NDISWAN encapsulates the packet in PPP.
>
> Placing an IM driver below NDIWAN and above the WAN Miniports (ASYNCMAC,
> PPTP, L2TP, ISDN cards, etc.) does allow one to get into the PPP packet
> stream but it would very tedious and error prone to attempt to modify the
> behavior of the IPCP options negotiation to try and ‘trick’ RAS into
> allowing a header compression algorithm for IP other than VJ. Even if it
> were attempted, such a technique must necessarily prevent RAS from
> negotiating any sort of link compression or encryption otherwise the IM
> driver will not see IP-in-PPP packets.
>
> Creating your own NDIS WAN Miniport, telling NDISWAN that you want to
> handle all of the link protocol stuff (in other words, NDISWAN’s PPP
> implementation is not used) and writing your own complete PPP implementation
> is an option open to you but not a very good one.
>
> Good Luck,
> Dave Cattley
> Consulting Engineer
> Systems Software Development
>
> ------------------------------
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of giri
> Sent: Thursday, October 05, 2006 3:06 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] New Header Compression Protocols
>
>
> Before jumping into actual implementation, I am trying to figure out the
> kind of support Windows gives for this kind of task. I was under the
> impression that, at RAS level we can direct NDISWAN (thru a RAS.dll) to
> negotiate a new header compression type with the peer. But after a lot of
> google search I could only figure out a flag in RASENTRY strucuture which
> can enable/disable header compression, but couldnt figure out if we can
> specify WHAT compression type should be used.
>
> I feel I can implement the header compression functionality in an IM
> driver which layers above NDISWAN or in a WAN Miniport driver which receives
> PPP frames from NDISWAN. But Iam not sure what becomes of the packet
> contents after the packet is processed by NDISWAN. Or in the other case Iam
> not sure if a compressed packet can be given to NDISWAN and if NDISWAN
> treats the compressed packet as a payload as such or would it need an
> uncompressed packet to check out on some fields which can affect its
> processing of the packet.
>
> I want to implement TCP/IP header compression if I can layer an IM above
> NDISWAN or a TCP/IP/PPP header compression if I can implement it in a Wan
> Miniport.
>
> Basically I would like to build a framework (may be modifying passthru.sys)
> to implement a new header compression type.
>
> Any suggestions?
>
> TIA,
> Giri.
>
> On 10/5/06, Steve Dispensa wrote:
> >
> > You could write an NDIS intermediate driver. There is documentation
> > in the DDK and in the Passthru sample. There is also lots of
> > additional information at www.ndis.com.
> >
> > This is a bit of a tricky area; it’s not a short project. You will
> > have to parse IP and TCP headers, handle fragmentation and reassembly
> > (for tiny frags with huge headers), and so on.
> >
> > -Steve
> >
> > On Oct 5, 2006, at 6:11 AM, giri wrote:
> >
> > > Current documentation indicates the only VanJAcobson Header
> > > compression is implemented on Windows (in NDISWAN?). Is there a
> > > provison for plugging in a new header compression protocol into
> > > windows? If so, how?
> > >
> > > TIA,
> > > Giri.
> > > — Questions? First check the Kernel Driver FAQ at http://
> > > www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
> > > Server section of OSR Online at http://www.osronline.com/page.cfm?
> > > name=ListServer
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> >
>
> — Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
> Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
OID_WAN_{GET|SET}COMP_INFO allows a miniport to influence the *link*
compression selection negotiated by CCP, not the *header* compression method
negotiated by IPCP. the OP said “header compression” and referred to VJ.
The OID_WAN{SET|GET}_COMP_INFO has nothing to do with IPCP negotiated
compression schemes.
Good luck,
Dave Cattley
Consulting Engineer
Systems Software Development
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of giri
Sent: Friday, October 06, 2006 5:21 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] New Header Compression Protocols
Thanks David , for your response.
I was reading the DDK documentation and I found that ISV’s can pitch in with
their prorietary header compression using OID_WAN_GET_COMP_INFO and
OID_WAN_SET_COMP_INFO.
According to my understanding:
- NDISWAN sends OID_WAN_GET_COMP_INFO to miniport
- miniport fills in its compression capabilities
- NDISWAN notifies protocol driver of the lower miniports capabilities.
- Protocol driver would chose one of the header compression types from the
list given and communicates it using OID_WAN_SET_COMP_INFO
Let me know if my interpretation is correct. Or if someone here has used
these OID’s and have a suggestion for me, I would be grateful.
Thanks,
Giri.
PS: Though Iam not new to windows driver programming, Iam new to NDIS
drivers. The way I present my questions might not be the best.
If I have an IM which is layered between NDISWAN and Wan Miniport and just
do IPCP negotiation at appropriate time (after LCP, but before CCP), it
would serve my purpose. Is there a clean way to do that? In that case what
is the appropriate time to negotiate IPCP?
-Giri.
On 10/6/06, David R. Cattley wrote:
>
> OID_WAN_{GET|SET}COMP_INFO allows a miniport to influence the link
> compression selection negotiated by CCP, not the header compression method
> negotiated by IPCP. the OP said “header compression” and referred to VJ.
> The OID_WAN{SET|GET}_COMP_INFO has nothing to do with IPCP negotiated
> compression schemes.
>
> Good luck,
> Dave Cattley
> Consulting Engineer
> Systems Software Development
>
> ------------------------------
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of *giri
> Sent: Friday, October 06, 2006 5:21 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] New Header Compression Protocols
>
>
> Thanks David , for your response.
>
> I was reading the DDK documentation and I found that ISV’s can pitch in
> with their prorietary header compression using OID_WAN_GET_COMP_INFO and
> OID_WAN_SET_COMP_INFO.
> According to my understanding:
> 1) NDISWAN sends OID_WAN_GET_COMP_INFO to miniport
> 2) miniport fills in its compression capabilities
> 3) NDISWAN notifies protocol driver of the lower miniports capabilities.
> 4) Protocol driver would chose one of the header compression types from
> the list given and communicates it using OID_WAN_SET_COMP_INFO
>
> Let me know if my interpretation is correct. Or if someone here has used
> these OID’s and have a suggestion for me, I would be grateful.
>
> Thanks,
> Giri.
>
> PS: Though Iam not new to windows driver programming, Iam new to NDIS
> drivers. The way I present my questions might not be the best.
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
editing the IPCP negotiation to convince the local host that it had
negotiated option 02 (IP-Compression-Protocol) as 00-21 (no compression) and
at the same time convincing the remote peer that some other value was agreed
is certainly possible. However, this ignores the “then what happens”
question of the remainder of the link’s negotiated attributes. It would be
necessary, for instance, to prevent NDISWAN from negotiating *any* link
compression/encryption to ensure that the proposed IM driver actually got a
‘clear’ IP packet to compress the header of. Losing link compression to
gain IP header compression (presumed to be better than VJ overall) could be
a different trade-off than your customer (or you) were expecting.
i would also caution that layering an IM between NDISWAN and NDIS WAN
Miniports is not a casual undertaking.
Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of giri
Sent: Monday, October 09, 2006 1:39 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] New Header Compression Protocols
If I have an IM which is layered between NDISWAN and Wan Miniport and just
do IPCP negotiation at appropriate time (after LCP, but before CCP), it
would serve my purpose. Is there a clean way to do that? In that case what
is the appropriate time to negotiate IPCP?
-Giri.
Hi David,
Thats a good info. Iam cautious on the task involved, but am trying
to understand all issues that needs to be considered! Further...
I understand that there are three compression stages:
Compression Type Negotiating
Protocol Compression Performed By
- IP header compression IPCP
TCPIP.sys or any IM above/below NDISWAN - PPP Header
Compression LCP NDISWAN? - Data/Link Compression CCP by
Miniport/Device?
Pls confirm if my understanding is right.
Considering my IM Driver is between NDISWAN and Miniport, if there is a PPP
Header compression done by NDISWAN its ok for me, as its well documented by
LCP protocol, considering the IM would interpret agreed-upon PPP Header
Compression options. But if Data Compression would happen before the data
reaches my IM, that I want to avoid by all means.
Thanks,
Giri.
On 10/9/06, David R. Cattley wrote:
>
> editing the IPCP negotiation to convince the local host that it had
> negotiated option 02 (IP-Compression-Protocol) as 00-21 (no compression) and
> at the same time convincing the remote peer that some other value was agreed
> is certainly possible. However, this ignores the "then what happens"
> question of the remainder of the link's negotiated attributes. It would be
> necessary, for instance, to prevent NDISWAN from negotiating any link
> compression/encryption to ensure that the proposed IM driver actually got a
> 'clear' IP packet to compress the header of. Losing link compression to
> gain IP header compression (presumed to be better than VJ overall) could be
> a different trade-off than your customer (or you) were expecting.
>
> i would also caution that layering an IM between NDISWAN and NDIS WAN
> Miniports is not a casual undertaking.
>
> Good Luck,
> Dave Cattley
> Consulting Engineer
> Systems Software Development
>
>
> ------------------------------
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of *giri
> Sent: Monday, October 09, 2006 1:39 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] New Header Compression Protocols
>
>
> If I have an IM which is layered between NDISWAN and Wan Miniport and
> just do IPCP negotiation at appropriate time (after LCP, but before CCP), it
> would serve my purpose. Is there a clean way to do that? In that case what
> is the appropriate time to negotiate IPCP?
>
> -Giri.
>
>
> ---
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> ListServer/Forum
>
>> 1) IP header compression IPCP
TCPIP.sys or any IM above/below NDISWAN
no. IPCP is a PPP protocol. TCPIP.SYS does not have any role in
compressing IP headers. All PPP processing is done by NDISWAN.
> 3) Data/Link Compression CCP
by Miniport/Device?
no. CCP is a PPP protocol implemented by NDISWAN. the individual network
control protocols (NCP) like MS-PPC and MS-PPE are implemented by NDISWAN.
Other link compression (or encryption) protocols *might* be implemented by a
particular NDIS WAN miniport.
I have no idea what you might mean by PPP header compression. AFAIK, there
is no such thing in general. PPP does allow for protocol field of the PPP
header be ‘compressed’ to one octet for suitably valued protocol numbers but
I don’t think this is what you mean.
If you have access to the book “PPP Design and Implementation” by James
Carlson, I recommend it emphatically.
As for how to trick NDISWAN/RAS into doing any of this, you are pretty much
on your own. If you are comfortable and confident that your aims can be
achieved by a ‘device-in-the-middle’ design whereby your processing can sit
in the middle of the PPP packet exchange of a PPP client and PPP server,
that is essentially what you can build in an IM driver.
Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development
> ----------
From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of David R. Cattley[SMTP:xxxxx@msn.com]
Reply To: Windows System Software Devs Interest List
Sent: Monday, October 09, 2006 9:03 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] New Header Compression ProtocolsAs for how to trick NDISWAN/RAS into doing any of this, you are pretty much on your own. If you are comfortable and confident that your aims can be achieved by a ‘device-in-the-middle’ design whereby your processing can sit in the middle of the PPP packet exchange of a PPP client and PPP server, that is essentially what you can build in an IM driver.
Maybe it won’t help in this case but anyway. Long time ago I played with NdisWan and PPP and found it is possible to write own control protocol (CP) DLL (see HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\PPP\ControlProtocols) which is used during PPP negotiation. Up to w2k it was possible to replace standard CP DLL as ipcp.dll with your own or simply register your own and call the existing one. I made successful experiment with CHAP protocol then but finally we didn’t use this solution for some reason. Currently it seem most of standard CPs are inside one DLL (rasppp.dll) which can make things harder.
The interface is (or was) undocumented but it wasn’t too hard to find it. It is similar to what is documented for the EAP protocol (but not the same).
Please don’t ask me for details, I already forgot them 
Just wanted to show other possible way how to influence PPP negotiation.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
> Basically I would like to build a framework (may be modifying passthru.sys)
to implement a new header compression type.
Very hard, if possible at all. Packets below NDISWAN can be with PPP
compression and encryption, it is too late to add your own header compression
to them.
Packets above NDISWAN must have the cleartext headers, NDISWAN wants so.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> Creating your own NDIS WAN Miniport, telling NDISWAN that you want to
handle
all of the link protocol stuff (in other words, NDISWAN’s PPP implementation
is not used) and writing your own complete PPP implementation is an option
open to you but not a very good one.
Correct. Such a thing will need to respond to all RAS IOCTLs.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> Considering my IM Driver is between NDISWAN and Miniport, if there is a PPP
Header compression done by NDISWAN its ok for me, as its well documented
Such an IM will possibly see the encrypted stream without the key knowledge.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Finally, I give up on this task.
If were to develop one with my current study, I would have an IM between
NDISWAN and Miniport and do the following:
2) Intercept IPCP and change the packet contents to make IPCP negotiate my
Header Compression Protocol
3) Make a note of the options that are negotiated during LCP, like
compression of fields like Protocol ID in PPP header
- Disable Link Compression from connection Options.
That would allow me to pick IP Datagram and hence IP Header from the PPP
packets that NDISWAN gives me. I hope that works, but in terms of bandwidth
effiency its NO solution, given that Iam doing away with link Compression
which is v.efficient.
BTW, why hasn’t Microsoft left an option to ISVs to implement New Header
Compression Protocols? I feel even Vista is going to stick around with Van
Jacobson’s?!
-Giri.
On 10/13/06, Maxim S. Shatskih wrote:
>
> > Considering my IM Driver is between NDISWAN and Miniport, if there is a
> PPP
> > Header compression done by NDISWAN its ok for me, as its well documented
>
> Such an IM will possibly see the encrypted stream without the key
> knowledge.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> BTW, why hasn’t Microsoft left an option to ISVs to implement
New Header Compression Protocols? I feel even Vista is going
to stick around with Van Jacobson’s?!
Maybe because all forms of extensibility come with a significant cost? It’s counterproductive to make every single aspect of every single component extensible.
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of giri
Sent: Friday, October 13, 2006 12:24 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] New Header Compression Protocols
Finally, I give up on this task.
If were to develop one with my current study, I would have an IM between NDISWAN and Miniport and do the following:
2) Intercept IPCP and change the packet contents to make IPCP negotiate my Header Compression Protocol
3) Make a note of the options that are negotiated during LCP, like compression of fields like Protocol ID in PPP header
- Disable Link Compression from connection Options.
That would allow me to pick IP Datagram and hence IP Header from the PPP packets that NDISWAN gives me. I hope that works, but in terms of bandwidth effiency its NO solution, given that Iam doing away with link Compression which is v.efficient.
BTW, why hasn’t Microsoft left an option to ISVs to implement New Header Compression Protocols? I feel even Vista is going to stick around with Van Jacobson’s?!
-Giri.
On 10/13/06, Maxim S. Shatskih wrote:
> Considering my IM Driver is between NDISWAN and Miniport, if there is a PPP
> Header compression done by NDISWAN its ok for me, as its well documented
Such an IM will possibly see the encrypted stream without the key knowledge.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 http:
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
— Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</http:>