Re: ppp vs mpd: ppp fails to keep connection, mpd works
I ran accross this anoying problem years ago when I upgraded to 4.11 I'm not sure if your problem is related to LQR, but these logs look familliar. In your default ppp.conf file add this: default: enable lqr set timeout 0 set lqrperiod 10 I'm not sure why they changed this from one version of PPP to the next, it made more sense to keep it on by default. - Original Message - From: "Vladimir Grebenschikov" <[EMAIL PROTECTED]> To: "freebsd-net" <[EMAIL PROTECTED]> Sent: Sunday, June 15, 2008 1:28 PM Subject: ppp vs mpd: ppp fails to keep connection, mpd works Hi I am trying to find why with same configuration ppp does not works with my CDMA modem (connected over usb) but mpd works. MPD log (it works as expected): ... [umodem0] link: UP event [umodem0] link: origination is remote [umodem0] LCP: Up event [umodem0] LCP: state change Starting --> Req-Sent [umodem0] LCP: phase shift DEAD --> ESTABLISH [umodem0] LCP: SendConfigReq #1 ACFCOMP PROTOCOMP ACCMAP 0x000a MRU 1500 MAGICNUM 04eb5958 MP MRRU 1600 MP SHORTSEQ ENDPOINTDISC [Magic] 41 a2 7a c0 29 08 7a c0 [umodem0] LCP: rec'd Configure Reject #1 link 0 (Req-Sent) MP MRRU 1600 MP SHORTSEQ [umodem0] LCP: SendConfigReq #2 ACFCOMP PROTOCOMP ACCMAP 0x000a MRU 1500 MAGICNUM 04eb5958 [umodem0] LCP: rec'd Configure Ack #2 link 0 (Req-Sent) ACFCOMP PROTOCOMP ACCMAP 0x000a MRU 1500 MAGICNUM 04eb5958 [umodem0] LCP: state change Req-Sent --> Ack-Rcvd [umodem0] LCP: rec'd Configure Request #8 link 0 (Ack-Rcvd) ACCMAP 0x AUTHPROTO CHAP MD5 MAGICNUM 43aeaeee [umodem0] LCP: SendConfigNak #8 AUTHPROTO PAP [umodem0] LCP: rec'd Configure Request #9 link 0 (Ack-Rcvd) ACCMAP 0x AUTHPROTO PAP MAGICNUM 43aeaeee [umodem0] LCP: SendConfigAck #9 ACCMAP 0x AUTHPROTO PAP MAGICNUM 43aeaeee [umodem0] LCP: state change Ack-Rcvd --> Opened [umodem0] LCP: phase shift ESTABLISH --> AUTHENTICATE [umodem0] LCP: auth: peer wants PAP, I want nothing [umodem0] PAP: using authname "mobile" [umodem0] PAP: sending REQUEST [umodem0] LCP: LayerUp [umodem0] PAP: rec'd ACK #1 [umodem0] LCP: authorization successful [umodem0] LCP: phase shift AUTHENTICATE --> NETWORK [skylink] setting interface ng0 MTU to 1500 bytes [skylink] up: 1 link, total bandwidth 28800 bps [skylink] IPCP: Up event [skylink] IPCP: state change Starting --> Req-Sent [skylink] IPCP: SendConfigReq #1 IPADDR 0.0.0.0 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [skylink] error writing len 20 frame to bypass: Network is down [skylink] IPCP: rec'd Configure Request #2 link 0 (Req-Sent) IPADDR 212.119.106.147 212.119.106.147 is OK [skylink] IPCP: SendConfigAck #2 IPADDR 212.119.106.147 [skylink] IPCP: state change Req-Sent --> Ack-Sent [skylink] rec'd unexpected protocol CCP on link 0, rejecting [skylink] IPCP: SendConfigReq #2 IPADDR 0.0.0.0 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [skylink] IPCP: rec'd Configure Reject #2 link 0 (Ack-Sent) COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [skylink] IPCP: SendConfigReq #3 IPADDR 0.0.0.0 [skylink] IPCP: rec'd Configure Nak #3 link 0 (Ack-Sent) IPADDR 92.36.111.152 92.36.111.152 is OK [skylink] IPCP: SendConfigReq #4 IPADDR 92.36.111.152 [skylink] IPCP: rec'd Configure Ack #4 link 0 (Ack-Sent) IPADDR 92.36.111.152 [skylink] IPCP: state change Ack-Sent --> Opened [skylink] IPCP: LayerUp 92.36.111.152 -> 212.119.106.147 [skylink] IFACE: Up event [skylink] setting interface ng0 MTU to 1500 bytes [skylink] exec: /sbin/ifconfig ng0 92.36.111.152 212.119.106.147 netmask 0x -link0 [skylink] exec: /sbin/route add 92.36.111.152 -iface lo0 [skylink] exec: /sbin/route add 0.0.0.0 212.119.106.147 [skylink] IFACE: Up event [skylink] rec'd unexpected protocol IP on link 0 [umodem0] NEW FRAME ERRS: FCS 1 RUNT 0 OVFL 0 Then it just works. But ppp, closes connection just after negotiation (log below). After pair of empty config requests. What may be wrong here ? Any hints will be very appreciated. Jun 15 20:03:54 vbook ppp[4771]: Phase: Using interface: tun0 Jun 15 20:03:54 vbook ppp[4771]: Phase: deflink: Created in closed state Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: default: ident user-ppp VERSION (built COMPILATIONDATE) Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: default: set speed 115200 Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: default: set dial ABORT BUSY ABORT NO\sCARRIER TIMEOUT 5"" AT OK-AT-OK ATE1Q0 OK \dATDT\T TIMEOUT 40 CONNECT Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: default: set timeout 0 Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: set log Phase Chat LCP IPCP CCP tun command Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: disable pred1 deflate deflate24 protocomp acfcomp shortseq vj Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: deny pred1 deflate deflate24 protocomp acfcomp shortseq vj Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: set speed 460800 Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: set timeout
Re: kern/124622: [rl] [patch] if_rl.ko bug fix: unknown device ID: 8039
Old Synopsis: if_rl.ko bug fix New Synopsis: [rl] [patch] if_rl.ko bug fix: unknown device ID: 8039 Responsible-Changed-From-To: gnats-admin->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jun 15 22:19:23 UTC 2008 Responsible-Changed-Why: Rescue this PR from the 'pending' category and assign. Note to submitter: your mailer is mangling your GNATS submissions. http://www.freebsd.org/cgi/query-pr.cgi?pr=124622 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mrtg peak on reboot / snmp-issue?
Sorry the blackberry is truncating your original mail, but yes I have noticed the same thing on my setup. In my case I am using a custom rrdtool perl script. While not a fix for the actual problem, my workaround has been to use a CDEF in my rrdgraph command to set the value to 0 if it exceeds a sane maximum. I'm not sure off hand if mrtg has a similar capability but you might be able to set a max value for the graph so at least it won't skew the graph and hide the rest of the data points. Another option is to use a custom script to collect the values by grabbing the data from snmp and then sanitizing them prior to outputting to the value. Regards, Josh On 6/15/08, Olivier Mueller <[EMAIL PROTECTED]> wrote: > Hello, > > Small but curious thing on my freebsd-based systems: when a > server is rebooted, it generates a peak (or "spike"?) on the > network mrtg for all interfaces (here just before 1 am): > http://8304.ch/om/stuff/mrtg_localhost_1-day.png > > It happens with both net-snmp and ucd-snmp, with a quite standard > mrtg installation (generated by cfgmaker). > > Do you have the same "issue" on your own servers? All I can add, is > that there is not such a high traffic after a reboot, and that it > doesn't happen on similar linux-based systems. > > Regards & a nice week to you, > Olivier > > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ppp vs mpd: ppp fails to keep connection, mpd works
Hi I am trying to find why with same configuration ppp does not works with my CDMA modem (connected over usb) but mpd works. MPD log (it works as expected): ... [umodem0] link: UP event [umodem0] link: origination is remote [umodem0] LCP: Up event [umodem0] LCP: state change Starting --> Req-Sent [umodem0] LCP: phase shift DEAD --> ESTABLISH [umodem0] LCP: SendConfigReq #1 ACFCOMP PROTOCOMP ACCMAP 0x000a MRU 1500 MAGICNUM 04eb5958 MP MRRU 1600 MP SHORTSEQ ENDPOINTDISC [Magic] 41 a2 7a c0 29 08 7a c0 [umodem0] LCP: rec'd Configure Reject #1 link 0 (Req-Sent) MP MRRU 1600 MP SHORTSEQ [umodem0] LCP: SendConfigReq #2 ACFCOMP PROTOCOMP ACCMAP 0x000a MRU 1500 MAGICNUM 04eb5958 [umodem0] LCP: rec'd Configure Ack #2 link 0 (Req-Sent) ACFCOMP PROTOCOMP ACCMAP 0x000a MRU 1500 MAGICNUM 04eb5958 [umodem0] LCP: state change Req-Sent --> Ack-Rcvd [umodem0] LCP: rec'd Configure Request #8 link 0 (Ack-Rcvd) ACCMAP 0x AUTHPROTO CHAP MD5 MAGICNUM 43aeaeee [umodem0] LCP: SendConfigNak #8 AUTHPROTO PAP [umodem0] LCP: rec'd Configure Request #9 link 0 (Ack-Rcvd) ACCMAP 0x AUTHPROTO PAP MAGICNUM 43aeaeee [umodem0] LCP: SendConfigAck #9 ACCMAP 0x AUTHPROTO PAP MAGICNUM 43aeaeee [umodem0] LCP: state change Ack-Rcvd --> Opened [umodem0] LCP: phase shift ESTABLISH --> AUTHENTICATE [umodem0] LCP: auth: peer wants PAP, I want nothing [umodem0] PAP: using authname "mobile" [umodem0] PAP: sending REQUEST [umodem0] LCP: LayerUp [umodem0] PAP: rec'd ACK #1 [umodem0] LCP: authorization successful [umodem0] LCP: phase shift AUTHENTICATE --> NETWORK [skylink] setting interface ng0 MTU to 1500 bytes [skylink] up: 1 link, total bandwidth 28800 bps [skylink] IPCP: Up event [skylink] IPCP: state change Starting --> Req-Sent [skylink] IPCP: SendConfigReq #1 IPADDR 0.0.0.0 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [skylink] error writing len 20 frame to bypass: Network is down [skylink] IPCP: rec'd Configure Request #2 link 0 (Req-Sent) IPADDR 212.119.106.147 212.119.106.147 is OK [skylink] IPCP: SendConfigAck #2 IPADDR 212.119.106.147 [skylink] IPCP: state change Req-Sent --> Ack-Sent [skylink] rec'd unexpected protocol CCP on link 0, rejecting [skylink] IPCP: SendConfigReq #2 IPADDR 0.0.0.0 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [skylink] IPCP: rec'd Configure Reject #2 link 0 (Ack-Sent) COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [skylink] IPCP: SendConfigReq #3 IPADDR 0.0.0.0 [skylink] IPCP: rec'd Configure Nak #3 link 0 (Ack-Sent) IPADDR 92.36.111.152 92.36.111.152 is OK [skylink] IPCP: SendConfigReq #4 IPADDR 92.36.111.152 [skylink] IPCP: rec'd Configure Ack #4 link 0 (Ack-Sent) IPADDR 92.36.111.152 [skylink] IPCP: state change Ack-Sent --> Opened [skylink] IPCP: LayerUp 92.36.111.152 -> 212.119.106.147 [skylink] IFACE: Up event [skylink] setting interface ng0 MTU to 1500 bytes [skylink] exec: /sbin/ifconfig ng0 92.36.111.152 212.119.106.147 netmask 0x -link0 [skylink] exec: /sbin/route add 92.36.111.152 -iface lo0 [skylink] exec: /sbin/route add 0.0.0.0 212.119.106.147 [skylink] IFACE: Up event [skylink] rec'd unexpected protocol IP on link 0 [umodem0] NEW FRAME ERRS: FCS 1 RUNT 0 OVFL 0 Then it just works. But ppp, closes connection just after negotiation (log below). After pair of empty config requests. What may be wrong here ? Any hints will be very appreciated. Jun 15 20:03:54 vbook ppp[4771]: Phase: Using interface: tun0 Jun 15 20:03:54 vbook ppp[4771]: Phase: deflink: Created in closed state Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: default: ident user-ppp VERSION (built COMPILATIONDATE) Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: default: set speed 115200 Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: default: set dial ABORT BUSY ABORT NO\sCARRIER TIMEOUT 5"" AT OK-AT-OK ATE1Q0 OK \dATDT\T TIMEOUT 40 CONNECT Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: default: set timeout 0 Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: set log Phase Chat LCP IPCP CCP tun command Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: disable pred1 deflate deflate24 protocomp acfcomp shortseq vj Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: deny pred1 deflate deflate24 protocomp acfcomp shortseq vj Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: set speed 460800 Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: set timeout 180 Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: enable dns Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: set device /dev/ttyU0 Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: set phone #777 Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: set dial ABORT BUSY ABORT NO\sCARRIER TIMEOUT 15 "" AT OK-AT-OK ATE1Q0 OK \dATDT\T TIMEOUT 40 CONNECT Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: set authname mobile Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: set authkey Jun 15 2
Re: mrtg peak on reboot / snmp-issue?
Olivier Mueller wrote: Hello, Small but curious thing on my freebsd-based systems: when a server is rebooted, it generates a peak (or "spike"?) on the network mrtg for all interfaces (here just before 1 am): http://8304.ch/om/stuff/mrtg_localhost_1-day.png This could happen if either the daemon fails to correctly provide ifCounterDiscontinuityTime or mrtg fails to correctly interpret sysUpTime and/or ifCounterDiscontinuityTime. It happens with both net-snmp and ucd-snmp, with a quite standard mrtg installation (generated by cfgmaker). Do you have the same "issue" on your own servers? All I can add, is that there is not such a high traffic after a reboot, and that it doesn't happen on similar linux-based systems. harti ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
mrtg peak on reboot / snmp-issue?
Hello, Small but curious thing on my freebsd-based systems: when a server is rebooted, it generates a peak (or "spike"?) on the network mrtg for all interfaces (here just before 1 am): http://8304.ch/om/stuff/mrtg_localhost_1-day.png It happens with both net-snmp and ucd-snmp, with a quite standard mrtg installation (generated by cfgmaker). Do you have the same "issue" on your own servers? All I can add, is that there is not such a high traffic after a reboot, and that it doesn't happen on similar linux-based systems. Regards & a nice week to you, Olivier ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/124609: [ipsec] [panic] ipsec 'remainder too big' panic with ping -s 3989
Synopsis: [ipsec] [panic] ipsec 'remainder too big' panic with ping -s 3989 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jun 15 14:01:36 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=124609 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Route messages
Paul wrote: Get these with GRE tunnel on FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #5: Sun May 11 19:00:57 EDT 2008 :/usr/obj/usr/src/sys/ROUTER amd64 But do not get them with 7.0-RELEASE Any ideas what changed? :) Wish there was some sort of changelog.. # of messages per second seems consistent with packets per second on GRE interface.. No impact in routing, but definitely impact in cpu usage for all processes monitoring the route messages. RTM_MISS is actually fairly common when you don't have a default route. Messages which get enqueued don't necessarily get delivered -- and very few processes actually listen to the routing socket actively like this, so I wouldn't worry about it. If it's a real concern for you then you could try hacking in a sysctl to tell the radix trie code not to issue RTM_MISS messages on the routing socket. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
