working SIM install, network problems - update
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>
>> 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
>>> by removing the line it is objecting to. It will then agree to the
>>> Most people automate that process to avoid the editing etc but that
>>> is a matter of taste only. Once you have things going without
>>> you can automate a lot of things.
>>> good luck,
>> 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.
>> My interpretation of ths scripts;
>> cat bin/OM-config
>> /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/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
>> iptables -A INPUT -s 192.168.0.200 -i eth+ -d 192.168.0.202 -j
>> iptables -A INPUT -s 192.168.1.0/24 -i eth+ -d 192.168.0.202 -j
>> iptables -A INPUT -s 192.168.1.0/24 -i eth+ -d 192.168.2.0/24 -j
>> iptables -A FORWARD -s 192.168.0.202 -i usb0 -d 192.168.2.0/24 -o
>> -j ACCEPT
>> iptables -A FORWARD -s 192.168.1.0/24 -i eth+ -d 192.168.0.202 -o
>> -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
> with an IP on 'this' machine as destination, OUTPUT is packets from
> 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
> 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
> off adding rules to permit the FR instead of flushing everything
> 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
> browse, are ESTABLISHED connections, while RELATED connections
> 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
> 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
> the policy is listed after the chain name OUTPUT when you list the
> with something like "iptables -vnL OUTPUT") OUTPUT rules are really
> 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'
> '-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
> If there's any REJECT or DROP rules in the chain, inserting these at
> top will ensure that the FR traffic gets through without puzzling
> out which
> rule might be stopping you.
> 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...
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