On Tue, 3 Aug 2021, Akshat Kakkar wrote:
> 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
> */
Those lines are from net/netfilter/nf_conntrack_h323_main.c ...
> 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.
According to your original mail
> 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).
the VCs share the same network. So if the comment above would be wrong,
then both VCs would not work.
Best regards,
Jozsef
> 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
>
-
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
