What's new
  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

VOIP Client behind AC66U Problems

lucian

Occasional Visitor
I use a fritzbox 7270 as VOIP client behind the AC66U. The 7270 is within the DMZ of the A66U. I can call outside and can receive calls coming from outside. However, its not possible to reveive voice packets from outside. They can hear me, but I can not hear them.

I wanted to analyse the traffic from the AC66U, however commands like tcpdump leads to reboot of my AC66U. iptraf cant access br0. (I usind entware.)

Any suggestions how to proceed?
 
If your VoIP box acts as a SIP client, you should not put it in the DMZ, or forward any port. My Cisco SPA112 ATA works fine here with no particular configuration on the router.

If it works as a PBX however, then you will have to disable the SIP helper:

Code:
nvram set nf_sip=0
nvram commit
 
I tried that and it seems to work now. Without DMZ and without any port forwarding - rly surprised I that the incomming calls get through without it :confused:

However thx very much, rly nice work.

Still why no comment on the reboot - is this a known issue?
 
update:

I cann not recive incomming calls anymore. However - if I put it in DMZ it works :o. But I would prefer to just forward the necessary ports.


Is here an way to monitor and find out the connections used? (tcpdump still crashes)
 
Some PBX/SIP interfaces have various settings related to NAT. Make sure yours are correctly configured in your box (I still don't know if it's a plain ATA, or a PBX).

Check the Wiki on voip.ms (the provider I use with my Cisco ATA). They show a lot of configuration examples that work fine through NAT, they might have recommended settings for you as well:

http://wiki.voip.ms/article/Welcome

I used tcpdump in the past and didn't have any problem, so not sure what is happening in your particular case. Only idea I might think of is to go to LAN -> Switch Control, and make sure that GRO is set to be disabled, then reboot. That option can lead to random reboots.

You could also try monitoring eth0 (WAN) instead of br0 (LAN bridge).
 
mh - could not find GRO - here is only:

Enable Jumbo Frame
Disable HW Accelerator
Spanning-Tree Protocol

which are all on NO. Is GRO the HW Accelerator? Should I disable it? What you use to log into the AC66 - telnet or ssh?

I am using netstat -a to see all connection. However - using your web interface "Connection" show way more connections than netstat. What you use to get that informations?
 
mh - could not find GRO - here is only:

Enable Jumbo Frame
Disable HW Accelerator
Spanning-Tree Protocol

which are all on NO. Is GRO the HW Accelerator? Should I disable it? What you use to log into the AC66 - telnet or ssh?

I am using netstat -a to see all connection. However - using your web interface "Connection" show way more connections than netstat. What you use to get that informations?

The GRO option is only available in the Asus firmware - I compile my firmware with the option totally disabled.

Netstat shows the established connections terminated directly on your router. That does not show all the NATed connections which aren't terminated on your router, and are established between a remote server and a device on your network. I use netstat-nat for this, which retrieve this information directly from the kernel's connection tracking.
 
I tested a little bit and could collect the following:

Using the command tcpdump -i eth0 printing on command line not omiting SSH traffic.

a) termianl telnet

crashing after printing about 20 lines, cpu load < 3%, output in window really slow

b) terminal ssh

crashing after printing about 200 lins, cpu load up to 100%, output in window really fast

c) terminal ssh , omiting SSH traffic (less captures)

random crasing after about 5 mins

-> looks like that in a) and b) here is a buffer overflow in the output buffer, since the ssh prints much faster, takes longer to fill the buffer. but no doesnt explain crashing in case of c)
 

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Back
Top