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);
