You should specify what switch you're talking about. As I remember it, this is a problem with the OpenFlow 1.0 reference implementation's user mode datapath. There have been other switches based on this code, though. If you're using one of them, you should specify which -- it may have been fixed in them, and/or different people may be interested in fixing it.
If you are indeed talking about the 1.0 reference in user mode... this isn't widely used anymore, and I don't think anyone ever fixed it. I think I figured out what the problem was, but I never actually submitted a patch since even when the bug came to my attention, I had long since moved to Open vSwitch. Normally, when the switch allocates a buffer, it allocates some extra headroom so that it can, e.g., add a VLAN tag. But when sending a packet_in, the switch stores a clone of that buffer, and the clone is exactly large enough for the current data -- no headroom. So if the controller sends back a flow_mod or packet_out which refers to the buffer by ID, there isn't enough room in the clone to actually add a VLAN tag. I think there's a similar bug for packet_outs where you send the raw data (instead of a buffer ID). In both cases, it's just a matter of allocating a few extra bytes. -- Murphy On Jul 6, 2014, at 11:28 PM, scbz...@gmail.com wrote: > Is the problem > ofdatapath: lib/ofpbuf.c:168: ofpbuf_prealloc_headroom: Assertion `size > <= ofpbuf_headroom(b)' failed. > solved? > > Best Regards > 杨海祥 > > scbz...@gmail.com > _______________________________________________ > openflow-discuss mailing list > openflow-discuss@lists.stanford.edu > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
_______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
