pppd vs "Fatal signal 11" @ 3.1.1b2

[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
(Is this 'Fatal signal 11' a SIGSEGV exception?)

There's other odd stuff that happens, but this seems to be the show
stopper. I do have the proper PPPoE-supporting modules loading up. When
my pppd daemon loads it reports early this odd entry, in logfile messages:
> Mar 29 12:55:52 firewall pppd[  618]: local  IP address 10.64.64.64
> Mar 29 12:55:52 firewall pppd[  618]: remote IP address 10.112.112.112
but then proceeds to have a fruitful negotiation & authentication and
gets assigned a proper dynamic, public IP addy as reported in daemon.log
(IPCP ConfAck id=0x2, IPCP ConfAck id=0x2d, etc) and as seen in the
syslog file, but then immediately gives the 'Fatal signal 11' error.

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?

Cheers & thx for any leads!
scott


------------------------------------------------------------------------------
------------------------------------------------------------------------
leaf-user mailing list: leaf-user@...
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

[KP Kirchdoerfer-2]

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
>
> (Is this 'Fatal signal 11' a SIGSEGV exception?)
>
> There's other odd stuff that happens, but this seems to be the show
> stopper. I do have the proper PPPoE-supporting modules loading up. When
>
> my pppd daemon loads it reports early this odd entry, in logfile messages:
> > Mar 29 12:55:52 firewall pppd[  618]: local  IP address 10.64.64.64
> > Mar 29 12:55:52 firewall pppd[  618]: remote IP address 10.112.112.112
>
> but then proceeds to have a fruitful negotiation & authentication and
> gets assigned a proper dynamic, public IP addy as reported in daemon.log
> (IPCP ConfAck id=0x2, IPCP ConfAck id=0x2d, etc) and as seen in the
> syslog file, but then immediately gives the 'Fatal signal 11' error.
>
> 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.

>From where do you get the 10.x adresses?

kp

------------------------------------------------------------------------------
------------------------------------------------------------------------
leaf-user mailing list: leaf-user@...
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

[groups, freeman]

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@...    # (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@...
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

[groups, freeman]

KP sent me a fix for this Fatal Error 11, which made the problem go away
for me, so just a heads up that there seems to be a known problem with
the PPP(oE) of 3.1.1b2.

Hat tip, of course, to KP :)

scott


------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
------------------------------------------------------------------------
leaf-user mailing list: leaf-user@...
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/