On Fri, Sep 18, 2020 at 8:52 PM Michael Siedzik <msiedzik@xxxxxxxxxxxxxxxxxxx> wrote: > A couple of months ago Mickael Chazaux posted a thread on this very topic: > So it looks like the existing code is incorrectly handling key server elections with more than two peers, and GroupCAs in general. Mickael was on the right track with his attempted patches, but additional work and testing of 3-peer networks is required. Part of his solution was to remove parameter block failures in certain circumstances. This matches with what I observed. It seems GroupCAs were never fully implemented in wpa_supplicant. > The problem is certainly fixable but it will take an in-depth knowledge of IEEE802.X-2010 and a some knowledge of C. Yes, it seems the basic principles are in place. However, I'm not a very good C programmer. I've been doing mostly Java for the past 20 years. Also, I'm not that much at home in network infrastructure terminology, which makes the IEEE802.X-2010 spec very hard to read. This makes it very hard for me to try to fix these issues. We also ran into another problem with the 2-peer network: when wpa_supplicant is restarted, it causes the entire routing table for both the macsec *and* the underlying ethernet link to be dropped. This was on CentOS 7, with a rather old version of wpa_supplicant, so the behavior may be different with newer versions. This additional problem did however cause us to decide to abandon the macsec route. We are now going to set up a wireguard network between the peers. I did like the macsec/wpa_supplicant solution because of simplicity and elegance, but the issues we had were too difficult for us to fix and we have a limited timeframe to get this all working. Thanks for the help and insight anyway! Best regards, Emond Papegaaij _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
