Closed tnelson closed 10 years ago
actually, what I've pasted below works, but I agree there is probably something broken in forward
handling :-/
ON udp_packet_in(pkt) WHERE pkt.dlDst = 0x01005e0000fb and
pkt.nwDst = 0xE00000FB and // 224.0.0.251 (mDNS group)
pkt.tpDst = 5353: // (mDns port)
DO forward(new) WHERE
atv_cxns(pkt.dlSrc, new.dlDst) and
new.locPt != pkt.locPt; // flooding for now ... should be forwarding directly
The error will only occur if you try to name a field of 'new' that isn't in eth_packet_fields. Since you're only mutating dlDst and locPt in that code, forward is happy to treat only the ethernet parts of the packet. Once the forward operation happens, of course, the packet itself is still UDP.
forward
is special because its type is always the same as its trigger packet. But that just means that we can use the same type that triggers the clause. (Will need to add this to the checker and treat the definition of forward as having a special type when assigning fields.)
yes, that makes sense.
This should be fixed as of 61ed9947d2dd541d32b51513233ca4ae623204d8.
Use examples/Mac_Learning_For_Notables.flg to test, with -notables enabled.
Right now, it's ethernet packets. This means that if one writes
on ip_packet_in(p): do forward(new) where new.nwSrc = ...
An error will be thrown---after all, ethernet packets have no nwSrc field!
We dealt with this in emit by having separate emit relations for every packet type. That'd be more ugly here: the semantics we want is "keep the packet type the same".
Are we looking at an inference story, then?