Re: mpd-netgraph problem.
Hi Archie, I've another, probably unrelated problem that has surfaced with mpd-netgraph in the last couple of months. The work-around is simple, which is why it's taken me so long to get around to raising the issue. I start mpd-netgraph at boot time, to create a VPN link to my office, with a script /usr/local/etc/rc.d/mpd. That used to work fine, and I haven't changed my mpd configuration at all in the mean time. For the last couple of months, though, this has resulted in no ng0 node, and a log that looks like: Feb 5 21:41:46 gurney mpd: mpd: pid 240, version 3.6 ([EMAIL PROTECTED] 18:28 19-Jan-2002) Feb 5 21:41:46 gurney mpd: [vpn] can't create socket node: Exec format error Feb 5 21:41:46 gurney mpd: mpd: local IP address for PPTP is xxx.xxx.xxx.xxx Feb 5 21:41:46 gurney mpd: [vpn] using interface Feb 5 21:41:46 gurney mpd: [vpn] IFACE: Open event Feb 5 21:41:46 gurney mpd: [vpn] IPCP: Open event Feb 5 21:41:46 gurney mpd: [vpn] IPCP: state change Initial --> Starting Feb 5 21:41:46 gurney mpd: [vpn] IPCP: LayerStart Feb 5 21:41:46 gurney mpd: [vpn] bundle: OPEN event in state CLOSED Feb 5 21:41:46 gurney mpd: [vpn] opening link "vpn"... Feb 5 21:41:46 gurney mpd: [vpn] link: OPEN event Feb 5 21:41:46 gurney mpd: [vpn] LCP: Open event Feb 5 21:41:46 gurney mpd: [vpn] LCP: state change Initial --> Starting Feb 5 21:41:46 gurney mpd: [vpn] LCP: LayerStart Feb 5 21:41:46 gurney mpd: [vpn] device: OPEN event in state DOWN Feb 5 21:41:46 gurney mpd: pptp0: connecting to yyy.yyy.yyy.yyy:1723 Feb 5 21:41:46 gurney mpd: [vpn] device is now in state OPENING Feb 5 21:41:46 gurney mpd: pptp0: connected to yyy.yyy.yyy.yyy:1723 Feb 5 21:41:46 gurney mpd: pptp0: attached to connection with yyy.yyy.yyy.yyy:1723 Feb 5 21:41:46 gurney mpd: pptp0-0: outgoing call connected at 14808325 bps Feb 5 21:41:46 gurney mpd: [vpn] PPTP call successful Feb 5 21:41:46 gurney mpd: [vpn] can't attach pptpgre node: Bad file descriptor Feb 5 21:41:46 gurney mpd: pptp0-0: clearing call Feb 5 21:41:46 gurney mpd: [vpn] can't shutdown "bypass.link0": Bad file descriptor Feb 5 21:41:46 gurney mpd: [vpn] device: DOWN event in state OPENING Feb 5 21:41:46 gurney mpd: [vpn] device is now in state DOWN Feb 5 21:41:46 gurney mpd: [vpn] link: DOWN event Feb 5 21:41:46 gurney mpd: [vpn] LCP: Down event Feb 5 21:41:46 gurney mpd: [vpn] device: OPEN event in state DOWN Feb 5 21:41:46 gurney mpd: [vpn] pausing 9 seconds before open Feb 5 21:41:46 gurney mpd: [vpn] device is now in state DOWN Feb 5 21:41:46 gurney mpd: pptp0-0: peer call disconnected res=zero? err=none Feb 5 21:41:46 gurney mpd: pptp0-0: killing channel Feb 5 21:41:46 gurney mpd: pptp0: closing connection with yyy.yyy.yyy.yyy:1723 Feb 5 21:41:46 gurney mpd: pptp0: killing connection with yyy.yyy.yyy.yyy:1723 With the section from "device: OPEN event in state DOWN" repeating until I stop mpd. It seems to be a race or dependancy problem, because the "fix" is to just wait for a couple of seconds after stopping mpd, then start it again, and then it works fine. After doing the manual stop/start sequence, the kernel mutters something like: Jan 30 09:29:03 gurney /kernel: bpf: ng0 attached Hints? Suggestions? -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: mpd-netgraph problem.
Hi Archie, On 2002.02.07 10:40 Archie Cobbs wrote: > Andrew Reilly writes: > > I've another, probably unrelated problem that has surfaced with > > mpd-netgraph in the last couple of months. The work-around is > > simple, which is why it's taken me so long to get around to > > raising the issue. > > > > I start mpd-netgraph at boot time, to create a VPN link to my > > office, with a script /usr/local/etc/rc.d/mpd. That used to > > work fine, and I haven't changed my mpd configuration at all in > > the mean time. > > > > For the last couple of months, though, this has resulted in no > > ng0 node, and a log that looks like: > > > > Feb 5 21:41:46 gurney mpd: mpd: pid 240, version 3.6 ([EMAIL PROTECTED] >18:28 19-Jan-2002) > > Feb 5 21:41:46 gurney mpd: [vpn] can't create socket node: Exec format error > > This error is probably coming from the KLD module code. I'd say so. > Try making sure the ng_socket(4) KLD is loaded before starting mpd, > or just compiling all your netgraph modules statically into your > kernel.. ? I've just done that: copied all of the option NETGRAPH_* lines from LINT into GURNEY, my kernel config file. There's probably stuff in the kernel that I don't need now (ng_frame_relay, for starters!), but (a) it didn't whinge, and (b) the MS-PPTP VPN link came straight up at re-boot. > As an experiment, you could try replacing the invocation of mpd > in /usr/local/etc/rc.d/mpd to something like 'ngctl ls' and see > if ngctl sees the same error. It did indeed. There has also been another couple of console messages at boot that might bear on the problem: Feb 7 15:20:16 gurney /kernel: module_register: module netgraph already exists! Feb 7 15:20:16 gurney /kernel: linker_file_sysinit "netgraph.ko" failed to register! 17 As you can see, these still happen, but now (probably because all of the modules are compiled in) it isn't causing a problem. This always happened, before the recent kernel config change, because I have always had "options NETGRAPH" (alone) in my kernel config. Well, I have since I started using mpd-netgraph. Presumably this is simple pilot-error: I should either have put all of the netgraph options into my kernel or none. But perhaps this indicates an error with one kldload being taken too strongly, and short-circuiting the loading of subsequent modules? -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: HEADS UP: ALTQ integration developer preview
On Sat, 2002-05-18 at 18:53, Terry Lambert wrote: > > Sending datagrams bigger than the MTU is a bad idea. > > I would be real tempted to drop the packets and send "don't fragment" > ICMP responses to beat up anyone who abused UDP by sending larger > than the MTU. > > I guess this is about Linux UDP NFS clients, in particular. Eh? Isn't the original, traditional and best NFS configuration 8k UDP packets? Sure worked fine that way on SunOS-4 those many years ago. (On LANs, of course. No one does NFS over the internet. I hope.) -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: MPD-3.11 MPPE key-breakage (was: mpd 3.11 doesn't send packets)
Hi Michael, Archie, On Tue, 2003-02-11 at 07:18, Michael Bretterklieber wrote: > Archie Cobbs wrote: > > > > Michael- did you test PPTP+MPPE, non-RADIUS, 128 bit, client side? > > Server side and client side may behave differently, etc. > The problem occured only if you are used mpd client side. > The new bund->msPassword was empty. I attached a patch wich should solve > the problem. And indeed it has. Thanks very much. I'm now running mpd-3.11+patch, and everything seems to be working as normal. Please let me know if there are logs that you would like to see, for verification or anything. Cheers, -- Andrew Reilly <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
