Re: no matching session in ng_pppoe.c 1.74.2.4? (RELENG_6)
On Sun, 09 Dec 2007 14:01:27 -0800 Julian Elischer [EMAIL PROTECTED] wrote: cpghost wrote: On Sun, 09 Dec 2007 11:13:13 -0800 Julian Elischer [EMAIL PROTECTED] wrote: --- manually restarting ppp(1), then: 17:10:47.306928 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x40C663C1] [Service-Name] 17:10:47.306939 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0xC06220C1] [Service-Name] we still have 2 sessions instead of 1, but there is less confusion so things sort themselves out. Just one more thing: If I remember correctly, sending two PADIs in quick succession was ppp's normal behaviour for *years* now (is it expected or required by the protocol? I don't know). I've always wondered why it was so. But that didn't cause any harm as it seemed one of the two PADO was picked up and eventually turned into a session. -cpghost. btw try mpd as well. So... I'm running net/mpd5 on that router for a few days now, and it managed 3 forced disconnects in a row and no session chaos at all, while ppp(8) would probably have initiated a lot of parallel sessions again but no connection. So up until now (but perhaps it's too early to be sure?), net/mpd5 is fine, while ppp(8) is not. Btw, I've compared the sources of ppp(8) from 2007-09-24/25 when it was still working, and 2007-11-30 when I've updated the router, and there's NO difference there at all. Whatever broke ppp(8), it was not ppp(8) but something else (I suspect ng_pppoe.c): maybe the code clean up exposed some hidden bug in ppp(8)? I hope ppp(8) will be fixed before 6.3-RELEASE; even though net/mpd5 is excellent and very snappy as well. ;-) Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no matching session in ng_pppoe.c 1.74.2.4? (RELENG_6)
cpghost wrote: On Sun, 09 Dec 2007 14:01:27 -0800 Julian Elischer [EMAIL PROTECTED] wrote: cpghost wrote: On Sun, 09 Dec 2007 11:13:13 -0800 Julian Elischer [EMAIL PROTECTED] wrote: --- manually restarting ppp(1), then: 17:10:47.306928 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x40C663C1] [Service-Name] 17:10:47.306939 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0xC06220C1] [Service-Name] we still have 2 sessions instead of 1, but there is less confusion so things sort themselves out. Just one more thing: If I remember correctly, sending two PADIs in quick succession was ppp's normal behaviour for *years* now (is it expected or required by the protocol? I don't know). I've always wondered why it was so. But that didn't cause any harm as it seemed one of the two PADO was picked up and eventually turned into a session. -cpghost. btw try mpd as well. So... I'm running net/mpd5 on that router for a few days now, and it managed 3 forced disconnects in a row and no session chaos at all, while ppp(8) would probably have initiated a lot of parallel sessions again but no connection. So up until now (but perhaps it's too early to be sure?), net/mpd5 is fine, while ppp(8) is not. Btw, I've compared the sources of ppp(8) from 2007-09-24/25 when it was still working, and 2007-11-30 when I've updated the router, and there's NO difference there at all. Whatever broke ppp(8), it was not ppp(8) but something else (I suspect ng_pppoe.c): maybe the code clean up exposed some hidden bug in ppp(8)? I hope ppp(8) will be fixed before 6.3-RELEASE; even though net/mpd5 is excellent and very snappy as well. ;-) mpd is also using ng_pppoe of course. Regards, -cpghost. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no matching session in ng_pppoe.c 1.74.2.4? (RELENG_6)
On Sun, 09 Dec 2007 14:02:50 -0800 Julian Elischer [EMAIL PROTECTED] wrote: Adding brian to CC list. Alexander Motin wrote: cpghost wrote: I think such behaviour can take place if ppp daemon for some reason don't waits for reply but closes session immediately after sending connect request. If it so it also explains original no matching session errors as for the answer received time session/hook can already be destroyed. Provide please your ppp configuration files and part of detailed log file (set log All) describing connection attempts. ppp.conf already sent. I don't have a 'set log All' turned on, but maybe the following logfile of the aborted session would help? http://www.cordula.ws/tests/ppp-tcpdump.txt Here is part of your logs which proves my assumption that it is ppp who creates numerous sessions: Dec 9 17:06:07 fw ppp[35265]: Phase: bundle: Establish Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: closed - opening Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: Connected! Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: opening - dial Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: dial - carrier Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: Disconnected! Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: carrier - hangup Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: Connect time: 0 secs: 0 octets in, 0 octets out Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: 7070012 packets in, 6467630 packets out Dec 9 17:06:07 fw ppp[35265]: Phase: total 0 bytes/sec, peak 0 bytes/sec on Sun Dec 9 17:06:07 2007 Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: hangup - closed Dec 9 17:06:07 fw ppp[35265]: Phase: bundle: Dead Dec 9 17:06:07 fw ppp[35265]: Phase: bundle: Establish Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: closed - opening Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: Connected! Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: opening - dial Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: dial - carrier Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: Disconnected! Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: carrier - hangup Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: Connect time: 0 secs: 0 octets in, 0 octets out Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: 7070012 packets in, 6467630 packets out Dec 9 17:06:07 fw ppp[35265]: Phase: total 0 bytes/sec, peak 0 bytes/sec on Sun Dec 9 17:06:07 2007 Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: hangup - closed Dec 9 17:06:07 fw ppp[35265]: Phase: bundle: Dead Dec 9 17:06:07 fw ppp[35265]: Phase: bundle: Establish For the some reason ppp logs Disconnected! message and terminates session (which is strange as it have not logged any message from ng_ppp node) just to initiate new without delay. Could you enable any more logs to understant why is it Disconnected!? Here's a new, more detailed log: http://www.cordula.ws/tests/ppp-tcpdump2.txt That's all I can do here. I guess it's up to Brian now... If you have some patches for ppp, I'd be happy to try them and report back. Thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no matching session in ng_pppoe.c 1.74.2.4? (RELENG_6)
On Thu, 6 Dec 2007 16:11:07 +0100 cpghost [EMAIL PROTECTED] wrote: On Thu, 06 Dec 2007 13:57:16 +0200 Alexander Motin [EMAIL PROTECTED] wrote: cpghost wrote: The problem is that the last mile carrier of the PPP provider that this router is attached to disconnects the ppp session forcibly once every 24h. Before the update, ppp would detect this and reconnect immediately. After the update, ppp doesn't recover gracefully from this anymore, but spits out on the console: ng_pppoe[5]: no matching session for hours, and tries to connect again every two minutes without success, until I manually stop and restart the userland ppp daemon (and then the connection is immediately restored with a new session). I've tried this for a few days now, and it is always the same: it's definitely not a problem on the provider's side: As soon as ppp restarts, it gets a new session without any problems and connects again. Since the last working sources were from 2007/09/25, and ng_pppoe.c was at rev. 1.74.2.3; and the new revision of ng_pppoe.c is now at 1.74.2.4; I'm suspecting that whatever was changed there could be the cause (because this no matching session is being logged from there). I have tested and unable to reproduce that myself with ppp - mpd or mpd - - mpd PPPoE connections. Actually I am not sure about any difference between reconnect and ppp restart. From the ng_pppoe node point of view it should be the same. Could you provide tcpdump output for connection tries from your Ethernet interface? Use -pes 0 options please. Will do; but I'll first have to wait 24h from now to get a forcibly disconnected session (I've just had to restart ppp again). All right, I've got a good tcpdump now: # tcpdump -i sis0 -n -pes 0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on sis0, link-type EN10MB (Ethernet), capture size 65535 bytes 17:06:08.400881 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0xC0C263C1] [Service-Name] 17:06:08.400891 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0xC0ED45C1] [Service-Name] 17:06:08.400898 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x40C263C1] [Service-Name] 17:06:08.400904 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x80CA63C1] [Service-Name] 17:06:08.400910 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x80C963C1] [Service-Name] 17:06:08.528227 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 66: PPPoE PADO [AC-Name DSSX43-erx] [Host-Uniq 0xC0C263C1] [Service-Name] [AC-Cookie ..7\t.K.,.!y.y.E] 17:08:08.488679 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x806320C1] [Service-Name] 17:08:08.488690 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x40D063C1] [Service-Name] 17:08:08.488696 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x00C063C1] [Service-Name] 17:08:08.488702 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x40CE63C1] [Service-Name] 17:08:08.488708 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x80EC45C1] [Service-Name] 17:08:08.552036 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 66: PPPoE PADO [AC-Name DSSX43-erx] [Host-Uniq 0x806320C1] [Service-Name] [AC-Cookie ..7\t.K.,.!y.y.E] 17:08:08.557191 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 66: PPPoE PADO [AC-Name DSSX43-erx] [Host-Uniq 0x40D063C1] [Service-Name] [AC-Cookie ..7\t.K.,.!y.y.E] 17:08:08.572971 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 66: PPPoE PADO [AC-Name DSSX43-erx] [Host-Uniq 0x00C063C1] [Service-Name] [AC-Cookie ..7\t.K.,.!y.y.E] 17:08:08.577148 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 66: PPPoE PADO [AC-Name DSSX43-erx] [Host-Uniq 0x40CE63C1] [Service-Name] [AC-Cookie ..7\t.K.,.!y.y.E] 17:08:08.581343 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 66: PPPoE PADO [AC-Name DSSX43-erx] [Host-Uniq 0x80EC45C1] [Service-Name] [AC-Cookie ..7\t.K.,.!y.y.E] 17:10:08.577488 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x80D063C1] [Service-Name] 17:10:08.577499 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x80C463C1] [Service-Name] 17:10:08.577505 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype
Re: no matching session in ng_pppoe.c 1.74.2.4? (RELENG_6)
cpghost wrote: On Thu, 6 Dec 2007 16:11:07 +0100 cpghost [EMAIL PROTECTED] wrote: On Thu, 06 Dec 2007 13:57:16 +0200 Alexander Motin [EMAIL PROTECTED] wrote: cpghost wrote: The problem is that the last mile carrier of the PPP provider that this router is attached to disconnects the ppp session forcibly once every 24h. Before the update, ppp would detect this and reconnect immediately. After the update, ppp doesn't recover gracefully from this anymore, but spits out on the console: ng_pppoe[5]: no matching session for hours, and tries to connect again every two minutes without success, until I manually stop and restart the userland ppp daemon (and then the connection is immediately restored with a new session). I've tried this for a few days now, and it is always the same: it's definitely not a problem on the provider's side: As soon as ppp restarts, it gets a new session without any problems and connects again. Since the last working sources were from 2007/09/25, and ng_pppoe.c was at rev. 1.74.2.3; and the new revision of ng_pppoe.c is now at 1.74.2.4; I'm suspecting that whatever was changed there could be the cause (because this no matching session is being logged from there). I have tested and unable to reproduce that myself with ppp - mpd or mpd - - mpd PPPoE connections. Actually I am not sure about any difference between reconnect and ppp restart. From the ng_pppoe node point of view it should be the same. Could you provide tcpdump output for connection tries from your Ethernet interface? Use -pes 0 options please. Will do; but I'll first have to wait 24h from now to get a forcibly disconnected session (I've just had to restart ppp again). All right, I've got a good tcpdump now: # tcpdump -i sis0 -n -pes 0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on sis0, link-type EN10MB (Ethernet), capture size 65535 bytes 17:06:08.400881 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0xC0C263C1] [Service-Name] 17:06:08.400891 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0xC0ED45C1] [Service-Name] 17:06:08.400898 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x40C263C1] [Service-Name] 17:06:08.400904 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x80CA63C1] [Service-Name] 17:06:08.400910 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x80C963C1] [Service-Name] why are we sending PADIs for 4 different sessions? what does ngctl list show? 17:06:08.528227 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 66: PPPoE PADO [AC-Name DSSX43-erx] [Host-Uniq 0xC0C263C1] [Service-Name] [AC-Cookie ..7\t.K.,.!y.y.E] they respond to the first one we sent. this info should now be sent the ppp daemon. 17:08:08.488679 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x806320C1] [Service-Name] 17:08:08.488690 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x40D063C1] [Service-Name] 17:08:08.488696 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x00C063C1] [Service-Name] 17:08:08.488702 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x40CE63C1] [Service-Name] 17:08:08.488708 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x80EC45C1] [Service-Name] hey these are 4 more new pppoe sessions making 8 Are they just accumlating from each try? maybe we are not cleaning up? 17:08:08.552036 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 66: PPPoE PADO [AC-Name DSSX43-erx] [Host-Uniq 0x806320C1] [Service-Name] [AC-Cookie ..7\t.K.,.!y.y.E] 17:08:08.557191 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 66: PPPoE PADO [AC-Name DSSX43-erx] [Host-Uniq 0x40D063C1] [Service-Name] [AC-Cookie ..7\t.K.,.!y.y.E] 17:08:08.572971 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 66: PPPoE PADO [AC-Name DSSX43-erx] [Host-Uniq 0x00C063C1] [Service-Name] [AC-Cookie ..7\t.K.,.!y.y.E] 17:08:08.577148 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 66: PPPoE PADO [AC-Name DSSX43-erx] [Host-Uniq 0x40CE63C1] [Service-Name] [AC-Cookie ..7\t.K.,.!y.y.E] 17:08:08.581343 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 66: PPPoE PADO [AC-Name DSSX43-erx] [Host-Uniq 0x80EC45C1] [Service-Name] [AC-Cookie ..7\t.K.,.!y.y.E] router has responded to 4 more.. they should all be reporting back to whatever started them. some retries.. I haven't looked at
Re: no matching session in ng_pppoe.c 1.74.2.4? (RELENG_6)
On Sun, 09 Dec 2007 11:13:13 -0800 Julian Elischer [EMAIL PROTECTED] wrote: cpghost wrote: On Thu, 6 Dec 2007 16:11:07 +0100 cpghost [EMAIL PROTECTED] wrote: On Thu, 06 Dec 2007 13:57:16 +0200 Alexander Motin [EMAIL PROTECTED] wrote: cpghost wrote: The problem is that the last mile carrier of the PPP provider that this router is attached to disconnects the ppp session forcibly once every 24h. Before the update, ppp would detect this and reconnect immediately. After the update, ppp doesn't recover gracefully from this anymore, but spits out on the console: ng_pppoe[5]: no matching session for hours, and tries to connect again every two minutes without success, until I manually stop and restart the userland ppp daemon (and then the connection is immediately restored with a new session). I've tried this for a few days now, and it is always the same: it's definitely not a problem on the provider's side: As soon as ppp restarts, it gets a new session without any problems and connects again. Since the last working sources were from 2007/09/25, and ng_pppoe.c was at rev. 1.74.2.3; and the new revision of ng_pppoe.c is now at 1.74.2.4; I'm suspecting that whatever was changed there could be the cause (because this no matching session is being logged from there). I have tested and unable to reproduce that myself with ppp - mpd or mpd - - mpd PPPoE connections. Actually I am not sure about any difference between reconnect and ppp restart. From the ng_pppoe node point of view it should be the same. Could you provide tcpdump output for connection tries from your Ethernet interface? Use -pes 0 options please. Will do; but I'll first have to wait 24h from now to get a forcibly disconnected session (I've just had to restart ppp again). All right, I've got a good tcpdump now: # tcpdump -i sis0 -n -pes 0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on sis0, link-type EN10MB (Ethernet), capture size 65535 bytes 17:06:08.400881 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0xC0C263C1] [Service-Name] 17:06:08.400891 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0xC0ED45C1] [Service-Name] 17:06:08.400898 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x40C263C1] [Service-Name] 17:06:08.400904 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x80CA63C1] [Service-Name] 17:06:08.400910 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x80C963C1] [Service-Name] why are we sending PADIs for 4 different sessions? what does ngctl list show? Right now, with the working connection: # ngctl list There are 6 total nodes: Name: ngctl53522Type: socketID: 02ec Num hooks: 0 Name: unnamed Type: socketID: 02eb Num hooks: 1 Name: unnamed Type: pppoe ID: 0005 Num hooks: 2 Name: sis2 Type: ether ID: 0003 Num hooks: 0 Name: sis1 Type: ether ID: 0002 Num hooks: 0 Name: sis0 Type: ether ID: 0001 Num hooks: 1 17:06:08.528227 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 66: PPPoE PADO [AC-Name DSSX43-erx] [Host-Uniq 0xC0C263C1] [Service-Name] [AC-Cookie ..7\t.K.,.!y.y.E] they respond to the first one we sent. this info should now be sent the ppp daemon. 17:08:08.488679 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x806320C1] [Service-Name] 17:08:08.488690 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x40D063C1] [Service-Name] 17:08:08.488696 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x00C063C1] [Service-Name] 17:08:08.488702 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x40CE63C1] [Service-Name] 17:08:08.488708 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x80EC45C1] [Service-Name] hey these are 4 more new pppoe sessions making 8 Are they just accumlating from each try? maybe we are not cleaning up? 17:08:08.552036 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 66: PPPoE PADO [AC-Name DSSX43-erx] [Host-Uniq 0x806320C1] [Service-Name] [AC-Cookie ..7\t.K.,.!y.y.E] 17:08:08.557191 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 66: PPPoE PADO [AC-Name DSSX43-erx] [Host-Uniq 0x40D063C1] [Service-Name] [AC-Cookie
Re: no matching session in ng_pppoe.c 1.74.2.4? (RELENG_6)
cpghost wrote: Could you provide tcpdump output for connection tries from your Ethernet interface? Use -pes 0 options please. Will do; but I'll first have to wait 24h from now to get a forcibly disconnected session (I've just had to restart ppp again). All right, I've got a good tcpdump now: # tcpdump -i sis0 -n -pes 0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on sis0, link-type EN10MB (Ethernet), capture size 65535 bytes 17:06:08.400881 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0xC0C263C1] [Service-Name] 17:06:08.400891 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0xC0ED45C1] [Service-Name] 17:06:08.400898 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x40C263C1] [Service-Name] Your host generates huge number of simultaneous session requests. Looking on different Host-Uniq values it should be different ng_pppoe sessions/hooks as Host-Uniq is actually pointer to the hook/session internal data and it stays persistent for all packets of the same session. So it looks that something creates those many hooks. I think such behaviour can take place if ppp daemon for some reason don't waits for reply but closes session immediately after sending connect request. If it so it also explains original no matching session errors as for the answer received time session/hook can already be destroyed. Provide please your ppp configuration files and part of detailed log file (set log All) describing connection attempts. PS: I am not ppp daemon expert, but quick code look shows that connection waiting can be configured with 'set cd ...' command. Setting 'set cd 0' gives results close to yours. Have you something like that in your configuration? -- Alexander Motin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no matching session in ng_pppoe.c 1.74.2.4? (RELENG_6)
On Sun, 09 Dec 2007 11:13:13 -0800 Julian Elischer [EMAIL PROTECTED] wrote: --- manually restarting ppp(1), then: 17:10:47.306928 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x40C663C1] [Service-Name] 17:10:47.306939 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0xC06220C1] [Service-Name] we still have 2 sessions instead of 1, but there is less confusion so things sort themselves out. Just one more thing: If I remember correctly, sending two PADIs in quick succession was ppp's normal behaviour for *years* now (is it expected or required by the protocol? I don't know). I've always wondered why it was so. But that didn't cause any harm as it seemed one of the two PADO was picked up and eventually turned into a session. -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no matching session in ng_pppoe.c 1.74.2.4? (RELENG_6)
cpghost wrote: If I remember correctly, sending two PADIs in quick succession was ppp's normal behaviour for *years* now (is it expected or required by the protocol? I don't know). I've always wondered why it was so. But that didn't cause any harm as it seemed one of the two PADO was picked up and eventually turned into a session. It is not required by protocol as I remember. ppp does not sends PADI itselt, it is done by ng_ppp node. And it retransmits packets with increasing time-out starting from 2 seconds. If you see many packets check their Host-Uniq values. -- Alexander Motin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no matching session in ng_pppoe.c 1.74.2.4? (RELENG_6)
On Sun, 09 Dec 2007 22:57:46 +0200 Alexander Motin [EMAIL PROTECTED] wrote: Your host generates huge number of simultaneous session requests. Looking on different Host-Uniq values it should be different ng_pppoe sessions/hooks as Host-Uniq is actually pointer to the hook/session internal data and it stays persistent for all packets of the same session. So it looks that something creates those many hooks. I think such behaviour can take place if ppp daemon for some reason don't waits for reply but closes session immediately after sending connect request. If it so it also explains original no matching session errors as for the answer received time session/hook can already be destroyed. Provide please your ppp configuration files and part of detailed log file (set log All) describing connection attempts. ppp.conf already sent. I don't have a 'set log All' turned on, but maybe the following logfile of the aborted session would help? http://www.cordula.ws/tests/ppp-tcpdump.txt PS: I am not ppp daemon expert, but quick code look shows that connection waiting can be configured with 'set cd ...' command. Setting 'set cd 0' gives results close to yours. Have you something like that in your configuration? Uh... I'm not sure I understand what you're asking for here? Thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no matching session in ng_pppoe.c 1.74.2.4? (RELENG_6)
cpghost wrote: On Sun, 09 Dec 2007 11:13:13 -0800 Julian Elischer [EMAIL PROTECTED] wrote: cpghost wrote: On Thu, 6 Dec 2007 16:11:07 +0100 cpghost [EMAIL PROTECTED] wrote: On Thu, 06 Dec 2007 13:57:16 +0200 Alexander Motin [EMAIL PROTECTED] wrote: cpghost wrote: The problem is that the last mile carrier of the PPP provider that this router is attached to disconnects the ppp session forcibly once every 24h. Before the update, ppp would detect this and reconnect immediately. After the update, ppp doesn't recover gracefully from this anymore, but spits out on the console: ng_pppoe[5]: no matching session for hours, and tries to connect again every two minutes without success, until I manually stop and restart the userland ppp daemon (and then the connection is immediately restored with a new session). I've tried this for a few days now, and it is always the same: it's definitely not a problem on the provider's side: As soon as ppp restarts, it gets a new session without any problems and connects again. Since the last working sources were from 2007/09/25, and ng_pppoe.c was at rev. 1.74.2.3; and the new revision of ng_pppoe.c is now at 1.74.2.4; I'm suspecting that whatever was changed there could be the cause (because this no matching session is being logged from there). I have tested and unable to reproduce that myself with ppp - mpd or mpd - - mpd PPPoE connections. Actually I am not sure about any difference between reconnect and ppp restart. From the ng_pppoe node point of view it should be the same. Could you provide tcpdump output for connection tries from your Ethernet interface? Use -pes 0 options please. Will do; but I'll first have to wait 24h from now to get a forcibly disconnected session (I've just had to restart ppp again). All right, I've got a good tcpdump now: # tcpdump -i sis0 -n -pes 0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on sis0, link-type EN10MB (Ethernet), capture size 65535 bytes 17:06:08.400881 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0xC0C263C1] [Service-Name] 17:06:08.400891 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0xC0ED45C1] [Service-Name] 17:06:08.400898 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x40C263C1] [Service-Name] 17:06:08.400904 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x80CA63C1] [Service-Name] 17:06:08.400910 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x80C963C1] [Service-Name] why are we sending PADIs for 4 different sessions? what does ngctl list show? Right now, with the working connection: # ngctl list There are 6 total nodes: Name: ngctl53522Type: socketID: 02ec Num hooks: 0 Name: unnamed Type: socketID: 02eb Num hooks: 1 Name: unnamed Type: pppoe ID: 0005 Num hooks: 2 Name: sis2 Type: ether ID: 0003 Num hooks: 0 Name: sis1 Type: ether ID: 0002 Num hooks: 0 Name: sis0 Type: ether ID: 0001 Num hooks: 1 17:06:08.528227 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 66: PPPoE PADO [AC-Name DSSX43-erx] [Host-Uniq 0xC0C263C1] [Service-Name] [AC-Cookie ..7\t.K.,.!y.y.E] they respond to the first one we sent. this info should now be sent the ppp daemon. 17:08:08.488679 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x806320C1] [Service-Name] 17:08:08.488690 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x40D063C1] [Service-Name] 17:08:08.488696 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x00C063C1] [Service-Name] 17:08:08.488702 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x40CE63C1] [Service-Name] 17:08:08.488708 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x80EC45C1] [Service-Name] hey these are 4 more new pppoe sessions making 8 Are they just accumlating from each try? maybe we are not cleaning up? 17:08:08.552036 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 66: PPPoE PADO [AC-Name DSSX43-erx] [Host-Uniq 0x806320C1] [Service-Name] [AC-Cookie ..7\t.K.,.!y.y.E] 17:08:08.557191 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 66: PPPoE PADO [AC-Name DSSX43-erx] [Host-Uniq 0x40D063C1] [Service-Name] [AC-Cookie ..7\t.K.,.!y.y.E] 17:08:08.572971 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 66: PPPoE PADO [AC-Name DSSX43-erx] [Host-Uniq 0x00C063C1] [Service-Name]
Re: no matching session in ng_pppoe.c 1.74.2.4? (RELENG_6)
cpghost wrote: On Sun, 09 Dec 2007 11:13:13 -0800 Julian Elischer [EMAIL PROTECTED] wrote: --- manually restarting ppp(1), then: 17:10:47.306928 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x40C663C1] [Service-Name] 17:10:47.306939 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0xC06220C1] [Service-Name] we still have 2 sessions instead of 1, but there is less confusion so things sort themselves out. Just one more thing: If I remember correctly, sending two PADIs in quick succession was ppp's normal behaviour for *years* now (is it expected or required by the protocol? I don't know). I've always wondered why it was so. But that didn't cause any harm as it seemed one of the two PADO was picked up and eventually turned into a session. -cpghost. btw try mpd as well. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no matching session in ng_pppoe.c 1.74.2.4? (RELENG_6)
On Sun, 09 Dec 2007 23:52:01 +0200 Alexander Motin [EMAIL PROTECTED] wrote: cpghost wrote: I think such behaviour can take place if ppp daemon for some reason don't waits for reply but closes session immediately after sending connect request. If it so it also explains original no matching session errors as for the answer received time session/hook can already be destroyed. Provide please your ppp configuration files and part of detailed log file (set log All) describing connection attempts. ppp.conf already sent. I don't have a 'set log All' turned on, but maybe the following logfile of the aborted session would help? http://www.cordula.ws/tests/ppp-tcpdump.txt Here is part of your logs which proves my assumption that it is ppp who creates numerous sessions: Dec 9 17:06:07 fw ppp[35265]: Phase: bundle: Establish Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: closed - opening Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: Connected! Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: opening - dial Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: dial - carrier Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: Disconnected! Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: carrier - hangup Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: Connect time: 0 secs: 0 octets in, 0 octets out Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: 7070012 packets in, 6467630 packets out Dec 9 17:06:07 fw ppp[35265]: Phase: total 0 bytes/sec, peak 0 bytes/sec on Sun Dec 9 17:06:07 2007 Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: hangup - closed Dec 9 17:06:07 fw ppp[35265]: Phase: bundle: Dead Dec 9 17:06:07 fw ppp[35265]: Phase: bundle: Establish Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: closed - opening Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: Connected! Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: opening - dial Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: dial - carrier Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: Disconnected! Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: carrier - hangup Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: Connect time: 0 secs: 0 octets in, 0 octets out Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: 7070012 packets in, 6467630 packets out Dec 9 17:06:07 fw ppp[35265]: Phase: total 0 bytes/sec, peak 0 bytes/sec on Sun Dec 9 17:06:07 2007 Dec 9 17:06:07 fw ppp[35265]: Phase: deflink: hangup - closed Dec 9 17:06:07 fw ppp[35265]: Phase: bundle: Dead Dec 9 17:06:07 fw ppp[35265]: Phase: bundle: Establish For the some reason ppp logs Disconnected! message and terminates session (which is strange as it have not logged any message from ng_ppp node) just to initiate new without delay. Could you enable any more logs to understant why is it Disconnected!? If you let me know which one to turn on: PPP ON fw set log +connect PPP ON fw show log Log: Log: CCP Chat Command Connect IPCP LCP Phase Tun Warning Error Alert Local: Warning Error Alert PPP ON fw I've briefly tried to turn on 'all' but since it's an active router but a slow box, I'd rather not log this for very long... :( it generates huge logs VERY fast. PPP ON fw set log all PPP ON fw show log Log: Async CBCP CCP Chat Command Connect Debug DNS Filter HDLC ID0 IPCP IPV6CP LCP LQM Phase Physical Radius Sync TCP/IP Timer Tun Warning Error Alert Local: Warning Error Alert PPP ON fw set log phase chat lcp ipcp ccp tun command PPP ON fw Should I try to re-connect with all enabled now? Of course, it will reset the 24h period... -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no matching session in ng_pppoe.c 1.74.2.4? (RELENG_6)
On Sun, 09 Dec 2007 14:01:27 -0800 Julian Elischer [EMAIL PROTECTED] wrote: cpghost wrote: On Sun, 09 Dec 2007 11:13:13 -0800 Julian Elischer [EMAIL PROTECTED] wrote: --- manually restarting ppp(1), then: 17:10:47.306928 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x40C663C1] [Service-Name] 17:10:47.306939 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0xC06220C1] [Service-Name] we still have 2 sessions instead of 1, but there is less confusion so things sort themselves out. Just one more thing: If I remember correctly, sending two PADIs in quick succession was ppp's normal behaviour for *years* now (is it expected or required by the protocol? I don't know). I've always wondered why it was so. But that didn't cause any harm as it seemed one of the two PADO was picked up and eventually turned into a session. -cpghost. btw try mpd as well. Never did before, but I'll definitely try it in a few days... ;) -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no matching session in ng_pppoe.c 1.74.2.4? (RELENG_6)
On Thu, 06 Dec 2007 13:57:16 +0200 Alexander Motin [EMAIL PROTECTED] wrote: cpghost wrote: The problem is that the last mile carrier of the PPP provider that this router is attached to disconnects the ppp session forcibly once every 24h. Before the update, ppp would detect this and reconnect immediately. After the update, ppp doesn't recover gracefully from this anymore, but spits out on the console: ng_pppoe[5]: no matching session for hours, and tries to connect again every two minutes without success, until I manually stop and restart the userland ppp daemon (and then the connection is immediately restored with a new session). I've tried this for a few days now, and it is always the same: it's definitely not a problem on the provider's side: As soon as ppp restarts, it gets a new session without any problems and connects again. Since the last working sources were from 2007/09/25, and ng_pppoe.c was at rev. 1.74.2.3; and the new revision of ng_pppoe.c is now at 1.74.2.4; I'm suspecting that whatever was changed there could be the cause (because this no matching session is being logged from there). I have tested and unable to reproduce that myself with ppp - mpd or mpd - - mpd PPPoE connections. Actually I am not sure about any difference between reconnect and ppp restart. From the ng_pppoe node point of view it should be the same. Could you provide tcpdump output for connection tries from your Ethernet interface? Use -pes 0 options please. Hi again, no luck this time: I just went through the 24h disconnect with tcpdump watching, but this time, ppp did reconnect flawlessly: [... packets belonging to ses 0x1d06 ..., then:] 16:03:28.367734 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 64: PPPoE PADT [ses 0x1d06] 16:03:28.368035 00:00:24:c2:45:74 00:90:1a:a0:15:b7, ethertype PPPoE D (0x8863), length 38: PPPoE PADT [ses 0x1d06] [Generic-Error session closed] 16:06:22.211545 00:00:24:c2:45:74 ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 32: PPPoE PADI [Host-Uniq 0x405B1AC1] [Service-Name] 16:06:22.383675 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 66: PPPoE PADO [AC-Name DSSX43-erx] [Host-Uniq 0x405B1AC1] [Service-Name] [AC-Cookie ..7\t.K.,.!y.y.E] 16:06:22.383871 00:00:24:c2:45:74 00:90:1a:a0:15:b7, ethertype PPPoE D (0x8863), length 66: PPPoE PADR [Host-Uniq 0x405B1AC1] [AC-Cookie ..7\t.K.,.!y.y.E] [AC-Name DSSX43-erx] [Service-Name] 16:06:22.503154 00:90:1a:a0:15:b7 00:00:24:c2:45:74, ethertype PPPoE D (0x8863), length 66: PPPoE PADS [ses 0xb6b] [Service-Name] [Host-Uniq 0x405B1AC1] [AC-Name DSSX43-erx] [AC-Cookie ..7\t.K.,.!y.y.E] 16:06:24.243677 00:00:24:c2:45:74 00:90:1a:a0:15:b7, ethertype PPPoE S (0x8864), length 36: PPPoE [ses 0xb6b] LCP (0xc021), length 16: LCP, Conf-Request (0x01), id 4, length 16 [... more LCP packets belonging to ses 0xb6b ...] So the PADT/PADI/PADO/PADR/PADS sequence is correct. Maybe the PADT got lost on its way to this box the last times? Would ng_pppoe.c handle this case gracefully? Anyway, I will monitor this a few more days with tcpdump and report back should a no matching session come up again. Thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no matching session in ng_pppoe.c 1.74.2.4? (RELENG_6)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 cpghost wrote: The problem is that the last mile carrier of the PPP provider that this router is attached to disconnects the ppp session forcibly once every 24h. Before the update, ppp would detect this and reconnect immediately. After the update, ppp doesn't recover gracefully from this anymore, but spits out on the console: ng_pppoe[5]: no matching session for hours, and tries to connect again every two minutes without success, until I manually stop and restart the userland ppp daemon (and then the connection is immediately restored with a new session). I've tried this for a few days now, and it is always the same: it's definitely not a problem on the provider's side: As soon as ppp restarts, it gets a new session without any problems and connects again. Since the last working sources were from 2007/09/25, and ng_pppoe.c was at rev. 1.74.2.3; and the new revision of ng_pppoe.c is now at 1.74.2.4; I'm suspecting that whatever was changed there could be the cause (because this no matching session is being logged from there). I have tested and unable to reproduce that myself with ppp - mpd or mpd - - mpd PPPoE connections. Actually I am not sure about any difference between reconnect and ppp restart. From the ng_pppoe node point of view it should be the same. Could you provide tcpdump output for connection tries from your Ethernet interface? Use -pes 0 options please. - -- Alexander Motin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHV+Oc0kCgngV3usoRAnZtAKCQ/7hW63Zli9UiytDK1xj8lNrsBQCffwhl 377pyCH24ytoR8tOnbtYqX8= =v+x0 -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no matching session in ng_pppoe.c 1.74.2.4? (RELENG_6)
On Thu, 06 Dec 2007 13:57:16 +0200 Alexander Motin [EMAIL PROTECTED] wrote: cpghost wrote: The problem is that the last mile carrier of the PPP provider that this router is attached to disconnects the ppp session forcibly once every 24h. Before the update, ppp would detect this and reconnect immediately. After the update, ppp doesn't recover gracefully from this anymore, but spits out on the console: ng_pppoe[5]: no matching session for hours, and tries to connect again every two minutes without success, until I manually stop and restart the userland ppp daemon (and then the connection is immediately restored with a new session). I've tried this for a few days now, and it is always the same: it's definitely not a problem on the provider's side: As soon as ppp restarts, it gets a new session without any problems and connects again. Since the last working sources were from 2007/09/25, and ng_pppoe.c was at rev. 1.74.2.3; and the new revision of ng_pppoe.c is now at 1.74.2.4; I'm suspecting that whatever was changed there could be the cause (because this no matching session is being logged from there). I have tested and unable to reproduce that myself with ppp - mpd or mpd - - mpd PPPoE connections. Actually I am not sure about any difference between reconnect and ppp restart. From the ng_pppoe node point of view it should be the same. Could you provide tcpdump output for connection tries from your Ethernet interface? Use -pes 0 options please. Will do; but I'll first have to wait 24h from now to get a forcibly disconnected session (I've just had to restart ppp again). Thanks for looking into this. ;) - -- Alexander Motin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
