Network Setup Advice

I'm trying to think of some ideas to set up this network nicely. It
will contain the following:

PPP link to Inet (maybe cable modem soon)
Wired ethernet between two hosts
Wireless (both hosts), capable of AP (have hostapd, wpa_supplicant)
Bluetooth (both hosts), capable of NAP, GN or whatever the setup would need.


Currently I'm using one subnet for this, with only the PPP/Ethernet
connectivity full-time and wireless/bluetooth (configured manually) as
needed. I'd like to work wireless and Bluetooth in here on a more
permanent basis, possibly one host running as an AP for wireless and
the other as a NAP for bluetooth clients. With the one subnet
approach, connecting something like a remote wireless client gets
tricky, because the traffic goes like so:

Inet <- ppp0 | <- eth0 <- ath0 | <- client
| |
Host #1 Host #2 Wireless client

Both above hosts have multiple addr/interfaces. If I add in Bluetooth
at the same time, you may have, for example, eth0, ath0, pan0. Is
keeping all this on one subnet the correct thing to do, since it's one
network (with many parts), or should I create seperate subnets for
wired, wireless, and Bluetooth? I'm trying to picture what this would
look like in a dhcpd.conf file. Currently I'm not using dhcp, but I
think it would be a good idea, especially for wireless clients that
don't know the network layout.

To put it another way, currently I'm using 192.168.10.x for
everything. Should I make 192.168.20.x, 192.168.30.x, etc. for
Bluetooth and wireless?



--
[** 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..._nsa_internal/
http://www.wired.com/politics/securi...007/08/wiretap
http://www.hermes-press.com/police_state.htm
http://www.privacyinternational.org/...D=x-347-559597

On Tue, 15 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <x77iezyv21.fsf@vdrl.ath.cx>, jayjwa wrote:

>I'm trying to think of some ideas to set up this network nicely. It
>will contain the following:
>
>PPP link to Inet (maybe cable modem soon)
>Wired ethernet between two hosts

Straight forward - the only question being where is the modem located?
I managed to find/recover the remnants of an old laptop from the
dumpster (display was destroyed, keyboard and case damaged), and set
this up (literally in a cardboard box) along with an Ethernet card to
reach my LAN, and an external modem for dial-out. This became the
gateway to the world for the rest of the LAN, and this system was
configured with 'dial-on-demand' pppd. Later when I got broadband,
I managed to add a second NIC which connects to the DSL router, which
gave minimal change to the rest of the LAN, and allowed the dial-out
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

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 ~]$

The script is pretty much "normal", and in the last line, the 'demand'
option is the key. This starts pppd at boot-up, and causes pppd to dial
out when there is traffic for the world. The 'idle 300' shuts down the
link when it is idle for 5 minutes. Obviously, you are running iptables
on this box to masquerade the systems on the LAN. It's best to do this
on a dedicated box, as that simplifies the routing and masquerading.

>Wireless (both hosts), capable of AP (have hostapd, wpa_supplicant)
>Bluetooth (both hosts), capable of NAP, GN or whatever the setup would
>need.

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.

>Currently I'm using one subnet for this, with only the PPP/Ethernet
>connectivity full-time and wireless/bluetooth (configured manually) as
>needed. I'd like to work wireless and Bluetooth in here on a more
>permanent basis, possibly one host running as an AP for wireless and
>the other as a NAP for bluetooth clients. With the one subnet
>approach, connecting something like a remote wireless client gets
>tricky, because the traffic goes

to he!! in a handbasket. Yup. A lot is going to depend on what you are
trying to do. While there is one computer, it may have multiple network
interfaces. The best solution if trying to connect from one multi-homed
host to another is to have the interfaces on different networks, so that
you can connect to "blue-work1" from "blue-work2" OR "802-work1" OR
'work1" (implied - "wire-work1". (Obviously, you would want to choose
more suitable names.) With separate networks, there is no confusion to
the kernel as to which interface[s] to use. Bandwidth bonding and
redundancy is _possible_ but getting this preliminary setup working is
likely to have you howling at the moon - no need for more torment.

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

>Both above hosts have multiple addr/interfaces. If I add in Bluetooth
>at the same time, you may have, for example, eth0, ath0, pan0.

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

>Is keeping all this on one subnet the correct thing to do, since it's
>one network (with many parts), or should I create seperate subnets for
>wired, wireless, and Bluetooth?

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'm trying to picture what this would look like in a dhcpd.conf file.

I don't use DHCP, because the computers I allow on my LAN don't go
walkies. You could get around the problem with some difficulty using
MAC (hardware) address as the control, but if you're going to that much
effort, it may be simpler/easier to use static addresses.

>Currently I'm not using dhcp, but I think it would be a good idea,
>especially for wireless clients that don't know the network layout.

DHCP verses static - where is the complex setup. With DHCP, the clients
can be dumb as posts, but the server setup can be hairy. With static,
the clients are more complex, and there is no server. Your choice.

>To put it another way, currently I'm using 192.168.10.x for
>everything. Should I make 192.168.20.x, 192.168.30.x, etc. for
>Bluetooth and wireless?

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

Old guy

ibuprofin@painkiller.example.tld (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..._nsa_internal/
http://www.wired.com/politics/securi...007/08/wiretap
http://www.hermes-press.com/police_state.htm
http://www.privacyinternational.org/...D=x-347-559597

On Sat, 19 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <x7od85ifvb.fsf@vdrl.ath.cx>, jayjwa wrote:

>ibuprofin@painkiller.example.tld (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.

Are you speaking about hosting a domain (and receiving Internet mail
directly) on a dialin? I gave that up years ago, as there are hundreds
of hosting companies that will do this for a low fee. If you mean
getting the mail from the ISP's POP or IMAP server, a cron job checking
the mail at an appropriate interval (I use 15 minutes on days when I am
at home, and hourly on nights and when I'm away) using fetchmail or
similar is more than enough, and the traffic would bring up the
connection if needed.

>> echo -n 1 > /proc/sys/net/ipv4/ip_dynaddr
>> /usr/local/bin/dialin
>
>sysctl. It was made for just such an occasion ;)

This script concept was developed long before sysctl was commonly
available (and before pppd got demand mode in 1997). As the boot script
(/etc/rc.d/rc.local or similar) is run as root, there's no need for
sysctl.

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

Yeah, but makes dial-on-demand much harder ;-)

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

That's what I'd be worried about. You may want to check your IP address
against the various RBL blocklists to see if it triggered them.

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

I think I've seen you posting on the 'alt.internet.wireless' Usenet
newsgroup, and I'd listen to Jeff Liebermann on that.

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

This has always been a problem, which is why the various routing
daemons have been around for years. The problem with such daemons
as routed and gated is that they need to be talking to peers to
make the right decisions. Lacking that, you wind up in the 'try
this, and if it fails, try the other' mode which is far less
efficient.

Old guy

ibuprofin@painkiller.example.tld (Moe Trin) writes:

> Are you speaking about hosting a domain (and receiving Internet mail
> directly) on a dialin? I gave that up years ago, as there are hundreds
> of hosting companies that will do this for a low fee.

Yes. It's not as bad as it sounds, as I'm always connected and there's
not much mail. I like the level of control it affords, and being in
control ultimately means less Spam/trouble. For example, I've gone for
the past 2-3 weeks without a piece of Spam.

> This script concept was developed long before sysctl was commonly
> available (and before pppd got demand mode in 1997). As the boot script
> (/etc/rc.d/rc.local or similar) is run as root, there's no need for
> sysctl.

Are you talking about this sysctl?

sysctl -w net.ipv4.ip_dynaddr=1
(in your example)

Plus it lists too (sysctl -A), which echo can't do.

> That's what I'd be worried about. You may want to check your IP address
> against the various RBL blocklists to see if it triggered them.

I didn't have any AP up at the time- these were other networks/clients
with one client moving around. Besides, I'm RBL-listed just being
"dynamic" on lists that track such things. One of the few lists that
shows proof, DSBL.org, has listings from years ago that suggest
infected Windows machines.

> I think I've seen you posting on the 'alt.internet.wireless' Usenet
> newsgroup, and I'd listen to Jeff Liebermann on that.

Correct. I'm just saying, it's not to level as it's sometimes made out
to be.

> This has always been a problem, which is why the various routing
> daemons have been around for years. The problem with such daemons
> as routed and gated is that they need to be talking to peers to
> make the right decisions. Lacking that, you wind up in the 'try
> this, and if it fails, try the other' mode which is far less
> efficient.

Are these still in use on modern systems? I don't see them being
talked about or recommended any more which leads me to think they are
being phased out (or gone already), at least on systems of the ssale
that mine is. Does the kernel alone handle all such decisions on
routing?


--
[** 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..._nsa_internal/
http://www.wired.com/politics/securi...007/08/wiretap
http://www.hermes-press.com/police_state.htm
http://www.privacyinternational.org/...D=x-347-559597

On Wed, 23 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <x7skxcs104.fsf@vdrl.ath.cx>, jayjwa wrote:

>ibuprofin@painkiller.example.tld (Moe Trin) writes:

>> This script concept was developed long before sysctl was commonly
>> available (and before pppd got demand mode in 1997). As the boot
>> script (/etc/rc.d/rc.local or similar) is run as root, there's no
>> need for sysctl.
>
>Are you talking about this sysctl?
>
>sysctl -w net.ipv4.ip_dynaddr=1
>(in your example)

Yeah - it's not just a Linux (or BSDism).

>Plus it lists too (sysctl -A), which echo can't do.

Echo deals with strings as input, not files. But 'cat' or even file
redirection works quite well.

>> The problem with such daemons as routed and gated is that they need
>> to be talking to peers to make the right decisions. Lacking that,
>> you wind up in the 'try this, and if it fails, try the other' mode
>> which is far less efficient.
>
>Are these still in use on modern systems?

If you mean on workstations/servers, they are less common - it depends
on the complexity of the routing table setups. As far as routers are
concerned - routing daemons are virtually mandatory if they have
multiple neighbors.

>I don't see them being talked about or recommended any more which
>leads me to think they are being phased out (or gone already), at least
>on systems of the ssale that mine is.

I think it's considerable overkill on your setup.

>Does the kernel alone handle all such decisions on routing?

Yes, but the data that the kernel uses can be modified by such daemons.

Old guy