Hi Merlin,
Here recently I was trying to remotely support a family member using the screen sharing option in iMessage. I've done this many times on older firmware, but I hadn't tried it in a while. We could never get it to work as of two days ago. I'm on 378.53 and they were on 378.54 (Both are ASUS RT-AC68x devices). So I punted on it and came back later to do some investigative work. Doing some testing on the two ISP connections I have at home, turns out all the options in iMessage i.e. screen sharing, video, and audio are all broken now. I did some logging and the firewall seems to be dropping connections sourced on port 16402 as seen here: (dropped mac and IPs for security)
Aug 3 01:21:58 kernel: DROP IN=eth0 OUT= MAC=xx:xx:xx SRC=xxx.xxx.xxx.xxx DST=xxx.xxx.xxx.xxx LEN=88 TOS=0x00 PREC=0x00 TTL=51 ID=13945 PROTO=UDP SPT=46450 DPT=40368 LEN=68
Aug 3 01:22:16 kernel: DROP IN=eth0 OUT= MAC=xx:xx:xx SRC=xxx.xxx.xxx.xxx DST=xxx.xxx.xxx.xxx LEN=1143 TOS=0x00 PREC=0x00 TTL=51 ID=46924 PROTO=UDP SPT=16402 DPT=53678 LEN=1123
Aug 3 01:22:17 kernel: DROP IN=eth0 OUT= MAC=xx:xx:xx SRC=xxx.xxx.xxx.xxx DST=xxx.xxx.xxx.xxx LEN=1143 TOS=0x00 PREC=0x00 TTL=51 ID=50498 PROTO=UDP SPT=16402 DPT=53678 LEN=1123
Aug 3 01:22:18 kernel: DROP IN=eth0 OUT= MAC=xx:xx:xx SRC=xxx.xxx.xxx.xxx DST=xxx.xxx.xxx.xxx LEN=1143 TOS=0x00 PREC=0x00 TTL=51 ID=21276 PROTO=UDP SPT=16402 DPT=53678 LEN=1123
Aug 3 01:22:31 kernel: DROP IN=eth0 OUT= MAC=xx:xx:xx SRC=xxx.xxx.xxx.xxx DST=xxx.xxx.xxx.xxx LEN=1143 TOS=0x00 PREC=0x00 TTL=51 ID=24298 PROTO=UDP SPT=16402 DPT=40368 LEN=1123
Aug 3 01:22:31 kernel: DROP IN=eth0 OUT= MAC=xx:xx:xx SRC=xxx.xxx.xxx.xxx DST=xxx.xxx.xxx.xxx LEN=1143 TOS=0x00 PREC=0x00 TTL=51 ID=65295 PROTO=UDP SPT=16402 DPT=40368 LEN=1123
Aug 3 01:22:32 kernel: DROP IN=eth0 OUT= MAC=xx:xx:xx SRC=xxx.xxx.xxx.xxx DST=xxx.xxx.xxx.xxx LEN=1143 TOS=0x00 PREC=0x00 TTL=51 ID=49603 PROTO=UDP SPT=16402 DPT=40368 LEN=1123
Thus resulting in the iMessage logs the following:
@/SourceCache/VideoConference/VideoConference-454.2/SIP/SIP.c:2919 type=4 (900A0015/316)
[SIPConnectIPPort failed]
Any idea why the firewall would be knocking this traffic down in these newer firmware versions and breaking SIP? (Trend?) iMessage does report that the Router Type is Port Restricted even though UPnP is turned on. This being broke for Apple desktops is a pretty big gap in the device support arena. I would also guess that this is broken in ASUS's FW as well.
Any and all help would be greatly appreciated as this is a very useful tool for me to support my family members who tend to struggle with technology, and I'd really rather not have to support complex iptables scripts or port forwarding rules on both ends to make this work.
Thanks,
FWFreak
Edit: And just to be clear I am talking about iMessage on OSX desktops, not iPhones, iPads, or Facetime, etc.
Here recently I was trying to remotely support a family member using the screen sharing option in iMessage. I've done this many times on older firmware, but I hadn't tried it in a while. We could never get it to work as of two days ago. I'm on 378.53 and they were on 378.54 (Both are ASUS RT-AC68x devices). So I punted on it and came back later to do some investigative work. Doing some testing on the two ISP connections I have at home, turns out all the options in iMessage i.e. screen sharing, video, and audio are all broken now. I did some logging and the firewall seems to be dropping connections sourced on port 16402 as seen here: (dropped mac and IPs for security)
Aug 3 01:21:58 kernel: DROP IN=eth0 OUT= MAC=xx:xx:xx SRC=xxx.xxx.xxx.xxx DST=xxx.xxx.xxx.xxx LEN=88 TOS=0x00 PREC=0x00 TTL=51 ID=13945 PROTO=UDP SPT=46450 DPT=40368 LEN=68
Aug 3 01:22:16 kernel: DROP IN=eth0 OUT= MAC=xx:xx:xx SRC=xxx.xxx.xxx.xxx DST=xxx.xxx.xxx.xxx LEN=1143 TOS=0x00 PREC=0x00 TTL=51 ID=46924 PROTO=UDP SPT=16402 DPT=53678 LEN=1123
Aug 3 01:22:17 kernel: DROP IN=eth0 OUT= MAC=xx:xx:xx SRC=xxx.xxx.xxx.xxx DST=xxx.xxx.xxx.xxx LEN=1143 TOS=0x00 PREC=0x00 TTL=51 ID=50498 PROTO=UDP SPT=16402 DPT=53678 LEN=1123
Aug 3 01:22:18 kernel: DROP IN=eth0 OUT= MAC=xx:xx:xx SRC=xxx.xxx.xxx.xxx DST=xxx.xxx.xxx.xxx LEN=1143 TOS=0x00 PREC=0x00 TTL=51 ID=21276 PROTO=UDP SPT=16402 DPT=53678 LEN=1123
Aug 3 01:22:31 kernel: DROP IN=eth0 OUT= MAC=xx:xx:xx SRC=xxx.xxx.xxx.xxx DST=xxx.xxx.xxx.xxx LEN=1143 TOS=0x00 PREC=0x00 TTL=51 ID=24298 PROTO=UDP SPT=16402 DPT=40368 LEN=1123
Aug 3 01:22:31 kernel: DROP IN=eth0 OUT= MAC=xx:xx:xx SRC=xxx.xxx.xxx.xxx DST=xxx.xxx.xxx.xxx LEN=1143 TOS=0x00 PREC=0x00 TTL=51 ID=65295 PROTO=UDP SPT=16402 DPT=40368 LEN=1123
Aug 3 01:22:32 kernel: DROP IN=eth0 OUT= MAC=xx:xx:xx SRC=xxx.xxx.xxx.xxx DST=xxx.xxx.xxx.xxx LEN=1143 TOS=0x00 PREC=0x00 TTL=51 ID=49603 PROTO=UDP SPT=16402 DPT=40368 LEN=1123
Thus resulting in the iMessage logs the following:
@/SourceCache/VideoConference/VideoConference-454.2/SIP/SIP.c:2919 type=4 (900A0015/316)
[SIPConnectIPPort failed]
Any idea why the firewall would be knocking this traffic down in these newer firmware versions and breaking SIP? (Trend?) iMessage does report that the Router Type is Port Restricted even though UPnP is turned on. This being broke for Apple desktops is a pretty big gap in the device support arena. I would also guess that this is broken in ASUS's FW as well.
Any and all help would be greatly appreciated as this is a very useful tool for me to support my family members who tend to struggle with technology, and I'd really rather not have to support complex iptables scripts or port forwarding rules on both ends to make this work.
Thanks,
FWFreak
Edit: And just to be clear I am talking about iMessage on OSX desktops, not iPhones, iPads, or Facetime, etc.
Last edited: