Lucent modem device, prism54 firmware, pppoe
September 09, 2008 —
BarryK
I'm confused. The docs in the source state that the correct device name is /dev/ttyLTM0 for the 2.6.kernel. For the old 2.4 kernel it is /dev/ttyLT0, but the makefile allowed ttyLT0 to be retained for the 2.6 kernel -- but that required an edit of 'Makefile' and I have not done this when building the module for 4.1.
But, rerwin says that the driver asks udevd to create /dev/ttySLTM0 ...very odd. Anyway, assuming that to be so, I have made relevant changes to the 'firmware tarball'.
As tempestuous has advised, I have modified a line in 'firmware.dep.2.6.25.16' to 'prism54_firmware:prism54.ko,p54pci.ko,p54usb.ko'. Note that I did not apply this modification to the 4.1retro build with the 2.6.21.7 kernel.
Comments
PppoeconfUsername: Alucinary
Hi, realise I have never posted before, but hope this helps: This connect package has worked wonders for me on my laptops - both on an old Dell Latitude LS with external Belkin Wireless usb dongle and on my main Dell Latitude D820 with an internal Intel Wireless card. In the previous version used in 4.0 I was unable to connect to my Wanadoo Broadband (using WPA security), but in the new version it was as simple as anything so am very happy :) Ta massively for Puppy!
Pppoeconf
Username: nohype
"Normally I don't use PPPOE because I use a DSL-router. But I can configure it as a DSL-modem. For testing I created a working rp-pppoe profile under Kanotix. But that doesn't work under 4.07. The profile I used for testing: noipdefault defaultroute replacedefaultroute hide-password #lcp-echo-interval 30 #lcp-echo-failure 4 noauth persist #mtu 1492 #persist #maxfail 0 #holdoff 20 plugin rp-pppoe.so nic-eth0 user "loginname" usepeerdns The pppd demon says something like unrecognized option "replacedefaultroute". -nohype
pppoe and roaring penguin
Username: happypuppy
"I actually prefer the old,FULL Roaring Penguin (not the one included in 4.0,but the official one with the GUI and bandwidth meter) The bandwith meter is so useful to me that I won't switch to any of the new pppoe config packages. If you keep the new pppoeconf package in 4.1beta I'll gladly test it as soon as 4.1 beta is released.
pppoe and roaring penguin
Username: gyle
">>I actually prefer the old,FULL Roaring Penguin (not the one included in 4.0,but the official one with the GUI and bandwidth meter) idem for me, Roaring Penguin always runs fine with my provider Orange (manual settings of the DNS required in my case) but the new pppoeconf package has never worked, from 4.0 to 4.07 . Cheers
Re: Pppoeconf
Username: BarryK
"Alunicary is reporting that it works, gyle is reporting that it doesn't ...but gyle, 4.00 does not have Pppoeconf, it has Roaring Penguin CLI with a small rough GUI I made up for it. Only recent alphas have Pppoeconf,and alpha7 has the latest with some bugfixes -- so, have you actually tested alpha7? If so, can you please give some details about how it is failing. If necessary, start 'pppoeconf' from a terminal window to get extra error information. Nohype, Pppoeconf has nothing to do with Roaring Penguin. I am asking for Pppoeconf to be tested.
Re: Pppoeconf
Username: gyle
">> the new pppoeconf package has never worked, from 4.0 to 4.07 . Sorry Barry, I was in a hurry. Yes from recent alpha, not 4.0, to puppy-4.1alpha7-k2.6.25.16-compromise. I tried some commands on the console after running the Wizard. (my choice to connect was "Internet by cable/DSL/wireless PPPOE..."). "Connection initiated. The DSL connection has been triggered. You can use the "plog" command...etc..." # plog bash: plog: command not found # pon dsl-provider /usr/sbin/pppd: In file /etc/ppp/peers/dsl-provider: unrecognized option 'replacedefaultroute' # poff -a /usr/bin/poff: No pppd is running. None stopped. # pppoeconf pppoe-discovery: Timeout waiting for PADO packets: Success run-parts /etc/network/if-pre-up.d ip addr add 127.0.0.1/8 dev lo ip link set lo up run-parts /etc/network/if-up.d run-parts /etc/network/if-pre-up.d run-parts /etc/network/if-up.d /usr/sbin/pppd: In file /etc/ppp/peers/dsl-provider: unrecognized option 'replacedefaultroute' ### my /etc/ppp/peers/dsl-provider file ### # Minimalistic default options file for DSL/PPPoE connections noipdefault defaultroute replacedefaultroute hide-password #lcp-echo-interval 30 #lcp-echo-failure 4 noauth persist #mtu 1492 #persist #maxfail 0 #holdoff 20 plugin rp-pppoe.so eth1 usepeerdns # user hidden by me user "xxxxxxxxxxx" my /etc/ppp/chap-secrets and pap-secret files are correct my /root/.etc/resolv.conf is empty It seems the connection with my provider is never established so DNS IP addresses can't be send. (I answered "yes" to add these addresses automatically in my resolv.conf file). The problem I have with the provider Orange is recurrent under Linux. It is not specific to Puppy. So I prefer to set the DNS by hand with Roaring Penguin, and to have a visual acknowledgment of the connexion. (2 or 3 seconds) Hope that helps Gyle
Re: Pppoeconf
Username: BarryK
"Gyle, thanks for the details. Unfortunately I only ever used PPPOE once, using Pppoeconf on a Ubuntu system and it worked. We just had to enter the username and password when it asked, and I don't recall having to enter anything else, it just worked and we were online. Well, I think that I will release 4.1retro-beta with both the Roaring Penguin CLI (as in 4.00) and Pppoeconf. From an earlier comment in this thread, Pppoeconf worked for that person. Maybe someone could take it onboard to find out why it doesn't work or others -- perhaps some more stuff needs to be brought in from Ubuntu -- like that plog.
Re: Pppoeconf
Username: gyle
"Thanks Barry, I don't know the effects for others, but in the case of the Orange ISP pppoeconf works fine if "replacedefaultroute", line 48, is disabled. #replacedefaultroute ==> /etc/resolv.conf has the DNS. This turnaround works only if the /etc/ppp/peers/dsl-provider file doesn't exist yet. If it exist from an old config where "replacedefaultroute" is enabled, it is not modified by pppoeconf. BTW the pppoeconf of the Debian 40r4a-kde-i386 works fine with "replacedefaultroute" enabled... I tried a patch without success.
Tags: puppy