John,
Drivers MUST be compiled from the same kernel-header resources as the
kernel was compiled from. But other software functions need not be
exactly matched.
For example, martian_modem remains functional over a broad range of kernels.
RE:
Mar 23 22:44:36 localhost pppd[3760]: primary DNS address 195.40.1.36
Mar 23 22:44:36 localhost pppd[3760]: secondary DNS address 193.131.248.36
and cannot ping.
Make sure that ALL other COMM channels except loopback (lo).
Check that the DNS have been copied into /etc/resolv.conf
You may need to add to /etc/ppp/options a line
usepeerdns
and to /etc/wvdial.conf
AutoDNS = 1
On 3/23/07, John Pate <johnny@xxxxxxxxxx> wrote:
On Fri, 23 Mar 2007, John Pate wrote:
> Anyhoo, some success with 2.6.20.2 and martian.
But only partial...
Mar 23 22:44:35 localhost chat[3761]: CONNECT
Mar 23 22:44:35 localhost chat[3761]: -- got it
Mar 23 22:44:35 localhost chat[3761]: send ()
Mar 23 22:44:35 localhost pppd[3760]: Serial connection established.
Mar 23 22:44:35 localhost pppd[3760]: Using interface ppp0
Mar 23 22:44:35 localhost pppd[3760]: Connect: ppp0 <--> /dev/modem
Mar 23 22:44:36 localhost pppd[3760]: Remote message: EASYSTART
Mar 23 22:44:36 localhost pppd[3760]: PAP authentication succeeded
Mar 23 22:44:36 localhost pppd[3760]: local IP address 194.128.82.30
Mar 23 22:44:36 localhost pppd[3760]: remote IP address 195.40.10.4
Mar 23 22:44:36 localhost pppd[3760]: primary DNS address 195.40.1.36
Mar 23 22:44:36 localhost pppd[3760]: secondary DNS address 193.131.248.36
...so I can get this far. But at this point I can't ping the
nameservers listed there - and, of course, since I can't ping the
nameservers I can't ping anything else.
The interface is there and looks to be up and running...
ppp0 Link encap:Point-to-Point Protocol
inet addr:194.128.82.30 P-t-P:195.40.10.4 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:12 errors:0 dropped:0 overruns:0 frame:0
TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:1050 (1.0 KiB) TX bytes:148 (148.0 b)
...but it's it not happening.
See the email from Patrick Volkerding as to why the compile was
`wrong' in that I shouldn't have had to symlink into the kernel headers
from the glibc tree.
I'd be pleased to know why this stops the martian module from
working but presumably the guys who wrote it will be able to figure that
one out!
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-|message from the cookie daemon|
If the brain were so simple we could understand it,
we would be so simple we couldn't.
--
John Pate <johnny@xxxxxxxxxx>
Edinburgh, Scotland (home PC)
Disclaimer: I've probably changed my opinions by the time you read this
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
