[prev in list] [next in list] [prev in thread] [next in thread]
List: leaf-user
Subject: Re: [leaf-user] pppd vs "Fatal signal 11" @ 3.1.1b2 (incl pppd
From: "groups, freeman" <freeman_groups () reason ! dyndns ! org>
Date: 2009-03-31 22:46:33
Message-ID: 49D29D49.5050101 () reason ! dyndns ! org
[Download RAW message or body]
KP Kirchdoerfer wrote:
> Am Sonntag, 29. März 2009 18:09:53 schrieb groups, freeman:
>
>> Hi, working with the new 3.1.1b2 release.
>>
>> I am working with the floppy image in a pretty near-to-defaults setup,
>> just to try to get the pppd working (PPPoE actually).
>>
>> I'm having trouble getting the pppd to behave - in the syslog I'm
>> seeing, every time I try to cause a PPPoE connection, my attempt ending
>>
>> with:
>>
>>> Mar 29 12:55:54 firewall pppd[618]: Local IP address changed to
>>> 69.196.xxx.yyy
>>> Mar 29 12:55:54 firewall pppd[618]: Remote IP address changed to
>>> 206.248.xxx.yyy
>>> Mar 29 12:55:54 firewall pppd[618]: Fatal signal 11
>>>
>> [...]
>>
>> So I wonder first, is anyone else successfully using pppd (PPPoE) under
>> BuC 3.1.1b2?
>>
>> And does this 'Fatal signal 11' indicate maybe a problem with the
>> executable, or compile options?
>>
> I have no idea; but I'm running pppd and pppoe without pb's.
>
Ok, thx for the feedback - it looks like me or my setup?!
> From where do you get the 10.x adresses?
>
They seem to be what pppd assigns as the default@startup ip address if
the ppp connection is a "demand" connection, until pppd has received an
IP addy from upstream.
=-=-=-=-
Let me update on my testing:
- I had some bad/missing settings for my PPP setup that seemed to be the
cause of all of my grief *except* "Fatal signal 11".
- pppd tip: include the option:
dump
in dsl-provider file and in one of the logfiles you'll get pppd's
interpretation of what options it's seeing (it seeks options from a few
files and identifies which options from which files). This is how I came
to observe the difference between my old, working 3.0b2 setup, versus
this new one.
- pppd tip: do that logging of the 'dump'ed options from within the
init-invoked pppd (i.e. don't use 'pppd call dsl-provider' from the
shell to see what options are active - I noticed discrepancies in the
listed options depending on how pppd was being invoked).
- pppd tip: In 3.0b2 some of my options that were placed in the 'ppp'
options file (/etc/ppp/options) did not get recognized under 3.1.1b2 so
I had to move them to the pppoe options file (/etc/ppp/peers/provider)
to get respect?!?!
So what I have now is an identical set of pppd options in my testing of
3.1.1b2 as to my working 3.0b2 and I still have one showstopper prob
left, the Fatal signal 11.
My LCP & IPCP transactions all happen nice (PAD*, IPCP reqs, acks, naks)
and I get assigned proper ip addy for dns1, dns2, my_ip and remote_ip,
then boom. From ppp.log:
> Mar 30 11:18:14 fw pppd[631]: local IP address 206.248.xxx.yyy
> Mar 30 11:18:14 fw pppd[631]: remote IP address 206.248.xxx.yyy
> Mar 30 11:18:14 fw pppd[631]: primary DNS address 206.248.154. 22
> Mar 30 11:18:14 fw pppd[631]: secondary DNS address 206.248.154.170
> Mar 30 11:18:14 fw pppd[631]: Fatal signal 11
> Mar 30 11:18:14 fw pppd[631]: Exit.
Noticeably absent is the 2 lines that should follow the 2ndary DNS line,
which under 3.0b2 says:
> Mar 30 09:30:29 R11 pppd[5793]: Script /etc/ppp/ip-up started
> (pid 25879)
> Mar 30 09:30:32 R11 pppd[5793]: Script /etc/ppp/ip-up finished
> (pid 25879), status = 0x0
In the pppd code, this is a wee walk between the line of code for the
2ndary DNS and the line of code for launching of the etc/ppp/ip-up
script where normally I would next see a log entry:
> if (go->dnsaddr[0])
> notice("primary DNS address %I", go->dnsaddr[0]);
> if (go->dnsaddr[1])
> notice("secondary DNS address %I", go->dnsaddr[1]);
> }
>
> reset_link_stats(f->unit);
>
> np_up(f->unit, PPP_IP);
> ipcp_is_up = 1;
>
> notify(ip_up_notifier, 0);
> if (ip_up_hook)
> ip_up_hook();
>
> /*
> * Execute the ip-up script, like this:
> * /etc/ppp/ip-up interface tty speed local-IP remote-IP
> */
> if (ipcp_script_state == s_down && ipcp_script_pid == 0) {
> ipcp_script_state = s_up;
> ipcp_script(_PATH_IPUP, 0);
> }
> }
- per the pppd code, the 'Fatal signal 11' /is/ in fact a SIGSEGV exception.
- Here's my minimal list of packages, sorted alpha:
> config 0.6 Rev 8 uClibc 0.9.28
> configdb
> dnsmasq 2.47 Rev 1 uClibc 0.9.28
> dropbear 0.52 Rev 1 uClibc 0.9.28
> etc 3.1.1 Rev 6 uClibc 0.9.28
> initrd 3.1.1 Rev 6 uClibc 0.9.28
> iptables 1.3.5 Rev 4 uClibc 0.9.28
> moddb
> modules 2.4.x Rev 5 uClibc 0.9.28
> ppp 2.4.4 Rev 3 uClibc 0.9.28
> pppoe 2.4.4 Rev 2 uClibc 0.9.28
> root 3.1.1 Rev 6 uClibc 0.9.28
> ulogd 1.24 Rev 5 uClibc 0.9.28
- Here are my pppd options, sorted alpha:
> asyncmap 0 # (from /etc/ppp/options)
> debug debug # (from /etc/ppp/peers/dsl-provider)
> defaultroute # (from /etc/ppp/peers/dsl-provider)
> dump # (from /etc/ppp/peers/dsl-provider)
> eth0 # (from command line)
> eth0 # (from command line)
> hide-password # (from /etc/ppp/peers/dsl-provider)
> ktune # (from /etc/ppp/peers/dsl-provider)
> lcp-echo-failure 3 # (from /etc/ppp/peers/dsl-provider)
> lcp-echo-interval 20 # (from /etc/ppp/peers/dsl-provider)
> maxfail 0 # (from /etc/ppp/peers/dsl-provider)
> mtu 1492 # (from /etc/ppp/peers/dsl-provider)
> name mylogin@my_isp.com # (from /etc/ppp/peers/dsl-provider)
> noauth # (from /etc/ppp/peers/dsl-provider)
> noipdefault # (from /etc/ppp/peers/dsl-provider)
> noipx # (from /etc/ppp/options)
> persist # (from /etc/ppp/peers/dsl-provider)
> plugin /usr/lib/pppd/rp-pppoe.so #(from /etc/ppp/peers/dsl-provider)
> usepeerdns # (from /etc/ppp/options)
- Here are my loaded modules, sorted alpha:
> Module Size Used by Not tainted
> 8390 5040 0 (unused)
> bridge 20524 0 (unused)
> crc32 2620 0 [sis900 8390]
> ip_conntrack 16548 2 [ipt_state ipt_helper ipt_conntrack
> ipt_REDIRECT ipt_MASQUERADE ip_nat_irc ip_nat_ftp iptable_nat
> ip_conntrack_irc ip_conntrack_ftp]
> ip_conntrack_ftp 3132 1
> ip_conntrack_irc 2484 1
> ip_nat_ftp 2152 0 (unused)
> ip_nat_irc 1704 0 (unused)
> ipt_MASQUERADE 1024 0 (unused)
> ipt_REDIRECT 480 0 (unused)
> ipt_conntrack 692 0 (unused)
> ipt_helper 400 0 (unused)
> ipt_ipp2p 5908 0 (unused)
> ipt_state 272 0 (unused)
> iptable_nat 14388 2 [ipt_REDIRECT ipt_MASQUERADE
> ip_nat_irc ip_nat_ftp]
> n_hdlc 5448 0 (unused)
> ppp_async 5644 0 (unused)
> ppp_generic 19672 0 [ppp_async pppoe pppox ppp_synctty]
> ppp_synctty 4288 0 (unused)
> pppoe 6280 0
> pppox 768 1 [pppoe]
> sis900 10976 1
> slhc 3844 0 [ppp_generic]
> softdog 1392 1
> tun 2944 0 (unused)
- Fearing that it might be a hardware issue I took the floppy and put it
onto a way different machine - (notably it has a different module for
the netcard) - same problem appeared.
- Thinking that maybe I didn't setup all the options for everything
correctly I used the configdb from my working 3.0b2 and copied it to the
floppy for 3.1.1b2 and got the same Fatal error.
=-=-=-=-
So for me, there's something definitely spooked about this pppd. Being
it is a SEG violation I'm inclined to guess that it's an unhealthy
compile or linking?
Does anyone have any ideas about how I might go about further working
this out? Would anyone want to email me a working configdb for 3.1.1b2
that succeeds with a PPPoE login?
Cheers & thx again for any info!
scott
> kp
------------------------------------------------------------------------------
------------------------------------------------------------------------
leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic