Network Setup Advice - Networking

This is a discussion on Network Setup Advice - Networking ; 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) ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Network Setup Advice

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

  2. Re: Network Setup Advice

    On Tue, 15 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
    article , 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

  3. Re: Network Setup Advice

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

  4. Re: Network Setup Advice

    On Sat, 19 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
    article , 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 . 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

  5. Re: Network Setup Advice

    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

  6. Re: Network Setup Advice

    On Wed, 23 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
    article , 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

+ Reply to Thread