working SIM install, network problems - update

Rodney Myers rdmyers at
Sun Dec 7 23:06:06 CET 2008

On Dec 6, 2008, at 9:41 PM, Joel Newkirk wrote:

> On Sat, 6 Dec 2008 20:00:36 -0800, Rodney Myers  
> <rdmyers at>
> wrote:
>> 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
>> them 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.
> [snip]
>> 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  
>> 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+
>> -j ACCEPT
>> iptables -A FORWARD -s -i eth+ -d -o  
>> usb0
>> -j ACCEPT
>> 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.

No. I took what Clare had written, and was attempting to get working  
with my LAN.  My lan is 192.168.1.*/24, not 192.168.2.* (probably a  
typo, but want to make sure)

Correct, in pinging everything on my lan. Once I was ssh'd into the  
OM, I could ping ever computer on my lan, from the router, wireless  
access point, the 2 wireless computers, and the debian (wired) computer.

> 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 -  
> 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.

No "firewall running on the debian machine. At this time.

> 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.
> j
> -- 
> Joel Newkirk

Thanks. I will experiment a bit more.

Rodney D. Myers <rdmyers.42 at>
ICQ#:         AIM#:            YAHOO:
18002350      mailman452       mailman42_5

They that can give up essential liberty to obtain a
little temporary safety deserve neither liberty nor safety.
         Ben Franklin - 1759

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : 

More information about the community mailing list