Thanks Ethan and Alex (and Ronny). I applied this to master and
backported it to branch-2.3, branch-2.1, and branch-2.0.
On Thu, Feb 12, 2015 at 12:33:10PM -0800, Ethan Jackson wrote:
> Solution seems clean, I'm happy with this as well.
>
> Acked-by: Ethan Jackson
>
>
> On Thu, Feb 12, 2015 a
Thx a lot for the explanation, it is clear now!
On Fri, Feb 13, 2015 at 8:44 AM, Ben Pfaff wrote:
> On Thu, Feb 12, 2015 at 11:02:06AM -0800, Alex Wang wrote:
> > > +struct mac_learning_port *mlport;
> >
> >
> > Simple C question, why don't we need to forward declare the struct
> > 'mac_lear
On Thu, Feb 12, 2015 at 11:02:06AM -0800, Alex Wang wrote:
> > +struct mac_learning_port *mlport;
>
>
> Simple C question, why don't we need to forward declare the struct
> 'mac_learning_port'?
Forward declarations are only necessary in one weird C corner case: when
the first use of the stru
Solution seems clean, I'm happy with this as well.
Acked-by: Ethan Jackson
On Thu, Feb 12, 2015 at 11:02 AM, Alex Wang wrote:
> Looks good to me,
>
> /* A MAC learning table entry.
>> - * Guarded by owning 'mac_learning''s rwlock */
>> + * Guarded by owning 'mac_learning''s rwlock. */
>> str
Looks good to me,
/* A MAC learning table entry.
> - * Guarded by owning 'mac_learning''s rwlock */
> + * Guarded by owning 'mac_learning''s rwlock. */
> struct mac_entry {
> struct hmap_node hmap_node; /* Node in a mac_learning hmap. */
> time_t expires; /* Expiration time
In "MAC flooding", an attacker transmits an overwhelming number of frames
with unique Ethernet source address on a switch port. The goal is to
force the switch to evict all useful MAC learning table entries, so that
its behavior degenerates to that of a hub, flooding all traffic. In turn,
that al
