Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932557Ab0KODBV (ORCPT ); Sun, 14 Nov 2010 22:01:21 -0500 Received: from mail-fx0-f46.google.com ([209.85.161.46]:51840 "EHLO mail-fx0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932493Ab0KODBT (ORCPT ); Sun, 14 Nov 2010 22:01:19 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=e+c4L0VDtlikW1jxkyPhwS0K84015W3IvemYmFRugyxgxBeYydhlNjfnStaCuA79a6 moxZS8A7NLV/6XPFB6+P/j9aGZJ5dcv/W0kgC+L+lIGA3GA8hXuiMjbGoceQMmFFqgSt CWF1wUfmG5NAsoer2E/mJw+GyByRgwA98uYr0= MIME-Version: 1.0 In-Reply-To: <1289764664.2743.110.camel@edumazet-laptop> References: <28d666269c390965f1a4edca42f93c12@localhost> <1289725175.2743.65.camel@edumazet-laptop> <1289764664.2743.110.camel@edumazet-laptop> Date: Sun, 14 Nov 2010 19:01:17 -0800 Message-ID: Subject: Re: [PATCH/RFC] netfilter: nf_conntrack_sip: Handle quirky Cisco phones From: Kevin Cernekee To: Eric Dumazet Cc: Patrick McHardy , "David S. Miller" , Alexey Kuznetsov , "Pekka Savola (ipv6)" , James Morris , Hideaki YOSHIFUJI , netfilter-devel@vger.kernel.org, netfilter@vger.kernel.org, coreteam@netfilter.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1135 Lines: 24 On Sun, Nov 14, 2010 at 11:57 AM, Eric Dumazet wrote: > Via: SIP/2.0/UDP 192.168.2.28:5060;branch=xxxxxxxx > > > Maybe a fix would be to use this "5060" port, instead of hardcoding it > like you did ? Just posted v2... appreciate the advice so far. My new code in process_sip_request() looks for an address match + port mismatch between the IP source and the Via: header. This is how it tries to detect whether we are talking directly to an afflicted Cisco phone. If the address doesn't match, I assume the request is passing through a non-SIP-aware NAT router so there is no special handling. Assuming we can reliably detect the "quirky phone" condition, is there any way to just trick Netfilter into thinking the source port was 5060 instead of 49xxx? 3/4ths of the patch could probably be eliminated if we could overwrite the port number inside tuplehash. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/