Latest working kernel version: 2.6.28 Earliest failing kernel version: 2.6.29-rc1 Distribution: Hardware Environment: Software Environment: Problem Description: Not sure if it is a bug: Got these in my dmesg output: CCMP: replay detected: STA=00:0e:2e:fe:88:50 previous PN 0000004072f4 received PN 0000004072f2 CCMP: replay detected: STA=00:0e:2e:fe:88:50 previous PN 0000004072f4 received PN 0000004072f3 CCMP: replay detected: STA=00:0e:2e:fe:88:50 previous PN 000000407759 received PN 00000040774f CCMP: replay detected: STA=00:0e:2e:fe:88:50 previous PN 000000407759 received PN 000000407750 CCMP: replay detected: STA=00:0e:2e:fe:88:50 previous PN 000000407759 received PN 000000407751 CCMP: replay detected: STA=00:0e:2e:fe:88:50 previous PN 000000407759 received PN 000000407752 CCMP: replay detected: STA=00:0e:2e:fe:88:50 previous PN 000000407759 received PN 000000407753 CCMP: replay detected: STA=00:0e:2e:fe:88:50 previous PN 000000407759 received PN 000000407754 CCMP: replay detected: STA=00:0e:2e:fe:88:50 previous PN 000000407759 received PN 000000407755 CCMP: replay detected: STA=00:0e:2e:fe:88:50 previous PN 000000407759 received PN 000000407756 CCMP: replay detected: STA=00:0e:2e:fe:88:50 previous PN 000000407759 received PN 000000407757 CCMP: replay detected: STA=00:0e:2e:fe:88:50 previous PN 000000407759 received PN 000000407758 CCMP: replay detected: STA=00:0e:2e:fe:88:50 previous PN 0000004077e2 received PN 0000004077de CCMP: replay detected: STA=00:0e:2e:fe:88:50 previous PN 0000004077e2 received PN 0000004077df CCMP: replay detected: STA=00:0e:2e:fe:88:50 previous PN 0000004077e2 received PN 0000004077e0 Steps to reproduce: most of the time i did not see this since 2.6.29-rc1 was out.....first time.....
Any reason not to believe someone is trying to break your wireless security? How often do you see these messages?
Trying to break CCMP would be quite stupid, but I don't remember any changes in this area so I doubt it's a bug on our side.
Oh, and next time, state which driver you're using! Clearly nothing of interest (i.e. either ipw* or hostap, which are both effectively unmaintained)
looks like lib80211_ccmp_decrypt doesn't support qos, WONTFIX, I guess, should disable QoS in ipw* then, maybe?
not sure what info is needed: lsmod |grep ipw ipw2200 131916 0 libipw 27268 1 ipw2200 lib80211 9348 3 lib80211_crypt_ccmp,ipw2200,libipw CONFIG_IPW2200_QOS=y CONFIG_BRIDGE_EBT_802_3=m CONFIG_VLAN_8021Q=m CONFIG_CFG80211=m CONFIG_NL80211=y CONFIG_LIB80211=m CONFIG_LIB80211_CRYPT_WEP=m CONFIG_LIB80211_CRYPT_CCMP=m CONFIG_LIB80211_CRYPT_TKIP=m CONFIG_MAC80211=m CONFIG_MAC80211_RC_MINSTREL=y CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y CONFIG_MAC80211_RC_DEFAULT="minstrel" CONFIG_MAC80211_LEDS=y CONFIG_MAC80211_DEBUG_MENU=y CONFIG_MAC80211_NOINLINE=y CONFIG_MAC80211_VERBOSE_DEBUG=y CONFIG_WLAN_PRE80211=y CONFIG_WLAN_80211=y if u suspect someone is trying to breakk my wireless security.....can u suspect a method to test this suspicion? i mean, when tcpdumping the traffic - how do you filter off those specific packets that which will ultimately end up generating the CCMP messages? Thanks you for your help.
OK, some code got moved and that message went from being turned-off to turned-on. I wouldn't worry about it for now. I'll see if I can make it disappear for you...
I marked this as a post-2.6.28 regression so Rafael gets to bug you ;)
Thank you Andrew, and everyone else. I don't have access to the same hardware anymore, which did gave a consistent behavior over many attempts over a few reboots. Now the same version of OS is not able to replicate the same behavior anymore, as I don't have access to that particular wireless router anymore. So sorry, this can be close.