Garrett D'Amore wrote: > On transmit, the best thing to do is pad with zeros. (This is > important to prevent a security leak where "short" packets can > unintentionally contain data from another packet, possibly sent to a > different host.)
Good point - I'll update. I'm still trying to narrow down the cause for frame corruption on transmit. Compared with similar drivers on Linux, *BSD, and even Masa's ni driver I am not doing anything differently. > On receive, you should never need to strip. If the packet is less than > the minimum size, you should probably just drop it on the floor, if the > hardware doesn't already do that for you. Unfortunately the RTL8029 doesn't do much in terms of hardware, however I do have a check in place which increments the runt_errors kstat and drops the packet. There is no logic in place to deal with padded packets. > On another note, mgmt has asked me about your DNET gldv3 work -- can you > provide a status update on it? Certainly. The GLDv3 conversion has been complete for quite some time now - I have not encountered any regressions in nicdrv testing so far. Jason King had a friend interested in the conversion and has been testing the changes (64-bit variety) for the last few months with no issues as well. To be honest, I had been holding off on submitting until I could make a couple more passes with nicdrv to present a comprehensive set of test results, however life, and re have interfered somewhat. I will finalize all changes and make a last run of nicdrv testing by next week to get ready for an RTI. Steve _______________________________________________ driver-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/driver-discuss
