set up gateway for PPP to Ethernet?

My DSL router box is at 192.168.1.1, and it is my gateway to the
Internet. My ISP gives me a Class B IP address, and since I don't run
bind, I use my ISP's DNS servers which also have Class B addresses. My
Linux system is at 192.168.1.3 on eth0. I'm not presently using routed
or gated, but I'm willing to use them if it would help.

I'm running pppd from /etc/inittab, listening to /dev/ttyS0. I want my
PDA to be able to reach the Internet. ppp0 is at 10.10.10.1 and the PDA
is at 10.10.10.200. I can change these to 192.168.1.* if it would help.
The PDA does support PPP and lets me specify DNS IPs (again, my ISP's
Class B servers), but doesn't let me provide a gateway IP.

What should I do to set up a routing table so that the PDA will be able
to reach the Internet?

--

On 22 May 2006, in the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed)>, Kaitlyn Luna wrote:

>My DSL router box is at 192.168.1.1, and it is my gateway to the
>Internet. My ISP gives me a Class B IP address, and since I don't run
>bind, I use my ISP's DNS servers which also have Class B addresses. My
>Linux system is at 192.168.1.3 on eth0.

OK - so you are using either NAT or masquerading on the DSL router. Key
questions - are you allowed to run more that one box on the 192.168.1.x
range? Are these static or DHCP configured addresses? Darn, you didn't
think it worth mentioning your Linux distribution or release - that might
have helped.

>I'm not presently using routed or gated, but I'm willing to use them if
>it would help.

Definitely NOT wanted. You use those when you have two or more ways to
reach a common destination AND the routers that lead to that destination
support a routing protocol such as RIP, OSPF, or similar.

>I'm running pppd from /etc/inittab, listening to /dev/ttyS0. I want my
>PDA to be able to reach the Internet. ppp0 is at 10.10.10.1 and the PDA
>is at 10.10.10.200. I can change these to 192.168.1.* if it would help.

If your DSL only supports one host on the LAN, leave the ppp link on the
existing network, and use IP-Masquerading on the Linux box, so the router
only sees one host.

If your DSL box allows multiple hosts with STATIC addresses, set the ppp
link to use 192.168.1.x, and set the Linux box to 'proxyarp' (pppd options
might be '192.168.1.151:192.168.1.4' and 'proxyarp' - see the man page).

If your DSL box allows multiple hosts, but requires DHCP, I'd go with the
masquerading option above.

>The PDA does support PPP and lets me specify DNS IPs (again, my ISP's
>Class B servers), but doesn't let me provide a gateway IP.

The gateway for the PDA box is the local ppp address of the Linux box.
With ANU style ppp, you need only specify 'defaultroute' on the PDA box.

>What should I do to set up a routing table so that the PDA will be able
>to reach the Internet?

Depends on which of the options you choose. On the PDA, you need only
specify the 'defaultroute' option, and the pppd on that box will handle it.
On the Linux box, you'll either proxyarp (need only supply that option to
pppd) or masquerade (see the IP-Masquerade-HOWTO or Masquerading-Simple-HOWTO
as appropriate).

708351 Nov 14 2005 IP-Masquerade-HOWTO
17605 Jul 21 2004 Masquerading-Simple-HOWTO
183087 Jul 19 2000 PPP-HOWTO

The last one is near useless, but it's all we have now.
http://axion.physics.ubc.ca/ppp-linux.html or
http://www.theory.physics.ubc.ca/ppp-linux.html (same page) may provide some
additional clues.

Old guy

Moe Trin wrote:

> OK - so you are using either NAT or masquerading on the DSL router.
> Key questions - are you allowed to run more that one box on the
> 192.168.1.x range? Are these static or DHCP configured addresses?
> Darn, you didn't think it worth mentioning your Linux distribution or
> release - that might have helped.

The DSL box is a SMC Barricade 7004 which provides NAT. It uses DHCP to
my ISP, even though my assigned IP hasn't changed in over a year. I
disabled its DHCP server so each computer uses a static IP which is
listed in each one's hosts file.

I'm using Debian sarge(stable), though I manually installed a few
testing and unstable packages. I forgot to mention it because I copied
my post from a Debian web forum but got no help after several weeks of
waiting.

> If your DSL only supports one host on the LAN, leave the ppp link on
> the existing network, and use IP-Masquerading on the Linux box, so
> the router only sees one host.

My ISP "thinks" I have only one though I really have several due to NAT.

I don't know if the stock Debian kernel (2.6.8) supports masquerading,
but I need to compile a 2.6.10 kernel anyway.

> The gateway for the PDA box is the local ppp address of the Linux box.
> With ANU style ppp, you need only specify 'defaultroute' on the PDA
> box.

I guess I'm forced to take that anyway. The PDA lets me specify static
IP or DHCP for itself, specify name servers or ask for them, idle
timeout, and login script. That's it.

On 23 May 2006, in the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed)>, Kaitlyn Luna wrote:

>Moe Trin wrote:

>The DSL box is a SMC Barricade 7004 which provides NAT. It uses DHCP to
>my ISP, even though my assigned IP hasn't changed in over a year. I
>disabled its DHCP server so each computer uses a static IP which is
>listed in each one's hosts file.

OK - static is the way to go. Easiest trick is to set the ppp options
'192.168.1.151:192.168.1.4' (first number is the IP on the Linux box
serial port, second is given to the PDA) and 'proxyarp' which _should_
do the entire thing.

>I don't know if the stock Debian kernel (2.6.8) supports masquerading,
>but I need to compile a 2.6.10 kernel anyway.

I haven't seen a distribution kernel that doesn't, at least for many years.

>> The gateway for the PDA box is the local ppp address of the Linux box.
>> With ANU style ppp, you need only specify 'defaultroute' on the PDA
>> box.
>
>I guess I'm forced to take that anyway. The PDA lets me specify static
>IP or DHCP for itself, specify name servers or ask for them, idle
>timeout, and login script. That's it.

Sounds a bit confused, but DHCP is _ONLY_ an Ethernet protocol, and that
has nothing to do with common ppp. I don't know what you are running on
the PDA, but every ppp implementation I've seen knows how to set up a
(serial) connection to a peer, and they all had the equivalent of a
defaultroute option (though it _might_ have a different name). For a
dialin client on Linux, you'd have something like

#!/bin/bash
exec /usr/sbin/pppd connect "/usr/sbin/chat -f /etc/ppp/dialscript" \
defaultroute lock noipdefault modem nodetach /dev/modem 115200 crtscts \
user Kaitlyn

(assuming 'Kaitlyn' is the username at the ISP). There must not be anything
after the \ in those two lines. The 'dialscript' would have the modem
commands to dial the ISP (which you probably don't need), such as

ABORT BUSY ABORT 'NO CARRIER' "" AT&F1 OK ATDT2662902 CONNECT \d\c

and authentication is handled by PAP or CHAP which means having the username
and password in /etc/ppp/pap-secrets or /etc/ppp/chap-secrets. The only
other thing needed is to set nameservers in /etc/resolv.conf. You can
read the man page for the Linux version of pppd and compare these options
with what you have on the PDA - should be _functionally_ similar.

Old guy

Moe Trin wrote:

> On 23 May 2006, in the Usenet newsgroup comp.os.linux.networking, in
> article <(E-Mail Removed)>, Kaitlyn Luna wrote:
>
> > Moe Trin wrote:
> OK - static is the way to go. Easiest trick is to set the ppp options
> '192.168.1.151:192.168.1.4' (first number is the IP on the Linux box
> serial port, second is given to the PDA) and 'proxyarp' which should
> do the entire thing.

Ok, here's my /etc/inittab line:
palm:2345:respawn:/usr/sbin/pppd /dev/ttyS0 115200
192.168.1.201:192.168.1.200 proxyarp persist local noauth silent
nodetach
(The noauth is temporary. I'll fix that once all's working.)
ps shows pppd is running, and the PDA does say connection established.

The PDA still can't connect to anything, LAN or Internet. If I start
Eudora Web and go to http://192.168.1.(anything)/ it just says Finding
site.... and never gets past there. Same for any Internet site. On the
LAN, I have httpd's listening on Win2000 the USB print server device,
and the Barricade. I also tried TuSSH to connect to the Linux system,
but I only get a timeout. I know sshd is ok because I can login from
the Win2000 system.

I never could get pppd's ms-dns to work, so I specify the name servers
(64.x.x.x) in the PDA's PPP setup.

The PDA does reach the Internet through Windows 2000 RAS, so I'm sure
it's just a config detail I'm missing for Linux.

On 24 May 2006, in the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed)>, Kaitlyn Luna wrote:

>Ok, here's my /etc/inittab line:
>palm:2345:respawn:/usr/sbin/pppd /dev/ttyS0 115200
>192.168.1.201:192.168.1.200 proxyarp persist local noauth silent
>nodetach
>(The noauth is temporary. I'll fix that once all's working.)
>ps shows pppd is running, and the PDA does say connection established.

I'm not used to seeing 'local' - but apparently that's not a problem.
Same for 'silent'. OK, next thing to look at is the output of
'/sbin/ifconfig' and '/sbin/route -n' - is the interface up, and is there
appropriate routing table entries. Are packets coming in/out (look at
the packet counts in ifconfig)?

>The PDA still can't connect to anything, LAN or Internet. If I start
>Eudora Web and go to http://192.168.1.(anything)/ it just says Finding
>site.... and never gets past there.

On the Linux box - run 'tcpdump' and see what packets are going where.
Lessee, you said this is Debian - have you told the kernel to forward
packets? Look at the contents of '/proc/sys/net/ipv4/ip_forward' which
should be a "1". I'm not using Debian, so I don't know where this
would be set in your boot scripts, but google seems to indicate setting
'ip_forward=yes' in /etc/network/options is the place.

>Same for any Internet site. On the LAN, I have httpd's listening on
>Win2000 the USB print server device, and the Barricade. I also tried
>TuSSH to connect to the Linux system, but I only get a timeout. I know
>sshd is ok because I can login from the Win2000 system.

Trying random applications isn't going to tell you much. Look at those
packets on the wire and see where they are going, what's coming back,
or even what _isn't_ coming back. On the PDA, try to connect to some
web server. Do you see packets coming from the PDA? Do you see packets
from the Linux box going in the direction of the web server? Are packets
coming back from the web server? Are they being forwarded to the PDA? All
of that should be visible using tcpdump (or any packet sniffer). As
regards SSH, look at 'netstat -tupan' and the configuration file for the
service, to see if the daemon is listening on the ppp interface.

>I never could get pppd's ms-dns to work, so I specify the name servers
>(64.x.x.x) in the PDA's PPP setup.

I don't use that - the addresses of name servers tend to be cast in stone,
and rarely change. The way I've seen it done is to put the ms-dns option
into /etc/ppp/options. What error message do you get?

Old guy

Moe Trin wrote:

> I'm not used to seeing 'local' - but apparently that's not a problem.
> Same for 'silent'. OK, next thing to look at is the output of
> '/sbin/ifconfig' and '/sbin/route -n' - is the interface up, and is
> there appropriate routing table entries. Are packets coming in/out
> (look at the packet counts in ifconfig)?

ipconfig does show ppp0 up and that it did handle some data.


> On the Linux box - run 'tcpdump' and see what packets are going where.
> Lessee, you said this is Debian - have you told the kernel to forward
> packets? Look at the contents of '/proc/sys/net/ipv4/ip_forward'
> which should be a "1". I'm not using Debian, so I don't know where
> this would be set in your boot scripts, but google seems to indicate
> setting 'ip_forward=yes' in /etc/network/options is the place.

It did say that, and I made the adjustment in options as well.

> Trying random applications isn't going to tell you much. Look at those
> packets on the wire and see where they are going, what's coming back,
> or even what isn't coming back. On the PDA, try to connect to some
> web server. Do you see packets coming from the PDA? Do you see packets
> from the Linux box going in the direction of the web server? Are
> packets coming back from the web server? Are they being forwarded to
> the PDA? All of that should be visible using tcpdump (or any packet
> sniffer). As regards SSH, look at 'netstat -tupan' and the
> configuration file for the service, to see if the daemon is listening
> on the ppp interface.

I installed Ethereal, though I don't have the experience to interpret
the results well.

This is what I got when trying to go from the PDA to the httpd in the
DSL router box.

1 0.000000 192.168.1.200 192.168.1.254 TCP 5747 > www [SYN] Seq=0 Ack=0
Win=2680 Len=0 MSS=536

Frame 1 (60 bytes on wire, 60 bytes captured)
Linux cooked capture
Internet Protocol, Src Addr: 192.168.1.200 (192.168.1.200), Dst Addr:
192.168.1.254 (192.168.1.254)
Transmission Control Protocol, Src Port: 5747 (5747), Dst Port: www
(80), Seq: 0, Ack: 0, Len: 0

I was using Eudora Web for PalmOS. It just said Finding site.... and
eventually timed out.

Next I tried an Internet web site, and still got stuck with Finding
site.... and a timeout. (xxx and yyy are for the primary and secondary
nameservers).

6 53.469502 192.168.1.200 64.xxx.xx.xx DNS Standard query A
iwin.nws.noaa.gov
Frame 6 (79 bytes on wire, 79 bytes captured)
Linux cooked capture
Internet Protocol, Src Addr: 192.168.1.200 (192.168.1.200), Dst Addr:
64.xxx.xx.xx (64.xxx.xx.xx)
User Datagram Protocol, Src Port: 28936 (28936), Dst Port: domain (53)
Domain Name System (query)

7 53.481496 192.168.1.200 64.yyy.yy.yy DNS Standard query A
iwin.nws.noaa.gov
Frame 7 (79 bytes on wire, 79 bytes captured)
Linux cooked capture
Internet Protocol, Src Addr: 192.168.1.200 (192.168.1.200), Dst Addr:
64.yyy.yy.yy (64.yyy.yy.yy)
User Datagram Protocol, Src Port: 28936 (28936), Dst Port: domain (53)
Domain Name System (query)

8 61.464110 192.168.1.200 64.xxx.xx.xx DNS Standard query A
iwin.nws.noaa.gov
Frame 8 (79 bytes on wire, 79 bytes captured)
Linux cooked capture
Internet Protocol, Src Addr: 192.168.1.200 (192.168.1.200), Dst Addr:
64.xxx.xx.xx (64.xxx.xx.xx)
User Datagram Protocol, Src Port: 28936 (28936), Dst Port: domain (53)
Domain Name System (query)

9 61.475115 192.168.1.200 64.yyy.yy.yy DNS Standard query A
iwin.nws.noaa.gov
Frame 9 (79 bytes on wire, 79 bytes captured)
Linux cooked capture
Internet Protocol, Src Addr: 192.168.1.200 (192.168.1.200), Dst Addr:
64.yyy.yy.yy (64.yyy.yy.yy)
User Datagram Protocol, Src Port: 28936 (28936), Dst Port: domain (53)
Domain Name System (query)

10 77.463356 192.168.1.200 64.xxx.xx.xx DNS Standard query A
iwin.nws.noaa.gov
Frame 10 (79 bytes on wire, 79 bytes captured)
Linux cooked capture
Internet Protocol, Src Addr: 192.168.1.200 (192.168.1.200), Dst Addr:
64.xxx.xx.xx (64.xxx.xx.xx)
User Datagram Protocol, Src Port: 28936 (28936), Dst Port: domain (53)
Domain Name System (query)

11 77.475348 192.168.1.200 64.yyy.yy.yy DNS Standard query A
iwin.nws.noaa.gov
Frame 11 (79 bytes on wire, 79 bytes captured)
Linux cooked capture
Internet Protocol, Src Addr: 192.168.1.200 (192.168.1.200), Dst Addr:
64.yyy.yy.yy (64.yyy.yy.yy)
User Datagram Protocol, Src Port: 28936 (28936), Dst Port: domain (53)
Domain Name System (query)

The routing table is where things might be falling apart. ppp0 (IP of
..201) has to go through eth0 (IP of .3) to reach the DSL router, but it
seems to not be doing that.

On 28 May 2006, in the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed)>, Kaitlyn Luna wrote:

>I installed Ethereal, though I don't have the experience to interpret
>the results well.
>
>This is what I got when trying to go from the PDA to the httpd in the
>DSL router box.
>
>1 0.000000 192.168.1.200 192.168.1.254 TCP 5747 > www [SYN] Seq=0 Ack=0
>Win=2680 Len=0 MSS=536

>I was using Eudora Web for PalmOS. It just said Finding site.... and
>eventually timed out.

Unfortunately, this doesn't tell me which interface you are looking at.
Using a packet sniffer isn't all that difficult, but you have to have
some idea what is "normal". You could do that by looking at the Ethereal
output on the Linux box when it talks to some other system. RFC1180 is
available on the Internet, and would also help.

A network connection is like a conversation - one person talk, then the
other responds. There is a difference in the Internet, in that you talk
to the "next hop" - somewhat akin to you trying to hold a conversation with
a person in a house on the next street, and to reach that person, you are
relaying the conversation through the person in the next house, who then
passes it to the next house, and so on.

I'm going to guess that this Ethereal snippet shows the conversation between
the PDA and the Linux box. As you can see, the PDA said something, but there
was no reply. You should be looking on the LAN interface, and see if the
packet from the PDA comes out of that interface. If it does, is there
something that comes back? I suspect that there isn't a conversation
at the moment.

Assuming the LAN has been quiet for a minute or more, you should see

ARP who-has 192.168.1.254 tell 192.168.1.200
ARP reply 192.168.1.254 is at 00:11:22:33:44:55
192.168.1.200 > 192.168.1.254 SYN
192.168.1.254 > 192.168.1.200 SYN/ACK
192.168.1.200 > 192.168.1.254 ACK Hello, How are you feeling?
192.168.1.254 > 192.168.1.200 ACK I'm fine, how are you?
192.168.1.200 > 192.168.1.254 ACK I'm great - thank you
192.168.1.200 > 192.168.1.254 ACK
192.168.1.200 > 192.168.1.254 ACK/FIN Goodbye
192.168.1.200 > 192.168.1.254 ACK/FIN Goodbye

This being an Ethernet, the first thing to do is to ARP to find out the
hardware address of the person next door. You won't see this on a ppp link
because there is only one person on each end of the wire, and there is no
need for this extra service.

The 'SYN' and 'SYN/ACK' are to start the conversation - the ACK is "I have
received this much of the conversation" - there with be a byte count value.
The 'FIN' is how the system shuts down the conservation.

>Next I tried an Internet web site, and still got stuck with Finding
>site.... and a timeout. (xxx and yyy are for the primary and secondary
>nameservers).
>
>6 53.469502 192.168.1.200 64.xxx.xx.xx DNS Standard query A
>iwin.nws.noaa.gov

Here. 192.168.1.200 wants to start a conversation with iwin.nws.noaa.gov,
but doesn't know the IP address. So, it trys to ask the name server. By
the way, there is no need to hide the addresses - they're public, and
anyone who wants to look can find them is a few seconds. But again,
we are only seeing the "start" of the conversation - there is no reply
from the name server. My guess is that the packet isn't being forwarded
(which is why you want to use Ethereal on the LAN interface), or there
could be a firewall on the Linux box that is blocking the traffic.

>7 53.481496 192.168.1.200 64.yyy.yy.yy DNS Standard query A
>iwin.nws.noaa.gov

Second DNS query - because we never heard anything from the first one.
Again, no reply. Lather, Rinse, Repeat.

>The routing table is where things might be falling apart. ppp0 (IP of
>.201) has to go through eth0 (IP of .3) to reach the DSL router, but it
>seems to not be doing that.

The routing table should look roughly like this on the Linux box:

Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 95017 eth0
192.168.1.201 0.0.0.0 255.255.255.255 UH 0 0 11695 ppp0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 420 lo
0.0.0.0 192.168.1.3 0.0.0.0 UG 0 0 2004 eth0

The first line is the standard LAN setup. The second line shows the route
to the PDA. As this is a 'host' route (UH), packets going to 192.168.1.201
instead of going out the eth0 interface. The third line is the loopback,
and the last line says that all packets NOT going to 192.168.1.x or
192.168.1.201, or 127.x.y.z should be set to 192.168.1.3 (which will send
them on their way to the world). If the PDA is running *nix, the routing
table on it will be even easier:

Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.201 0.0.0.0 255.255.255.255 UH 0 0 11695 ppp0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 170 lo
0.0.0.0 192.168.1.201 0.0.0.0 UG 0 0 55 ppp0

which says 'loopback, and 'everything else goes to 192.168.1.201'.

The other boxes on the LAN are similar:

Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 95017 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 420 lo
0.0.0.0 192.168.1.3 0.0.0.0 UG 0 0 2004 eth0

Notice that the PDA is _not_ listed separately. As far as the rest of the
LAN is concerned, the PDA is "right here", except that it has the same MAC
address as the Linux box. The routing table on the Barricade would be
identical, except that it would have a different gateway address and an
interface connected to the 64.203.64.0/19 network of your ISP.

Old guy

Moe Trin wrote:

>
> I'm going to guess that this Ethereal snippet shows the conversation
> between the PDA and the Linux box. As you can see, the PDA said
> something, but there was no reply. You should be looking on the LAN
> interface, and see if the packet from the PDA comes out of that
> interface. If it does, is there something that comes back? I suspect
> that there isn't a conversation at the moment.

You're all right so far. Ethereal has shown me eth0 never hears from
ppp0. The only things I captured were NTP and Samba.

> Here. 192.168.1.200 wants to start a conversation with
> iwin.nws.noaa.gov, but doesn't know the IP address. So, it trys to
> ask the name server. By the way, there is no need to hide the
> addresses - they're public, and anyone who wants to look can find
> them is a few seconds. But again, we are only seeing the "start" of

If someone is determined to do something to my ISP, nothing will stop
them from trying.

As you probably know, you can use someone else's DNS. When I had
bellsouth.net for DSL, the service was terrible. I reconfigured my
TCP/IP to use vic.com's nameservers instead of bellsouth.net's
nameservers. (Vic.com didn't mind since I was using them for domain and
web hosting.) That didn't help the other problems -- like IP leases not
being renewed properly or service being completely down for 3 or 5
hours -- but it did let me dodge their slow and flaky nameservers.

Bottom line is I don't want to advertise an alternate. If you're going
to leech someone else's DNS, at least make some effort to find an IP.

> the conversation - there is no reply from the name server. My guess
> is that the packet isn't being forwarded (which is why you want to
> use Ethereal on the LAN interface), or there could be a firewall on
> the Linux box that is blocking the traffic.

I do have Firestarter installed (though I might switch to Firehol).
Allow forwarding is checked in Firestarter's setup. This is separate
from the Barricade.

> The routing table should look roughly like this on the Linux box:

Nothing like it.

This is what I get after booting (PDA not connected)
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth0

With PDA connected
192.168.1.200 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth0

Even I can realize now this isn't right.
PDA (.200) needs to talk to the Barricade (.254) to get to the rest of
the LAN and the world. But it can't reach the Barricade without going
through eth0 (.3).
It looks like the PDA tries to go directly to the Barricade which isn't
possible.

The PDA uses PalmOS 3.5.3. There aren't really any net tools (arp,
ping, traceroute, route, netstat, ifconfig, etc.) for it.

On 30 May 2006, in the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed)>, Kaitlyn Luna wrote:

>As you probably know, you can use someone else's DNS.

Getting off topic, but that depends on how the server is configured. Our
public servers know how to resolve names within our zone, but return a
REFUSED (error code 5) for queries they are not authoratative for. Our
internal servers are not reachable from outside, but will answer all
queries, recursively if required.

>I do have Firestarter installed (though I might switch to Firehol).
>Allow forwarding is checked in Firestarter's setup. This is separate
>from the Barricade.

Firestarter is just an interface to control the builtin firewall. You may
want to look at '/sbin/iptables -L' and see what rules are actually in
place. This strongly sounds that you are not forwarding for some reason,
_or_ the firewall is ignoring/not accepting the ppp0 interface, because
it thinks all 192.168.1.0/24 traffic should only be on the eth0 interface..

>> The routing table should look roughly like this on the Linux box:
>
>Nothing like it.
>
>This is what I get after booting (PDA not connected)
>192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
>0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth0

There should also be a loopback, but that's fine. I thought the Barricade
was at 192.168.1.3

>With PDA connected
>192.168.1.200 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
>192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
>0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth0

OK - my confusion on which host was which. This is fine.

>Even I can realize now this isn't right.

It is, but what do you think it should look like?

>PDA (.200) needs to talk to the Barricade (.254) to get to the rest of
>the LAN and the world. But it can't reach the Barricade without going
>through eth0 (.3).
>It looks like the PDA tries to go directly to the Barricade which isn't
>possible.

That's not what the routing table says. The PDA can _ONLY_ talk to .201
(the ppp0 interface), and any traffic going anywhere has to go from the
PDA to that address, either directly (when trying to talk to the Linux
box itself) or as the gateway (when trying to speak to anyone other than
the Linux box or the loopback). As far as the routing table here on the
Linux box, the second line says that all of the LAN (except the host route
to the PDA) is directly reachable on eth0 - no need to talk to the
Barricade except when going off to the world, or when trying to talk to a
name server.

The PDA doesn't know anything about the Barricade or .3 for the very simple
reason that they are not _directly_ attached to the PDA. The PDA can not
send packets _directly_ to anything except the host on the other end of the
ppp link. That is is the .201 interface.

The problem is here in the Linux box - the packets are coming in on the
ppp interface, but are not being forwarded to the LAN. Additionally, there
are no ICMP errors sent back to the PDA. That's a firewall issue.

Old guy