netdev - Re: [PATCH net-next-2.6 v4] bonding: allow arp_ip_targets on separate vlans to use arp validation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20091229005145.GB6490@gospo.rdu.redhat.com>
Date:	Mon, 28 Dec 2009 19:51:45 -0500
From:	Andy Gospodarek <andy@...yhouse.net>
To:	Jay Vosburgh <fubar@...ibm.com>
Cc:	David Miller <davem@...emloft.net>, andy@...yhouse.net,
	eric.dumazet@...il.com, netdev@...r.kernel.org
Subject: Re: [PATCH net-next-2.6 v4] bonding: allow arp_ip_targets on
	separate vlans to use arp validation

On Mon, Dec 28, 2009 at 01:55:33PM -0800, Jay Vosburgh wrote:
> David Miller <davem@...emloft.net> wrote:
> 
> >From: Andy Gospodarek <andy@...yhouse.net>
> >Date: Mon, 28 Dec 2009 10:26:32 -0500
> >
> >> This patch should be ready for inclusion.
> >
> >Yes, but I haven't seen ACK's from Jay or Eric.
> 
> 	I was testing with the final patch just before my personal
> holiday adventures began, and was having one problem: the ARP monitor
> part worked fine on the VLAN (the slaves were up) but regular traffic on
> that same VLAN, e.g., ping, was dropped on receive at the bond.  The
> peer (without bonding) saw the traffic, and responded, but it appeared
> that ARP replies from the peer (again, over the VLAN) weren't making it
> to the ARP table (at the bond end), so everything that depended on the
> ARP table wasn't working.
> 
> 	I'm willing to believe this is a personal problem at my end, but
> I haven't determined the cause, and won't have the opportunity until
> next week (after my house has drained of relatives).
> 
> 	If Andy isn't seeing the above misbehavior, I'm fine with
> assuming it's my problem and applying the patch; if I find something
> actually wrong with the patch next week we can address it then.
> 

>From time to time, I would see something similar would be if I was
testing without VLANs and ended up with a stale entry in the remote
hosts ARP table that would cause the response traffic to get sent
without a VLAN tag.

I was able to pass tagged traffic when the bond was up and always made
sure to scp my tested patches over that link to the machine that would
post them.  It seems like good practice to exercise the changes I'm
making during the posting process. :)

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html