working SIM install, network problems - update

Joel Newkirk freerunner at
Sun Dec 7 06:41:35 CET 2008

On Sat, 6 Dec 2008 20:00:36 -0800, Rodney Myers <rdmyers at>
> On Dec 4, 2008, at 3:57 AM, clare johnstone wrote:
>> At this stage I can  do
>> ssh root at
>> Normally it will argue and I have to edit the file ~/.ssh/known hosts
>> by removing the line it is objecting to. It will then agree to the
>> ssh.
>> Most people automate that process to avoid the editing etc but that
>> is a matter of taste only. Once you have things going without trouble
>> you can automate a lot of things.
>> good luck,
>> clare
>   Thank you for your scripts. I "think" I edited them to correlate
> tthem to my network;
> I now can ssh into the OM, and set the time to my local "America/
> Los_Angeles". One step ahead.
> I can ping the debian machine, and everything on my lan, but nothing
> outside the lan.


> My interpretation of ths scripts;
> cat bin/OM-config
> #!/bin/sh
> /sbin/ifconfig usb0 netmask
> /sbin/route add -host dev usb0
> rodney at riverside:~$ cat bin/om-network
> #!/bin/sh
> /bin/echo 1 > /proc/sys/net/ipv4/ip_forward
> iptables -F
> iptables -A INPUT -s -i usb0  -d   -j ACCEPT
> iptables -A INPUT  -s  -i eth+  -d  -j
> iptables -A INPUT  -s  -i eth+  -d  -j
> iptables -A INPUT  -s  -i eth+  -d  -j
> iptables -A FORWARD -s -i usb0 -d -o eth+
> iptables -A FORWARD -s -i eth+ -d -o usb0
> iptables -A OUTPUT -d -o eth+   -j ACCEPT
> iptables -A OUTPUT -d -o usb0  -j ACCEPT
> iptables -A POSTROUTING -t nat -j MASQUERADE -s

Is this the complete firewall script??  There's several things missing, and
a couple possible errors.  (since you only posted ifconfig info for usb0 on
the host I can't tell if the are typos, or correct with
missing rules) Now, since you say you can ping everything on the LAN, and
have only the two FORWARD rules listed, I'm going to assume a typo and that
you have just in play.

A few points:

You have rules to accept INPUT from for destIP, but this should never be the case - INPUT is only packets
with an IP on 'this' machine as destination, OUTPUT is packets from 'this'
machine, FORWARD is packets from somewhere else TO somewhere else that are
just being FORWARDed by 'this' machine.

"iptables -F" flushes all rules from the 'filter' table's chains - INPUT,
OUTPUT and FORWARD.  But it doesn't touch the 'nat' table (PREROUTING,
POSTROUTING, and OUTPUT chains) unless you separately invoke "iptables -t
nat -F", and it doesn't set/change the default chain policies.  I'm not
sure if this is really what you want to do anyway - doesn't the host
already have a set of firewall rules in place? If so you're likely better
off adding rules to permit the FR instead of flushing everything that's
already in place.

Presuming the host communicates fine to begin with, instead of ALL of the
iptables commands above, try these (NOTE there's NOT an 'iptables -F' to
flush the existing rules, we're just appending additional rules):

iptables -A INPUT -i usb0 -s -j ACCEPT
iptables -A FORWARD -i usb0 -s -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o usb0 -j ACCEPT
iptables -t nat -A POSTROUTING -s -j MASQUERADE

The first rule lets the FR talk to the host, the second lets it talk
/through/ the host to whatever else is reachable, the third lets the
response to that traffic back through to the FR (we're invoking the
connection-tracking state engine where replies, like web pages when you
browse, are ESTABLISHED connections, while RELATED connections includes
things like ICMP dest unreachable being 'related' to an attempted
connection, FTP data being 'related' to FTP control port 21, RTP related to
SIP for VOIP,  etc), fourth lets the host talk to the FR, fifth NATs any
packets from the FR that are going out on the LAN so that they appear to be
from the host, and replies will route correctly back to the host.

The OUTPUT rule should only be needed if your host has a REALLY tight
firewall: often the OUTPUT chain is left in an 'allow all' state, with few
or no rules and 'ACCEPT' policy.  ("iptables -p OUTPUT ACCEPT" sets this,
the policy is listed after the chain name OUTPUT when you list the rules
with something like "iptables -vnL OUTPUT")  OUTPUT rules are really only
useful when you don't trust the host itself, IE on a multiuser system,
shared server, etc. 

Finally, if there is already a complex set of rules in place, you may
benefit from using INSERT instead of APPEND - just replace all '-A' with
'-I' and it will insert rules at the start of the chain, or '-I INPUT 4'
for example to insert a new rule #4, the current rule #4 becoming #5 etc. 
If there's any REJECT or DROP rules in the chain, inserting these at the
top will ensure that the FR traffic gets through without puzzling out which
rule might be stopping you.


Joel Newkirk      (blog) (FR stuff)

More information about the community mailing list