What's new

Port Forwarding Troubleshooting

  • 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!

gatorback

Regular Contributor
Goal: forward WWAN port (554) traffic to LAN device pinned at 192.168.8.110. Used this site as a guide: https://www.asus.com/support/FAQ/114093/


Not able to reach the device from the WAN side:
snap00203.jpg


I manually configured VLC's .xpsf file to use my WWAN IP 24.120.XX.YY:554 as shown above.

Attempt to forward traffic to LAN device:

snap00202.jpg


Actionable suggestions are appreciated as well as any diagnostic questions. Thank you
 
Last edited:
The first screenshot you show says " Check the log for details". I assume it's refering to a vlc logfile. Is there anything in that log that give additional clues?
 
rtsp doesn't stream media. It is a control channel to tell vlc how to connect. You may need additional ports. rtsp on port X can tell vlc that the stream is available on port Y.
 
It may also be using RTSP over TCP. VLC will default to rtsp over udp. If its over tcp, you may need to adjust vlc accordingly.
 
Try setting the protocol to 'Other'....I think that 'Other' really means 'Any'
 
Observations are provided to address the good suggestions & questions from the community.

I am able to stream from the LAN, can I conclude that the problem is solely with forwarding the inbound traffic (port forwarding)?

OBSERVATION 1: successful streaming from LAN
The following .xpsf successfully opens the device stream from the LAN IP address:

<?xml version="1.0" encoding="UTF-8"?>
<playlist version="1" xmlns="http://xspf.org/ns/0/">
<trackList>
<track><location>rtsp://192.168.8.110:554/live/ch00_0</location><title>Full resolution</title></track>
<track><location>rtsp://192.168.8.110:554/live/ch01_0</location><title>Half resolution</title></track>
</trackList>
</playlist>

OBSERVATION 2: failed streaming from WAN
I copied the .xpsf file and replaced 192.168.87.110 with my WAN IP and tried to forward WAN port 554 traffic to 192.168.8.110:554 as shown in my original post, only to find the error message.

Is the problem solely with forwarding the inbound traffic (port forwarding)?

Here is the VLC log:

main debug: auto hiding mouse cursor
main debug: VoutDisplayEvent 'mouse button' 0 t=8
main debug: VoutDisplayEvent 'mouse button' 0 t=9
main debug: auto hiding mouse cursor
main debug: adding item `AIRCAM WWAN.xspf' ( file:///C:/Users/XXXX/Desktop/AIRCAM%20WWAN.xspf )
main debug: incoming request - stopping current input
main debug: Creating an input for 'AIRCAM WWAN.xspf'
main debug: no fetch required for (null) (art currently (null))
main debug: control: stopping input
main debug: incoming request - stopping current input
main debug: finished input
main warning: can't get output picture
avcodec warning: disabling direct rendering
main debug: removing module "avcodec"
avcodec debug: ffmpeg codec (H264 - MPEG-4 AVC (part 10)) stopped
main debug: killing decoder fourcc `h264', 0 PES in FIFO
main debug: saving a free vout
main debug: reusing provided vout
main debug: removing module "packetizer_h264"
main debug: removing module "live555"
main debug: Program doesn't contain anymore ES
main debug: incoming request - stopping current input
main debug: dead input
main error: Failed to resize display
main debug: processing request item: AIRCAM WWAN.xspf, node: Playlist, skip: 0
main debug: rebuilding array of current - root Playlist
main debug: rebuild done - 5 items, index 4
main debug: starting playback of the new playlist item
main debug: resyncing on AIRCAM WWAN.xspf
main debug: AIRCAM WWAN.xspf is at 2
main debug: creating new input thread
main debug: Creating an input for 'AIRCAM WWAN.xspf'
main debug: using timeshift granularity of 50 MiB, in path 'C:\Users\User\AppData\Local\Temp'
main debug: `file:///C:/Users/User/Desktop/AIRCAM%20WWAN.xspf' gives access `file' demux `' path `/C:/Users/User/Desktop/AIRCAM%20WWAN.xspf'
main debug: creating demux: access='file' demux='' location='/C:/Users/User/Desktop/AIRCAM%20WWAN.xspf' file='C:\Users\User\Desktop\AIRCAM WWAN.xspf'
main debug: looking for access_demux module matching "file": 12 candidates
main debug: no access_demux modules matched
main debug: creating access 'file' location='/C:/Users/User/Desktop/AIRCAM%20WWAN.xspf', path='C:\Users\User\Desktop\AIRCAM WWAN.xspf'
main debug: looking for access module matching "file": 20 candidates
filesystem debug: opening file `C:\Users\User\Desktop\AIRCAM WWAN.xspf'
main debug: using access module "filesystem"
main debug: Using stream method for AStream*
main debug: starting pre-buffering
main debug: received first data after 0 ms
main debug: pre-buffering done 358 bytes in 0s - 349609 KiB/s
main debug: looking for stream_filter module matching "any": 6 candidates
main debug: no stream_filter modules matched
main debug: looking for stream_filter module matching "record": 6 candidates
main debug: using stream_filter module "record"
main debug: creating demux: access='file' demux='' location='/C:/Users/User/Desktop/AIRCAM%20WWAN.xspf' file='C:\Users\User\Desktop\AIRCAM WWAN.xspf'
main debug: looking for demux module matching "any": 63 candidates
playlist debug: using XSPF playlist reader
main debug: using demux module "playlist"
main debug: looking for a subtitle file in C:\Users\User\Desktop\
main debug: looking for meta reader module matching "any": 2 candidates
lua debug: Trying Lua scripts in C:\Users\User\AppData\Roaming\vlc\lua\meta\reader
lua debug: Trying Lua scripts in C:\Program Files (x86)\VideoLAN\VLC\lua\meta\reader
lua debug: Trying Lua playlist script C:\Program Files (x86)\VideoLAN\VLC\lua\meta\reader\filename.luac
main debug: no meta reader modules matched
main debug: `file:///C:/Users/User/Desktop/AIRCAM%20WWAN.xspf' successfully opened
main debug: looking for xml reader module matching "any": 1 candidates
main debug: using xml reader module "xml"
playlist debug: parsed 2 tracks successfully
main info: stopping playback
main debug: deleting item `AIRCAM WWAN.xspf'
main debug: incoming request - stopping current input
main debug: EOF reached
main debug: control: stopping input
main debug: incoming request - stopping current input
main debug: removing module "playlist"
main debug: finished input
main debug: removing module "record"
qt4 debug: IM: Deleting the input
main debug: no fetch required for Full resolution (art currently (null))
main debug: no fetch required for Half resolution (art currently (null))
main debug: removing module "filesystem"
main debug: incoming request - stopping current input
main debug: dead input
main debug: processing request item: rtsp://24.129.XX.YY:554/live/ch00_0, node: Playlist, skip: 0
main debug: rebuilding array of current - root Playlist
main debug: rebuild done - 6 items, index 4
main debug: starting playback of the new playlist item
main debug: resyncing on rtsp://24.129.XX.YY:554/live/ch00_0
main debug: rtsp://24.129.XX.XX:554/live/ch00_0 is at 1
main debug: creating new input thread
main debug: Creating an input for 'rtsp://24.129.XX.YY:554/live/ch00_0'
main debug: using timeshift granularity of 50 MiB, in path 'C:\Users\User\AppData\Local\Temp'
main debug: `rtsp://24.129.XX.YY:554/live/ch00_0' gives access `rtsp' demux `' path `24.129.xx.yy:554/live/ch00_0'
main debug: creating demux: access='rtsp' demux='' location='24.129.xx.yy:554/live/ch00_0' file='\\24.129.xx.yy:554\live\ch00_0'
main debug: looking for access_demux module matching "rtsp": 12 candidates
live555 debug: version 2014.05.27
qt4 debug: IM: Setting an input
qt4 debug: IM: Deleting the input
qt4 debug: IM: Setting an input
qt4 debug: IM: Deleting the input
qt4 debug: IM: Setting an input
qt4 debug: IM: Deleting the input
qt4 debug: IM: Setting an input
main debug: incoming request - stopping current input
live555 debug: connection timeout
live555 error: Failed to connect with rtsp://24.129.XX.YY:554/live/ch00_0
main debug: no access_demux modules matched
main debug: creating access 'rtsp' location='24.129.XX.YY:554/live/ch00_0', path='\\24.129.XX.YY:554\live\ch00_0'
main debug: looking for access module matching "rtsp": 20 candidates
main debug: net: connecting to 24.129.XX.YY port 554
main debug: incoming request - stopping current input
main debug: object waitpipe triggered
access_realrtsp error: cannot connect to 24.129.XX.YY:554
access_realrtsp debug: could not connect to: 24.129.XX.YY:554/live/ch00_0
main debug: no access modules matched
main debug: incoming request - stopping current input
main debug: dead input
main debug: destroying useless vout
main debug: removing module "direct3d"
direct3d debug: Direct3D scene released successfully
qt4 debug: IM: Deleting the input
direct3d debug: DirectXEventThread terminating
direct3d debug: DirectXCloseWindow
direct3d debug: WinProc WM_DESTROY
qt4 debug: releasing video...
qt4 debug: Video is not needed anymore
main debug: removing module "freetype"
main debug: removing module "yuvp"
main debug: removing module "swscale"


OBSERVATION 3: Port Forwarding Protocol Setting
Try setting the protocol to 'Other'....I think that 'Other' really means 'Any'

Selecting 'Other' would not allow port value of 554 and asks for a value from 1-255: I tried 222 and it accepted the value. This would seem to be an bug, unless this was intentionally limited from 1-255.

Protocol was set to UDP and the same VLC error occurred (not the '255' error described in previous paragraph).
 
Last edited:
Try setting the protocol to 'Other'....I think that 'Other' really means 'Any'

Other is used to specify an ICMP protocol by its number (for instance, ICMP 47 is for GRE).

The proper setting here would be BOTH, which handles both udp and tcp.
 
A couple of thoughts (other than I'm sorry I asked if the logfile yielded anything helpful!). And hopefully they won't detract from the thread.

Hopefully, not a stupid question but: the firewall on your Windows machine (192.169.8.110) isn't blocking the traffic is it? (If you consider thar possible you could temporarily disable it.) Do you have an Apple device with VLC Player installed, on which you could, for troubleshooting purposes, test your port-forwarding procedure? VLC Player can be quirky at times, and, if you did have an Apple device, I'd be recommending you try Moli Player (again for troubleshooting purposes) just to rule out any VLC quirkiness. (I've found Moli Player copes handsomely where VLC fails, but I do realise your question relates to a Windows machine - I'm merely considering some troubleshooting/diagnostic steps.).
 
So we've determined offline that the port forward is working but it seems vlc is acting different against the local port vs the WAN port.

How are you testing vlc? are you yrying from the local lan connecting to the wan port? or are you testing from the internet? You should test from internet.

I also wonder if it has to do with your udp port forward. Your device only uses tcp so remove the udp forward. Perhaps vlc is getting confused or perhaps vlc is working on the lan because it can determine to switch to tcp rather than udp. You should try explicately setting vlc to rtsp over tcp.
 
Connected to xfinity wifi hostpot and streams (very poorly) through the port. Thank you. I think that your suggestion to explicitly set VLC's RTSP over TCP may improve the streaming.

" You should try to explicitly set VLC to RTSP over TCP" -How is that best done? in the .xpsf file? or is that a setting?
 
I plugged this into the "open network stream" menu -> rtsp://24.129.XX.YY/live/ch01_0

The streaming session invoked with this procedure was significantly better! I suspect that if it was solely done explicitly over either TCP or UDP (preferable) the transmission would be optimized.
 

Similar threads

Latest threads

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!
Top