working SIM install, network problems - update

Rodney Myers rdmyers at mtpalomar.net
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 mtpalomar.net>
> wrote:
>>
>> On Dec 4, 2008, at 3:57 AM, clare johnstone wrote:
>>
>>> At this stage I can  do
>>> ssh root at 192.168.0.202
>>>
>>> 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;
>>
>> 192.168.1.0/24
>>
>> 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 192.168.0.200 netmask 255.255.255.0
>> /sbin/route add -host 192.168.0.202/32 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 192.168.0.202 -i usb0  -d 192.168.0.200   -j  
>> ACCEPT
>> iptables -A INPUT  -s 192.168.0.200  -i eth+  -d 192.168.0.202  -j
>> ACCEPT
>> iptables -A INPUT  -s 192.168.1.0/24  -i eth+  -d 192.168.0.202  -j
>> ACCEPT
>> iptables -A INPUT  -s 192.168.1.0/24  -i eth+  -d 192.168.2.0/24  -j
>> ACCEPT
>>
>> iptables -A FORWARD -s 192.168.0.202 -i usb0 -d 192.168.2.0/24 -o  
>> eth+
>> -j ACCEPT
>> iptables -A FORWARD -s 192.168.1.0/24 -i eth+ -d 192.168.0.202 -o  
>> usb0
>> -j ACCEPT
>>
>> iptables -A OUTPUT -d 192.168.1.0/24 -o eth+   -j ACCEPT
>> iptables -A OUTPUT -d 192.168.0.202 -o usb0  -j ACCEPT
>> iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24
>
> 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 192.168.2.0/24 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 192.168.1.0/24 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 192.168.1.0/24 for destIP
> 192.168.0.202, 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 192.168.0.202 -j ACCEPT
> iptables -A FORWARD -i usb0 -s 192.168.0.202 -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 192.168.0.0/24 -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 gmail.com>
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 : http://lists.openmoko.org/pipermail/community/attachments/20081207/5db358c0/attachment.pgp 


More information about the community mailing list