Ping. I haven't heard from Petr yet. Does anyone else want to review/test/ok this?
On Fri, Jan 10, 2014 at 01:20:41PM +0100, Stefan Sperling wrote: > On Sun, Jan 05, 2014 at 11:35:51AM +0100, Petr Hoffmann wrote: > > >Synopsis: missing packets when not in promiscuous mode > > >Category: kernel > > >Environment: > > System : OpenBSD 5.4 > > Details : OpenBSD 5.4-stable (GENERIC.MP) #0: Thu Jan 2 > > 07:25:09 CET 2014 > > p...@lambda.my.domain > > :/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > Architecture: OpenBSD.amd64 > > Machine : amd64 > > >Description: > > I have a fresh OpenBSD 5.4 machine that is connected to a network > > by a USB->Ethernet MCS7830-based adapter handled by the 'mos' driver. > > While I'm able to establish connections originating on that machine > > with no problem, it is not possible to connect in the other direction, > > I even do not see the packets using tcpdump with the -p option (but > > I saw a packet from the client coming to 224.0.0.252 (a multicast > > address used by the link-local multicast name resolution protocol). > > I updated my machine to the -patch version but the problem persists. > > Both the client and the server machine are on the same IPv4 network, > > connected directly to the same router. > > > > I figured out that this problem disappears if I start 'tcpdump -i mos0' > > (mos0 being the interface corresponding to my adapter) but not if I > > start tcpdump with the -p option (i.e. in the non-promiscuous mode). > > Unfortunatelly, shortly after exiting the tcpdump, it is not possible > > to connect anymore (unless I start tcpdump again). > > > > Another workaround is to first establish a connection from my machine > > to, let's say, a machine X, then it is possible to connect from X to > > my machine (at least if X is a linux machine). > > > > I conjecture the problem is in that my adapter does not pass ARP > > who-is requests made by clients and thus they have no IP->MAC mapping. > > Actually, I see such requests when in the promiscuous mode but no such > > requests otherwise. BUT, surprisingly, even in the non-promiscuous > > mode, I see ARP who-is requests from my router! > > > > At first I thought my router is blocking ARP who-is requests from > > clients, but if I try to connect to some non-existing IP address, > > the ARP who-is request arrives to my machine so that's probably not > > the case. > > > > This problems seems slightly similar to the one below, maybe it will > > help. I'm new to the OpenBSD world, sorry, I don't know how to > > refer to that bug correctly: > > > > http://marc.info/?l=openbsd-bugs&m=117897452708054&w=2 > > > > >How-To-Repeat: > > Install a fresh OpenBSD 5.4 machine, configure the only network > > interface mos0 to use dhcp, and try to connect to that machine > > e.g. by ssh. > > >Fix: > > I know two work arounds: > > a) tcpdump -i mos0 > > b) connect from the machine to the client trying to establish > > the connection at first > > I can reproduce this problem with an MCS7830 mos adapter. > The patch below seems to fix it. Can you confirm? > > Index: if_mos.c > =================================================================== > RCS file: /cvs/src/sys/dev/usb/if_mos.c,v > retrieving revision 1.22 > diff -u -p -r1.22 if_mos.c > --- if_mos.c 15 Nov 2013 10:17:39 -0000 1.22 > +++ if_mos.c 10 Jan 2014 11:54:38 -0000 > @@ -558,6 +558,13 @@ mos_iff(struct mos_softc *sc) > > ETHER_NEXT_MULTI(step, enm); > } > + /* > + * The datasheet claims broadcast frames were always accepted > + * regardless of filter settings. But the hardware seems to > + * filter broadcast frames, so pass them explicitly. > + */ > + h = ether_crc32_be(etherbroadcastaddr, ETHER_ADDR_LEN) >> 26; > + hashtbl[h / 8] |= 1 << (h % 8); > } > > mos_write_mcast(sc, (void *)&hashtbl);
