Date: Sat, 28 Jun 2008 11:15:35 +0000 From: Jens Rehsack <rehsack@web.de> To: FreeBSD Net <freebsd-net@freebsd.org> Subject: unbreaking igmpproxy Message-ID: <48661D57.3040505@web.de>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48661D57.3040505>