Re: Nf_nat_h323 module not working with Panasonic VCs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Netfitler Users]     [Berkeley Packet Filter]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux