On 05/12/10 06:44 PM, Jason King wrote:
On Wed, May 12, 2010 at 7:30 PM, James Carlson<[email protected]> wrote:On 05/12/10 19:57, Garrett D'Amore wrote:On 05/12/10 04:51 PM, Jason King wrote:I don't believe it does -- the best you can do is bind to SAP 0, then push the pfil module configured to pass the desired packets through.There used to be an llc2 module that would help with this... I'm not sure these days though. You should check llc2 to see if it will work with modern drivers.I've used the llc2 module, and the one thing I can say about it is that almost no matter what you want to do, that's not what it does. There's also an llc1 module, but I'm less sure about the state of it. Binding to SAP 0 is the accepted way of getting non-DIX packets on DLPIv2. You then need to check for the LLC/SNAP headers on your received messages. (Historically, there've been applications that have tried to bind the MTU value [!] as a SAP, such as the AppleTalk stack for Solaris. Binding numbers greater than 0 but less than 0x0800 may, and likely also should, result in getting the same thing as binding the magic SAP 0, but I do recall seeing problems with some DLPI providers that didn't understand this glitch.)I thought it was documented as such (SAP< 1500 gets you everything), I had to do that once because the qfe driver in Solaris 10 would panic (i think, it did something nasty) if you tried to bind to sap 0 (no idea if it was ever fixed), and had to use 1 instead.
I think I saw that bug ages ago.In any case it *was* fixed in Nevada... when I converted hme and qfe to GLDv3. :-)
- Garrett
_______________________________________________
networking-discuss mailing list
[email protected]
