There seems to be a fundamental flaw in the assumption of how BPDUs can be
handled in packet/bpdu.py (or I'm completely misunderstanding something,
which is also possible) in the implementation of bpdu.parser:
@classmethod
def parser(cls, buf):
assert len(buf) >= cls._PACK_LEN
(protocol_id, version_id,
bpdu_type) = struct.unpack_from(cls._PACK_STR, buf)
assert protocol_id == PROTOCOL_IDENTIFIER
bpdu_cls = cls._BPDU_TYPES.get(bpdu_type, None)
if bpdu_cls:
assert version_id == bpdu_cls.VERSION_ID
assert len(buf[cls._PACK_LEN:]) >= bpdu_cls.PACK_LEN
return bpdu_cls.parser(buf[cls._PACK_LEN:])
else:
# Unknown bdpu type.
return buf, None, None
BPDU classes are looked up by type, but without paying any attention to
what version the BPDU is - the same type can appear in multiple versions
and there appears to be no way to handle this in the current architecture.
For example, I have a (very common) situation where type 2 BPDUs are sent
for version 3 (MSTP). The current implementation of Ryu already has a type
2 BPDU, but it requires the version to be 2 (bpdu.RstBPDUs) and the
assertion causes the application to crash (which is also bad).
Even if I add a type 2 / version 3 BPDU handler, it'll conflict with the
existing registration for a type 2 BPDU in version 2. It seems that the
registration (and lookup) mechanism needs to operate on a tuple of
(version, type) instead of just using type - or am I missing something here?
--
Nick
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Ryu-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ryu-devel
