@seiichiro0185
I have disconnects about every 10 - 150 minutes, too. Did your Turris Omnia reboot after some failed connection attempts?
I didn’t get any reboots during my test. Only thing I had to reboot for (manually) was to switch back from the SFP-Module to the external VDSL Box.
Hello, I have changed 16 Mbit line now at German Telekom.
I bought a ALL4781-VDSL2-SFP and changed config to this:
root@turris:~# cat /etc/config/network
config interface ‘loopback’
option ifname ‘lo’
option proto ‘static’
option ipaddr ‘127.0.0.1’
option netmask ‘255.0.0.0’
config globals ‘globals’
option ula_prefix ‘fd67:aef3:b5fb::/48’
config interface ‘lan’
option force_link ‘1’
option type ‘bridge’
option proto ‘static’
option netmask ‘255.255.255.0’
option ip6assign ‘60’
option ipaddr ‘192.168.1.1’
option gateway ‘192.168.1.1’
option ifname ‘eth0 eth2 wlan0 wlan1’
option nat ‘1’
config interface ‘wan’
option proto ‘pppoe’
option username ‘MyName@t-online.de’
option password ‘MyPassword’
option ipv6 ‘auto’
option ifname ‘eth1.7’
option mtu ‘1492’
config interface ‘wan6’
option ifname ‘eth1’
option proto ‘dhcpv6’
config switch
option name ‘switch0’
option reset ‘1’
option enable_vlan ‘1’
config switch_vlan
option device ‘switch0’
option vlan ‘1’
option ports ‘0 1 2 3 4 5’
option vid ‘1’
config switch_vlan
option device ‘switch0’
option vlan ‘2’
option vid ‘2’
option ports ‘6t’
But as now I get no connection.
This is in log:
root@turris:~# dmesg
[ 208.408825] device eth2 entered promiscuous mode
[ 208.416242] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 208.417826] IPv6: ADDRCONF(NETDEV_UP): eth1.7: link is not ready
[ 210.070373] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 210.073512] device wlan0 entered promiscuous mode
[ 210.100334] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
[ 210.101408] device wlan1 entered promiscuous mode
[ 210.101446] br-lan: port 4(wlan1) entered forwarding state
[ 210.101464] br-lan: port 4(wlan1) entered forwarding state
[ 210.101515] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
[ 210.166257] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
[ 210.400932] mvneta f1070000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
[ 210.400950] mvneta f1030000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
[ 210.400971] br-lan: port 2(eth2) entered forwarding state
[ 210.400995] br-lan: port 2(eth2) entered forwarding state
[ 210.401532] br-lan: port 1(eth0) entered forwarding state
[ 210.401554] br-lan: port 1(eth0) entered forwarding state
[ 210.410985] mvneta f1034000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
[ 210.411000] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 210.411465] IPv6: ADDRCONF(NETDEV_CHANGE): eth1.7: link becomes ready
[ 210.433731] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 210.433823] br-lan: port 3(wlan0) entered forwarding state
[ 210.433852] br-lan: port 3(wlan0) entered forwarding state
[ 212.100909] br-lan: port 4(wlan1) entered forwarding state
[ 212.400932] br-lan: port 1(eth0) entered forwarding state
[ 212.400961] br-lan: port 2(eth2) entered forwarding state
[ 212.430913] br-lan: port 3(wlan0) entered forwarding state
…
root@turris:~# tail -f /var/log/messages
2018-12-10 23:10:04 notice netifd[]: Interface ‘wan6’ is now down
2018-12-10 23:10:04 notice netifd[]: Interface ‘wan6’ is setting up now
2018-12-10 23:10:04 notice netifd[]: Interface ‘wan’ is now down
2018-12-10 23:10:04 notice netifd[]: Interface ‘wan’ is setting up now
2018-12-10 23:10:15 info pppd[3946]: Plugin rp-pppoe.so loaded.
2018-12-10 23:10:15 info pppd[3946]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
2018-12-10 23:10:15 info pppd[3950]: Plugin rp-pppoe.so loaded.
2018-12-10 23:10:15 info pppd[3950]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
2018-12-10 23:10:15 notice pppd[3946]: pppd 2.4.7 started by root, uid 0
2018-12-10 23:10:15 notice pppd[3950]: pppd 2.4.7 started by root, uid 0
2018-12-10 23:10:30 warning pppd[3946]: Timeout waiting for PADO packets
2018-12-10 23:10:30 warning pppd[3950]: Timeout waiting for PADO packets
2018-12-10 23:10:30 err pppd[3946]: Unable to complete PPPoE Discovery
2018-12-10 23:10:30 info pppd[3946]: Exit.
2018-12-10 23:10:30 notice netifd[]: Interface ‘wan6’ is now down
2018-12-10 23:10:30 notice netifd[]: Interface ‘wan6’ is setting up now
2018-12-10 23:10:30 err pppd[3950]: Unable to complete PPPoE Discovery
2018-12-10 23:10:30 info pppd[3950]: Exit.
2018-12-10 23:10:30 notice netifd[]: Interface ‘wan’ is now down
2018-12-10 23:10:30 notice netifd[]: Interface ‘wan’ is setting up now
I tried several other settings but without success.
Who has a working config please?
Kind regards
Stefan
The physical link is reported as up and thus the issue seems to be with the PADO packets time out and thus PPoE is failing, judging from the log.
Is your ISP providing ipv6 only (with ipv6 over it). I am not familiar with ipv6 really and thus perhaps not of help in such scenario. Maybe you can run a search for pado packet timeout and see if there is anything that can be learned from it.
Else if the search or the forum does not provide a remedy you may contact TO support via email since this may not be caused by the modem but the PPoE plugin
PADO Packet timeout normally means either you have no DSL-Sync (should be visible on the SFP-Module, LED on the right side of the Module looking from the RJ45 jack) or wrong VLAN. (assuming your Provider doesn’t have a Problem)
1 Like
Both, green and yellow LED on the ALL4781 have to be on (green = xDSL sync, yellow = SFP connection).
Did you change from 16 MBit/s ADSL2+ to VDSL2 or do you still have an 16 MBit/s ADSL2+ socket?
ADSL2+ sockets on old DSLAMs: no VLAN tagging -> eth1
ADSL2+ sockets on BNG DSLAMs: VLAN tagging -> eth1.7
If it is an ADSL2+ socket ask Teuerkom if the DSLAM is BNG.
config interface 'wan'
option proto 'pppoe'
option username '<Anschlusskennung><Zugangsnummer>#0001@t-online.de'
option password '<password>'
option ipv6 '1'
option ifname 'eth1.7'
config interface 'wan6'
option ifname '@wan'
option proto 'dhcpv6'
Works for me on a VDSL2-BNG socket (except the annoying disconnects).
Set force_mode = 'phy-sfp-noneg' in /usr/sbin/sfpswitch.py and make sure /etc/init.d/sfpswitch is started on boot (‘phy-def’ is the 1000Base-T-mode for the RJ-45 WAN port).
I have this random disconnects too.
Have you verifyed If the connection to the SFP Module drops or the VDSL sync stops?
I did not checked it here yet.
If the VDSL sync stops it could be a normal procedure initialysed by the Provider. They so it If the DSL modem sends with to much power for example.
regards
In my case the Sync is lost (as indicated by the blinking sync LED on the Module), the Connection of the SFP-Module to the Omina is stable.
The disconnects happen every 10-200 minutes. Sometimes i can see the green LED flickering, yellow is on, eth1 goes down and up once. PPPd logs Timeout. No PADO packets received. After multiple restarts of PPPd the TurrisOmnia reboots. It takes about 5-10 minutes until the internet connection is up again. This renders the internet socket useless.
Gerhard Zerwes from ALLNET checked the ALL4781. Hardware is fine and firmware up-to-date.
Connection between APL and TAE is 6 meters Cat.5e, TAE cable is 2 meters Cat.5e.
A TP-Link Archer VR200v syncs stable at 38 MBit/s (75% of 50 MBit/s).
A Fritz!Box 7490 works stable at 55 Mbit/s (110% of contract speed):
I have tested the complete day and ended in reading the VDSL tech specs from Deutsche Telekom
https://www.telekom.de/hilfe/downloads/1tr112.zip
At the moment iam Online since 3h 33m 10s.
UPDATE 4h 45m 27s since the last disconnect
Thats the end for now.
I do not have any reboot from the turris.
Only the WAN connection reconnects
My network-config:
/etc/config/network
[…]
config dsl ‘eth1’
option annex ‘a’
option tone ‘av’
option xfer_mode ‘ptm’
config interface ‘wan’
option proto ‘pppoe’
option _orig_ifname ‘ptm0’
option _orig_bridge ‘false’
option ifname ‘eth1.7’
option username ‘XXXXX#0001@t-online.de’
option password ‘XXXXX’
option ipv6 ‘auto’
/etc/ppp/options
#uncomment debug and change logfile location
#because i want to see whats going on
debug
logfile /tmp/pptp-server.log
/usr/sbin/sfpswitch.py
[…]
force_mode = ‘phy-sfp’
[…]
Speedtest:
My contract is Down 100Mbit/s / Up 40 Mbit/s
Testing from Deutsche Telekom AG (217.[…])…
Retrieving speedtest.net server list…
Selecting best server based on ping…
Hosted by […]: 29.114999999999998 ms
Testing download speed…
Download: 72.66 Mbit/s
Testing upload speed…
Upload: 31.50 Mbit/s
1 Like
config dsl ‘eth1’
option annex ‘a’
option tone ‘av’
option xfer_mode ‘ptm’
What’s the reason for this?
Mmmh, unless this annex option is only evaluated for ATM?ADSL links this is wrong as all the bandplans for europe are in annex b (side note since the ITU standards for ADSL and VDSL are different documents they each have their own independent Annexes, so VDSL2 Annex B != ADSL Annex B)
No response to 5 echo-requests
Serial link appears to be disconnected.
Connect time 21.7 minutes.
Sent 32559864 bytes, received 1804049357 bytes.
Script /lib/netifd/ppp-down started (pid 12934)
Script /lib/netifd/ppp-down started (pid 12939)
sent [LCP TermReq id=0x2 "Peer not responding"]
Script /lib/netifd/ppp-down finished (pid 12939), status = 0x1
Script /lib/netifd/ppp-down finished (pid 12934), status = 0x1
sent [LCP TermReq id=0x3 "Peer not responding"]
Connection terminated.
Connect time 21.7 minutes.
Sent 32559864 bytes, received 1804049357 bytes.
Send PPPOE Discovery V1T1 PADT session 0x4a length 20
dst dc:38:e1:10:99:9f src d8:58:d7:00:7a:26
[AC-cookie cf f7 58 cc a0 6e 8c 76 7a 0e 90 1e 0e 05 22 d1]
Sent PADT
Modem hangup
after 21 minutes …
Does anyone have a SFP-1000Base-T media-converter and can try to use the ALL4781 as an external Modem with a Fritz!box doing VLAN 7 and PPPoE?
This is caused by netifd the connection manager and does not mean that the line been dead. See if disabling the feature gets you relief with the disconnects.
Disabling LCP pings isn’t possible on OpenWRT.
No response to 5 echo-requests
Serial link appears to be disconnected.
Connect time 2.5 minutes.
Sent 149106 bytes, received 1546929 bytes.
Script /lib/netifd/ppp-down started (pid 24168)
sent [LCP TermReq id=0x2 “Peer not responding”]
Script /lib/netifd/ppp-down finished (pid 24168), status = 0x1
sent [LCP TermReq id=0x3 “Peer not responding”]
Connection terminated.
Send PPPOE Discovery V1T1 PADT session 0x25 length 20
dst dc:38:e1:10:99:9f src d8:58:d7:00:7a:26
[AC-cookie cf f7 58 cc a0 6e 8c 76 7a 0e 90 1e 0e 05 22 d1]
Sent PADT
Modem hangup
I just saw the green LED (DSL sync) flashing. It is probably a problem on the VDSL side, not SFP or OpenWRT.
Well, you cannot tell really because it is netifd actually killing the connection and thus initiating another sync. That LCP is not producing a response does not mean that line is dead.
How about increasing the threshold and interval?
Adding option keepalive 1024 86400 in /etc/config/network keeps the PPPoE interface up but the ALL4781 looses VDSL-sync (green LED flashing).
It was mentioned earlier
I am wondering whether this might be the cause. Maybe I am just lucky with the line or the hardware deployed by the ISP at the ATM but haven’t had any of this sync issues since I wrote the initial post.
And really too bad this happening as otherwise the modem seems a good supplement to the router.
Not that any of this is helping your case though, unfortunately. 
According to speedtest.net the ALL4781 achieves 48 MBit/s downstream and 9 MBit/s upstream which is a good value for a 50/10 MBit/s socket. All of a sudden it looses VDSL-sync. After a few minutes it synchronizes at full speed.