> Also, before blaming netgraph, which may well be to blame, could it be > that you have interference from some other source that's making things > bad? The exactly every other packet being dropped does seem to be a > big clue.
I have ruled out interference as a contributor to these results. My next step was to remove netgraph from the equation - I simply set up the two channel/SSID pairs across the two laptops, and assigned one pair addresses 10.10.10.10 and 10.10.10.20 with a /24 netmask and the other pair 192.168.0.129 and 192.168.0.130 with a /25 netmask. Each pair could ping between themselves with 0% packet loss. Therefore, it seems that there are no real technical difficulties in running two pair 802.11b networks between two laptops, using two adaptors in each machine. So, I switched the master/slave order for the cards participating in the multi-link on each laptop. That is, I made wi1 the master and wi0 the slave on one side, and an1 the master and an0 the slave on the other. This was illuminating, as this configuration did not allow any functionality - not even the 50% packet loss. Instead, on the system with two Lucent cards, I got the familiar watchdog timeout errors: /kernel: wi1: wi_write_data device timeout /kernel: wi1: xmit failed /kernel: wi1: watchdog timeout ... /kernel: wi1: failed to allocate 1594 bytes on NIC /kernel: wi1: tx buffer allocation failed Basically the same old watchdog errors that I see quite frequently on Lucent cards. So, the point made earlier in this thread that the behavior I produced looked like the behavior of a ng_one2many setup with 50% of the link not working seems to be correct. However, because the first test I mentioned above (two wireless nets operating simultaneously across two systems without netgraph) succeeded, I am not simply dealing with a bad card or a down link. Instead, I think this may be a firmware issue. Specifically, different revisions of the Lucent firmware behave differently as regards promiscuous mode, etc. Because the card works in all other tests, and because the other Lucent card can successfully master the netgraph ng_one2many, I am tentatively concluding that some Lucent firmwares will not work in a ng_one2many setting. OR maybe it is just general `wi` flakiness - this suspect card produces wi_seek timeouts when given an IBSS to create (`wicontrol -q`) on Toshiba Libretto laptops, but not on other laptops (even other Toshibas). Therefore, it is possible that there is no ng_one2many / firmware problem, but rather, since Lucent cards (seem to) malfunction based on somewhat random and arbitrary conditions, perhaps this is just one more of those random and arbitrary conditions. Comments ? In the meantime I will retry this experiment with Cisco cards exclusively. ----- John Kozubik - [EMAIL PROTECTED] - http://www.kozubik.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
