Some (un-named) wireless controllers will send back EAP packets. Some samples taken from eduroam are:

        AVP: t=EAP-Message(79) l=31 Last Segment[1]
            Type: 79
            Length: 31
            [Length: 29]
            EAP fragment: 6c6f63616c00095f7365727669636573075f646e732d7364045f756470		"local._services._dnsd._udp" in DNS label format
...
        AVP: t=EAP-Message(79) l=31 Last Segment[1]
            Type: 79
            Length: 31
            [Length: 29]
            EAP fragment: 436f6c6f72204c617365724a6574204d4650204d323737647720402053		"Color LaserJet MFP M277dw ..."
...
        AVP: t=EAP-Message(79) l=31 Last Segment[1]
            Type: 79
            Length: 31
            [Length: 29]
            EAP fragment: 0000000000000000000000000000000000000000000000000000000000		!!!! all zeroes !!!!

We've put patches into FreeRADIUS to check for RADIUS packets which contain EAP-Message. If the EAP packet is malformed (and it's easy to tell), we just return an Access-Reject.

https://github.com/FreeRADIUS/freeradius-server/blob/v3.2.x/src/modules/rlm_eap/rlm_eap.c#L563

One reason to do this at the proxy is that many educational institutions use NPS. And if NPS receives these packets, it will simply discard the entire packet. Which makes the proxy think that the home server is down. So it's better for the proxy to reject the packets.

This should probably be hidden behind a configuration option, because it is a behavior change. But I can't think of anything that would go wrong if the proxy sent Access-Reject for these packets. It's impossible for the home server to authenticate this user, so reject is the best choice.