I feel the bug can be in this section :
/* If the calling party is on the same side of the forward-to party,
* we don't need to track the second call
*/
static int callforward_do_filter(struct net *net,
const union nf_inet_addr *src,
const union nf_inet_addr *dst,
u_int8_t family)
... where it is wrongly assumed that the calling party is on the same
side of the forward-to party. In case of natting (like a virtual-ip)
and dial-out, the initial call will look to be on the same side but it
is after natting that forward-to party is known. In my case, the
initial call is from 172.16.1.100 to 172.16.1.120 which looks to be on
the same side. But after natting, it changes to 10.1.1.12 which is on
the other side i.e. it becomes a call from 172.16.1.100 to 10.1.1.12.
It's just a wild guess.
On Tue, Aug 3, 2021 at 12:03 PM Akshat Kakkar <akshat.1984@xxxxxxxxx> wrote:
>
> My kernel is 4.4.82. It may be demotivating, I know.
>
> However, the logs shared by me, though very less, still shows clearly
> that for Panasonic VC packets the module isn't treating this as a q931
> packet (or cs:connect of h.225) and hence not processed.
>
> As far as output of the command is concerned, there is no .c file with
> that name.
>
> when I try to find files having 323 in the name in /usr/src path using
> following command
>
> find . -name *323*
>
> Following is the output:
> ./kernels/4.4.82-1.el7.elrepo.x86_64/include/linux/netfilter/nf_conntrack_h323.h
> ./kernels/4.4.82-1.el7.elrepo.x86_64/include/linux/netfilter/nf_conntrack_h323_types.h
> ./kernels/4.4.82-1.el7.elrepo.x86_64/include/linux/netfilter/nf_conntrack_h323_asn1.h
> ./kernels/4.4.82-1.el7.elrepo.x86_64/include/linux/i2c/lm8323.h
> ./kernels/4.4.82-1.el7.elrepo.x86_64/include/config/rtc/drv/ds3234.h
> ./kernels/4.4.82-1.el7.elrepo.x86_64/include/config/rtc/drv/ds3232.h
> ./kernels/4.4.82-1.el7.elrepo.x86_64/include/config/nf/conntrack/h323.h
> ./kernels/4.4.82-1.el7.elrepo.x86_64/include/config/nf/nat/h323.h
> ./kernels/4.4.82-1.el7.elrepo.x86_64/include/config/cm3232.h
>
>
> On Mon, Aug 2, 2021 at 11:50 PM Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxx> wrote:
> >
> > Hi Akshat,
> >
> > On Mon, 2 Aug 2021, Akshat Kakkar wrote:
> >
> > > > For the VC which is working (i.e. VC2, IP:172.16.1.120) following are
> > > > the generated debug log:
> >
> > That can't be the full debug log, lines are missing/left out. What is the
> > kernel version? Isn't there any output from the command
> >
> > $ grep 'pr_debug("nf_ct_q931' net/netfilter/nf_conntrack_h323_main.c
> >
> > > > [Jul27 17:29] nf_nat_q931: expect H.245 172.16.1.100:0->172.16.1.120:5516
> > > > [ +0.249944] nf_nat_h323: expect RTP 172.16.1.100:0->172.16.1.120:5506
> > > > [ +0.000021] nf_nat_h323: expect RTCP 172.16.1.100:0->172.16.1.120:5507
> > > > [ +0.003265] nf_nat_h323: expect RTP 172.16.1.100:0->172.16.1.120:5508
> > > > [ +0.000011] nf_nat_h323: expect RTCP 172.16.1.100:0->172.16.1.120:5509
> > > > [ +0.007606] nf_nat_h323: expect RTP 172.16.1.100:0->172.16.1.120:5506
> > > > [ +0.000012] nf_nat_h323: expect RTCP 172.16.1.100:0->172.16.1.120:5507
> > > > [ +0.000010] nf_nat_h323: expect RTP 172.16.1.100:0->172.16.1.120:5506
> > > > [ +0.000004] nf_nat_h323: expect RTCP 172.16.1.100:0->172.16.1.120:5507
> > > > [ +0.004337] nf_nat_h323: expect RTP 172.16.1.100:0->172.16.1.120:5508
> > > > [ +0.000010] nf_nat_h323: expect RTCP 172.16.1.100:0->172.16.1.120:5509
> > > > [ +0.000007] nf_nat_h323: expect RTP 172.16.1.100:0->172.16.1.120:5508
> > > > [ +0.000007] nf_nat_h323: expect RTCP 172.16.1.100:0->172.16.1.120:5509
> > > > [ +0.006028] nf_nat_h323: expect RTP 172.16.1.100:0->172.16.1.120:5510
> > > > [ +0.000011] nf_nat_h323: expect RTCP 172.16.1.100:0->172.16.1.120:5511
> > > > [ +0.001171] nf_nat_h323: expect RTP 172.16.1.100:0->172.16.1.120:5510
> > > > [ +0.000008] nf_nat_h323: expect RTCP 172.16.1.100:0->172.16.1.120:5511
> > > > [ +0.000006] nf_nat_h323: expect RTP 172.16.1.100:0->172.16.1.120:5510
> > > > [ +0.000003] nf_nat_h323: expect RTCP 172.16.1.100:0->172.16.1.120:5511
> > > > [ +0.003261] nf_nat_h323: expect RTP 172.16.1.100:0->172.16.1.120:5512
> > > > [ +0.000011] nf_nat_h323: expect RTCP 172.16.1.100:0->172.16.1.120:5513
> > > > [ +0.000006] nf_nat_h323: expect RTP 172.16.1.100:0->172.16.1.120:5512
> > > > [ +0.000003] nf_nat_h323: expect RTCP 172.16.1.100:0->172.16.1.120:5513
> > > > [ +0.007889] nf_nat_h323: expect RTP 172.16.1.100:0->172.16.1.120:5512
> > > > [ +0.000012] nf_nat_h323: expect RTCP 172.16.1.100:0->172.16.1.120:5513
> > > >
> > > > However, for the panasonic VC1 i.e. the VC which is having issue,
> > > > there are no debug log generated. absolutely nothing.
> >
> > Best regards,
> > Jozsef
> >
> > > > On Mon, Jul 26, 2021 at 1:13 PM Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxx> wrote:
> > > > >
> > > > > On Mon, 26 Jul 2021, Akshat Kakkar wrote:
> > > > >
> > > > > > MCU is using IP only to dial to VC1 and not hostname.
> > > > > >
> > > > > > I went through packet capture and find everything in line with the
> > > > > > standard. Just that it is sending "CS : Call Proceeding" packet which
> > > > > > is an optional packet but it is part of standard.
> > > > > > I can share pcap file if needed.
> > > > >
> > > > > Could you enable dynamic debugging in the kernel and enable it for the
> > > > > nf_conntrack_h323 module? Then please repeate the testing with the
> > > > > working and not working VCs and send the generated kernel debug log
> > > > > messages.
> > > > >
> > > > > Best regards,
> > > > > Jozsef
> > > > > > On Mon, Jul 26, 2021 at 2:11 AM Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxx> wrote:
> > > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > On Sat, 24 Jul 2021, Akshat Kakkar wrote:
> > > > > > >
> > > > > > > > I have 2 vc endpoints VC1 (Make:Panasonic, IP:10.1.1.11),
> > > > > > > > VC2(make:Polycom,IP: 10.1.1.12) and 1 MCU (172.16.1.100).
> > > > > > > >
> > > > > > > > There is a Linux firewall between VCs and MCU.
> > > > > > > >
> > > > > > > > There is one to one nat configured for these 2 VCs (10.1.1.11 <-->
> > > > > > > > 172.16.1.110, 10.1.1.12 <--> 172.16.1.120)
> > > > > > > > There is no natting for MCU IP as it is routable.
> > > > > > > >
> > > > > > > > nf_nat_h323 and nf_conntrack_h323 module is enabled in the firewall.
> > > > > > > >
> > > > > > > > When VC1 and VC2 initiate call to MCU, everything works fine. Video
> > > > > > > > call is successful for both VC1 and VC2. h245 IP address for tcp in
> > > > > > > > h225: CS connect packet is correctly replaced by the natted IP.
> > > > > > > >
> > > > > > > > However, when there is a dial out from MCU to VCs (i.e. MCU initiate
> > > > > > > > call to the natted IP (i.e. 172.16.1.110 and 172.16.1.120 of VCs),
> > > > > > > > natting works fine but h245 IP address for tcp in h225:CS is replaced
> > > > > > > > correctly only for VC2 and not for VC1. For VC1, it is still its
> > > > > > > > actual IP (i.e. 10.1.1.12 and not 172.16.1.120).
> > > > > > > >
> > > > > > > > Because of this, video call is successful only with VC2 and not with
> > > > > > > > VC1, when initiated from MCU. I tried with another panasonic VC
> > > > > > > > hardware, there was no change.
> > > > > > > >
> > > > > > > > Further packet dump analysis showed that for VC1, there are 3 h225
> > > > > > > > packets (setup, call proceeding and alert) before Connect message but
> > > > > > > > for VC2 there are only 2 h225 packets (setup and alert) before connect
> > > > > > > > message.
> > > > > > > >
> > > > > > > > Is there a bug in nf_nat_h323 module or am I missing something?
> > > > > > >
> > > > > > > It can be a bug/incompatibility with the H.323 implementation in the
> > > > > > > Panasonic device. However, first I'd make sure the MCU does not use
> > > > > > > hostname for VC1 instead of its IP address. Hostnames in the calls are not
> > > > > > > supported.
> > > > > > >
> > > > > > > Best regards,
> > > > > > > Jozsef
> > > > > > > -
> > > > > > > E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlecsik.jozsef@xxxxxxxxx
> > > > > > > PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt
> > > > > > > Address : Wigner Research Centre for Physics
> > > > > > > H-1525 Budapest 114, POB. 49, Hungary
> > > > > >
> > > > >
> > > > > -
> > > > > E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlecsik.jozsef@xxxxxxxxx
> > > > > PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt
> > > > > Address : Wigner Research Centre for Physics
> > > > > H-1525 Budapest 114, POB. 49, Hungary
> > >
> >
> > -
> > E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlecsik.jozsef@xxxxxxxxx
> > PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt
> > Address : Wigner Research Centre for Physics
> > H-1525 Budapest 114, POB. 49, Hungary
