Re: working SIM install, network problems - update

[Rodney Myers]

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

On Sat, 6 Dec 2008 20:00:36 -0800, Rodney Myers <[EMAIL PROTECTED]>

wrote:

On Dec 4, 2008, at 3:57 AM, clare johnstone wrote:

At this stage I can  do
ssh [EMAIL PROTECTED]


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

you can automate a lot of things.

good luck,
clare

Normally it will argue and I have to edit the file ~/.ssh/known hosts is a matter of taste only. Once you have things going without trouble

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

[EMAIL PROTECTED]:~$ cat bin/om-network
#!/bin/sh
/bin/echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -F

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


-j ACCEPT

-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

iptables -A INPUT -s 192.168.0.202 -i usb0 -d 192.168.0.200 -j ACCEPT iptables -A FORWARD -s 192.168.0.202 -i usb0 -d 192.168.2.0/24 -o eth+ iptables -A FORWARD -s 192.168.1.0/24 -i eth+ -d 192.168.0.202 -o usb0

the host I can't tell if the 192.168.2.0/24 are typos, or correct with

you have just 192.168.1.0/24 in play.

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

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

just being FORWARDed by 'this' machine.


OUTPUT and FORWARD.  But it doesn't touch the 'nat' table (PREROUTING,

sure if this is really what you want to do anyway - doesn't the host

already in place.


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

things like ICMP dest unreachable being 'related' to an attempted

from the host, and replies will route correctly back to the host.

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 "iptables -F" flushes all rules from the 'filter' table's chains - INPUT, 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 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 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 connection-tracking state engine where replies, like web pages when you browse, are ESTABLISHED connections, while RELATED connections includes 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

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

The OUTPUT rule should only be needed if your host has a REALLY tight

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

rule might be stopping you.

j

--
Joel Newkirk

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

Thanks. I will experiment a bit more.

--
Rodney D. Myers <[EMAIL PROTECTED]>
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

PGP.sig
Description: This is a digitally signed message part

_______________________________________________
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community