I face some disconnection issues, they last only for a minute or two, but they occur about once an hour. I give you the logs and my setup for reviewing, I hope I did something basic wrong. I am grateful about any tips.
Before changing to the TO I had a fritzbox (AVM router+modem) in place which didn’t cause any troubles and these kinds of connection disruptions.
Running the connection test I get a failed IPv4 gateway connectivity and failed IPv6 connectitiy and gateway connectivity test. IPv6 is not used with my ISP I guess, that checks.
From what I am reading off this logs I see the router is checking the connection and didn’t get a response to the 5 echo-requests, the router thinks the connection is down. What happens after that I do not fully understand, I greatly appriciate any explanations. I am relativly new to this topic and eager to learn something. A ton of time googleing unfortunetly didn’t get me anywhere.
my setup:
Turris Omnia 2020,
ALLNET ALL4781V Mini GBIC, VDSL2 SFP modem
PPPoE connection using eth2.7 interface
Kernel Log:
[185439.021117] IPv6: ADDRCONF(NETDEV_UP): eth2.7: link is not ready
[185439.077750] mvneta f1034000.ethernet eth2: Link is Down
[185439.092007] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[185439.101743] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
[185454.432714] pppoe-wan: renamed from ppp0
System Log:
Jan 12 19:10:51 turris pppd[10383]: No response to 5 echo-requests
Jan 12 19:10:51 turris pppd[10383]: Serial link appears to be disconnected.
Jan 12 19:10:51 turris pppd[10383]: Connect time 85.7 minutes.
Jan 12 19:10:51 turris pppd[10383]: Sent 83970678 bytes, received 2786084432 bytes.
Jan 12 19:10:51 turris netifd: Network device ‘pppoe-wan’ link is down
Jan 12 19:10:51 turris netifd: Network alias ‘pppoe-wan’ link is down
Jan 12 19:10:51 turris netifd: Interface ‘wan6’ has link connectivity loss
Jan 12 19:10:51 turris netifd: Interface ‘wan6’ is now down
Jan 12 19:10:51 turris netifd: Interface ‘wan6’ is disabled
Jan 12 19:10:51 turris netifd: Interface ‘wan6’ is enabled
Jan 12 19:10:51 turris netifd: Interface ‘wan’ has lost the connection
Jan 12 19:10:51 turris netifd: Interface ‘wan6’ is disabled
Jan 12 19:10:57 turris pppd[10383]: Connection terminated.
Jan 12 19:10:57 turris pppd[10383]: Sent PADT
Jan 12 19:10:57 turris pppd[10383]: Modem hangup
Jan 12 19:10:57 turris pppd[10383]: Exit.
Jan 12 19:10:57 turris netifd: Interface ‘wan’ is now down
Jan 12 20:10:57 turris kernel: [178152.675125] IPv6: ADDRCONF(NETDEV_UP): eth2.7: link is not ready
Jan 12 19:10:57 turris netifd: Interface ‘wan’ is disabled
Jan 12 20:10:57 turris kernel: [178152.711223] mvneta f1034000.ethernet eth2: Link is Down
Jan 12 20:10:57 turris kernel: [178152.725142] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
Jan 12 20:10:57 turris kernel: [178152.733282] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
Jan 12 19:10:57 turris netifd: Interface ‘wan’ is enabled
Jan 12 19:10:57 turris netifd: Interface ‘wan’ is setting up now
Jan 12 19:10:57 turris insmod: module is already loaded - slhc
Jan 12 19:10:57 turris insmod: module is already loaded - ppp_generic
Jan 12 19:10:57 turris insmod: module is already loaded - pppox
Jan 12 19:10:57 turris insmod: module is already loaded - pppoe
Jan 12 19:10:57 turris netifd: wan (17517): ppp: warning: Sleeping for ‘10’ seconds
Jan 12 19:11:01 turris crond[17781]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jan 12 19:11:01 turris crond[17780]: (root) CMDEND (/usr/bin/rainbow_button_sync.sh)
Jan 12 19:11:07 turris pppd[17794]: Plugin rp-pppoe.so loaded.
Jan 12 19:11:07 turris pppd[17794]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
Jan 12 19:11:07 turris pppd[17794]: pppd 2.4.7 started by root, uid 0
Jan 12 19:11:22 turris pppd[17794]: Timeout waiting for PADO packets
Jan 12 19:11:22 turris pppd[17794]: Unable to complete PPPoE Discovery
Jan 12 19:11:22 turris pppd[17794]: Exit.
Jan 12 19:11:22 turris netifd: Interface ‘wan’ is now down
Jan 12 20:11:22 turris kernel: [178177.992478] IPv6: ADDRCONF(NETDEV_UP): eth2.7: link is not ready
Jan 12 19:11:22 turris netifd: Interface ‘wan’ is disabled
Jan 12 20:11:22 turris kernel: [178178.030488] mvneta f1034000.ethernet eth2: Link is Down
Jan 12 20:11:22 turris kernel: [178178.043680] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
Jan 12 20:11:22 turris kernel: [178178.051804] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
Jan 12 19:11:22 turris netifd: Interface ‘wan’ is enabled
Jan 12 19:11:22 turris netifd: Interface ‘wan’ is setting up now
Jan 12 19:11:22 turris insmod: module is already loaded - slhc
Jan 12 19:11:22 turris insmod: module is already loaded - ppp_generic
Jan 12 19:11:22 turris insmod: module is already loaded - pppox
Jan 12 19:11:22 turris insmod: module is already loaded - pppoe
Jan 12 19:11:22 turris netifd: wan (17853): ppp: warning: Sleeping for ‘10’ seconds
Jan 12 19:11:32 turris pppd[18127]: Plugin rp-pppoe.so loaded.
Jan 12 19:11:32 turris pppd[18127]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
Jan 12 19:11:32 turris pppd[18127]: pppd 2.4.7 started by root, uid 0
Jan 12 20:11:34 turris dnsmasq-dhcp[13596]: DHCPDISCOVER(br-lan)
Jan 12 20:11:34 turris dnsmasq-dhcp[13596]: DHCPOFFER(br-lan)
Jan 12 20:11:34 turris dnsmasq-dhcp[13596]: DHCPREQUEST(br-lan)
Jan 12 20:11:34 turris dnsmasq-dhcp[13596]: DHCPACK(br-lan)
Jan 12 19:11:35 turris /dhcp_host_domain_ng.py: DHCP update hostname []
Jan 12 19:11:35 turris /dhcp_host_domain_ng.py: Refresh kresd leases
Jan 12 19:11:47 turris pppd[18127]: Timeout waiting for PADO packets
Jan 12 19:11:47 turris pppd[18127]: Unable to complete PPPoE Discovery
Jan 12 19:11:47 turris pppd[18127]: Exit.
Jan 12 19:11:47 turris netifd: Interface ‘wan’ is now down
Jan 12 20:11:47 turris kernel: [178203.341154] IPv6: ADDRCONF(NETDEV_UP): eth2.7: link is not ready
Jan 12 19:11:47 turris netifd: Interface ‘wan’ is disabled
Jan 12 20:11:47 turris kernel: [178203.418312] mvneta f1034000.ethernet eth2: Link is Down
Jan 12 20:11:47 turris kernel: [178203.432744] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
Jan 12 20:11:48 turris kernel: [178203.441229] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
Jan 12 19:11:48 turris netifd: Interface ‘wan’ is enabled
Jan 12 19:11:48 turris netifd: Interface ‘wan’ is setting up now
Jan 12 19:11:48 turris insmod: module is already loaded - slhc
Jan 12 19:11:48 turris insmod: module is already loaded - ppp_generic
Jan 12 19:11:48 turris insmod: module is already loaded - pppox
Jan 12 19:11:48 turris insmod: module is already loaded - pppoe
Jan 12 19:11:48 turris netifd: wan (18221): ppp: warning: Sleeping for ‘10’ seconds
Jan 12 19:11:58 turris pppd[18471]: Plugin rp-pppoe.so loaded.
Jan 12 19:11:58 turris pppd[18471]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
Jan 12 19:11:58 turris pppd[18471]: pppd 2.4.7 started by root, uid 0
Jan 12 19:12:01 turris crond[18486]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jan 12 19:12:01 turris crond[18487]: (root) CMD (/usr/sbin/logrotate -s /tmp/logrotate.state /etc/logrotate.conf)
Jan 12 19:12:01 turris crond[18485]: (root) CMDEND (/usr/sbin/logrotate -s /tmp/logrotate.state /etc/logrotate.conf)
Jan 12 19:12:01 turris crond[18484]: (root) CMDEND (/usr/bin/rainbow_button_sync.sh)
Jan 12 19:12:13 turris pppd[18471]: Timeout waiting for PADO packets
Jan 12 19:12:13 turris pppd[18471]: Unable to complete PPPoE Discovery
Jan 12 19:12:13 turris pppd[18471]: Exit.
Jan 12 19:12:13 turris netifd: Interface ‘wan’ is now down
Jan 12 20:12:13 turris kernel: [178228.710157] IPv6: ADDRCONF(NETDEV_UP): eth2.7: link is not ready
Jan 12 19:12:13 turris netifd: Interface ‘wan’ is disabled
Jan 12 20:12:13 turris kernel: [178228.766567] mvneta f1034000.ethernet eth2: Link is Down
Jan 12 20:12:13 turris kernel: [178228.782346] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
Jan 12 20:12:13 turris kernel: [178228.790449] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
Jan 12 19:12:13 turris netifd: Interface ‘wan’ is enabled
Jan 12 19:12:13 turris netifd: Interface ‘wan’ is setting up now
Jan 12 19:12:13 turris insmod: module is already loaded - slhc
Jan 12 19:12:13 turris insmod: module is already loaded - ppp_generic
Jan 12 19:12:13 turris insmod: module is already loaded - pppox
Jan 12 19:12:13 turris insmod: module is already loaded - pppoe
Jan 12 19:12:13 turris netifd: wan (18563): ppp: warning: Sleeping for ‘10’ seconds
Jan 12 19:12:23 turris pppd[18820]: Plugin rp-pppoe.so loaded.
Jan 12 19:12:23 turris pppd[18820]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
Jan 12 19:12:23 turris pppd[18820]: pppd 2.4.7 started by root, uid 0
Jan 12 19:12:33 turris pppd[18820]: PPP session is 3945
Jan 12 19:12:33 turris pppd[18820]: Connected to [] via interface eth2.7
Jan 12 20:12:33 turris kernel: [178249.175877] pppoe-wan: renamed from ppp0
Jan 12 19:12:33 turris pppd[18820]: Renamed interface ppp0 to pppoe-wan
Jan 12 19:12:33 turris pppd[18820]: Using interface pppoe-wan
Jan 12 19:12:33 turris pppd[18820]: Connect: pppoe-wan <–> eth2.7
Jan 12 19:12:33 turris pppd[18820]: PAP authentication succeeded
Jan 12 19:12:33 turris pppd[18820]: peer from calling number [] authorized
Jan 12 19:12:34 turris pppd[18820]: local IP address []
Jan 12 19:12:34 turris pppd[18820]: remote IP address []
Jan 12 19:12:34 turris pppd[18820]: primary DNS address []
Jan 12 19:12:34 turris pppd[18820]: secondary DNS address []
Jan 12 19:12:34 turris netifd: Network device ‘pppoe-wan’ link is up
Jan 12 19:12:34 turris netifd: Interface ‘wan6’ is enabled
Jan 12 19:12:34 turris netifd: Network alias ‘pppoe-wan’ link is up
Jan 12 19:12:34 turris netifd: Interface ‘wan6’ has link connectivity
Jan 12 19:12:34 turris netifd: Interface ‘wan6’ is setting up now
Jan 12 19:12:34 turris netifd: Interface ‘wan6’ is now up
Jan 12 19:12:34 turris netifd: Interface ‘wan’ is now up
Jan 12 19:12:34 turris firewall: Reloading firewall due to ifup of wan (pppoe-wan)
Jan 12 19:12:37 turris firewall: Reloading firewall due to ifup of wan6 (pppoe-wan)
I will try to get the ‘collecttd’ plugin running to check that in numbers. Judging from touching it it is hotter than I am comfortable with, but not screaming hot. So around 50°C I would guess.
I will try to change the AVM modem+router to modem only mode and deinstall the SFP, maybe this works so it could be an temp issue. But wouldn’t SFP modules almost always have this kind of problem, since they are passive cooled?
Before the disconnect message, the log always shows a message that crond has run the rainbow_button_sync.sh script. Try removing the rainbow file from /etc/crond.d. Restart turris and observe if the eth2 link disconnection continues. This solution helped me. Please report back if this solved your problem.
Same setup, loosing connection every ~20 Min. Any idea how to fix?
Turris Omnia 2020,
ALLNET ALL4781V Mini GBIC, VDSL2 SFP modem
[Sun Jan 8 04:10:32 2023] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[Sun Jan 8 04:10:32 2023] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
[Sun Jan 8 04:10:47 2023] mvneta f1034000.ethernet eth2: Link is Down
[Sun Jan 8 04:10:47 2023] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[Sun Jan 8 04:10:47 2023] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[Sun Jan 8 04:10:47 2023] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
[Sun Jan 8 04:11:03 2023] mvneta f1034000.ethernet eth2: Link is Down
[Sun Jan 8 04:11:03 2023] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[Sun Jan 8 04:11:03 2023] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[Sun Jan 8 04:11:03 2023] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
[Sun Jan 8 04:11:18 2023] mvneta f1034000.ethernet eth2: Link is Down
[Sun Jan 8 04:11:18 2023] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[Sun Jan 8 04:11:18 2023] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[Sun Jan 8 04:11:19 2023] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
[Sun Jan 8 04:31:56 2023] mvneta f1034000.ethernet eth2: Link is Down
[Sun Jan 8 04:31:56 2023] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[Sun Jan 8 04:31:56 2023] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[Sun Jan 8 04:31:56 2023] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
[Sun Jan 8 04:32:12 2023] mvneta f1034000.ethernet eth2: Link is Down
[Sun Jan 8 04:32:12 2023] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[Sun Jan 8 04:32:12 2023] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[Sun Jan 8 04:32:12 2023] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
[Sun Jan 8 04:32:27 2023] mvneta f1034000.ethernet eth2: Link is Down
[Sun Jan 8 04:32:27 2023] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[Sun Jan 8 04:32:27 2023] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[Sun Jan 8 04:32:28 2023] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
[Sun Jan 8 04:32:43 2023] mvneta f1034000.ethernet eth2: Link is Down
[Sun Jan 8 04:32:43 2023] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[Sun Jan 8 04:32:43 2023] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[Sun Jan 8 04:32:43 2023] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
[Sun Jan 8 04:32:59 2023] mvneta f1034000.ethernet eth2: Link is Down
[Sun Jan 8 04:32:59 2023] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[Sun Jan 8 04:32:59 2023] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[Sun Jan 8 04:32:59 2023] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
[Sun Jan 8 04:33:14 2023] mvneta f1034000.ethernet eth2: Link is Down
[Sun Jan 8 04:33:14 2023] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[Sun Jan 8 04:33:14 2023] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[Sun Jan 8 04:33:14 2023] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
[Sun Jan 8 04:33:30 2023] mvneta f1034000.ethernet eth2: Link is Down
[Sun Jan 8 04:33:30 2023] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[Sun Jan 8 04:33:30 2023] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[Sun Jan 8 04:33:30 2023] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
[Sun Jan 8 04:43:50 2023] mvneta f1034000.ethernet eth2: Link is Down
[Sun Jan 8 04:43:50 2023] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[Sun Jan 8 04:43:50 2023] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[Sun Jan 8 04:43:50 2023] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
[Sun Jan 8 04:55:12 2023] mvneta f1034000.ethernet eth2: Link is Down
[Sun Jan 8 04:55:12 2023] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[Sun Jan 8 04:55:12 2023] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[Sun Jan 8 04:55:12 2023] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
[Sun Jan 8 04:55:28 2023] mvneta f1034000.ethernet eth2: Link is Down
[Sun Jan 8 04:55:28 2023] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[Sun Jan 8 04:55:28 2023] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[Sun Jan 8 04:55:28 2023] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
[Sun Jan 8 05:17:08 2023] mvneta f1034000.ethernet eth2: Link is Down
[Sun Jan 8 05:17:08 2023] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[Sun Jan 8 05:17:08 2023] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[Sun Jan 8 05:17:08 2023] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
[Sun Jan 8 05:17:24 2023] mvneta f1034000.ethernet eth2: Link is Down
Hi,
Just to update on my issue, i switched back to AVM fritzbox because i couldn’t get the setup working. I am a bit disappointed with this thing but periodic loss of connection is not acceptable and I can’t see why it occurs.
Please keep your efforts updated in this thread if you find any solution. I am planning on switching ISP and trying it again at some point later this year despite my low hopes.
When I had some mild issues with PPPoE reconnects on my omnia some time ago, I checked the ‘force link’ checkbox for the interface in the ‘Advanced Settings’ tab for the wan interface. For my set-up with a bridged modem connected via ethernet that solved the issue, but it is not clear that our issues are related.
BTW did you check the temperature of the SFP module?
Also can you get any connection statistics for the DSL link from that modem? To rule out that DSL disconnects might be the root cause of the issue?
I understand the attraction of SFP modules, but inter-device compatibility is still a problem compared with e.g. PCIe or separate devices connected via ethernet.
Will check that “force link” option. Fingers crossed. I will report.
Where can i get DSL statistics like damping values and so on on a SFP module like this?
Couldn’t find anything.
No idea, I think one of these DSL SFP modules offers some proprietary software to get some diagnostic data, not sure about the Allnet model. (This is one reason, why I am sticking to an external DSL-modem where I can get better diagnostics from, the other main reasons for me are high price and high temperature and location*).
*) I located my modem directly at where the POTS line enters my apartment (which noticeably reduced noise and increased reliability of my DSL link) which is not the place where I want my WiFi router to sit, as it would result in uneven WiFi coverage and likely would require an additional AP at which point the power saving from using an SFP modem instead of a stand-alone modem would be wasted.
~2 hours now without disconnect. “Force link” was probably the solution.
Must have been a pppd driver issue. Found this in logs also, before disconnect:
Jan 9 07:13:40 router pppd[21541]: Timeout waiting for PADO packets
Jan 9 07:13:41 router pppd[21760]: Connected to f4:b5:2f:f0:8b:b9 via interface eth2.7
Jan 9 07:35:38 router pppd[22963]: Connected to f4:b5:2f:f0:8b:b9 via interface eth2.7
Jan 9 07:38:10 router pppd[23968]: Timeout waiting for PADO packets
Jan 9 07:38:11 router pppd[24190]: Connected to f4:b5:2f:f0:8b:b9 via interface eth2.7
Jan 9 07:40:41 router pppd[25182]: Connected to f4:b5:2f:f0:8b:b9 via interface eth2.7
Jan 9 13:28:08 router pppd[32478]: Timeout waiting for PADO packets
Jan 9 13:28:09 router pppd[32724]: Connected to f4:b5:2f:f0:8b:b9 via interface eth2.7
Jan 9 14:49:35 router pppd[32724]: cif6addr: ioctl(SIOCDIFADDR): No such address
Jan 9 14:49:57 router pppd[4810]: Timeout waiting for PADO packets
Jan 9 14:49:58 router pppd[5028]: Connected to f4:b5:2f:f0:8b:b9 via interface eth2.7
Jan 9 14:50:01 router pppd[5028]: cif6addr: ioctl(SIOCDIFADDR): No such address
Jan 9 15:17:13 router pppd[9488]: Timeout waiting for PADO packets
Jan 9 15:17:14 router pppd[9708]: Connected to f4:b5:2f:f0:8b:b9 via interface eth2.7
Jan 9 15:17:15 router pppd[9708]: cif6addr: ioctl(SIOCDIFADDR): No such address
Jan 9 15:19:46 router pppd[10833]: Timeout waiting for PADO packets
Jan 9 15:19:57 router pppd[11051]: Connected to f4:b5:2f:f0:8b:b9 via interface eth2.7
Jan 9 15:20:00 router pppd[11051]: cif6addr: ioctl(SIOCDIFADDR): No such address
looks like the SFP is running stable. also not getting too hot. despite of the high price happy i have found it to safe one extra box in my room. thumbs up.
and as of what i read the PADO timeout is caused by the ISP. a performance issue server side.
edit: nope, forced link doesn’t seem to help. can i adjungs the timeout for PADO packets?
A PADO timeout is terribly unspecific, all it tells you that for the PADI packet your PPPoE client sent it did not receive a response. That can be caused by your ISP, but if you e.g. disconnect the phone line from the modem at the appropriate time you will get the same error, also when you use the wrong VLAN. So in your case it can well be the ISP’s responsibility it is just that this will not generally be the case.
Not that I know of, maybe by patching the PPPoE client, but I have no idea what the PPPoE RFC require.
How do you measure that, and what exactly would be “too hot”?
to me “too hot” is if i can’t hold my finger on it for longer than 5 seconds. but thats not the case.
i don’t see a DSL desync when connection drops. so the problem should be somewhere in pppd, isn’t it?
edit: just checked, i have dsl sync problems. the sfp module is syncing every 30min - 2h. anything i can do? i contacted the vendor.
If you have access to a more conventional modem you could try to get some diagnostic data. I like @janh’s go-dsl a lot, but that is probably not working with the allnet.
If you can reproduce the issues with your ISP’s modem you could also contact their helpline (you can and probably also should do this right away, independent of your modem, but be prepared to hear things like ‘allnet not supported’).
Contecting the vendor is also a decent idea, as they might have some tricks for diagnosis?
I was using the BT Home Hub 5 router before. I had to test different DSL firmware until i found one which won’t disconnect for days and weeks. So i would say it’s no an ISP issue and i know they always say to use the router they send to me. So the only thing to fix is on my side or not at all.
From all i read in all threads the problem is not fixable so i will probably return the Allnet SFP module and get a standalone DSL modem or go back to my BT Home Hub router.
