IPv6 fragmentation

[Jouni Malinen]

On Thu, Mar 03, 2011 at 08:33:51PM -0000, Panagiotis Georgopoulos wrote:
>                 Now, when my wireless client initiates an EAP-TLS based
> network request (using wpa_supplicant) the 4 initial exchanges of Access
> Request and Access Accept packets happen just fine (8 packets in total).
> Then, the next Access Request (which seems to be containing a certificate)
> arrives at PC_B correctly but PC_B does NOT forwarding it to the AAA_Server,
> and replies to the hostapd_PC_A with an ICMPv6 error of "too big" to PC_A.

Would you be able to capture the IP packets exchanged between hostapd
and the RADIUS server (ideally at a place that sees both the long packet
and the ICMPv6 error message) with tcpdump or Wireshark? I would like to
see a capture file showing this behavior since I have not tested RADIUS
packet fragmentation with IPv6.

> This seems to me a fragmentation problem and occurs because hostapd_PC_A
> does not split the packet appropriately. I've seen the fragm_thershold on
> hostapd's configuration file and set it to 1300 but it seems that it has no
> effect. 

fragm_threshold does not have anything to do with the size of the IP
packets. You could try reducing fragment_size parameter to try to reduce
the length of EAP fragments and as such, length of the RADIUS packets.

> Does it work on IPv6 Packets? Does it work only for the Access point side or
> also to the packets that the NAS is forwarding to the AAA_Server?

fragment_size may help, but it would be better to figure out why this
issues shows up in the first place. This sounds similar to an issue with
IPv4 where use of Path MTU discovery ended up getting long RADIUS
messages lost. This is no disabled on the socket (IP_MTU_DISCOVER set to
IP_PMTUDISC_DONT), but that may only affect IPv4. If there is a similar
option for IPv6, that could be added in
radius_client_disable_pmtu_discovery().

-- 
Jouni Malinen                                            PGP id EFC895FA