miface option doesn't work in VLC 2.0.x on Windows

[r21514]

VLC 1.0.x and 1.1.x:
vlc.exe --miface-addr=192.168.0.10 udp://@239.1.15.1:1234 <- works perfectly

VLC 2.0
vlc.exe --miface=192.168.0.10 udp://@239.1.15.1:1234 <- nothing
vlc.exe --miface-addr=192.168.0.10 udp://@239.1.15.1:1234 <- nothing

Windows XP SP3 with all updates.

What should I do?

[r21514]

as far as I understand the problen in with function "if_nametoindex" that before 2.0 was defined to "atoi" and worked

[VLC_help]

VLC 2.0.x doesn't have miface-addr option. And miface is only for output

Code: Select all

--miface=<string> Multicast output interface Default multicast interface. This overrides the routing table

[r21514]

miface-addr ALWAYS worked also for input for last 6 years that I use VLC since version 0.8.4

so how to change INPUT interface in VLC 2.0.x ???

[r21514]

I have found the problem. Function "if_nametoindex" requires Windows Vista or higher.

So you left millions of IPTV users who use Windows XP without support. Thank you very much.

[VLC_help]

The atoi should still be used in Windows builds since the config.h with Windows builds doesn't define the HAVE_IF_NAMETOINDEX
so in VLC 1.1.x it is like

Code: Select all

define if_nametoindex( str ) atoi( str )

(src/network/udp.c)
and in VLC 2.0.x is like

Code: Select all

# ifndef HAVE_IF_NAMETOINDEX # define if_nametoindex(name) atoi(name) # endif

(include/vlc_fixups.h)

[r21514]

You are offering me to recompile VLC myself? Cool.

Only my ISP has 100K of IPTV users, ~50% is XP. So they all will forever stay on 1.1.11 now.

[VLC_help]

No recompile. It should already be like it used to, so the issue is in somewhere else.

[r21514]

It's funny but miface gives no result even on Windows 7:

vlc.exe --miface=192.168.0.10 udp://@239.1.15.1:1234 <- nothing
vlc.exe --miface=0 udp... <- nothing (I used number if function "atoi" still used)
vlc.exe --miface=1 udp... <- nothing
vlc.exe --miface=2 udp... <- nothing
vlc.exe --miface="Local area connection 2" udp... <- nothing (name of connection)
vlc.exe "--miface=Local area connection 2" udp... <- nothing
vlc.exe --miface="Realtek...." udp... <- nothing (name of ethernet adapter)
vlc.exe "--miface=Realtek...." udp... <- nothing

So what parameter of network interface must I specify for "miface" to work?
Anybody ever tested miface on Windows?

[Rémi Denis-Courmont]

Depending on the toolchain that was used to compile VLC, I think multicast interface selection will either work only on Windows Vista and later, or will not work at all.

There is no way to support this on Windows XP anyway. It does not support the needed interface, as it predates the TCP/IP stack updates by Microsoft.

So you need to fix your routing table instead of relying on the hack that the --miface option constitute.

[r21514]

As I mentioned above it doesn't work even in Windows 7. It doesn't work at all!

When you do IP_ADD_MEMBERSHIP you anyway use McastReq structure that contains inet_addr.
Why not simply check if miface matches "*.*.*.*" and set inet_addr('what is miface set to') ?

/src/network/udp.c :

Code: Select all

case AF_INET: { struct ip_mreq imr; memset (&imr, 0, sizeof (imr)); assert (grplen >= sizeof (struct sockaddr_in)); imr.imr_multiaddr = ((const struct sockaddr_in *)grp)->sin_addr; >> add settings "imr.imr_interface. s_addr" to "inet_addr('value of "--miface"')" here << if (setsockopt (fd, SOL_IP, IP_ADD_MEMBERSHIP, &imr, sizeof (imr)) == 0) return 0; break; }

One line of code!
It's a critical feature for IPTV and it was used for years till VLC 2.0

[Jean-Baptiste Kempf]

Patch is very welcome.

[Titanic]

Is there a solution for Windows Vista and higher users available? I've tried to use "--miface=<Index_of_NIC>" (e.g. --miface=17) but nothing happened. I still didn't get the stream in VLC even if I see it on the network with wireshark. Has anybody already used miface and got it to work?

[Rémi Denis-Courmont]

• Add the IETF RFC3678 §5 definitions to Mingw toolchain.
• Build VLC with that updated toolchain.

AFAIK, VLC is just fine. The problem is in the Mingw SDK.

[Titanic]

Hi Remi,

Thx for the quick reply. Is there a way to add these RFC3678 §5 definitions to the standard VLC build toolchain used for nightly builds of VLC because I'm not really sure how to add these definitions to the Mingw toolchain. Also my Mingw toolchain was set up a couple of months ago and it's not in a working condition right now so if this could be added to the nightly builds of VLC on the main development servers you would do me a really big favour

[Rémi Denis-Courmont]

I don't know what the build bots use. I would guess some Mingw version from Debian.

[Jean-Baptiste Kempf]

Buildbots are using mingw-w64 3.0-beta.
Releases are still using the old mingw.org compilers

[Titanic]

Does that mean the Nightly Builds of VLC are not having this problem with miface parameter? I'll give it a try.

[Titanic]

I've checked it with last nightly build (2.1.0) for x86 and x64 and both are not working as expected with the miface parameter. Any ideas?

[Jean-Baptiste Kempf]

You will have to do it yourself, I am afraid.

[Titanic]

If I need Win x86 and x64 builds, best way to achive this is using Ubuntu and mingw-x64_beta3.0 I assume.

[mvelkavrh]

I agree with quite few things posted by r21514.

I have the same problem and i find it quite ignorant.

This was posted as a bug at before and dismissed. I've posted it again with the same result and without any helpful advice:
https://trac.videolan.org/vlc/ticket/7707

The explanation stated in release notes is by no means useful, at least not for Windows user where there are no such things as eth0... I've tried with network adapter "names", IPs, numbers. Nothing.

It seem we'll have to stick to 1.1.11.

However, I would expect different attitude towards users. It doesn't seem very reasonable also and I didn't expect something like that.

I hope it will be addressed in the future and I wish all the best to VideoLAN an VLC, probably the best in its field.

Regards, Marko

[tttonyyy]

On Linux I tested it working as this: --miface="eth1" to use my second network card.

On Windows as observed above - it does nothing.

However there is a quick fix for Windows - under

Network Connections -> Local Area Connect 2 -> Properties -> Internet Protocol (TCP/IP) -> Properties -> Advanced

...there is an "Interface metric" box. Untick auto, and set your metric to 1 on the interface you want VLC to use, then go back out and do the same for the interface you don't want VLC to use, but set it to 2.

If you run wireshark you'll see that VLC's IGMP joins/leaves are sent on the interface with the lower metric and things should start working again