options in plugins?

I'm not sure if development on pppd is still active. It seems there are dozens of patches floating around and no upstream releases coming. Is it? Is this still the list to reach the upstream maintainers?

My question is whether there's a way to add options in a plugin. It seems the options list is a static array in plugins.c and plugins are loaded using dlsym. So unless I've missed some piece of infrastructure there isn't.

This is really unfortunate. My ultimate goal is to make the timeouts and retries in pppoe configurable just as they are for LCP. Currently they're set to 5s with unbounded exponential backoff and a max of 3 retries. That makes any temporary outage of even about 30s result in a complete failure.

I've hacked my personal copy to just retry every 5s forever but in an ideal world there would be a pppoe-restart and pppoe-maxfail just like lcp-restart and maxfail that could be set in the options or peers files.

But I don't see any reasonable way to do that without writing a lot of code. Nor am I clear whether such a patch would eventually get released. There's not much point in writing it just for myself -- I have my personal version hacked up for my use already. If development is dead then there's not much point in fixing this problem so generally.

greg

Hi Greg,

It is a very quiet list, I emailed someone last year to see if they taking patches and no response. Only monitoring this group couple weeks, seems little traffic, holiday season?

I wish I knew more of the pppoe <-> ADSL linkup as sometimes it takes a long time to establish a connection.

What scripts are you using? I'm using rp-pppoe to drive the connection, dunno what other ways there may be.

Scratch your itch, see if anyone else agrees with solution?

Perhaps some like me, mostly have working connection, sometimes problems, it aint too broke to worry about?

Another issue perhaps is that users may not be comfortable testing pppoe code on firewall box? Mine is running 2.4 kernel.

Cheers,
Grant.

hi,

yeah - you definately can add options in a plugin.

define a global static option_t array in your code:

e.g.

static option_t options[] = {{"optionname", o_string, &variable_name, "Description"},{"option2name", o_string, &variable2_name, "Description2"}, ... , {NULL}};

(o_string is the option type - there are some other ones - i forget which pppd source file to look in for the list and i don't have a copy of the source on hand atm. Also, there has to be a {NULL} entry to denote the end of the list)

then include an add_options(options); command in your plugin_init().

I think all you need include is pppd.h.

As for development, as far as i can tell, there is still development going on. I've been suscribed to this list for a few years and it is very low traffic. I'm guessing development is done somewhat as an exclusive club kinda thing.

hope this helps.

cheers,

David

Yes it is still active, although slow.

It'll do. :)

There are two ways a plugin can add options. The first is to call add_options, and the second is to set the_channel to point to the plugin's channel structure, which can have a pointer to an array of channel-specific options.

Just add them to the Options[] array in pppd/plugins/rp-pppoe/plugin.c.

Paul.

It's a fairly quiet list most of the time, as the code base is fairly mature.

There ought to be a FAQ on getting changes integrated with a given project, as it seems to be an obscure art. In short, just sending a bunch of diffs to the maintainers rarely (if ever) works. The sorts of things we want to know are:

- What exactly are you doing? Are you fixing a problem you saw or adding a new feature? If it's a problem, what are the symptoms and can it be reproduced? If it's a new feature, how does it fit in with existing features, and why were the existing features "not enough" to do what was needed?

- What testing have you done? Have you checked for memory leaks? Have you checked for compatibility with other implementations (if necessary)?

- Are you _sure_ this is the right fix, or are you just soliciting comments? Is there perhaps a bigger (and unfixed) problem lurking behind this one?

It's not that it's some sort of "club," but if we don't know who you are and what you're doing, it's not always clear what to do about the bags of bits we sometimes get.

As others have pointed out, this feature already exists. No need to scratch anything.

James Carlson                                 <[email protected]>