Telkom still do adsl resets

Okay.

Cross-reffing the two log files might cast some light on the problem :

Edited the IP addy of the machine as I don't want any script kiddiots to hammer on my ports...

The pppd log file :

Code: 
01:00:07 pppd LCP terminated by peer
01:00:07 pppd Connect time 109.1 minutes.
01:00:07 pppd Sent 8383 bytes, received 13203 bytes.
01:00:07 pppoe Session 17610 terminated -- received PADT from peer
01:00:07 pppoe Sent PADT
01:00:07 pppd Modem hangup
01:00:07 pppd Connection terminated.
01:00:07 pppd Using interface ppp0
01:00:07 pppd Connect: ppp0 <--> /dev/ttyp0
01:00:08 pppoe PPP session is 9208 (0x23f8)
01:00:11 pppd PAP authentication succeeded
01:00:11 pppd kernel does not support PPP filtering
01:00:13 pppd local IP address 165.146.43.xxx
01:00:13 pppd remote IP address 165.146.40.1
01:00:13 pppd primary DNS address 196.43.45.190
01:00:13 pppd secondary DNS address 196.43.46.190
02:12:24 pppd LCP terminated by peer
02:12:24 pppd Connect time 72.2 minutes.
02:12:24 pppd Sent 3142 bytes, received 7684 bytes.
02:12:24 pppoe Session 9208 terminated -- received PADT from peer
02:12:24 pppoe Sent PADT
02:12:24 pppd Modem hangup
02:12:24 pppd Connection terminated.
02:12:24 pppd Using interface ppp0
02:12:24 pppd Connect: ppp0 <--> /dev/ttyp0
02:12:39 pppoe PPP session is 48006 (0xbb86)
02:12:41 pppd PAP authentication succeeded
02:12:41 pppd kernel does not support PPP filtering
02:12:41 pppd local IP address 165.146.43.xxx
02:12:41 pppd remote IP address 165.146.40.1
02:12:41 pppd primary DNS address 196.43.45.190
02:12:41 pppd secondary DNS address 196.43.46.190
04:18:28 pppd LCP terminated by peer
04:18:28 pppd Connect time 125.8 minutes.
04:18:28 pppd Sent 10557 bytes, received 17046 bytes.
04:18:29 pppoe Session 48006 terminated -- received PADT from peer
04:18:29 pppoe Sent PADT
04:18:29 pppd Modem hangup
04:18:29 pppd Connection terminated.
04:18:29 pppd Using interface ppp0
04:18:29 pppd Connect: ppp0 <--> /dev/ttyp0
04:18:44 pppoe PPP session is 50849 (0xc6a1)
04:18:46 pppd PAP authentication succeeded
04:18:46 pppd kernel does not support PPP filtering
04:18:46 pppd local IP address 165.146.43.xxx
04:18:46 pppd remote IP address 165.146.40.1
04:18:46 pppd primary DNS address 196.43.45.190
04:18:46 pppd secondary DNS address 196.43.46.190
05:00:14 pppd LCP terminated by peer
05:00:14 pppd Connect time 41.5 minutes.
05:00:14 pppd Sent 3954 bytes, received 7615 bytes.
05:00:14 pppoe Session 50849 terminated -- received PADT from peer
05:00:14 pppoe Sent PADT
05:00:14 pppd Modem hangup
05:00:14 pppd Connection terminated.
05:00:14 pppd Using interface ppp0
05:00:14 pppd Connect: ppp0 <--> /dev/ttyp0
05:00:14 pppoe PPP session is 7933 (0x1efd)
05:00:18 pppd PAP authentication succeeded
05:00:18 pppd kernel does not support PPP filtering
05:00:18 pppd local IP address 165.146.43.xxx
05:00:18 pppd remote IP address 165.146.40.1
05:00:18 pppd primary DNS address 196.43.45.190
05:00:18 pppd secondary DNS address 196.43.46.190
06:00:11 pppd LCP terminated by peer
06:00:11 pppd Connect time 59.9 minutes.
06:00:11 pppd Sent 5454 bytes, received 8310 bytes.
06:00:11 pppoe Session 7933 terminated -- received PADT from peer
06:00:11 pppoe Sent PADT
06:00:11 pppd Modem hangup
06:00:11 pppd Connection terminated.
06:00:11 pppd Using interface ppp0
06:00:11 pppd Connect: ppp0 <--> /dev/ttyp0
06:00:11 pppoe PPP session is 39888 (0x9bd0)
06:00:14 pppd PAP authentication succeeded
06:00:14 pppd kernel does not support PPP filtering
06:00:14 pppd local IP address 165.146.43.xxx
06:00:14 pppd remote IP address 165.146.40.1
06:00:14 pppd primary DNS address 196.43.45.190
06:00:14 pppd secondary DNS address 196.43.46.190
07:00:07 pppd LCP terminated by peer
07:00:07 pppd Connect time 59.9 minutes.
07:00:07 pppd Sent 5335 bytes, received 8578 bytes.
07:00:07 pppoe Session 39888 terminated -- received PADT from peer
07:00:07 pppoe Sent PADT
07:00:07 pppd Modem hangup
07:00:07 pppd Connection terminated.
07:00:07 pppd Using interface ppp0
07:00:07 pppd Connect: ppp0 <--> /dev/ttyp0
07:00:07 pppoe PPP session is 6928 (0x1b10)
07:00:10 pppd PAP authentication succeeded
07:00:10 pppd kernel does not support PPP filtering
07:00:10 pppd local IP address 165.146.43.xxx
07:00:10 pppd remote IP address 165.146.40.1
07:00:10 pppd primary DNS address 196.43.45.190
07:00:10 pppd secondary DNS address 196.43.46.190
08:00:10 pppd LCP terminated by peer
08:00:10 pppd Connect time 60.0 minutes.
08:00:10 pppd Sent 5182 bytes, received 9998 bytes.
08:00:10 pppoe Session 6928 terminated -- received PADT from peer
08:00:10 pppoe Sent PADT
08:00:10 pppd Modem hangup
08:00:10 pppd Connection terminated.
08:00:10 pppd Using interface ppp0
08:00:10 pppd Connect: ppp0 <--> /dev/ttyp0
08:00:10 pppoe PPP session is 42451 (0xa5d3)
08:00:12 pppd PAP authentication succeeded
08:00:12 pppd kernel does not support PPP filtering
08:00:13 pppd local IP address 165.146.43.xxx
08:00:13 pppd remote IP address 165.146.40.1
08:00:13 pppd primary DNS address 196.43.45.190
08:00:13 pppd secondary DNS address 196.43.46.190

and the corresponding smoothie log entry :

Code: 
00:30:07 smoothwall System clock successfully updated; using server(s) ntp.cs.unp.ac.za ntp.public.otago.ac.nz ntp2b.audiotel.com.mx ntp.tuxfamily.net ntps.net4u.it.
01:00:07 smoothwall PPP has gone down on ppp0
01:00:13 smoothwall PPP has gone up on ppp0
01:00:20 smoothwall Dyanmic DNS ip-update: your IP is already up-to-date
01:30:05 smoothwall System clock successfully updated; using server(s) ntp.incaf.net ntp2a.mcc.ac.uk chronos1.umt.edu ntp1.demon.co.uk ntp-1.vt.edu.
02:12:24 smoothwall PPP has gone down on ppp0
02:12:42 smoothwall PPP has gone up on ppp0
02:12:47 smoothwall Dyanmic DNS ip-update: your IP is already up-to-date
02:30:16 smoothwall System clock successfully updated; using server(s) si.pool.ntp.org nl.pool.ntp.org ntp.waikato.ac.nz ntp1.sf-bay.org ch.pool.ntp.org.
03:30:12 smoothwall System clock successfully updated; using server(s) it.pool.ntp.org fr.pool.ntp.org ph.pool.ntp.org ntp.cs.strath.ac.uk ntp.linux.org.ve.
04:18:28 smoothwall PPP has gone down on ppp0
04:18:46 smoothwall PPP has gone up on ppp0
04:18:53 smoothwall Dyanmic DNS ip-update: your IP is already up-to-date
04:30:06 smoothwall System clock successfully updated; using server(s) tk1.ihug.co.nz ntp-1.cso.uiuc.edu tick.nap.com.ar es.pool.ntp.org info.cyf-kr.edu.pl.
05:00:14 smoothwall PPP has gone down on ppp0
05:00:18 smoothwall PPP has gone up on ppp0
05:00:24 smoothwall Dyanmic DNS ip-update: your IP is already up-to-date
05:30:08 smoothwall System clock successfully updated; using server(s) ca.pool.ntp.org tick.tanac.net tick.tanac.net tick.tanac.net pl.pool.ntp.org.
06:00:11 smoothwall PPP has gone down on ppp0
06:00:14 smoothwall PPP has gone up on ppp0
06:00:19 smoothwall Dyanmic DNS ip-update: your IP is already up-to-date
06:30:07 smoothwall System clock successfully updated; using server(s) ntp.waikato.ac.nz us.pool.ntp.org ntp.ucsd.edu ntp.shim.org time.nrc.ca.
07:00:07 smoothwall PPP has gone down on ppp0
07:00:10 smoothwall PPP has gone up on ppp0
07:00:16 smoothwall Dyanmic DNS ip-update: your IP is already up-to-date
07:30:08 smoothwall System clock successfully updated; using server(s) ntp2.kansas.net sundial.columbia.edu no.pool.ntp.org ntp.ourconcord.net no.pool.ntp.org.
08:00:10 smoothwall PPP has gone down on ppp0
08:00:13 smoothwall PPP has gone up on ppp0
08:00:19 smoothwall Dyanmic DNS ip-update: your IP is already up-to-date
08:30:07 smoothwall System clock successfully updated; using server(s) ntp.cpsc.ucalgary.ca louie.udel.edu tick.cs.unlv.edu nl.pool.ntp.org info.cyf-kr.edu.pl.
09:30:14 smoothwall System clock successfully updated; using server(s) dk.pool.ntp.org ntp.public.otago.ac.nz ntp.ip.ro at.pool.ntp.org fr.pool.ntp.org.
10:30:07 smoothwall System clock successfully updated; using server(s) ntp.cpsc.ucalgary.ca ntp2b.audiotel.com.mx gilbreth.ecn.purdue.edu it.pool.ntp.org ntp.tuxfamily.net.
11:30:08 smoothwall System clock successfully updated; using server(s) ntp1.demon.co.uk zh2.ntp.carnet.hr ntp.incaf.net time.deakin.edu.au dk.pool.ntp.org.
12:30:05 smoothwall System clock successfully updated; using server(s) ntp0.cornell.edu ntp.shim.org ntp2b.audiotel.com.mx info.cyf-kr.edu.pl ntp1.demon.co.uk.
13:30:07 smoothwall System clock successfully updated; using server(s) ntp.cs.unp.ac.za ntp.public.otago.ac.nz ntp-1.vt.edu ntp2a.mcc.ac.uk ca.pool.ntp.org.
14:30:18 smoothwall System clock successfully updated; using server(s) ntp.cs.strath.ac.uk at.pool.ntp.org ntp.karpo.cz ca.pool.ntp.org tick.cs.unlv.edu.
15:30:20 smoothwall System clock successfully updated; using server(s) ntp1.belbone.be ntp.waikato.ac.nz ntp.incaf.net au.pool.ntp.org tick.nap.com.ar.
 
Ok lets have a look at this log -

08:00:10 pppd Connect time 60.0 minutes.
07:00:07 pppd Connect time 59.9 minutes.
06:00:11 pppd Connect time 59.9 minutes.

The above shows you are connected bang on 1 hour, and are disconnected every hour.

05:00:14 pppd Connect time 41.5 minutes.

This one shows that you were connected for less than an hour, but were disconnected on the hour - there is no way an ISP will disconnect you on the hour - it is either session time related

04:18:28 pppd Connect time 125.8 minutes.

This shows you that there is definitely no 1 hour disconnects as here you are connected over 2 hours.

02:12:24 pppd Connect time 72.2 minutes.

Again, same as above.

It is weird. The next thing that I would look at is the audit trail. Maybe you have like an unusually large number of connections, which might be able to shed some light on it. Sometimes ISPs receive the stop record before the start record. That can play havoc as the ISP system sees a start record and believes that the session is alive, but really it is not.

However, my biggest area of suspicion would be the session that ended after 41.5 minutes. Why at 5am would your session drop? It is obviously not related to session time - 41.5 minutes makes no sense. It is too weird that it happened bang on 5am.

You are more than welcome to PM your username and I can have a look on the accounting database to see if there is any thing odd. (on monday) ;)
 
Telkom doesn't CARE if it does something 'against ICASA ruling"...

There have been numerous issues over the past few years where ICASA ruled ABC and Telkom happily carried on doing XYZ.

Resets no tbeing done by Telkom Internet? Possibly true, as Telkom Internet as an ISP are a bit separated from the actual DSlams at the exchanges, which *may* have be programmed to disconnect users every 24hrs or so.

The reason for that not being so much to tally stats for your cap usage, but to force your router to re-negotiate for a new IP address, so you couldn't host on a fixed IP at home. Obviously this is why Dynamic DNS was invented, to circumvent this nuisance. But that doesn't mean the 'resets' have been stopped.

My 1c worth.
 
My connections haven't been reset since maybe beginning of last month or whenever they were supposed to stop doing it. I have no issues getting a new dynamic IP each time I reconnect, nor do I have any major issues with my cap statistics. They are obviously a little behind atm but who cares. As long as I don't download at maximum the whole time.
 
scorpioso69 said:
There have been numerous issues over the past few years where ICASA ruled ABC and Telkom happily carried on doing XYZ.

Resets no tbeing done by Telkom Internet? Possibly true, as Telkom Internet as an ISP are a bit separated from the actual DSlams at the exchanges, which *may* have be programmed to disconnect users every 24hrs or so.

The reason for that not being so much to tally stats for your cap usage, but to force your router to re-negotiate for a new IP address, so you couldn't host on a fixed IP at home. Obviously this is why Dynamic DNS was invented, to circumvent this nuisance. But that doesn't mean the 'resets' have been stopped.

My 1c worth.
Click to expand...

I am not familiar with DSLAM technology, so how would it be possible to schedule resets at the dslam level?

It is too convenient that the above users' disconnects happen on the hour - at the time set by HIS clock - either there is a big conspiracy going on (/me waits for everyone to determine that that is the case) and both the ISP's servers and the user's machine have he exact time (possible, unlikely though) - or there is something happening on the machine on the hour. /etc/cron.d/ or /etc/cron.hourly or # crontab -l should shed some light if there is a job running on the hour which might be causing an issue.

Best way is to try with a different ISP if he has a username to test and see if it continues to happen.
 
@bonobo_slr
Seeing as we're on the topic, I see in the ADSL user statistics that my session is restarted every night, usually somewhere after midnight. Is this just for the day-by-day accounting graphs in the TI Tracker? Usually the modem still shows an uninterrupted connection time, so these are obviously not "resets".
Unfortunately, for some reason yesterday, my connection was reset because I was still on the local-only 165.146.* domain. I am now back on 41.242.*, which is a bit inconvenient cos I was downloading from local sites.
 
Let's examine some of those lines...
The_Librarian said:
The pppd log file :

Code: 
01:00:07 pppd LCP terminated by peer
01:00:07 pppoe Session 17610 terminated -- received PADT from peer

02:12:24 pppd LCP terminated by peer
02:12:24 pppoe Session 9208 terminated -- received PADT from peer

04:18:28 pppd LCP terminated by peer
04:18:29 pppoe Session 48006 terminated -- received PADT from peer

etc
Click to expand...

This is being caused by the PPPOE peer, namely TelkomInternet. No two ways about it.
 
SecretCode said:
Let's examine some of those lines...

This is being caused by the PPPOE peer, namely TelkomInternet. No two ways about it.
Click to expand...

That shows you how much you know then.

As I posted the radius config earlier indicating that there is no session timeout attribute.

Explain why everyone else is on for weeks on end then ?

plum...
 
fskmh said:
@bonobo_slr
Seeing as we're on the topic, I see in the ADSL user statistics that my session is restarted every night, usually somewhere after midnight. Is this just for the day-by-day accounting graphs in the TI Tracker? Usually the modem still shows an uninterrupted connection time, so these are obviously not "resets".
Unfortunately, for some reason yesterday, my connection was reset because I was still on the local-only 165.146.* domain. I am now back on 41.242.*, which is a bit inconvenient cos I was downloading from local sites.
Click to expand...

We no longer do day by day accounting. It is just displayed like that. Your usage on the tracker tool is correct up to an hour of your usage.

All I can think of is that there may be an idle attribute configured by SAIX. I will check on Monday to see what I can find.
 
bonobo_slr said:
Ok lets have a look at this log -

08:00:10 pppd Connect time 60.0 minutes.
07:00:07 pppd Connect time 59.9 minutes.
06:00:11 pppd Connect time 59.9 minutes.

The above shows you are connected bang on 1 hour, and are disconnected every hour.

05:00:14 pppd Connect time 41.5 minutes.

This one shows that you were connected for less than an hour, but were disconnected on the hour - there is no way an ISP will disconnect you on the hour - it is either session time related

04:18:28 pppd Connect time 125.8 minutes.

This shows you that there is definitely no 1 hour disconnects as here you are connected over 2 hours.

02:12:24 pppd Connect time 72.2 minutes.

Again, same as above.

It is weird. The next thing that I would look at is the audit trail. Maybe you have like an unusually large number of connections, which might be able to shed some light on it. Sometimes ISPs receive the stop record before the start record. That can play havoc as the ISP system sees a start record and believes that the session is alive, but really it is not.

However, my biggest area of suspicion would be the session that ended after 41.5 minutes. Why at 5am would your session drop? It is obviously not related to session time - 41.5 minutes makes no sense. It is too weird that it happened bang on 5am.

You are more than welcome to PM your username and I can have a look on the accounting database to see if there is any thing odd. (on monday) ;)
Click to expand...

What I see, when comparing the two logs, is that the resets originates from Telkom's side.

Code: 
02:12:24 pppoe Session 9208 terminated -- received PADT from peer

Code: 
02:12:24 smoothwall PPP has gone down on ppp0

Look at both logs again, and compare the two - there's a matching entry every hour on the hour.

And no, I did not edit the logs at all.
 
Here's my 2c worth. You might have checked it already but you never know:
- Is your router on the latest firmware
- Are you running the latest version of smooth
- Been a while since I used smooth - but I seem to remember you should schedule modem disconnects. Might be worth checking.


Found this on PADT - might help:

"The PPPoE Active Discovery Terminate (PADT) packet may be sent any time after a session is established to indicate that a PPPoE session has been terminated. It may be sent by either the host or the Access Concentrator. The DESTINATION_ADDR field is a unicast Ethernet address, the CODE field is set to 0xa7 and the SESSION_ID must be set to indicate which session is to be terminated. No tags are required. When a PADT is received, no further PPP traffic is allowed to be sent using that session. Even normal PPP termination packets must not be sent after sending or receiving a PADT. A PPP peer should use the PPP protocol itself to bring down a PPPoE session, but the PADT may be used when PPP cannot be used."


If all else fails you could run tcpdump to check where the disconnect is coming from. If its happening almost every hour it 'should' be fairly easy to catch.
 
bonobo_slr said:
That shows you how much you know then.

As I posted the radius config earlier indicating that there is no session timeout attribute.

Explain why everyone else is on for weeks on end then ?

plum...
Click to expand...

Would you care to enlighten me then? Regarding the pppd messages, not your view of what is happening inside the Telkom network? Thank you
 
SecretCode said:
Would you care to enlighten me then? Regarding the pppd messages, not your view of what is happening inside the Telkom network? Thank you
Click to expand...

You said it is Telkom Internet - no two ways about it. It is not Telkom Internet - it may be Telkom network - SAIX though...
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X