From owner-freebsd-net@FreeBSD.ORG Fri Nov 29 17:28:16 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C26D1FD9 for ; Fri, 29 Nov 2013 17:28:16 +0000 (UTC) Received: from mail.euro-comm.net (mail.euro-comm.net [194.190.78.14]) by mx1.freebsd.org (Postfix) with ESMTP id 7B3621318 for ; Fri, 29 Nov 2013 17:28:16 +0000 (UTC) Received: from [192.168.0.4] (unknown [195.91.216.248]) by mail.euro-comm.net (Postfix) with ESMTPSA id 87A8E6BD5E3 for ; Fri, 29 Nov 2013 21:28:08 +0400 (MSK) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) Subject: Re: Netgraph ng_patch and ng_input: where to find packets? From: Victor Gamov In-Reply-To: Date: Fri, 29 Nov 2013 21:27:59 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5293E3E7.6090604@freebsd.org> To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 17:28:16 -0000 ipfw allow log udp from 192.168.230.9 to 192.168.230.128 dst-port 1234 this rule added to ipfw before ngtee action and I see patched packets at = ipfw now -- its marked as received via vlan999 still. Yes, it's OK. Also, I make 3 actions at ng_patch now: set TTL=3D3 set src_ip=3D192.168.230.9 (vlan333) set dst_ip=3D192.168.230.128 now. But packets still does not exists on vlan333 as outgoing. Any suggestions? Is it possible patched packets silently drops by kernel ? On 26Nov, 2013, at 13:44, Victor Gamov wrote: >=20 > On 26Nov, 2013, at 03:57, Julian Elischer wrote: >=20 >> On 11/24/13, 5:05 AM, Victor Gamov wrote: >>> Hi All >>>=20 >>> I want to get 2 or 3 copies of input packet at my system to resend = it to new destinations. So I prepare following configuration: >>>=20 >>> # ipfw add 10000 ngtee 100 udp from any to 239.0.0.19 dst-port 1234 = in via vlan999 >>>=20 >>> # ngctl mkpeer ipfw: hub 100 hub-in >>> # ngctl name ipfw:100 hub100 >>>=20 >>> # ngctl mkpeer hub100: patch hub100-out1 in >>> # ngctl name hub100:hub100-out1 patch100 >>> # ngctl msg patch100: setconfig '{ count=3D1 csum_flags=3D1 ops=3D[ = { value=3D0xc0a8e680 offset=3D16 length=3D4 mode=3D1 } ] }' >>>=20 >>> Now when I connect to patch:out as >>> # nghook -a patch100: out >>>=20 >>> then I see packets with new IP: >>>=20 >>> 0000: 45 00 05 40 00 00 40 00 ff 11 b9 27 c0 a8 0d 12 >>> 0010: c0 a8 e6 80 04 dc 04 dc 05 2c 00 00 47 4c ef 1a >>>=20 >>> Now I want to put this packets back into IP processing to send it to = new destination 192.168.230.128 (0xc0a8e680): >>>=20 >>> # ngctl mkpeer patch100: ip_input out new100_to_dst_1 >>>=20 >>> But packets not shown on outgoing interface: >>>=20 >>> # ifconfig vlan333 >>> vlan333: flags=3D8843 metric = 0 mtu 1500 >>> options=3D103 >>> ether 00:1b:21:5b:7e:e9 >>> inet 192.168.230.9 netmask 0xffffff00 broadcast 192.168.230.255 >>>=20 >>> # arp 192.168.230.128 >>> ? (192.168.230.128) at 62:99:4c:3b:22:fc on vlan333 expires in 1190 = seconds >> I would looking at giving the packet back to the firewall as = suggested.. >>=20 >> netgraph cookie >> Divert packet into netgraph with given cookie. The search = termi- >> nates. If packet is later returned from netgraph it is = either >> accepted or continues with the next rule, depending on >> net.inet.ip.fw.one_pass sysctl variable. >> see ng_ipfw for more details.. >=20 > Yes I read this manuals :-) But I still can't see packets neither at = ipfw nor at outgoing interface. >=20 > net.inet.ip.fw.one_pass: 0 > net.inet.ip.forwarding: 1 >=20 > Is my original idea is correct? -- CU, Victor Gamov