Here is a new ebuild for SpeedTouch ADSL modems, born out of bug #89863 and http://gentoo-wiki.com/HOWTO_Speedtouch_modem Thanks to Kerin Millar for the firmware extraction commands, and guidance.
Created attachment 71602 [details] speedtouch-3.0.12.ebuild
Created attachment 71603 [details] README
Created attachment 71604 [details] adsl.sample-pppoatm
Created attachment 71605 [details] adsl.sample-pppoe
Created attachment 71606 [details] speedtch-hotplug-3
Created attachment 71607 [details] speedtch.usermap
Created attachment 71608 [details] speedtouch.confd-3
Created attachment 71609 [details] speedtouch.rc-pppoatm
Created attachment 71610 [details] speedtouch.rc-pppoe
Any particular reason why this ebuild should have nofetch restriction?
Good point - that's a remannt of my uncertainty about the license ( http://www.speedtouch.com/driver_upgrade_lx_3.0.1.2.htm ), and some half-thinking about the catch-22 situation of needing the Internet in order to set up Internet connectivity :) Hopefully the fetch restriction can be removed - I'm not sure how the license fits with Gentoo.
Lets put it this way: unless they send a "cease and desist" note, we will mirror their firmware. IANAL and really tired of the lawyer language of the agreement (do not do this or that and under no circumstances the R-E thing). now about the name of the package. I think net-dialup/speedtouch330 is the proper name, copied after their product. what do you think?
I prefer "speedtouch", same as the existing package. The ebuild supports several models, including the Ethernet-only model 510 ( http://www.speedtouch.com/prod510.htm ) currently being tested, hopefully: http://forums.gentoo.org/viewtopic-p-2836856.html It's then a natural version upgrade for the current speedtouch users.
I was under the impression that ADSL modems with Ethernet ports don't need any driver installed on the PC connected to it (for example Zyxel ADSL modems make ATM-Ethernet bridging internally, without help from outside). Isn't it so? What other products does this package support? As for PPPoE, you don't need anything else than net-dialup/ppp for making it work over an Ethernet device (see bug #53954).
Created attachment 71755 [details] speedtouch-usb-3.0.1.2.ebuild Unfortunately, my only experience with speedtouch modems is regarding USB, not Ethernet. For the Ethernet side, I set things up "blind" and untested, following e.g. http://www.linux-usb.org/SpeedTouch/gentoo/index.html - this seems to be a failure, so I've removed all mention of Ethernet from the ebuild and renamed it to "speedtouch-usb". For the USB models, there's a pretty picture at http://www.linux-usb.org/SpeedTouch/index.html - the old green model is affectionately named "Stingray", and it is *not* model 330. Its formal title was just "SpeedTouch USB". The silver and purple modems are different revisions of model 330 (see "Single User Products" section at http://www.speedtouch.com/supfaq.htm ). This ebuild (using the kernel module "speedtch") supports all 3 USB modems. Note that the following files are no longer needed: adsl.sample-pppoe, speedtouch.rc-pppoe
Created attachment 71756 [details] README Removed mention of PPPoE.
Created attachment 72142 [details] speedtouch-usb-3.0.1.2.ebuild Please try this version by using pppd baselayout net module found in bug #53954. As you can see, this version don't have a init script as I believe it would be redundant with the upcoming pppd net module. Consequently, speedtch-hotplug-3 should be adapted to use /etc/init.d/net.${iface} (where $iface prolly is ppp0), but it cannot be installed in /etc/hotplug because we can't possibly know what interface name will be choosed by user (right now is installed in docs dir). README file have to be rewritten as well and this time should be oriented on the remaining tasks not implemented by emerge --config speedtouch-usb, such as pppd net module configuration.
Created attachment 72368 [details, diff] speedtouch-usb-3.0.1.2.diff Yes, the new baselayout-1.12.0_pre9-r1 method works. I ran: mv /etc/ppp/peers/adsl /etc/ppp/options.ppp0 ln -sfn /etc/init.d/net.lo /etc/init.d/net.ppp0 rc-update add net.ppp0 default And added to /etc/conf.d/net: config_ppp0=( ppp ) link_ppp0=" " preup() { modprobe pppoatm modprobe speedtch } What's the purpose of link_ppp0? Running "/etc/init.d/net.ppp0 stop" causes my net.ath0 wireless interface to stop also (which has its own script in /etc/init.d/, and there is no mention of ath0 in /etc/conf.d/net). Enclosed is a patch for the ebuild.
(In reply to comment #18) > What's the purpose of link_ppp0? It should be the device over which PPP connection is established. On serial links is the serial port (e.g. /dev/ttyS0) and for PPPoE is the Ethernet interface name (e.g. eth0). I believe in your case is /dev/null (for some strange reason pppoatm.so plugin do not need a device to read from/write to). > Running "/etc/init.d/net.ppp0 stop" causes my net.ath0 wireless interface to > stop also (which has its own script in /etc/init.d/, and there is no mention of > ath0 in /etc/conf.d/net). I think baselayout expects that all /etc/init.d/net.* scripts to be symlinked to net.lo. Roy, could you explain this please?
(In reply to comment #19) > (In reply to comment #18) > > Running "/etc/init.d/net.ppp0 stop" causes my net.ath0 wireless interface to > > stop also (which has its own script in /etc/init.d/, and there is no mention of > > ath0 in /etc/conf.d/net). > > I think baselayout expects that all /etc/init.d/net.* scripts to be symlinked to > net.lo. Roy, could you explain this please? > Yes, all net.* should be linked to net.lo in /etc/init.d I cannot explain why net.ppp0 stop also net.ath0 Could the reporter please attach the complete conf.d/net to this bug please?
Oops, my problem was caused by having "need net" in /etc/init.d/net.ath0 (which is almost a circular dependency). Then I changed RC_NET_STRICT_CHECKING to "yes" in /etc/conf.d/rc. Changing the "need net" to "after net.lo", stops ath0 from being dragged down with all the other net dependencies when ppp0 is deliberately stopped :)
(In reply to comment #17) > As you can see, this version don't have a init script as I believe it would be > redundant with the upcoming pppd net module. Consequently, speedtch-hotplug-3 > should be adapted to use /etc/init.d/net.${iface} (where $iface prolly is > ppp0), but it cannot be installed in /etc/hotplug because we can't possibly > know what interface name will be choosed by user (right now is installed in > docs dir). Can't "${iface}" only vary between ppp0 and ppp9? Does the user actually have any influence over the number, aside from specifying a startup order for the ppp-using devices somehow? Presumably, all the other hotpluggable ppp-related devices all share this problem, along with what to put in /etc/hotplug/ - is there a standard solution with the new baselayout 1.12? I'm starting to miss the simplicity of having /etc/init.d/speedtouch. I've never seen a speedtouch startup script which *didn't* assume ppp0. > README file have to be rewritten I'll do that, once I've gotten a grip on the pppX issue :)
no, pppd will use the proper name for the interface. name of the interface will be given by the name of the script (e.g. ppp0 for /etc/init.d/net.ppp0). as for ppp0-9 range, I am not aware of such limitation. AFAIK you could very well set ppp999 as interface name.
Since the common model number for the modem is 330, the manual setup effort for users can be reduced by having the ebuild assume interface ppp330 - OK? The chances of a SpeedTouch user already having ppp330 set up are 1 in a squillion.
You miss the point. The name of the ppp interface is the user's choice. Besides, user could have 2 or more Speedtouch modems. The hotplug script could be installed only in docs dir, as an example of how you do it if you wanna have a hot pluggable DSL connection.
I'm not referring only to the hotplug script - the interface number's variability spoils the convenient setup of the ebuild, to the point where it's hardly worth having it. Why make the setup harder for the majority that have a single modem attached to a home PC, and couldn't care less what the ppp number is, as long as it works? For custom setups, they can go RTFM for baselayout, and http://gentoo-wiki.com/HOWTO_Speedtouch_modem - they would have to *anyway*, to even know what they're doing. So, assuming the unlikely scenario that the user actually cares what the ppp interface number is, what's the best method of having the user specify that number (rather than the default 330) to the ebuild?
Is it hard for a gentooer to properly configure its ppp interfaces, in very much the same way as any other kind of interface? To be clear, The Gentoo Way of setting network links is through baselayout. IMO, the upcoming baselayout is the best thing ever because unify all bits'n'pieces into one comprehensive human interface. This ebuild is welcomed because take the load off the users shoulders, but it can't substitute user nor do baselayout job. Judging after comment #18 you seem to get the idea of how a ppp should be configured. A readme/tutorial should give users only this kind of information, focused on how to setup their SpeedTouch modem. This type of documents usually assume user want to set ppp0 as interface name.
I've got net.ppp330 running fine for speedtouch, using baselayout-1.12.0_pre10-r1. /lib/rcscripts/net.modules.d/pppd contains two "eerror" references to "[0-9]", which I suppose should be changed to whatever the appropriate wildcard for "1 or more digits" is. The following files need to contain references (either in the filenames or the contents) to the PPP interface number: /etc/conf.d/net 'config_ppp330=( ppp )' and 'link_ppp330="/dev/null"' /etc/init.d/net.ppp330 filename /etc/ppp/options.ppp330 filename /etc/hotplug/usb/speedtch '/etc/init.d/net.ppp330 start' and '/etc/init.d/net.ppp330 stop' But, the ebuild cannot be told or assume what the number is (even using "--config"?), so the user has to perform the file renaming and editing after reading a big README? This is not user-friendliness, this is the concept of "choice" taken to extremes. It's a backwards step, compared to having /etc/init.d/speedtouch. Tell me why 330 is unacceptable, given that e.g. Debian just blindy assumes *ppp0* as the interface, and doesn't require the user to jump through hoops due to an interface number which 99% of the time he couldn't care less about? The SpeedTouch modem is for home users, *not* PCs likely to have multiple PPP interfaces. I thought ebuilds were supposed to have sensible defaults which will work for the majority of the target audience?
the pppd net module does the right thing - checks if name of the interface is ppp${number} where ${number} is something like [0-9]*. Agreed, it isn't error prone, but in bash you cannot specify "1 or more decimal digits" (at least I don't know how). Maybe the eerror messages aren't the best, but it is understandable by average user, while the more experienced ones will know that ppp interfaces could be more than 10. Please try not to use /etc/ppp/options.${iface} or /etc/ppp/options. The recommended way is using vars from /etc/conf.d/net (pppd_ppp0, plugins_ppp0, username_ppp0, password_ppp0, ...) If you really insist in setting the whole /etc/conf.d/net in "emerge --config speedtouch-usb", you could ask user what interface name does it prefer through "read" bash internal command. However, I wonder what you'll going to do when user will run emerge --config several times. For the record, I consider such feature a waste of time. I don't like usage of ppp330 because is meaningless and take the option away from the user (which I strongly believe Gentoo will never do). As for the sensible defaults, sure, all programs should work by default, but you cannot ask that for a network interface before you configure it first, do ya? The way I see it is put in speedtouch-usb the things needed to be done for having a working Speedtouch USB device and let peeps configure their own network link like all network connections, namely through baselayout's /etc/conf.d/net. With proper documentation, of course, which is why I asked you to rewrite README from a newly installed net-dialup/speedtouch-usb perspective.
Created attachment 73449 [details] speedtouch-usb-3.0.1.2.ebuild Please test this version using sys-apps/baselayout-1.12.0_pre11. You should use only /etc/conf.d/net for configuring the ppp0. Please don't use /etc/ppp/options or /etc/ppp/options.ppp0 at all. Note that you don't need to run modprobe pppoatm anymore. Also, if you have settings that you want to pass to pppoatm plugin, you should do it like this: plugins_ppp0=( "pppoa your_plugin_settings" ) When done, post here your ppp0 settings from /etc/conf.d/net.
It's working, aside from bug 113431 and bug 113378. So, manual configuration within /etc/ppp/ is no longer necessary. Here are my speedtouch lines in /etc/conf.d/net: config_ppp330=( "ppp" ) link_ppp330="/dev/null" plugins_ppp330=( "pppoa 0.38" ) pppd_ppp330=( "updetach" "lock" "debug" "defaultroute" ) username_ppp330=( "myusername@hg7.btclick.com" ) password_ppp330=( "mypassword" ) I added pppoatm and speedtch to /etc/modules.autoload.d/kernel-2.6, because "speedtch" requires "pppoatm" to be loaded first. The ebuild should have the "Check pppd support for PPPoA" line removed - it looks like it's telling the user to do something. Should the baselayout version in RDEPEND be changed to 1.12.0?
Hi, There is no need for symlinks, simply name firmwares speedtch-1.bin.0.00, speedtch-2.bin.0.00, speedtch-1.bin.2.00, etc.. Also KQD6_3.012 seems to not always work with 0.00 revision modems, but this older one will : http://download.ethomson.com/download/speedmgmt.tar.gz ( the mgmt.o file )
Also you should not use and depend on hotplug at all, and not use an init script ( only net.ppp0 )
Created attachment 75860 [details] speedtouch-usb-3.0.1.2.ebuild ( another approach ) another approach still need upgraded doc
With bug 117512 my /etc/conf.d/net configuration changes ("0.38" gets moved) to: config_ppp330=( "ppp" ) link_ppp330="/dev/null" plugins_ppp330=( "pppoa" ) pppd_ppp330=( "updetach" "lock" "debug" "defaultroute" "0.38") username_ppp330=( "myusername@hg7.btclick.com" ) password_ppp330=( "mypassword" ) That's great news about the symlinks not being required. It's preferable to use the existing handful of "dd" commands in the ebuild to extract the firmware, rather than have to download and compile an executable. I've not seen any half-decent evidence that the old mgmt.o file is ever required over KQD6, especially with kernel >=2.6.10. My two green frog modems (revision 0.00) both work fine with KQD6.
Yet more improvements to my config (tweaked 0.38 and removed lock), with the resolvement of bug 117512 config_ppp330=( "ppp" ) link_ppp330="/dev/null" plugins_ppp330=( "pppoa 0.38" ) pppd_ppp330=( "updetach" "debug" "defaultroute" ) username_ppp330=( "myusername@hg7.btclick.com" ) password_ppp330=( "mypassword" )
username and password aren't arrays. also, you should use simple quotas for avoiding problems with special bash characters (most notably $): username_ppp0='myusername@hg7.btclick.com' password_ppp0='mypassword'
Created attachment 79207 [details] speedtouch-usb-3.0.1.2.ebuild The ebuild is now much simpler :)
How about updating the README? It should contain only the information needed to setup the modem in the context of the new baselayout. Also, I think the ebuild should be renamed to speedtouch-firmware - the SRC_URI is really the firmware for the USB modem, not to mention the PV.
Will do. Sorry for the delay. "speedtouch-usb" is a good name because the firmware will only work on the *USB* Speedtouch modems (see clause 1 at http://www.speedtouch.com/driver_upgrade_lx_3.0.1.2.htm ). This helps to prevent confusion with people trying it on the Speedtouch Ethernet/wireless modems.
Created attachment 80819 [details] speedtouch-usb-3.0.1.2.ebuild Kernel 2.6.16-rc3 does not contain KOBJECT_UEVENT, so I've removed its check from the ebuild.
Created attachment 80820 [details] README Finally, here is the updated README.
several suggestions for the README file: - word wrap the entire file (use an editor for wrapping around column 72) - don't recommend 330 as PPP interface ID. users should use the smallest number available on their systems - VPI/VCI isn't really a configuration by country, but by ISP. Since it is impossible to put together all VPI/VCI settings of all the ISPs of the world, you should advise users to ask their provider about those settings. - you forgot to load the kernel module before starting ppp0 interface. add something like this: #if you compiled Speedtouch driver as a module, add following lines function preup() { if [ "$1" = "ppp0" ]; then modprobe speedtouch-module-name fi }
Created attachment 80882 [details] README Fixed README.
Created attachment 80910 [details, diff] speedtouch-1.3.1-r3.diff Here's a handy hint to add to the "old" speedtouch ebuild, when speedtouch-usb enters Portage.
I've submitted a modified version to the portage. Modifications are: - cleaned up dependencies which are also in the system. - removed baselayout-1.12 from dependency - even if README only explains how to use the driver with this particular version of baselayout, it doesn't mean it cannot be used without it. - moved kernel configuration check in pkg_postinst and use the non-fatal version of them. add the ATM_BR2684 config test, needed by PPPoE - added PPPoE test for user-space program (br2684ctl) - modified README to include installation instructions for PPPoE connections (I didn't test it though because I don't have the hardware). I also inter-blocked this package with net-dialup/speedtouch. Thanks for you contribution! I'm sorry it tooked that long, but package inclusions have the lowest priority in gentoo (we need to manage those that already are in the portage before commiting new ones) and the last couple of months were the most soliciting period of my life, both gentoo dev life and real life.
That's quite a few changes with *zero* warning. The reason this package is called speedtouch-usb is that it does *not* support pppoe - please re-submit my files *unaltered*. I am willing and able to test speedtouch-usb. Few others are. I think this is a chicken-and-egg situation - the first thing that home users need after booting into Linux with a Speedtouch modem, is an Internet connection.
what warnings? If I had doubts about my changes I would have ask you, but my changes are fine. A friend of mine tested net-dialup/speedtouch with PPPoE and I assure you, speedtouch modems + br2684ctl can work perfectly on PPPoE. The PPPoE part of the ebuild might change but will not go away. For testing the PPPoE method, you must have a ISP who use it and, of course, a SpeedTouch USB modem. Do you have such an environment?
Good job :d, but from my pov it's still not perfectly clean Keep in mind that hotplug is already obsolete ( usermap is useless ), and will be soon fully replaced by udev. Another point is that you recommend to modprobe modules in preup() while these modules are loaded automatically by udev ( or hotplug/coldplug ). Take a look on this report : http://bugs.gentoo.org/show_bug.cgi?id=119989. Last thing i noticed 'is about suggested pppd options; no need for "noaccomp nobsdcomp noccp nodeflate nopcomp novj novjccomp" because compression is auto-negociated at ppp session start Here's a Debian package i made ( supports both PPPoA and PPPoE ), it may help you : http://moigeeknevro.com/speedtouch-ng/files/1.2.3/
(In reply to comment #48) > For testing the PPPoE method, you must have a ISP who use it and, of course, a > SpeedTouch USB modem. Do you have such an environment? I only have PPPoATM. Has anyone actually tested PPPoE in speedtouch-usb before it went live? (In reply to comment #49) > Keep in mind that hotplug is already obsolete ( usermap is useless ) Thanks for the info. I confirm that hotplug is not required, with udev-086. mrness, please remove ${FILESDIR}/speedtch.usermap > Another point is that you recommend to modprobe > modules in preup() while these modules are loaded automatically by udev ( or > hotplug/coldplug ). I just tested it, and "pppoatm" was *not* automatically loaded, so the connection was not established. "speedtch" was automatically loaded. > no need for ... because compression is auto-negociated at ppp session start From my README: Some ISPs require compression to be disabled in order for the connection to work. Look at http://www.linux-usb.org/SpeedTouch/gentoo/index.html and search for "noacc". > Here's a Debian package i made ( supports both PPPoA and PPPoE ), it may help Cool. It mentions "sleep time" - sounds like it should use the option "passive" - see http://gentoo-wiki.com/HOWTO_Speedtouch_modem
Comment on attachment 71607 [details] speedtch.usermap Not needed with udev-086.
Comment on attachment 80910 [details, diff] speedtouch-1.3.1-r3.diff Is now live.
Created attachment 82540 [details, diff] speedtouch-usb-3.0.1.2.ebuild.diff Here is a cleanup patch to the live ebuild.
Created attachment 82541 [details, diff] README.diff Here is a cleanup patch to the live README.
(In reply to comment #50) > I only have PPPoATM. Has anyone actually tested PPPoE in speedtouch-usb before > it went live? As I said, my friend test it with net-dialup/speedtouch, but I don't see why shouldn't work with speedtouch-usb. The principle is the same: start your ATM link (done by loading the driver), start the RFC2468 bridge for creating the "virtual" Ethernet interface and run pppd in PPPoE mode. I've submitted following changes: - the README patch has been fully applied - ebuild patch has been partially applied (basically it was applied without the new atm useflag) I cannot abuse on useflags like that. In order to justify a new useflag, it needs to enable some kind of functionality that would be otherwise unavailable. In our case, no matter what useflags would be enabled, the functionality of the package will be still the same. The only thing that would be different are some warnings and errors displayed in postinst. The best way is to leave the package without pppoe or pppoa USE flags and leave the user interpret information displayed in postinst warnings/infos. I would say our users are intelligent enough to understand them (not really rocket science, isn't it).
Ah, I forgot about compression options. Short answer: I agree with Paul, those should be suggested in the README. Long answer: Even if they are negociated parameters, some ISPs would require you to not accept any kind of compression, while others will accept any compression you configure (this is from personal experience). While the compression is a good thing on dialup connections, on broadband any kind of compression does more bad than good. Besides, no one put a gun to user's head; it could use compression if it has a masochistic mind.
(In reply to comment #55) > In order to justify a new useflag "atm" is not a *new* use flag, it exists for net-dialup/ppp. Given that "atm" is necessary for me to use my modem anyway, I think it is *entirely* appropriate that "atm" is a USE flag in speedtouch-usb also. And, I don't want to see an "eerror" warning from the ebuild about pppoe, or any warning about pppoe at all, given that I'm using pppoatm :) Will you fully apply my patch?
Removing invalid dependency on bug #117512.
(In reply to comment #57) > "atm" is not a *new* use flag, it exists for net-dialup/ppp. Given that "atm" > is necessary for me to use my modem anyway, I think it is *entirely* > appropriate that "atm" is a USE flag in speedtouch-usb also. And, I don't want > to see an "eerror" warning from the ebuild about pppoe, or any warning about > pppoe at all, given that I'm using pppoatm :) Will you fully apply my patch? Yes, atm will be a *new* USE flag because there is no global USE flag called atm: mrness@alin ~ $ euse -i atm global use flags (searching: atm) ************************************************************ no matching entries found local use flags (searching: atm) ************************************************************ [+ C ] atm (net-dialup/ppp): Enables support for PPP over ATM (PPPoA) [+ C ] atm (sys-apps/iproute2): Add support for ATM qdisc manager As you can see, there are 2 atm local USE flags, with no connection between them. Also, for you to be happy we would need not one but 2 local USE flags, 'pppoa' and 'pppoe', which is hilarious if you think the same files will be installed no matter what combination of flags you use. I repeat myself here. The USE flag should only enable/disable optional functionality, not display different messages in postinst! This issue has been discussed over the time on gentoo-dev@g.o and IRC. Formerly, I made my own errors by using global USE flags as functionality filters - something like 'X? ( tcltk? ( dev-lang/tk ) )' - but I've got spanked and I've seen the light. Please leave this bug FIXED. You don't have a chance in convincing me otherwise.
(In reply to comment #59) > As you can see, there are 2 atm local USE flags, with no connection between > them. Also, for you to be happy we would need not one but 2 local USE flags, > 'pppoa' and 'pppoe', which is hilarious if you think the same files will be > installed no matter what combination of flags you use. I have never mentioned any other USE flag than "atm", which already exists. Whoever mentioned more than one USE flag for this ebuild? > I repeat myself here. The USE flag should only enable/disable optional > functionality, not display different messages in postinst! This issue has been > discussed over the time on gentoo-dev@g.o and IRC. I did not know that. But, to repeat, I do not want to see an "eerror" message regarding pppoe when I'm not even using pppoe! A bit of sanity regarding USE flags and error messages would be nice. Work *with* me, and tell me who determines the flawed policy so I can go beat on them rather than you :)
this particular policy is correct. what would you say if, just because you enabled atm, you will be forced to re-emerge the package (consequence of emerge -uDN world) to discover at the end that only the postinst messages were different, messages with no interest to you other than at initial setup? I am willing to make those messages more easy to read if you want, but you will have to do it without 'use atm'... and with PPPoE warn/info messages too (no discrimination between PPPoE and PPPoA).
(In reply to comment #61) > this particular policy is correct. what would you say if, just because you > enabled atm, you will be forced to re-emerge the package (consequence of > emerge -uDN world) to discover at the end that only the postinst messages were > different, messages with no interest to you other than at initial setup? > messages with no interest to you other than at initial setup I couldn't care less! I really, really, couldn't care less. I want the stupid computer to make sense. A computer that moans to me about pppoe (especially an "eerror"), when I'm not using pppoe and have the "atm" USE flag to prove it, is stupid. Computers should do what we ask, not throw stupid moans at us because they choose to ignore our USE flags. What do you think USE flags are for? Stop dodging my question - tell me who decides this policy, so I can bug them rather than you. I can't see what corruption you have made of my ebuild, until it is syncable. Do you think I enjoy seeing it corrupted? Yes I've kept this bug as fixed, because I'm close to giving up. Re-open this bug yourself, if you care about my contribution to this ebuild. You don't seem to understand that the "atm" USE flag is required, for the majority of people using this ebuild. It's REQUIRED. It's not optional. See the difference? Isn't the importantance of the "atm" USE flag obvious by now?
Hi thanks for the new package. I've been helping a collegue from poland who's a user of Net24 try to setup his modem. We had initially started building his gentoo system in a chroot on a working mandrake install after which I stage4 tarballed the filesystem which he later installed from local livecd.Were are currently in progress with testing the network setup. I've mostly used the README included with the speedtouch-usb package as a guide for setting up the net scripts but we've run into a few snags as it appears the syntax used in section b) pppoE preup() configuration is invalid of incorrect with the latest baselayout or bash release. --makepid is supposed to be --make-pidfile after which --exec should follow for the command. I can only relay what i've been offered from a less experienced but still agile user in poland who i'm sure would be extatic if someone has a solution for these errors. We had edited the start-stop-daemon syntax used for preup() in /etc/conf.d/net however the following errors resulted. Thanks in advance. /etc/conf.d/net:line644:syntax error unexpected token { /etc/conf.d/net:line644:"function preup() {" Below is the current revision we have in place follwed by the README examples for pppoe. function preup() { if [[ "$1" = "ppp0" ]] ; then modprobe -q speedtch # The number after "-c" corresponds with the Ethernet interface, # e.g. 0 for nas0. # Use "-e 0" for LLC mux or "-e 1" for VC mux. # The 2 numbers after "-a" represent the VPI & VCI of your ISP, and # they are separated by a dot. Choose here, or ask your ISP: # http://www.linux-usb.org/SpeedTouch/faq/index.html#q12 eval local nasifname=\$\{link_$1\} start-stop-daemon --start --pidfile /var/run/${nasifname}.pid --make-pidfile \ --exec br2684ctl -c ${nasifname#nas} -e 0 -a 8.35 fi } function postdown() { if [[ "$1" = "ppp0" ]] ; then eval local nasifname=\$\{link_$1\} start-stop-daemon --stop --pidfile /var/run/${nasifname}.pid fi } b) PPPoE configuration: + +config_ppp0=( 'ppp' ) # Runs /lib/rcscripts/net.modules.d/pppd +# The name of the Ethernet interface over which PPPoE links +link_ppp0='nas0' # Must correspond to the -c option of the br2684ctl utility +plugins_ppp0=( pppoe ) +# 'man pppd' shows other options. Compression is disabled because it is +# rarely taken advantage of, and may interfere with the connection. +# Add option 'usepeerdns' to populate /etc/ppp/resolv.conf +pppd_ppp0=( updetach debug defaultroute noaccomp nobsdcomp noccp + nodeflate nopcomp novj novjccomp ) +username_ppp0='username@isp.com' # E.g. 'fredbloggs@hg5.btclick.com' +password_ppp0='password' # ADSL password, assigned by your ISP + +# If the kernel modules are not built-in, then they must be loaded +# before starting the PPP daemon: +function preup() { + if [[ "$1" = "ppp0" ]] ; then + modprobe -q speedtch + # The number after "-c" corresponds with the Ethernet interface, + # e.g. 0 for nas0. + # Use "-e 0" for LLC mux or "-e 1" for VC mux. + # The 2 numbers after "-a" represent the VPI & VCI of your ISP, and + # they are separated by a dot. Choose here, or ask your ISP: + # http://www.linux-usb.org/SpeedTouch/faq/index.html#q12 + eval local nasifname=\$\{link_$1\} + start-stop-daemon --start --pidfile /var/run/${nasifname}.pid --makepid -- \ + br2684ctl -c ${nasifname#nas} -e 0 -a 0.38 + fi +} + +function postdown() { + if [[ "$1" = "ppp0" ]] ; then + eval local nasifname=\$\{link_$1\} + start-stop-daemon --stop --pidfile /var/run/${nasifname}.pid + fi +}
See forum: http://forums.gentoo.org/viewtopic-p-3260050.html#3260050
The mistakes in PPPoE configuration have been fixed in -r1 and were tested thanks to Smok <smok.pl@gmail.com>. Also, the noauth has been added to the reccomended pppd_ppp0 parameters.
