[BUG] PMS doesn't bind 127.0.0.1 when IPv6 and Bind to Net Interface are used

Plex Media Server Desktops & Laptops
1

Dear Plexer,

I discovered this misbehaviour: Enabling IPv6 and Binding on specific Network interface (available with last PMS), no services are bind to 127.0.0.1 (IPv4 localhost) address. The result is that (sub)services fail to connect to loopback with IPv4.

Workarounds: Disable IPv6 OR bind on all interfaces (0.0.0.0)

Fixes: When specific network interface bind is required bind on interface’s ip and 127.0.0.1 and if IPv6 has been enabled also on ::1

Best regards,

ciao

Luigi

PS: PMS v1.13.5.5291 on Linux 64bit

Plex not correctly binding to 127.0.0.1
2

Thank you for reporting this!

Please restore the problematic settings
verify ‘Debug Logging’ in Plex is activated
then restart Plex server
wait 5 minutes
fetch server log files and post them here or PM them to me if you rather not post them publicly

Also please add the outputs of netstat -a -b -n and ifconfig

3

“netstat -anp|grep 32400” output:

tcp        0      0 192.168.1.1:32400       0.0.0.0:*               LISTEN      7605/./Plex Media S 
tcp        0      0 192.168.1.1:32400       93.56.17.34:60417       ESTABLISHED 7605/./Plex Media S 
tcp        0      0 192.168.1.1:32400       54.246.248.53:53889     TIME_WAIT   -                   
tcp        0      0 192.168.1.1:32400       172.19.0.2:48212        ESTABLISHED 7605/./Plex Media S 
tcp6       0      0 ::1:32400               :::*                    LISTEN      7605/./Plex Media S

“ip addr” output:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether d0:50:99:95:25:8e brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.1/24 brd 192.168.1.255 scope global dynamic enp3s0
       valid_lft 66483sec preferred_lft 66483sec
    inet6 2001:b07:2ed:1c2a:d250:99ff:fe95:258e/64 scope global mngtmpaddr noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::d250:99ff:fe95:258e/64 scope link 
       valid_lft forever preferred_lft forever
...
5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:79:4d:07:d5 brd ff:ff:ff:ff:ff:ff
    inet 192.168.42.1/24 brd 192.168.42.255 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:79ff:fe4d:7d5/64 scope link 
       valid_lft forever preferred_lft forever
...
4

Thank you for the info and the logs.

Is there something specific with your linux network configuration for how loopback is defined? wondering why it is showing as 127.0.0.1/8 ?

I can see an error in the log

Aug 22, 2018 12:06:32.797 [0x7fc0621ca840] DEBUG - HttpServer: Listening on IPv6 as well as IPv4.

Aug 22, 2018 12:06:32.800 [0x7fc0621ca840] ERROR - HttpServer: Error binding acceptor: Invalid argument

Aug 22, 2018 12:06:32.800 [0x7fc0621ca840] ERROR - HttpServer: Error opening acceptor on IPv6, falling back to IPv4: Invalid argument
5

127.0.0.1/8 is conforming to RFC 6890. There is nothing special here.

              +----------------------+----------------------------+
              | Attribute            | Value                      |
              +----------------------+----------------------------+
              | Address Block        | 127.0.0.0/8                |
              | Name                 | Loopback                   |
              | RFC                  | [RFC1122], Section 3.2.1.3 |
              | Allocation Date      | September 1981             |
              | Termination Date     | N/A                        |
              | Source               | False [1]                  |
              | Destination          | False [1]                  |
              | Forwardable          | False [1]                  |
              | Global               | False [1]                  |
              | Reserved-by-Protocol | True                       |
              +----------------------+----------------------------+

              [1] Several protocols have been granted exceptions to this
                  rule.  For examples, see [RFC4379] and [RFC5884].

                             Table 4: Loopback
6

Thank you. I am trying to establish why you have the problem but has not been encountered elsewhere.

We will be referring it to the development team but would like to see what it is in your setup that led to the issue.

Does the problem arise if loopback is defined to be 127.0.0.1/255.255.255.255 >

7

same results here.

“ip addr”:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/32 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever

Plex Media Server.log:

Aug 22, 2018 15:58:34.154 [0x7f64f26d6840] ERROR - HttpServer: Error binding acceptor: Invalid argument
Aug 22, 2018 15:58:34.154 [0x7f64f26d6840] ERROR - HttpServer: Error opening acceptor on IPv6, falling back to IPv4: Invalid argument

“netstat -ntpl|grep 32400”:

tcp        0      0 192.168.1.1:32400       0.0.0.0:*               LISTEN      6711/./Plex Media S 
tcp6       0      0 ::1:32400               :::*                    LISTEN      6711/./Plex Media S

Ciao

luigi

8

Interesting… I have reproduced the error on ubuntu desktop

Sorry for my earlier assumption that this was specific to your environment

10

This has now been referred to the development team

Suggest either disabling ipv6 or do not make use of the new network interface selection feature.

11

Hi @sa2000,
don’t worry. I’m also a sw dev and I well understand your workflow in order to reduce the noise.

Thank you. BTW the last 1.13.6.5339 faces the same issue.

Ciao!

luigi

12

Hi @sa2000,

Does the new 1.13.7.5369 solve this issue?

ciao

luigi

13

I am sorry but there isn’t an imminent fix.

I am no longer recommending the use of the new feature for network interface selection.

14

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.