MTU size and 802.1x authentication

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

 

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.

 

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

 

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.

 

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

 

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.