› Forums › Network Management › ZeroShell › UDP issue on 3.5 and 3.6 new installs
- This topic is empty.
-
AuthorPosts
-
July 12, 2016 at 5:00 pm #44599
iulyb
MemberHi,
My SIP device a Linksys / Cisco SPA 3102 doesn’t register anymore using UDP port 5060 when using 3.5 and then 3.6 after a reboot.
Worked flawless for more than 4 years with older versions.Going into firewall section and then on conntrack press flush seems to fix it until the next reboot.
Even more interesting this issue doesn’t appear on a device that has been upgraded, just on new installs.
July 13, 2016 at 2:30 pm #54183DrmCa
ParticipantFWIW my Linksys PAP2T continued to work with 3.5 after upgrage from 3.0
AFAIK they do not require any setup to work and as long as firewall is not blocking the address/port/protocol everything should be hunky-dory.July 13, 2016 at 8:25 pm #54184iulyb
Member@DrmCa wrote:
FWIW my Linksys PAP2T continued to work with 3.5 after upgrage from 3.0
AFAIK they do not require any setup to work and as long as firewall is not blocking the address/port/protocol everything should be hunky-dory.That is correct, forgot to mention, I have an upgrade setup and works ok on that, on the new install doesn’t.
I have no rules so you are right, no setup is required.
There is a bug open on the ddwrt on this issue related to contrack. This is how I figure out the workaround to do contrack flush.July 14, 2016 at 4:38 pm #54185DrmCa
ParticipantSorry, I probably mislead you!
Mine was a brand new install of 3.5 where I restored a backup taken under 3.0. It was an “upgrade” in terms of going up a version only, not that I installed 3.5 over 3.0.In your brand new install do you have any forwarding under virtual server at all? Any chance 5060 or the RTP ports are forwarded to a wrong host?
July 14, 2016 at 6:36 pm #54186iulyb
Member@DrmCa wrote:
Mine was a brand new install of 3.5 where I restored a backup taken under 3.0. It was an “upgrade” in terms of going up a version only, not that I installed 3.5 over 3.0.
In your brand new install do you have any forwarding under virtual server at all? Any chance 5060 or the RTP ports are forwarded to a wrong host?
Thanks,
This is good to know. I do not have any rules under virtual server.
I have an Alix box and an APU box.
On Alix I started with some 2.x version then applied upgrades.
On APU I started with 3.5 then applied upgrades. I never imported config, I just redid a similar config having a real domain (not example.com.. )Besides the hardware differences, I changed the network IP from 192.168.0.75 to 192.168.5.5 in order to have more flexibly on VPN.
Here is the output of iptables:
iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
SYS_GUI all -- anywhere anywhere
SYS_INPUT all -- anywhere anywhere
SYS_HTTPS tcp -- anywhere anywhere tcp dpt:http
SYS_HTTPS tcp -- anywhere anywhere tcp dpt:https
SYS_SSH tcp -- anywhere anywhere tcp dpt:ssh
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
SYS_OUTPUT all -- anywhere anywhere
Chain NetBalancer (0 references)
target prot opt source destination
Chain SYS_DNS (2 references)
target prot opt source destination
ACCEPT all -- 192.168.5.0/24 anywhere
ACCEPT all -- 192.168.5.0/24 anywhere
ACCEPT all -- 192.168.5.0/24 anywhere
ACCEPT all -- 192.168.250.0/24 anywhere
ACCEPT all -- 192.168.15.0/24 anywhere
DROP all -- anywhere anywhere
Chain SYS_GUI (1 references)
target prot opt source destination
ACCEPT tcp -- 192.168.250.1 anywhere tcp dpt:12081
Chain SYS_HTTPS (2 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- 192.168.5.0/24 anywhere
ACCEPT all -- 192.168.5.0/24 anywhere
ACCEPT all -- 192.168.5.0/24 anywhere
ACCEPT all -- 192.168.250.0/24 anywhere
ACCEPT all -- 192.168.15.0/24 anywhere
DROP all -- anywhere anywhere
Chain SYS_INPUT (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT udp -- anywhere anywhere udp spt:domain state ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp spt:domain state ESTABLISHED
SYS_DNS udp -- anywhere anywhere udp dpt:domain
SYS_DNS tcp -- anywhere anywhere tcp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp spt:http state ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp spt:8245 state ESTABLISHED
ACCEPT udp -- anywhere anywhere udp spt:ntp state ESTABLISHED
RETURN all -- anywhere anywhere
Chain SYS_OUTPUT (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT tcp -- anywhere anywhere tcp dpt:8245
ACCEPT udp -- anywhere anywhere udp dpt:ntp
RETURN all -- anywhere anywhere
Chain SYS_SSH (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- 192.168.5.0/24 anywhere
ACCEPT all -- anywhere anywhere
DROP all -- anywhere anywhere
I did more investigation and here are the results:
after reboot:
root@zs scripts> conntrack -L |grep 5060
udp 17 3598 src=192.168.5.56 dst=85.204.232.10 sport=5060 dport=5060 packets=718 bytes=341879 [UNREPLIED] src=85.204.232.10 dst=192.168.5.56 sport=5060 dport=5060 packets=0 bytes=0 mark=0 use=1Then flush table fix the issue
root@zs scripts> conntrack -F
root@zs scripts> conntrack -L |grep 5060
udp 17 3588 src=192.168.5.56 dst=85.204.232.10 sport=5060 dport=5060 packets=1 bytes=428 src=85.204.232.10 dst=154.20.113.39 sport=5060 dport=5060 packets=1 bytes=393 mark=0 use=1
When I get some time I will switch the configs between the 2 devices to exclude the HW as a culprit and keep you posted.
-
AuthorPosts
- You must be logged in to reply to this topic.