MTU size and 802.1x authentication

Discussion in 'Windows Vista Drivers' started by Shailendra, Oct 15, 2008.

  1. Shailendra

    Shailendra Guest

    Hi,

    I have a mp driver which is modifying the MTU by trapping and tweaking
    queries to OID_GEN_MAXIMUM_FRAME_SIZE (to 1400 from 1500) and
    OID_GEN_MAXIMUM_TOTAL_SIZE (to 1414 from 1514) OIDs.

    The issue is when I try to perform 802.1x authentication on a wired NIC
    using zero config and smartcard (EAP-TLS) it stops midway through the
    handshake and does not complete. Packet sniffing indicates that the server
    sends all its relevant information and is waiting for the client (the machine
    running my driver) to send its information, including it's certificate. This
    never happens. I don't see any response packets going through my driver
    either.

    If I do not tweak the MTU size or if my driver is not bound the 802.1x
    authentication handshake completes successfully and I can pass traffic. I can
    see the whole TLS handshake by sniffing packets.

    What am I missing here? Does changing the MTU have no affect on zero config
    or is it not handling the changed MTU properly? Restarting the zero config
    service does not change this behavior either. Do I have to trap some more
    OIDs and change them? Has anyone see this kind of a problem? Any help is
    greatly appreciated.

    Thanks,
    Shailendra
     
    Shailendra, Oct 15, 2008
    #1
    1. Advertisements

  2. Shailendra

    Luv2Hike Guest

    I ran into the same problem. By shrinking the MTU, you cause a problem with
    the 802.1x supplicant on XP which may send out an EAPOL packet > 1400 bytes.
    What happens is the NDISUIO stack will not forward the EAPOL packet to the
    underlying miniport if the MTU < packet length.

    Since we supported an 802.11 CAPWAP interface, we simply advertised an MTU
    of 1500 and then fragmented any packets with a length > our supported MTU.
     
    Luv2Hike, Oct 16, 2008
    #2
    1. Advertisements

  3. Shailendra

    Shailendra Guest

    This sounds like a bug with NDISUIO. On the one hand it seems to check what
    the MTU is and on the other it does not honor it.

    The EAP-TLS protocol has fragmentation login built into it. Is there a
    registry setting which can be changed to manage that fragmentation size?
    Hopefully this will cause zero config to transmit smaller packets which would
    be below the MTU size. Alternatively, is there a registry setting which will
    force NDISUIO to break down these large frames so they are smaller than the
    advertised MTU and pass them along?

    Thanks,
    Shailendra
     
    Shailendra, Oct 16, 2008
    #3
  4. Shailendra

    Luv2Hike Guest

    This sounds like a bug with NDISUIO. On the one hand it seems to check
    I believe it is doing both. Your MP is advertising an MTU of 1400, and
    NDISUIO is rejecting any tx packets that exceed that MTU.
    AFAIK, NDISUIO is agnostic of the EAPOL packet payloads, and I don't know of
    a registry setting that will help here. What you really need to look at is
    the 802.1x supplicant and see if that can support fragmenting, although I
    don't belive there's a way you can do this.
     
    Luv2Hike, Oct 16, 2008
    #4
  5. Shailendra

    Shailendra Guest

    What you say does make sense. But I would expect the protocol driver (not
    NDISUIO) to handle fragmenting the packets by looking at the MTU, just like
    TCP. I am using the Windows Zero Config as my 802.1x supplicant. Looks like I
    may be at a dead-end. I was hoping that there would be a registry key that
    controls the fragment size for EAP-TLS which is used by Zero Config. I was
    trying to avoid fragmentation login in my MP and let the protocol driver
    handle it.

    Anyway, thanks for your help. If you do come across something that would
    help please forward it to me?

    Thanks,
    Shailendra
     
    Shailendra, Oct 16, 2008
    #5
  6. Shailendra

    Luv2Hike Guest

    Sure, but please note that NDISUIO IS the protocol driver in this case. I
    believe the XP 802.1x supplicant issues read/write IRPs to this stack, which
    are not handled well if the write payloads > the underlying MP MTU.
     
    Luv2Hike, Oct 17, 2008
    #6
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.