From owner-freebsd-net@FreeBSD.ORG Sat Jun 28 11:35:24 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B12E1065673 for ; Sat, 28 Jun 2008 11:35:24 +0000 (UTC) (envelope-from rehsack@web.de) Received: from fmmailgate03.web.de (fmmailgate03.web.de [217.72.192.234]) by mx1.freebsd.org (Postfix) with ESMTP id B03B98FC1E for ; Sat, 28 Jun 2008 11:35:23 +0000 (UTC) (envelope-from rehsack@web.de) Received: from smtp05.web.de (fmsmtp05.dlan.cinetic.de [172.20.4.166]) by fmmailgate03.web.de (Postfix) with ESMTP id D307BE1A8440 for ; Sat, 28 Jun 2008 13:15:37 +0200 (CEST) Received: from [87.149.225.180] (helo=waldorf.muppets.liwing.de) by smtp05.web.de with esmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.109 #226) id 1KCYP3-00012M-00 for freebsd-net@freebsd.org; Sat, 28 Jun 2008 13:15:37 +0200 Message-ID: <48661D57.3040505@web.de> Date: Sat, 28 Jun 2008 11:15:35 +0000 From: Jens Rehsack User-Agent: Thunderbird 2.0.0.14 (X11/20080608) MIME-Version: 1.0 To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: rehsack@web.de X-Sender: rehsack@web.de X-Provags-ID: V01U2FsdGVkX1+L9o4ev4xm3FDwKybKia1efMggdmnvYEqrFZtc FpEbLNT1GRVw2kN7h1YCRXvw2SvYWOGrtmvEXAhumsZNqnDN7w xIu0s9BEs= Subject: unbreaking igmpproxy X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2008 11:35:24 -0000 Hi all, last week I tried to configure my fbsd-router to enhance it to forward multicast traffic as read on http://un.geeig.net/openbsd-vdsl.html. Sure - it's OpenBSD, but I thought with a little work, I will make it run. But I wont :-( I tried even mrouted(8) but it wont work, because the PPPoE interface to the provider has a netmask of 255.255.255.255 (is it called "host route"?). By the way, I decided to go deeper into igmpproxy: I created a port (using the patches from Markus Friedl from the obsd port), compile, install on router and it delivers: (1) Note: joinMcGroup: 224.0.0.2 on fxp0 (2) Debu: building IGMP packet with datalen=0 (3) Info: sendto to 224.0.0.1 on 10.62.10.12; Errno(22): Invalid argument (4) Debu: SENT Membership query from 10.62.10.12 to 224.0.0.1 Line 2 is added by me, because I want to be sure, that there is no crap in the packet. The code which sends the packet looks like the code in mrouted, where igmpproxy is derived from: sendto(MRouterFD, send_buf, (size_t)sendsize, 0, (struct sockaddr *)&sdst, sizeof(sdst)); send(2) tells, the EINVAL wont be delivered by send or sendto etc. - but there is it. I've searched a bit and seen in sys/kern/uipc_socket.c a routine 'sosend_generic' which seems to handle those sendto calls. This function can return EINVAL when the iovec belonging to the write has negative bytes to handle (sendsize is length of IP header + length of IGMP header) or the mbuf has negative length (I didn't check if the mbuf is source or dest - I mean to remember from VxWorks, that it could be both). But both arguments, mbuf and uio, I cannot influence ... The second 'question' may be the same, maybe not ... The recvfrom() call seems to get scambled network data - but not all of them, just a few ... This is what tcpdump sees: 1. 988526 AF IPv4 (2), length 40: (tos 0xc0, ttl 1, id 40489, offset 0, flags [none], proto IGMP (2), length 36, options (RA)) 217.0.119.167 > 224.0.0.1: igmp query v3 0x0000: 0200 0000 46c0 0024 9e29 0000 0102 5541 ....F..$.)....UA 0x0010: d900 77a7 e000 0001 9404 0000 1164 ec8c ..w..........d.. 0x0020: 0000 0000 020f 0000 ........ And this igmpproxy receives through recvfrom(2): Debu: received 36 bytes on fd 4 Debu: received packet: 46 c0 0c 00 27 6e 00 00 01 02 cb fc d9 00 77 a7 e0 00 00 01 Warn: received packet from 217.0.119.167 shorter (36 bytes) than hdr+data length (24+3048) As you can see, the bytes 3-12 (count begins at 1) contains special refuse. But why only 3-12? Why are the first 2 bytes not scrambled at all? Ok, the IP version and length might be filled separately, but the ToS field is ok. The source and target addresses are ok - but the rest of the IP header? What is going on there? I really have no idea where to search next. The socket open looks ok (compared to the explanation in Stevens 'Network Programming' and 'TCP/IP illustrated' and looks very similar to the code in mrouted). This is all tested with FreeBSD-7.0 stable. I compiled the igmpproxy using standard flags (-O2 -fno-strict-aliasing) and using '-O -g3' - same behaviour. Of course I tried to find related resources using google and the freebsd search - but there was nothing what really affects this problem. Best regards, Jens