Re: missing packets when not in promiscuous mode
Hi, I confirm that the patch fixed the problem and the machine works as expected. Many thanks, Petr On Fri, Jan 10, 2014 at 1:20 PM, Stefan Sperling s...@openbsd.org 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-bugsm=117897452708054w=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.c15 Nov 2013 10:17:39 - 1.22 +++ if_mos.c10 Jan 2014 11:54:38 - @@ -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); -- +420 605 033 801 (vodafone) It's your way!
Re: missing packets when not in promiscuous mode
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-bugsm=117897452708054w=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 - 1.22 +++ if_mos.c 10 Jan 2014 11:54:38 - @@ -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);
Re: missing packets when not in promiscuous mode
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-bugsm=117897452708054w=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.c15 Nov 2013 10:17:39 - 1.22 +++ if_mos.c10 Jan 2014 11:54:38 - @@ -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);
