svn bisect across forks to find fix for openwrt dropped ARPs

The IRC channels are asleep, so it's time for Plan Omega - ask LUV. 2,123 is a lot of commits to just eyeball, and I'm not sure how to deal with the fact that e.g. r33965 isn't in the a_a branch. Any insights from a fresh perspective ? To #openwrt: | Anybody ever run across ARP not propagating to wifi devices across a | wired/wifi bridge? | | I see it in 10.03.01rc4, but not in 12.09.01. The problem is, | $customer is using some hobbyist board that doesn't use stock openwrt, | so I want to track down the fix so they can apply it to their fork. To #svn: | OK, so I'm in the... exciting position of trying to do a bisect across | three repos - a fork of a fork - and I don't have the equipment to | actually perform tests myself, and I'm a git weenie who doesn't know | svn very well. | | I'm trying to work out a reasonable strategy to find the commit that | fixed the bug, so I can tell the devs, and they can either merge that | entire tree in, or cherry-pick that specific commit. Symptoms present on Gateworks GW2347 as at r11689 (in-house svn repo) Symptoms present on TP-Link 1043ND as at 10.03.1-rc4, r24045 (svn://svn.openwrt.org/openwrt/backfire) Symptoms absent on TP-Link 1043ND as at 12.09.01, r36088 (svn://svn.openwrt.org/openwrt/attitude_adjustment) Allegedly in-house repo is based off http://svn.gateworks.com/generic/trunk r402. Allegedly gateworks repo is based off svn://svn.openwrt.org/openwrt/trunk r33965. I *think* in both cases, the fork simply committed upstream-as-at-N as a monolithic commit, rather than importing all the commits or using externals or whatever. Symptoms: - as a wired or wifi device, attempt to ping a wifi device. ARP fails. tcpdump on AP indicates in some cases ARP never hits the AP, in other cases it does but no reply is seen. - wifi devices associated with different APs can ARP each other. - wifi device can ARP a wired device. * * * I suppose the other things to do, while I wait for you lot, is to look through the openwrt BTS for likely-looking closed tickets, and to find the appropriate MLs on gmane to punt the question to.
participants (1)
-
trentbuck@gmail.com