Re: Network Setup Advice



ibuprofin@xxxxxxxxxxxxxxxxxxxxxx (Moe Trin) writes:

Straight forward - the only question being where is the modem located?

Similar to your dial-up setup, it is the link to the outside
Internet. I just leave it connected, instead of using
dial-on-demand. This lets inbound connections work for mail, etc.

to act as a backup. Obviously on a headless box, everything is run
by scripts, and a ppp script was started out of /etc/rc.d/rc.local
with two lines:

echo -n 1 > /proc/sys/net/ipv4/ip_dynaddr
/usr/local/bin/dialin

sysctl. It was made for just such an occasion ;)


where /usr/local/bin/dialin consisted of a standard dumb script to
dial in

[compton ~]$ cat /usr/local/bin/dialin
#!/bin/bash
exec /usr/sbin/pppd connect "/usr/sbin/chat -f /etc/ppp/dialscript" lock \
defaultroute noipdefault /dev/modem 115200 crtscts user ibuprofin \
demand idle 300 holdoff 15
[compton ~]$

There must not be anything after the \ in those two lines.

[compton ~]$ cat /etc/ppp/dialscript
ABORT BUSY ABORT 'NO CARRIER' "" AT&F1 OK ATDT2662902 CONNECT \d\c
[compton ~]$

I have several places I call, only one used with any frequency, but
they go in /etc/ppp/peers. Then I just do pppd call <place>. Easy
to type.


Just another network. Be _very_ sure your wireless links are encrypted
lest you have the neighborhood skript-kiddy surfing pr0n and sending
spam on your dime.

So far no one's messed with any AP I've had up. I did see something
which might have been someone spamming through wireless, though. I
didn't see the message, so it's hard to tell. A bit too much smtp
traffic to too many different servers for most normal use cases.

I tried a WEP-cracking experiment as well. It's not quite as easy as
it's sometimes made out to be.


The one problem you get into is the 'default route'. On each computer,
there can be only ONE default. In networking, the word 'default' is
used in the programming sense - a choice of A, B, or C and if they
don't work, then use the default (which might be D). So, think what
link will "always" be up, and that is going to have to be the route
to the world. Then juggle the routing tables so that (using the
defaults), any system has an obvious way to the world (and equally
important, the other end has a way to _reply_ to any/all systems).

I think this was the problem, there were two or more ways that
appeared to reach to the router that had the outside link. 'ip nei
show' gave a look at what was happen, that packets would try one
route, fail, go another, then that way would be marked
reachable. Following traffic would go the reachable route as shown in
the neighbor table.

And a very confused user (and maybe a confused kernel as well).

The Linux kernel is pretty good at sorting things out and doing the
'right thing', whatever that is in whatever situation is at hand. Most
of the time...

This isn't a standard condition. With everyone on the same network, you
are going to have considerable confusion over which interface to use.
Don't forget, it's not the interfaces that form the conversation - it's
the schizophrenic kernel that is actually running the computer. By
setting each interface on a different (sub)network, you lessen the
confusion.

I did go on and try this way one night a few days ago, and it seemed
to work better without having to wait for the neighbor/reachable issue
above. The only issue is I will likely have to re-write the Netfilter
rules to allow for the different subnets.


192.168.10.75 dev eth0 lladdr 00:0c:41:e8:30:31 REACHABLE

Use which-ever RFC1918 address range you'd like, but yes - I would
definitely go with individual networks.

Right. That does look like the way to go. Thanks for your input.


--
[** America, the police state **]
Whoooose! What's that noise? Why, it's US citizen's
rights, going down the toilet with Bush flushing.
http://www.theregister.co.uk/2008/01/27/bush_nsa_internal/
http://www.wired.com/politics/security/news/2007/08/wiretap
http://www.hermes-press.com/police_state.htm
http://www.privacyinternational.org/article.shtml?cmd%5B347%5D=x-347-559597
.



Relevant Pages

  • Re: Async Understanding
    ... normally uses a cellular interface to connect to an MPLS network. ... serial connections which behave differently. ... You can use route map to filter out dial up subnet during redistribution. ...
    (comp.dcom.sys.cisco)
  • Re: strange TCP issue on RELENG_7
    ... corresponds to see if that interface supports TCP offload. ... inpcb locked (which isn't used as part of the route lookup). ... But all connections exit out em0 other than connected ...
    (freebsd-net)
  • Re: strange TCP issue on RELENG_7
    ... corresponds to see if that interface supports TCP offload. ... inpcb locked (which isn't used as part of the route lookup). ... The server has just one default gateway, which is out em0, ... But all connections exit out em0 other than ...
    (freebsd-net)
  • Re: Experiences with ath(4)
    ... >> connections to the outside drop, I can ping and connect to any host in my ... > sending to the right mac address and out the right interface. ... the route is ok. ...
    (freebsd-current)
  • IRowConsumer webpart runat client
    ... (with runat client because i'm using an OWC Pivottable to interface). ... many connections can ... public override ConnectionRunAt CanRunAt() ... Public Overrides Sub EnsureInterfaces() ...
    (microsoft.public.sharepoint.portalserver.development)