what is MAC wildcard matching for?

[joshreich]

Is this code needed? If so, it needs fixing.

[monsanto]

I'll use this bug to address your comments in netcore.py:

### JREICH - disabled incorrect registration calls
### Wildcard takes a binary encoding, but srcmac/dstmac fields are ':' delimited hex strings
#register_header("srcmac", Wildcard(48))
#register_header("dstmac", Wildcard(48))

That's not true. srcmac/dstmac (should) be MAC objects, not strings (they may, however, print in the console as strings). They have a method that returns a bitarray, which (should) be used to match on the wildcard with. So, the registerheader calls are fine as-is. The reason we have IPWildcard is because there are IP specific ways of representing wildcards, like "192.168.0.0/16" or "192.168.._" However, if there is something funny going on I will take a look at it tomorrow.

[joshreich]

Completely true - that's an old comment from when hadn't figured out the real reason why the bug was popping up and I should have cut out.

Anyway the actual problem (I think) is that either there's missing logic in Wildcard or something wrong w/ the parameters. Also, we might want a MACWildcard class or an extension to the Wildcard class to enable use of string encoding of masks (forcing the programmer to use a bitarray seems unnecessary and overly different from how they will handle IP matching)

In terms of the underlying problem, here's the first thing that happens when you enable registration for src/dstmacs.

If this is a quick fix, I'd say go for it. If not, I'd suggest not bothering as we don't need to do MAC wildcard matching at the moment.

-Josh

Traceback (most recent call last): File "/usr/lib/python2.7/threading.py", line 552, in *bootstrap_inner self.run() File "/usr/lib/python2.7/threading.py", line 505, in run self.__target(_self.__args, _self.__kwargs) File "pyretic/examples/learning_switch.py", line 45, in learning_switch_logic for pkt in query_unique(network, all_packets, fields=['switch', 'srcmac']): File "/home/mininet/pyretic/frenetic/network.py", line 576, in gen while True: yield self.filter_queue() File "/home/mininet/pyretic/frenetic/network.py", line 559, in filter_queue pred = match([(field,pkt[field]) for field in self.fields]) File "/home/mininet/pyretic/frenetic/netcore.py", line 352, in __init init_map[k] = matchable_for_header(k)(v) File "/home/mininet/pyretic/frenetic/netcore.py", line 134, in new* mask = bitarray([False] \ len(prefix)) TypeError: object of type 'MAC' has no len()

On Jan 11, 2013, at 3:24 AM, Christopher Monsanto notifications@github.com wrote:

I'll use this bug to address your comments in netcore.py:

JREICH - disabled incorrect registration calls

Wildcard takes a binary encoding, but srcmac/dstmac fields are ':' delimited hex strings

register_header("srcmac", Wildcard(48))

register_header("dstmac", Wildcard(48))

That's not true. srcmac/dstmac (should) be MAC objects, not strings (they may, however, print in the console as strings). They have a method that returns a bitarray, which (should) be used to match on the wildcard with. So, the registerheader calls are fine as-is. The reason we have IPWildcard is because there are IP specific ways of representing wildcards, like "192.168.0.0/16" or "192.168.._" However, if there is something funny going on I will take a look at it tomorrow.

— Reply to this email directly or view it on GitHub.