Could this be PPPD's keep-alive feature?
Can we see the logs, please?
Enable more verbose pppoe logging, by editing the first two lines of /etc/ppp/options to read something like:
debug
logfile /tmp/ppp.log
just make sure to write to a location with enough space to last for your testing and stop the test after a while and disable the logfile again by prefixing that line with a #. You can keep debug at all times to see more verbose reporting in the system log (logread | grep -e ppp).
here is what i was able to retrieve. Interface name is "kpn" with vlan6.
Connect time for each cycle is always 0.2 minutes.
Is this the cause: pppd[11376]? No idea what it stands for btw.
Fri Jan 20 13:52:30 2023 kern.info kernel: [ 307.102640] mvneta f1070000.ethernet eth0: configuring for fixed/rgmii-id link mode
Fri Jan 20 13:52:30 2023 daemon.notice netifd: Interface 'kpn' is disabled
Fri Jan 20 13:52:30 2023 kern.info kernel: [ 307.110905] mvneta f1070000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
Fri Jan 20 13:52:30 2023 kern.info kernel: [ 307.122099] mvneta f1070000.ethernet eth0: Link is Down
Fri Jan 20 13:52:30 2023 kern.info kernel: [ 307.132758] mvneta f1070000.ethernet eth0: configuring for fixed/rgmii-id link mode
Fri Jan 20 13:52:30 2023 kern.info kernel: [ 307.140777] mvneta f1070000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
Fri Jan 20 13:52:30 2023 kern.info kernel: [ 307.144819] mv88e6085 f1072004.mdio-mii:00 wan: configuring for phy/gmii link mode
Fri Jan 20 13:52:30 2023 kern.info kernel: [ 307.161379] 8021q: adding VLAN 0 to HW filter on device wan
Fri Jan 20 13:52:30 2023 daemon.notice netifd: Interface 'kpn' is enabled
Fri Jan 20 13:52:30 2023 daemon.notice netifd: Interface 'kpn' is setting up now
Fri Jan 20 13:52:30 2023 daemon.notice netifd: 8021q 'wan.6' link is down
Fri Jan 20 13:52:30 2023 daemon.notice netifd: Interface 'kpn' has link connectivity loss
Fri Jan 20 13:52:30 2023 daemon.notice netifd: Network device 'wan' link is down
Fri Jan 20 13:52:30 2023 daemon.notice netifd: Interface 'kpn' is now down
Fri Jan 20 13:52:30 2023 kern.info kernel: [ 307.295625] mvneta f1070000.ethernet eth0: Link is Down
Fri Jan 20 13:52:30 2023 kern.info kernel: [ 307.306152] mvneta f1070000.ethernet eth0: configuring for fixed/rgmii-id link mode
Fri Jan 20 13:52:30 2023 kern.info kernel: [ 307.314153] mvneta f1070000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
Fri Jan 20 13:52:30 2023 daemon.notice netifd: Interface 'kpn' is disabled
Fri Jan 20 13:52:30 2023 kern.info kernel: [ 307.326126] mvneta f1070000.ethernet eth0: Link is Down
Fri Jan 20 13:52:30 2023 kern.info kernel: [ 307.336571] mvneta f1070000.ethernet eth0: configuring for fixed/rgmii-id link mode
Fri Jan 20 13:52:30 2023 kern.info kernel: [ 307.344590] mvneta f1070000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
Fri Jan 20 13:52:30 2023 kern.info kernel: [ 307.344970] mv88e6085 f1072004.mdio-mii:00 wan: configuring for phy/gmii link mode
Fri Jan 20 13:52:30 2023 kern.info kernel: [ 307.364530] 8021q: adding VLAN 0 to HW filter on device wan
Fri Jan 20 13:52:30 2023 daemon.notice netifd: Interface 'kpn' is enabled
Fri Jan 20 13:52:33 2023 daemon.notice netifd: Network device 'wan' link is up
Fri Jan 20 13:52:33 2023 kern.info kernel: [ 310.038543] mv88e6085 f1072004.mdio-mii:00 wan: Link is Up - 100Mbps/Full - flow control rx/tx
Fri Jan 20 13:52:33 2023 kern.info kernel: [ 310.047228] IPv6: ADDRCONF(NETDEV_CHANGE): wan: link becomes ready
Fri Jan 20 13:52:33 2023 kern.info kernel: [ 310.054118] IPv6: ADDRCONF(NETDEV_CHANGE): wan.6: link becomes ready
Fri Jan 20 13:52:33 2023 daemon.notice netifd: 8021q 'wan.6' link is up
Fri Jan 20 13:52:33 2023 daemon.notice netifd: Interface 'kpn' has link connectivity
Fri Jan 20 13:52:33 2023 daemon.notice netifd: Interface 'kpn' is setting up now
Fri Jan 20 13:52:33 2023 daemon.err insmod: module is already loaded - slhc
Fri Jan 20 13:52:33 2023 daemon.err insmod: module is already loaded - ppp_generic
Fri Jan 20 13:52:33 2023 daemon.err insmod: module is already loaded - pppox
Fri Jan 20 13:52:33 2023 daemon.err insmod: module is already loaded - pppoe
Fri Jan 20 13:52:33 2023 daemon.info pppd[11376]: Plugin pppoe.so loaded.
Fri Jan 20 13:52:33 2023 daemon.info pppd[11376]: PPPoE plugin from pppd 2.4.9
Fri Jan 20 13:52:33 2023 daemon.notice pppd[11376]: pppd 2.4.9 started by root, uid 0
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: Send PPPOE Discovery V1T1 PADI session 0x0 length 12
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: dst ff:ff:ff:ff:ff:ff src 8c:68:c8:89:26:13
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: [service-name] [host-uniq 70 2c 00 00]
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: Recv PPPOE Discovery V1T1 PADO session 0x0 length 35
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: dst 8c:68:c8:89:26:13 src c4:44:7d:c5:7c:a4
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: [service-name] [host-uniq 70 2c 00 00] [AC-name 195.190.228.106] [end-of-list]
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: Send PPPOE Discovery V1T1 PADR session 0x0 length 12
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: dst c4:44:7d:c5:7c:a4 src 8c:68:c8:89:26:13
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: [service-name] [host-uniq 70 2c 00 00]
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: Recv PPPOE Discovery V1T1 PADS session 0x289d length 16
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: dst 8c:68:c8:89:26:13 src c4:44:7d:c5:7c:a4
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: [service-name] [host-uniq 70 2c 00 00] [end-of-list]
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: PADS: Service-Name: ''
Fri Jan 20 13:52:33 2023 daemon.info pppd[11376]: PPP session is 10397
Fri Jan 20 13:52:33 2023 daemon.warn pppd[11376]: Connected to c4:44:7d:c5:7c:a4 via interface wan.6
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: using channel 17
Fri Jan 20 13:52:33 2023 kern.info kernel: [ 310.285170] pppoe-kpn: renamed from ppp0
Fri Jan 20 13:52:33 2023 daemon.info pppd[11376]: Renamed interface ppp0 to pppoe-kpn
Fri Jan 20 13:52:33 2023 daemon.info pppd[11376]: Using interface pppoe-kpn
Fri Jan 20 13:52:33 2023 daemon.notice pppd[11376]: Connect: pppoe-kpn <--> wan.6
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: sent [LCP ConfReq id=0x1 <mru 1492> <magic 0x2205fc5a>]
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: rcvd [LCP ConfReq id=0x2 <mru 1500> <auth pap> <magic 0xe09af417>]
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: sent [LCP ConfAck id=0x2 <mru 1500> <auth pap> <magic 0xe09af417>]
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: rcvd [LCP ConfAck id=0x1 <mru 1492> <magic 0x2205fc5a>]
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: sent [LCP EchoReq id=0x0 magic=0x2205fc5a]
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: sent [PAP AuthReq id=0x1 user="internet" password=<hidden>]
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: rcvd [LCP EchoRep id=0x0 magic=0xe09af417]
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: rcvd [PAP AuthAck id=0x1 "Authentication success,Welcome!"]
Fri Jan 20 13:52:33 2023 daemon.info pppd[11376]: Remote message: Authentication success,Welcome!
Fri Jan 20 13:52:33 2023 daemon.notice pppd[11376]: PAP authentication succeeded
Fri Jan 20 13:52:33 2023 daemon.notice pppd[11376]: peer from calling number C4:44:7D:C5:7C:A4 authorized
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: sent [IPV6CP ConfReq id=0x1 <addr fe80::79ba:20d1:dddf:4784>]
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: rcvd [IPCP ConfReq id=0x1 <addr 195.190.228.106>]
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: sent [IPCP ConfAck id=0x1 <addr 195.190.228.106>]
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: rcvd [IPV6CP ConfReq id=0x1 <addr fe80::c644:7dff:fec5:7ca4>]
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: sent [IPV6CP ConfAck id=0x1 <addr fe80::c644:7dff:fec5:7ca4>]
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: rcvd [IPCP ConfNak id=0x1 <addr 86.87.216.133> <ms-dns1 195.121.1.34> <ms-dns2 195.121.1.66>]
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: sent [IPCP ConfReq id=0x2 <addr 86.87.216.133> <ms-dns1 195.121.1.34> <ms-dns2 195.121.1.66>]
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: rcvd [IPV6CP ConfAck id=0x1 <addr fe80::79ba:20d1:dddf:4784>]
Fri Jan 20 13:52:33 2023 daemon.notice pppd[11376]: local LL address fe80::79ba:20d1:dddf:4784
Fri Jan 20 13:52:33 2023 daemon.notice pppd[11376]: remote LL address fe80::c644:7dff:fec5:7ca4
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: Script /lib/netifd/ppp6-up started (pid 11401)
Fri Jan 20 13:52:33 2023 daemon.warn dnsmasq[1]: failed to create listening socket for fe80::c644:7dff:fec5:7ca4%pppoe-kpn: Address not available
Fri Jan 20 13:52:33 2023 daemon.warn dnsmasq[1]: failed to create listening socket for fe80::c644:7dff:fec5:7ca4%pppoe-kpn: Address not available
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: rcvd [IPCP ConfAck id=0x2 <addr 86.87.216.133> <ms-dns1 195.121.1.34> <ms-dns2 195.121.1.66>]
Fri Jan 20 13:52:33 2023 daemon.notice pppd[11376]: local IP address 86..xxx
Fri Jan 20 13:52:33 2023 daemon.notice pppd[11376]: remote IP address 195.xxx
Fri Jan 20 13:52:33 2023 daemon.notice pppd[11376]: primary DNS address 195.121.1.34
Fri Jan 20 13:52:33 2023 daemon.notice pppd[11376]: secondary DNS address 195.121.1.66
Fri Jan 20 13:52:33 2023 daemon.warn dnsmasq[1]: failed to create listening socket for fe80::c644:7dff:fec5:7ca4%pppoe-kpn: Address not available
Fri Jan 20 13:52:33 2023 daemon.warn dnsmasq[1]: failed to create listening socket for fe80::c644:7dff:fec5:7ca4%pppoe-kpn: Address not available
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: Script /lib/netifd/ppp-up started (pid 11402)
Fri Jan 20 13:52:33 2023 daemon.notice netifd: Network device 'pppoe-kpn' link is up
Fri Jan 20 13:52:33 2023 daemon.notice netifd: Network alias 'pppoe-kpn' link is up
Fri Jan 20 13:52:33 2023 daemon.notice netifd: Interface 'kpn' is now up
Fri Jan 20 13:52:33 2023 daemon.info dnsmasq[1]: reading /tmp/resolv.conf.d/resolv.conf.auto
Fri Jan 20 13:52:33 2023 daemon.info dnsmasq[1]: using nameserver 195.121.1.34#53
Fri Jan 20 13:52:33 2023 daemon.info dnsmasq[1]: using nameserver 195.121.1.66#53
Fri Jan 20 13:52:33 2023 daemon.info dnsmasq[1]: using only locally-known addresses for test
Fri Jan 20 13:52:33 2023 daemon.info dnsmasq[1]: using only locally-known addresses for onion
Fri Jan 20 13:52:33 2023 daemon.info dnsmasq[1]: using only locally-known addresses for localhost
Fri Jan 20 13:52:33 2023 daemon.info dnsmasq[1]: using only locally-known addresses for local
Fri Jan 20 13:52:33 2023 daemon.info dnsmasq[1]: using only locally-known addresses for invalid
Fri Jan 20 13:52:33 2023 daemon.info dnsmasq[1]: using only locally-known addresses for bind
Fri Jan 20 13:52:33 2023 daemon.info dnsmasq[1]: using only locally-known addresses for lan
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: Script /lib/netifd/ppp-up finished (pid 11402), status = 0x1
Fri Jan 20 13:52:33 2023 daemon.notice netifd: Interface 'kpn_6' is enabled
Fri Jan 20 13:52:33 2023 daemon.notice netifd: Interface 'kpn_6' has link connectivity
Fri Jan 20 13:52:33 2023 daemon.notice netifd: Interface 'kpn_6' is setting up now
Fri Jan 20 13:52:33 2023 daemon.debug pppd[11376]: Script /lib/netifd/ppp6-up finished (pid 11401), status = 0x0
Fri Jan 20 13:52:33 2023 user.notice firewall: Reloading firewall due to ifup of kpn (pppoe-kpn)
Fri Jan 20 13:52:34 2023 user.notice firewall: Reloading firewall due to ifupdate of kpn (pppoe-kpn)
Fri Jan 20 13:52:34 2023 daemon.warn dnsmasq[1]: failed to create listening socket for fe80::c644:7dff:fec5:7ca4%pppoe-kpn: Address not available
Fri Jan 20 13:52:34 2023 daemon.warn dnsmasq[1]: failed to create listening socket for fe80::c644:7dff:fec5:7ca4%pppoe-kpn: Address not available
Fri Jan 20 13:52:35 2023 daemon.warn dnsmasq[1]: failed to create listening socket for fe80::c644:7dff:fec5:7ca4%pppoe-kpn: Address not available
Fri Jan 20 13:52:35 2023 daemon.warn dnsmasq[1]: failed to create listening socket for fe80::c644:7dff:fec5:7ca4%pppoe-kpn: Address not available
Fri Jan 20 13:52:43 2023 daemon.info pppd[11376]: No response to 5 echo-requests
Fri Jan 20 13:52:43 2023 daemon.notice pppd[11376]: Serial link appears to be disconnected.
Fri Jan 20 13:52:43 2023 daemon.info pppd[11376]: Connect time 0.2 minutes.
Fri Jan 20 13:52:43 2023 daemon.info pppd[11376]: Sent 3989 bytes, received 1099 bytes.
Fri Jan 20 13:52:43 2023 daemon.warn dnsmasq[1]: failed to create listening socket for fe80::c644:7dff:fec5:7ca4%pppoe-kpn: Address not available
Fri Jan 20 13:52:43 2023 daemon.warn dnsmasq[1]: failed to create listening socket for fe80::c644:7dff:fec5:7ca4%pppoe-kpn: Address not available
Fri Jan 20 13:52:43 2023 daemon.debug pppd[11376]: Script /lib/netifd/ppp-down started (pid 11651)
Fri Jan 20 13:52:43 2023 daemon.notice netifd: Network device 'pppoe-kpn' link is down
Fri Jan 20 13:52:43 2023 daemon.notice netifd: Network alias 'pppoe-kpn' link is down
Fri Jan 20 13:52:43 2023 daemon.notice netifd: Interface 'kpn_6' has link connectivity loss
Fri Jan 20 13:52:43 2023 daemon.err odhcp6c[11449]: Failed to send RS (Network unreachable)
Fri Jan 20 13:52:43 2023 daemon.debug pppd[11376]: Script /lib/netifd/ppp-down started (pid 11652)
Fri Jan 20 13:52:43 2023 daemon.debug pppd[11376]: sent [LCP TermReq id=0x2 "Peer not responding"]
Fri Jan 20 13:52:43 2023 daemon.notice netifd: Interface 'kpn' has lost the connection
A d-suffix typically denotes a daemon process that is run continuously in the background, and PPP expands to Point-to-Point-Protocol.
Why did you name the interface kpn? OpenWrt usually uses wan or pppoe-wan at least for single WAN-connected routers.
So your pppoe-client believes that the PPPoE link does not work, as the LCP packets it sends out did not elicit a response from the ISP's side. Is the link actually usable for these whole 10 seconds with IPv4?
Does KPN actually offer IPv6?
According to the wiki the following is recommended:
config interface 'wan6'
option proto 'dhcpv6'
option device 'pppoe-kpn'
option reqaddress 'none'
option reqprefix 'auto'
option peerdns '0'
list dns '2001:4860:4860::8888'
list dns '2001:4860:4860::8844'
option metric '0'
whether that is not obsolete advice for your OpenWrt version.
Try replacing the
option device 'pppoe-kpn'
line with either
option ifname '@wan'
or if that does not work with
option ifname 'pppoe-kpn'
1 Like
I tried everything, configuring from scratch with luci to copy/paste using vi into the etc//network file. Also tried to increase the LCP threshold numbers but all that did was that the connection kept alive for approx 2 minutes.
Could it be a specific linksys 1200 issue? In the past both eth1 and eth0 were available to configure, but with the new dsa of openwrt the eth1 disappeared.
So i cannot open a vlan on eth1, only on wan port.
And somewhere i read that this router needed eth0 for lan and eth1 for wan and it was exact the opposite of other routers eth1/eth0. However this does tell me nothing s the connection successfully establishes with vlan6 on the wan port. The cycle is consistent however so some process seems to be failing.
In this specific router, i cannot configure eth1 as required in the instructions (only eth0 but that is not successful)
config device
option name 'eth1'
option mtu '1508'
config device
option type '8021q'
option ifname 'eth1'
option vid '6'
option name 'eth1.6'
config interface 'wan'
option proto 'pppoe'
option device 'eth1.6'
So some instructions in the OpenWrt wikis are ancient and were not adited to reeflect changes in netwik configuration, so it is well possible that eth0 and eth1 got switched (these are just logical names the kernel assigns sequentially based on in what sequence the devices are discovered and that sequence is not guaranteed to be stable).
What happens if you remove the whole IPv6 configuration section completely? Do you get stable IPv4 connectivity? I ask because it might be simpler to try to separate these two issues if possible. We see a problem with IPv6 which might or might not hose the whole process (and given the apparent age of thw wiki entry the ipv6 stanza for KPN ftth might simply be wrong). So could you try without IPv6 please?
To be explicit, I am not talking about getting rid of IPv6 forever, but just to test whether IPv6 contributes to the problem or not.
thanks for the swift response, but that i did try as well. No difference however. The crazy thing is that using the KPN provided box, the connection establishes immediately and stays up forever.
I will try an older openwrt version (like 18.x) without dsa and even dd-wrt to see if that makes any difference....
So, as suspected, the PPPD's keep-alive feature is detecting a dead line, and closing the connection. I would start by disabling it (perhaps it is over-actuating), and trying again.
I increased the keep alive values (showing in the LCP threshold value in advanced settings for pppoe).
However that only increased uptime up to a couple of minutes. So that did not work out.
However, this message also is in the log:
Fri Jan 20 13:52:43 2023 daemon.warn dnsmasq[1]: failed to create listening socket for fe80::c644:7dff:fec5:7ca4%pppoe-kpn: Address not available
I switched off dnsmasq in the firewall tab and as a result the pppoe link stayed up indefinitely. However, i did not get access to the internet. My knowledge on this is insufficient to explain why.
Any suggestions?
While the link is up, can you reach external hosts? Or it just seems to be up, but there is no traffic?
Try disabling dnsmasq from listening on the pppoe-kpn interface to see if that makes a difference.
uci add_list dhcp.@dnsmasq[0].notinterface='pppoe-kpn'
uci commit dhcp
/etc/init.d/dnsmasq restart
Did you try ?
option keepalive '5 5'
I have a complete stable connection 
with this setup:
config device
option name 'wan'
option macaddr 'XX:XX:XX:XX:XX:XX'
option mtu '1508'
option multicast '0'
option ipv6 '0'
config interface 'wan'
option proto 'pppoe'
option username 'FB7590@xs4all.nl'
option password '1234567890'
option keepalive '5 5'
option mtu '1508'
option device 'wan.6'
option ipv6 '0'
option delegate '0'
thanks! i will modify the network file and do the test.
And as expected, the same behavior occurred. Cycling on/off PPPoE connection.
I guess the router goes into the bin.
Hmm i do have kpn myself 
So far im not seeing alot wrong in the configuration if I compare with mine (correct me if im wrong I scanned fast over it).
Except:
Username should be: XX-XX-XX-XX@internet where XX is your mac address of the original modem, ive had times other usernames did not work even though ive not seeing proof its a actual enforcement.
Where password is just: ppp
Interface should be dhcp client, edit: I mean it should not have a dhcp defined, it should automatically create a ipv6 client aswell as soon it finds it when pppoe is authenticated.
The only thing what might blocks it is a temporary block because kpn sees another device connected with a different mac address when there only can be one, best is to spoof the mac of the modem you can do this by editing the wan device in the devices tab.
The only other thing I can think off is maybe you selected the wrong wan port 
, on my mochabin I got two wan devices... Eth0 and eth2... And I was using eth1
Hi,
thanks for the response! The configuration as i use it gets me access to the internet for 12 seconds up to 2 minutes depending on setting the LCP treshold (keepalive). But then breaks and build up again etc.
Fri Jan 20 13:52:33 2023 daemon.info pppd[11376]: Remote message: Authentication success,Welcome!
i will try to investigate further what the impact of dnsmasq is, as there are entries in the log that refer to that function.
Let me sent my configuration in case it can be usefull 
The wan device
Wan bridge (I had 2 wan ports but I only listed the current connected one eth2, for you probably eth0 I would suggest if theres no bridge u keep it that way ):
uci show network.@device[1]
network.cfg050f15=device
network.cfg050f15.name='br-wan'
network.cfg050f15.type='bridge'
network.cfg050f15.macaddr='00:00:00:00:00:00' <- should be the mac address of box12 modem.
network.cfg050f15.ipv6='0'
network.cfg050f15.bridge_empty='1'
network.cfg050f15.ports='eth2'
Wan device (note: I dont see a port listed so I dont think ive used this at all but I did had my mac address set to box12 mac):
uci show network.@device[2]
network.cfg140f15=device
network.cfg140f15.name='wan'
network.cfg140f15.macaddr='00:00:00:00:00:00' <- should be the mac address of box12 modem.
network.cfg140f15.ipv6='0'
The pppoe wan interface
Wan interface:
uci show network.@interface[7]
network.wan=interface
network.wan.proto='pppoe'
network.wan.username='00-00-00-00-00-00@internet' <- should be same mac address as box12 modem.
network.wan.password='ppp'
network.wan.device='eth2.6' <- here I add the direct port with vlan 6.
network.wan.delegate='0'
network.wan.ipv6='0'
network.wan.metric='20' <- note this metric is not usual but ive used it for wireguard so connectivity restores if I turn wireguard down.
tl;tr optionally.
also for later would be nice from me to include aswell since alot of information is scarce to set things up for iptv and even normal internet the information site from the isp didn't gave me alot
of information to start with.
the iptv device
uci show network.@device[4]
network.cfg190f15=device
network.cfg190f15.type='bridge'
network.cfg190f15.name='br-iptv'
network.cfg190f15.bridge_empty='1'
network.cfg190f15.igmp_snooping='1'
network.cfg190f15.ipv6='0'
network.cfg190f15.ports='eth2.4'
the iptv interface
uci show network.@interface[9]
network.iptv=interface
network.iptv.proto='dhcp'
network.iptv.vendorid='IPTV_RG'
network.iptv.device='br-iptv'
network.iptv.delegate='0'
igmpproxy (you have to restart the router afterwards)
uci show igmpproxy
igmpproxy.@igmpproxy[0]=igmpproxy
igmpproxy.@igmpproxy[0].quickleave='1'
igmpproxy.@phyint[0]=phyint
igmpproxy.@phyint[0].network='iptv'
igmpproxy.@phyint[0].direction='upstream'
igmpproxy.@phyint[0].altnet='0.0.0.0/0'
igmpproxy.@phyint[1]=phyint
igmpproxy.@phyint[1].network='lan'
igmpproxy.@phyint[1].zone='lan'
igmpproxy.@phyint[1].direction='downstream'
firewall rules and zones
uci show firewall.@zone[8]
firewall.cfg1ddc81=zone
firewall.cfg1ddc81.name='iptv'
firewall.cfg1ddc81.input='ACCEPT'
firewall.cfg1ddc81.output='ACCEPT'
firewall.cfg1ddc81.forward='REJECT'
firewall.cfg1ddc81.masq='1'
firewall.cfg1ddc81.network='iptv'
uci show firewall.@forwarding[10]
firewall.cfg21ad58=forwarding
firewall.cfg21ad58.src='lan'
firewall.cfg21ad58.dest='iptv'
uci show firewall.@forwarding[9]
firewall.cfg1ead58=forwarding
firewall.cfg1ead58.src='iptv'
firewall.cfg1ead58.dest='wan'
uci show firewall.@rule[10]
firewall.cfg1f92bd=rule
firewall.cfg1f92bd.name='allow iptv'
firewall.cfg1f92bd.src='lan'
firewall.cfg1f92bd.dest='iptv'
firewall.cfg1f92bd.target='ACCEPT'
uci show firewall.@rule[11]
firewall.cfg2092bd=rule
firewall.cfg2092bd.name='allow-mcast'
firewall.cfg2092bd.src='iptv'
firewall.cfg2092bd.dest='lan'
firewall.cfg2092bd.dest_ip='224.0.0.1/4'
firewall.cfg2092bd.target='ACCEPT'
so far for iptv you don't seem to need a route set anymore as what they did put on multiple tutorials, it seems it gets pushed by a dhcp option automaticly now.
I hope this can help you finding your issue
edit:
if you want to use ipv6 just ignore the ipv6 options I have set in the configuration it should work but I have disabled it myself only iptv should be non ipv6.
Thanks for this!
However, my router keeps breaking the connection so i suspect the HW to have issues, although i wouldn't know why.
KPN only needs vlan6 for internet so in essence it is very simple.
username and password don't really matter, just cannot be empty.
Anyhow, using the same setup as advised but to no avail.
Below is the content from /etc/config/network
config device
option type '8021q'
option ifname 'wan'
option vid '6'
option name 'wan.6'
option macaddr '8C:xx:C8:89:xx:13'
config interface 'wan'
option proto 'pppoe'
option device 'wan.6'
option ipv6 '0'
option username '8C-xx-C8-89-xx-13@internet'
option password 'ppp'
option delegate '0'
config device
option name 'wan'
option macaddr '8C:xx:C8:89:xx:13'
for me it only worked using the direct device, if wan was eth0 it would be eth0.6 as device in the wan interface.
its kinda strange why wan.6 didn't work for me either but I think in my case it might had to do that eth0 was sfp, eth1 a internal switch (I don't think thats supposed to show up like that on the mochabin but per default it was in the br-wan bridge for me), and eth2 was the active wan port for me so maybe the wan interface also could mismatch traffic to the switch?
once I used the direct eth2.6 it worked for me.
Bought a new device. Got it working in about 0.5 sec.
Still OpenWrt and still the same configuration? If yes that points to the first device being simply broken, no?
1 Like