Hi Gleb, Thanks for your patch, i applied it and its production already. i had to stop mpd, and once started it i saw that all home routers connected immediatly. most of them don't use mppc, so I wonder why this problem happend in the first place. whats surprising i had few hours ago the same problem: Dec 27 14:11:29 mpd2 kernel: ng_mppc_decompress: too many (4092) packets dropped, disabling node 0xffffff000ba12700! Dec 27 14:11:29 mpd2 kernel: Dec 27 19:19:10 mpd2 kernel: ng_mppc_decompress: too many (4092) packets dropped, disabling node 0xffffff0006307400! Dec 27 19:19:10 mpd2 kernel:
i hope the patch will solve the problem for good now, i'll let it work for the coming few days andif something will go wrong i'll paste you. Sami 2011/12/27 Gleb Smirnoff <gleb...@freebsd.org> > On Tue, Dec 27, 2011 at 09:44:23AM +0200, Sami Halabi wrote: > S> >1) Is the number always 4094? > S> > S> No, i see 4092, 4093 also: > S> Dec 24 09:17:04 mpd2 kernel: ng_mppc_decompress: too many (4092) packets > S> dropped > S> , disabling node 0xffffff003051e400! > S> Dec 24 09:17:04 mpd2 kernel: > S> Dec 24 14:22:45 mpd2 kernel: ng_mppc_decompress: too many (4093) packets > S> dropped > S> , disabling node 0xffffff003d53db00! > S> Dec 24 14:22:45 mpd2 kernel: > S> Dec 24 19:28:45 mpd2 kernel: ng_mppc_decompress: too many (4092) packets > S> dropped > S> , disabling node 0xffffff00304e8500! > > Well, here is my histrogram of probability: > > 38 4094 > 5 4093 > 3 4095 > 1 4092 > 1 4091 > 1 4087 > 1 4083 > 1 3275 > 1 2173 > 1 2172 > 1 2171 > 1 2170 > 1 2169 > 1 2137 > 1 2135 > 1 2132 > 1 2122 > 1 2121 > 1 2120 > 1 1130 > 1 1013 > > I believe that problem is caused by re-ordering of packets that may happen > on the Internet. We definitely didn't lose 4094 packets so often. > > Shift of 4095 means that we received a packet that should be the previous > one. Shift of 4094 means that we received a packet, that should have been > two packets ago. I have no idea why this condition is much more probable :( > > Today I thought of some patch that would detect and fix reordering, but > failed to find any elegant way on fixing this MPPE poor design. > > So, I have decided to remove the protection at all. The decision is based > on > the following facts: > > 1) Our current limit of 1000 isn't by an order of magnitude greater than > maximum possible rekeying number - 4095. So, the DoS protection is quite > not really a noticable one. > 2) Since ng_mppc was developed CPUs got faster by more than an order of > magnitude. > 3) Linux implementations do as much rekeying as needed. > 4) It looks like Windows does too. Not very clear from the article, but > out of ordering is mentioned here: > > http://technet.microsoft.com/en-us/library/cc958061.aspx > > I suggest the attached patch. Can you please test it for a period > of time and report how it goes? > > I am going to try it, too. > > -- > Totus tuus, Glebius. > -- Sami Halabi Information Systems Engineer NMS Projects Expert _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
