Nf_nat_h323 module not working with Panasonic VCs

Nf_nat_h323 module not working with Panasonic VCs

[Akshat Kakkar]

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?

Re: Nf_nat_h323 module not working with Panasonic VCs

[Jozsef Kadlecsik]

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@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: Nf_nat_h323 module not working with Panasonic VCs

[Akshat Kakkar]

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.

On Mon, Jul 26, 2021 at 2:11 AM Jozsef Kadlecsik <kadlec@netfilter.org> 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@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
> PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt
> Address : Wigner Research Centre for Physics
>           H-1525 Budapest 114, POB. 49, Hungary

Re: Nf_nat_h323 module not working with Panasonic VCs

[Jozsef Kadlecsik]

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@netfilter.org> 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@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
> > 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@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: Nf_nat_h323 module not working with Panasonic VCs

[Akshat Kakkar]

Hi Jozsef,

For the VC which is working (i.e. VC2, IP:172.16.1.120) following are
the generated debug log:

[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.

On Mon, Jul 26, 2021 at 1:13 PM Jozsef Kadlecsik <kadlec@netfilter.org> 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@netfilter.org> 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@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
> > > 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@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
> PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt
> Address : Wigner Research Centre for Physics
>           H-1525 Budapest 114, POB. 49, Hungary

Re: Nf_nat_h323 module not working with Panasonic VCs

[Akshat Kakkar]

Hi Jozsef,

Any idea how to go about?

On Tue, Jul 27, 2021 at 7:02 PM Akshat Kakkar <akshat.1984@gmail.com> wrote:
>
> Hi Jozsef,
>
> For the VC which is working (i.e. VC2, IP:172.16.1.120) following are
> the generated debug log:
>
> [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.
>
> On Mon, Jul 26, 2021 at 1:13 PM Jozsef Kadlecsik <kadlec@netfilter.org> 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@netfilter.org> 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@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
> > > > 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@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
> > PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt
> > Address : Wigner Research Centre for Physics
> >           H-1525 Budapest 114, POB. 49, Hungary

Re: Nf_nat_h323 module not working with Panasonic VCs

[Jozsef Kadlecsik]

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@netfilter.org> 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@netfilter.org> 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@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
> > > > > 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@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
> > > 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@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: Nf_nat_h323 module not working with Panasonic VCs

[Akshat Kakkar]

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@netfilter.org> 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@netfilter.org> 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@netfilter.org> 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@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
> > > > > > 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@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
> > > > 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@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
> PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt
> Address : Wigner Research Centre for Physics
>           H-1525 Budapest 114, POB. 49, Hungary

Re: Nf_nat_h323 module not working with Panasonic VCs

[Akshat Kakkar]

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@gmail.com> 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@netfilter.org> 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@netfilter.org> 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@netfilter.org> 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@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
> > > > > > > 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@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
> > > > > 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@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
> > PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt
> > Address : Wigner Research Centre for Physics
> >           H-1525 Budapest 114, POB. 49, Hungary

Re: Nf_nat_h323 module not working with Panasonic VCs

[Jozsef Kadlecsik]

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@gmail.com> 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@netfilter.org> 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@netfilter.org> 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@netfilter.org> 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@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
> > > > > > > > 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@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
> > > > > > 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@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
> > > 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@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: Nf_nat_h323 module not working with Panasonic VCs

[Jozsef Kadlecsik]

On Tue, 3 Aug 2021, Akshat Kakkar 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.

Then do you have the full source code of the running kernel? Or do you 
have only the header files? At the moment I have got an 4.4.244 kernel 
tree and it does contain net/netfilter/nf_conntrack_h323_main.c.

Best regards,
Jozsef

> 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@netfilter.org> 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@netfilter.org> 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@netfilter.org> 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@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
> > > > > > > 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@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
> > > > > 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@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
> > 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@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: Nf_nat_h323 module not working with Panasonic VCs

[Akshat Kakkar]

For me also its same. only header files.

On Tue, Aug 3, 2021 at 1:33 PM Jozsef Kadlecsik <kadlec@netfilter.org> wrote:
>
> On Tue, 3 Aug 2021, Akshat Kakkar 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.
>
> Then do you have the full source code of the running kernel? Or do you
> have only the header files? At the moment I have got an 4.4.244 kernel
> tree and it does contain net/netfilter/nf_conntrack_h323_main.c.
>
> Best regards,
> Jozsef
>
> > 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@netfilter.org> 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@netfilter.org> 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@netfilter.org> 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@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
> > > > > > > > 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@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
> > > > > > 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@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
> > > 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@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
> PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt
> Address : Wigner Research Centre for Physics
>           H-1525 Budapest 114, POB. 49, Hungary

Re: Nf_nat_h323 module not working with Panasonic VCs

[Akshat Kakkar]

I mean ... only header files. No c files.

On Tue, Aug 3, 2021 at 1:34 PM Akshat Kakkar <akshat.1984@gmail.com> wrote:
>
> For me also its same. only header files.
>
> On Tue, Aug 3, 2021 at 1:33 PM Jozsef Kadlecsik <kadlec@netfilter.org> wrote:
> >
> > On Tue, 3 Aug 2021, Akshat Kakkar 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.
> >
> > Then do you have the full source code of the running kernel? Or do you
> > have only the header files? At the moment I have got an 4.4.244 kernel
> > tree and it does contain net/netfilter/nf_conntrack_h323_main.c.
> >
> > Best regards,
> > Jozsef
> >
> > > 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@netfilter.org> 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@netfilter.org> 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@netfilter.org> 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@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
> > > > > > > > > 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@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
> > > > > > > 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@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
> > > > 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@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
> > PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt
> > Address : Wigner Research Centre for Physics
> >           H-1525 Budapest 114, POB. 49, Hungary

Re: Nf_nat_h323 module not working with Panasonic VCs

[Jozsef Kadlecsik]

Hello Akshat,

On Sat, 24 Jul 2021, Akshat Kakkar wrote:

> 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.

Could you send me the full packet dump of both cases?

When the debugging is enabled, there should be debug lines in the kernel 
log for the VC1 case too. It's really strange that there isn't any.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics
          H-1525 Budapest 114, POB. 49, Hungary