• Simplest eth0 between 2 PCs?

    From Unknown@110:110/2002 to All on Mon Dec 30 21:39:19 2013

    Please lets confirm each stage.
    Like seeing the actual water-flowing-in-the-pipe.

    1= plug cross-over cat-cable between PC1 <-> PC2.
    2= PC1: ifconfig eth0 192.168.0.1
    PC2: ifconfig eth0 192.168.0.2
    See LEDs on PC1 connector light-up.

    What is the minimal command/s to confirm that each PC detects the other?

    What is the minimal command/s to transfer a file from 'src -> dest'?

    == TIA.

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:110/2002@linuxnet)
  • From Bit Twister@110:110/2002 to All on Mon Dec 30 21:49:04 2013
    On Mon, 30 Dec 2013 21:39:19 +0000 (UTC), Unknown wrote:

    Please lets confirm each stage.
    Like seeing the actual water-flowing-in-the-pipe.

    1= plug cross-over cat-cable between PC1 <-> PC2.
    2= PC1: ifconfig eth0 192.168.0.1
    PC2: ifconfig eth0 192.168.0.2
    See LEDs on PC1 connector light-up.

    What is the minimal command/s to confirm that each PC detects the other?

    PC1: ping -c1 192.168.0.2
    PC2: ping -c1 192.168.0.1

    What is the minimal command/s to transfer a file from 'src -> dest'?

    PC1: scp fn_here $USER@192.168.0.2:/wherever/fn_here

    copy a whole directory:
    PC1: rsync /some/dir/ $USER@192.168.0.2:/some/dir

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:110/2002@linuxnet)
  • From unruh@110:110/2002 to All on Mon Dec 30 22:07:48 2013
    On 2013-12-30, Bit Twister <BitTwister@mouse-potato.com> wrote:
    On Mon, 30 Dec 2013 21:39:19 +0000 (UTC), Unknown wrote:

    Please lets confirm each stage.
    Like seeing the actual water-flowing-in-the-pipe.

    1= plug cross-over cat-cable between PC1 <-> PC2.
    2= PC1: ifconfig eth0 192.168.0.1
    PC2: ifconfig eth0 192.168.0.2
    See LEDs on PC1 connector light-up.

    What is the minimal command/s to confirm that each PC detects the other?

    PC1: ping -c1 192.168.0.2
    PC2: ping -c1 192.168.0.1

    Well, only if there is no firewall which switches off pings. The default
    seems to be these days to disable pings.


    What is the minimal command/s to transfer a file from 'src -> dest'?

    PC1: scp fn_here $USER@192.168.0.2:/wherever/fn_here

    Well, first you had better make sure that sshd is running on both
    machines-- install sshd and start it up on both.


    copy a whole directory:
    PC1: rsync /some/dir/ $USER@192.168.0.2:/some/dir

    Or scp -pr /some/dir 192.168.0.2:/some/dir
    Or use rsync to transfer individual files. Again you have to make sure
    that rsync is installed on both machines and sshd is running on both and
    that ssh is installed on both.

    Note that the $USER@ is pretty useless since that is the default. If the
    user on the remote machine has a different name than the one on the
    local machine, then you need to put that different name on that line



    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:110/2002@linuxnet)
  • From Jorgen Grahn@1:0/0 to All on Mon Dec 30 22:40:31 2013
    On Mon, 2013-12-30, unruh wrote:
    On 2013-12-30, Bit Twister <BitTwister@mouse-potato.com> wrote:
    On Mon, 30 Dec 2013 21:39:19 +0000 (UTC), Unknown wrote:

    Please lets confirm each stage.
    Like seeing the actual water-flowing-in-the-pipe.

    1= plug cross-over cat-cable between PC1 <-> PC2.

    Side note: recent NICs, switches etc don't care if the
    cables are crossed or not.

    2= PC1: ifconfig eth0 192.168.0.1
    PC2: ifconfig eth0 192.168.0.2
    See LEDs on PC1 connector light-up.

    What is the minimal command/s to confirm that each PC detects the other?

    PC1: ping -c1 192.168.0.2
    PC2: ping -c1 192.168.0.1

    Well, only if there is no firewall which switches off pings. The default seems to be these days to disable pings.

    In Linux distributions? I find that hard to believe (and sad if it's
    true).

    /jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From unruh@110:110/2002 to All on Mon Dec 30 23:35:34 2013
    On 2013-12-30, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
    On Mon, 2013-12-30, unruh wrote:
    On 2013-12-30, Bit Twister <BitTwister@mouse-potato.com> wrote:
    On Mon, 30 Dec 2013 21:39:19 +0000 (UTC), Unknown wrote:

    Please lets confirm each stage.
    Like seeing the actual water-flowing-in-the-pipe.

    1= plug cross-over cat-cable between PC1 <-> PC2.

    Side note: recent NICs, switches etc don't care if the
    cables are crossed or not.

    2= PC1: ifconfig eth0 192.168.0.1
    PC2: ifconfig eth0 192.168.0.2
    See LEDs on PC1 connector light-up.

    What is the minimal command/s to confirm that each PC detects the other? >>>
    PC1: ping -c1 192.168.0.2
    PC2: ping -c1 192.168.0.1

    Well, only if there is no firewall which switches off pings. The default
    seems to be these days to disable pings.

    In Linux distributions? I find that hard to believe (and sad if it's
    true).

    They all come with firewalls activated by default. Often those firewalls
    by default are maximum firewalls (ie reject everything incoming,
    including pings.)


    /jorgen


    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:110/2002@linuxnet)
  • From detha@110:110/2002 to All on Tue Dec 31 05:33:15 2013
    On Mon, 30 Dec 2013 23:35:34 +0000, unruh wrote:

    On 2013-12-30, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
    [quoted text muted]

    They all come with firewalls activated by default. Often those firewalls
    by default are maximum firewalls (ie reject everything incoming, including pings.)

    Examples? The only things I know of that do not respond to ICMP ping out-of-the-box are recent Windows versions, and the odd firewall
    distribution.

    -d


    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: whoever pays best (110:110/2002@linuxnet)
  • From Jorgen Grahn@1:0/0 to All on Tue Dec 31 10:15:54 2013
    On Tue, 2013-12-31, detha wrote:
    On Mon, 30 Dec 2013 23:35:34 +0000, unruh wrote:

    On 2013-12-30, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
    [quoted text muted]

    They all come with firewalls activated by default. Often those firewalls
    by default are maximum firewalls (ie reject everything incoming, including >> pings.)

    Examples?

    He wrote "all", so it's already obvious he doesn't know what he's
    talking about.

    The only things I know of that do not respond to ICMP ping
    out-of-the-box are recent Windows versions, [...]

    Even that strikes me as odd. The benefits of complicating IP
    troubleshooting that way seem insignificant in all scenarios I can
    think of. I.e. what dangerous things can you do with ICMP echo that
    you cannot do with a TCP SYN? (Not counting broadcast ping.)

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From detha@110:110/2002 to All on Tue Dec 31 13:15:23 2013
    On Tue, 31 Dec 2013 10:15:54 +0000, Jorgen Grahn wrote:

    On Tue, 2013-12-31, detha wrote:


    The only things I know of that do not respond to ICMP ping
    out-of-the-box are recent Windows versions, [...]

    Even that strikes me as odd. The benefits of complicating IP
    troubleshooting that way seem insignificant in all scenarios I can think
    of. I.e. what dangerous things can you do with ICMP echo that you cannot
    do with a TCP SYN? (Not counting broadcast ping.)

    Security by obscurity. What the script kiddie doesn't see in a ping or
    nmap scan it won't try to exploit.

    That's the only plausible reason I can think of, and yes it has caused me endless grief in faultfinding - try walking an untrained user through
    enabling ICMP in the firewall, over the phone :P

    -d

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: whoever pays best (110:110/2002@linuxnet)
  • From David Brown@110:110/2002 to All on Tue Dec 31 14:01:13 2013
    On 31/12/13 14:15, detha wrote:
    On Tue, 31 Dec 2013 10:15:54 +0000, Jorgen Grahn wrote:

    On Tue, 2013-12-31, detha wrote:


    The only things I know of that do not respond to ICMP ping
    out-of-the-box are recent Windows versions, [...]

    Even that strikes me as odd. The benefits of complicating IP
    troubleshooting that way seem insignificant in all scenarios I can think
    of. I.e. what dangerous things can you do with ICMP echo that you cannot
    do with a TCP SYN? (Not counting broadcast ping.)

    Security by obscurity. What the script kiddie doesn't see in a ping or
    nmap scan it won't try to exploit.


    That's exactly right. Many "drive-by" hacking attempts do pings first -
    and if they fail, then the attacker (or script) just moves on to the
    next target. It is not security as such - ICMP is seldom used in the
    actual attack. But it can reduce the number of attack attempts, saving
    your /real/ security system effort (less wasted bandwidth, less extra
    log file lines, etc.). It is much the same as putting your sshd daemon
    on a non-standard port.

    That's the only plausible reason I can think of, and yes it has caused me endless grief in faultfinding - try walking an untrained user through enabling ICMP in the firewall, over the phone :P


    And there you see the disadvantage of it - it's a pain in fault-finding.
    But those of us who have to deal with Windows machines on a network,
    are used to that particular pain. And as usual, Linux has the remedy - "arping" works at a lower level than ICMP, and is not blocked by
    firewalls. Of course, it only works on the same network segment and
    will not pass through routers, but I find it /very/ useful.



    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:110/2002@linuxnet)
  • From Pascal Hambourg@110:110/2002 to All on Tue Dec 31 18:13:23 2013
    Reply-To: pascal.news@plouf.fr.eu.org

    Unknown a ‚crit :

    1= plug cross-over cat-cable between PC1 <-> PC2.
    2= PC1: ifconfig eth0 192.168.0.1
    PC2: ifconfig eth0 192.168.0.2
    See LEDs on PC1 connector light-up.

    What is the minimal command/s to confirm that each PC detects the other?

    ifconfig should display the flag "RUNNING" for each interface.

    What is the minimal command/s to transfer a file from 'src -> dest'?

    man nc (netcat).

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: Plouf ! (110:110/2002@linuxnet)
  • From Unknown@110:110/2002 to All on Tue Dec 31 18:23:47 2013
    On Mon, 30 Dec 2013 21:49:04 +0000, Bit Twister wrote:

    On Mon, 30 Dec 2013 21:39:19 +0000 (UTC), Unknown wrote:

    Please lets confirm each stage.
    Like seeing the actual water-flowing-in-the-pipe.

    1= plug cross-over cat-cable between PC1 <-> PC2. 2= PC1: ifconfig eth0
    192.168.0.1
    PC2: ifconfig eth0 192.168.0.2
    See LEDs on PC1 connector light-up.

    What is the minimal command/s to confirm that each PC detects the
    other?

    PC1: ping -c1 192.168.0.2
    PC2: ping -c1 192.168.0.1

    What is the minimal command/s to transfer a file from 'src -> dest'?

    PC1: scp fn_here $USER@192.168.0.2:/wherever/fn_here

    copy a whole directory:
    PC1: rsync /some/dir/ $USER@192.168.0.2:/some/dir

    OK, thanks.
    rsync /var/CONTROL/* pi@192.168.0.2:/home/pi/MOBO
    pi@192.168.0.2's password:
    copies all files of /var/CONTROL/* into /home/pi/MOBO/

    It's quiet a big story.

    I'm used to `mc`, where you can see the file / dir,
    and just reach-out-and-copy/move/delete it.

    Apparently mc does ftp; so I'll ask on their mail-list, now
    that I've confirmed that the connection works.


    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:110/2002@linuxnet)
  • From Bit Twister@110:110/2002 to All on Tue Dec 31 18:40:22 2013
    On Tue, 31 Dec 2013 18:23:47 +0000 (UTC), Unknown wrote:

    OK, thanks.
    rsync /var/CONTROL/* pi@192.168.0.2:/home/pi/MOBO
    pi@192.168.0.2's password:
    copies all files of /var/CONTROL/* into /home/pi/MOBO/

    Yes, but using my example, you should have done a
    rsync /var/CONTROL/ pi@192.168.0.2:/home/pi/MOBO

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:110/2002@linuxnet)
  • From ein@110:110/2002 to All on Tue Dec 31 18:42:29 2013
    Jorgen Grahn wrote:
    On Mon, 2013-12-30, unruh wrote:
    On 2013-12-30, Bit Twister <BitTwister@mouse-potato.com> wrote:
    On Mon, 30 Dec 2013 21:39:19 +0000 (UTC), Unknown wrote:

    Please lets confirm each stage.
    Like seeing the actual water-flowing-in-the-pipe.

    1= plug cross-over cat-cable between PC1 <-> PC2.

    Side note: recent NICs, switches etc don't care if the
    cables are crossed or not.

    2= PC1: ifconfig eth0 192.168.0.1
    PC2: ifconfig eth0 192.168.0.2
    See LEDs on PC1 connector light-up.

    What is the minimal command/s to confirm that each PC detects the other? >>>
    PC1: ping -c1 192.168.0.2
    PC2: ping -c1 192.168.0.1

    Well, only if there is no firewall which switches off pings. The default
    seems to be these days to disable pings.

    In Linux distributions? I find that hard to believe (and sad if it's
    true).

    As far as I remember CentoOS 6 has enabled firewall with preconfigured
    iptables rules.



    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: ATMAN - ATM S.A. (110:110/2002@linuxnet)
  • From ein@110:110/2002 to All on Tue Dec 31 18:48:45 2013
    Bit Twister wrote:
    On Mon, 30 Dec 2013 21:39:19 +0000 (UTC), Unknown wrote:

    Please lets confirm each stage.
    Like seeing the actual water-flowing-in-the-pipe.

    1= plug cross-over cat-cable between PC1 <-> PC2.
    2= PC1: ifconfig eth0 192.168.0.1

    You forgot about "up"

    PC2: ifconfig eth0 192.168.0.2

    Again.

    See LEDs on PC1 connector light-up.

    About LEDs thing, behavior like this is hardware specific. LEDs *can*
    turn on just after cable plug. Interface state *can* has no influence at
    LEDs.


    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: ATMAN - ATM S.A. (110:110/2002@linuxnet)
  • From unruh@110:110/2002 to All on Tue Dec 31 19:02:10 2013
    On 2013-12-31, detha <detha@foad.co.za> wrote:
    On Mon, 30 Dec 2013 23:35:34 +0000, unruh wrote:

    On 2013-12-30, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
    [quoted text muted]

    They all come with firewalls activated by default. Often those firewalls
    by default are maximum firewalls (ie reject everything incoming, including >> pings.)

    Examples? The only things I know of that do not respond to ICMP ping out-of-the-box are recent Windows versions, and the odd firewall distribution.

    -d

    I just installed a Mageia 2 distro which had ping disabled in the
    firewall, just as an example.
    Note as I said, the ping disabling IS the firewall, and then you say tht
    the "odd" firewall does it. Well, not so sure it is "odd" but it is
    firewall.


    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:110/2002@linuxnet)
  • From unruh@110:110/2002 to All on Tue Dec 31 19:07:04 2013
    On 2013-12-31, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
    On Tue, 2013-12-31, detha wrote:
    On Mon, 30 Dec 2013 23:35:34 +0000, unruh wrote:

    On 2013-12-30, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
    [quoted text muted]

    They all come with firewalls activated by default. Often those firewalls >>> by default are maximum firewalls (ie reject everything incoming, including >>> pings.)

    Examples?

    He wrote "all", so it's already obvious he doesn't know what he's
    talking about.

    Uh, early start on New Year's celebrations?
    The All come with firewalls activated. I believe that is true, but I
    will admit I have not tested all distros.
    Then regarding ping, "Often" ....


    The only things I know of that do not respond to ICMP ping
    out-of-the-box are recent Windows versions, [...]

    Even that strikes me as odd. The benefits of complicating IP
    troubleshooting that way seem insignificant in all scenarios I can
    think of. I.e. what dangerous things can you do with ICMP echo that
    you cannot do with a TCP SYN? (Not counting broadcast ping.)

    I have read that some regard pings as a security risk. In particular it
    allows an attacker to know that there is actually a computer attached to
    some IP address. That knowledge is useful in attacking that computer.

    I do agree that ping SHOULD be enabled by default.

    /Jorgen


    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:110/2002@linuxnet)
  • From unruh@110:110/2002 to All on Tue Dec 31 19:13:29 2013
    On 2013-12-31, Unknown <dog@gmail.com> wrote:
    On Mon, 30 Dec 2013 21:49:04 +0000, Bit Twister wrote:

    On Mon, 30 Dec 2013 21:39:19 +0000 (UTC), Unknown wrote:

    Please lets confirm each stage.
    Like seeing the actual water-flowing-in-the-pipe.

    1= plug cross-over cat-cable between PC1 <-> PC2. 2= PC1: ifconfig eth0
    192.168.0.1
    PC2: ifconfig eth0 192.168.0.2
    See LEDs on PC1 connector light-up.

    What is the minimal command/s to confirm that each PC detects the
    other?

    PC1: ping -c1 192.168.0.2
    PC2: ping -c1 192.168.0.1

    What is the minimal command/s to transfer a file from 'src -> dest'?

    PC1: scp fn_here $USER@192.168.0.2:/wherever/fn_here

    copy a whole directory:
    PC1: rsync /some/dir/ $USER@192.168.0.2:/some/dir

    OK, thanks.
    rsync /var/CONTROL/* pi@192.168.0.2:/home/pi/MOBO
    pi@192.168.0.2's password:
    copies all files of /var/CONTROL/* into /home/pi/MOBO/

    It's quiet a big story.

    Yes. You told it to copy all of the files in /var/CONTROL and it did so.
    If you did not want it to copy all the files do not tell it to copy all
    the files.
    Note that if you give rsync a directory name, it will copy over all the
    files and directories under that directory ( and watch what happens if
    you terminate with a / or not) . If you give it a filename it will copy
    just that file.


    I'm used to `mc`, where you can see the file / dir,
    and just reach-out-and-copy/move/delete it.

    Great. There you have 10000 files you want to transfer and you have to
    pick them out one by one.


    Apparently mc does ftp; so I'll ask on their mail-list, now
    that I've confirmed that the connection works.

    IF you have one or two files to transfer and you forgot their name, mc
    is a good idea. If not, it is pretty terrible.
    One advantage of rsync is that it also hashes the file to make sure it
    got transferred correctly.
    But use whatever tools you want.





    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:110/2002@linuxnet)
  • From Keith Keller@110:110/2002 to All on Tue Dec 31 19:20:40 2013
    On 2013-12-31, David Brown <david.brown@hesbynett.no> wrote:

    And there you see the disadvantage of it - it's a pain in fault-finding.

    One compromise is to block or discard ICMP only from external hosts.
    This way you can still perform troubleshooting with ping internally,
    but external attackers can't find your hosts easily. This can be done
    at the public-facing router or at each internal host. What you give up
    in this instance is, if an internal host is compromised, the attacker
    can now use ping to report other hosts, but in that scenario it seems
    like you have bigger problems than an attacker knowing your hosts.
    (OTOH, if you're blocking all ICMP, and reporting them somewhere, then receiving such a report might expose a compromised host earlier.)

    --keith


    --
    kkeller-usenet@wombat.san-francisco.ca.us
    (try just my userid to email me) AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
    see X- headers for PGP signature information


    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:110/2002@linuxnet)
  • From Keith Keller@110:110/2002 to All on Tue Dec 31 19:16:20 2013
    On 2013-12-31, Unknown <dog@gmail.com> wrote:
    On Mon, 30 Dec 2013 21:49:04 +0000, Bit Twister wrote:

    copy a whole directory:
    PC1: rsync /some/dir/ $USER@192.168.0.2:/some/dir

    rsync /var/CONTROL/* pi@192.168.0.2:/home/pi/MOBO
    pi@192.168.0.2's password:
    copies all files of /var/CONTROL/* into /home/pi/MOBO/

    If you haven't already (and we know you haven't, because you never do),
    read the man page for rsync to see what the differences are between your command, Bit Twister's, and omitting the trailing / on the source
    directory. All three are subtly different. Also consider the
    difference between

    ls -a
    ls -ad *

    --keith

    --
    kkeller-usenet@wombat.san-francisco.ca.us
    (try just my userid to email me) AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
    see X- headers for PGP signature information


    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:110/2002@linuxnet)
  • From Avoid9Pdf@gmail.com@110:110/2002 to All on Wed Jan 1 02:28:48 2014
    In article <slrnlc63sm.iis.BitTwister@wb.home.test>, Bit Twister <BitTwister@mouse-potato.com> wrote:

    On Tue, 31 Dec 2013 18:23:47 +0000 (UTC), Unknown wrote:

    OK, thanks.
    rsync /var/CONTROL/* pi@192.168.0.2:/home/pi/MOBO
    pi@192.168.0.2's password:
    copies all files of /var/CONTROL/* into /home/pi/MOBO/

    Yes, but using my example, you should have done a
    rsync /var/CONTROL/ pi@192.168.0.2:/home/pi/MOBO

    Here's the log:-------------
    rsync /var/CONTROL/ $USER@192.168.0.2:/home/pi/MOBO
    pi@192.168.0.2's password:
    skipping directory .

    rsync /var/CONTROL/* pi@192.168.0.2:/home/pi/MOBO
    pi@192.168.0.2's password:
    copies all files of /var/CONTROL/* into /home/pi/MOBO/
    ------------ end of log paste ---------

    I see now: the verbage/word-clutter confused me.
    But a script at each side hides the clutter: 2rPi <File> , 2PC <file>

    So now, can't I also easily *RUN* the rPi from the PC's nice display?

    NB. PC is x86 hardware and rPi is ARM hardware;
    so: from PC-keybrd <gcc ...>
    means that rPi should act as if <gcc ...> was entered to its keybrd.

    How would I do that?

    == TIA.


    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:110/2002@linuxnet)
  • From Unknown@110:110/2002 to All on Wed Jan 1 03:11:04 2014
    On Tue, 31 Dec 2013 19:13:29 +0000, unruh wrote:

    On 2013-12-31, Unknown <dog@gmail.com> wrote:
    On Mon, 30 Dec 2013 21:49:04 +0000, Bit Twister wrote:

    On Mon, 30 Dec 2013 21:39:19 +0000 (UTC), Unknown wrote:

    Please lets confirm each stage.
    Like seeing the actual water-flowing-in-the-pipe.

    1= plug cross-over cat-cable between PC1 <-> PC2. 2= PC1: ifconfig
    eth0 192.168.0.1
    PC2: ifconfig eth0 192.168.0.2
    See LEDs on PC1 connector light-up.

    What is the minimal command/s to confirm that each PC detects the
    other?

    PC1: ping -c1 192.168.0.2
    PC2: ping -c1 192.168.0.1

    What is the minimal command/s to transfer a file from 'src -> dest'?

    PC1: scp fn_here $USER@192.168.0.2:/wherever/fn_here

    copy a whole directory:
    PC1: rsync /some/dir/ $USER@192.168.0.2:/some/dir

    OK, thanks.
    rsync /var/CONTROL/* pi@192.168.0.2:/home/pi/MOBO pi@192.168.0.2's
    password:
    copies all files of /var/CONTROL/* into /home/pi/MOBO/

    It's quiet a big story.

    Yes. You told it to copy all of the files in /var/CONTROL and it did so.
    If you did not want it to copy all the files do not tell it to copy all
    the files.
    Note that if you give rsync a directory name, it will copy over all the
    files and directories under that directory ( and watch what happens if
    you terminate with a / or not) . If you give it a filename it will copy
    just that file.


    I'm used to `mc`, where you can see the file / dir, and just
    reach-out-and-copy/move/delete it.

    Great. There you have 10000 files you want to transfer and you have to
    pick them out one by one.

    mc allows moving a dir-tree with 2 or 3 key-strokes.
    Plus giving visual confirmation: <scr has gone> and <dest has appeared>.


    Apparently mc does ftp; so I'll ask on their mail-list, now that I've
    confirmed that the connection works.

    IF you have one or two files to transfer and you forgot their name, mc
    is a good idea. If not, it is pretty terrible. One advantage of rsync is
    that it also hashes the file to make sure it got transferred correctly.
    But use whatever tools you want.

    Our very different views are probably due to this being a networking
    group, and emphasising bulk delivery.
    OTOH my problems entail a dozen files, hopefully mostly in the same
    directory [of THAT project]. I don't want to remember names, when mc
    allows me to just *recognise* <yes, gime that one>.

    Your pov is the delivery-van load of items.
    My pov is the clerk at his desk with 8 docos open, and 2 more just
    arrived. Once I've identified the doco, I don't want to remember it's
    name. It's just <the small green one>.

    Names/verbalising are for communication between-people.
    mc/visualisation is easier and more efficient for self-communication.


    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:110/2002@linuxnet)
  • From detha@110:110/2002 to All on Wed Jan 1 09:43:35 2014
    On Tue, 31 Dec 2013 19:42:29 +0100, ein wrote:

    Jorgen Grahn wrote:
    On Mon, 2013-12-30, unruh wrote:
    On 2013-12-30, Bit Twister <BitTwister@mouse-potato.com> wrote:


    Well, only if there is no firewall which switches off pings. The
    default seems to be these days to disable pings.

    In Linux distributions? I find that hard to believe (and sad if it's
    true).

    As far as I remember CentoOS 6 has enabled firewall with preconfigured iptables rules.

    Yes, sensible ones. Allow icmp, and allow ssh access to further configure
    the machine.

    -d

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: whoever pays best (110:110/2002@linuxnet)
  • From detha@110:110/2002 to All on Wed Jan 1 09:54:29 2014
    On Tue, 31 Dec 2013 19:02:10 +0000, unruh wrote:

    On 2013-12-31, detha <detha@foad.co.za> wrote:
    On Mon, 30 Dec 2013 23:35:34 +0000, unruh wrote:

    On 2013-12-30, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
    [quoted text muted]

    They all come with firewalls activated by default. Often those
    firewalls by default are maximum firewalls (ie reject everything
    incoming, including pings.)

    Examples? The only things I know of that do not respond to ICMP ping
    out-of-the-box are recent Windows versions, and the odd firewall
    distribution.

    -d

    I just installed a Mageia 2 distro which had ping disabled in the
    firewall, just as an example.
    Note as I said, the ping disabling IS the firewall, and then you say tht
    the "odd" firewall does it. Well, not so sure it is "odd" but it is
    firewall.

    Don't know Mageia - from a quick look it seems to be one of the
    fluffy-fied distros that wants to be windows.

    'The odd firewall distro' referring to distributions that are primarily intended to be used as router/firewall, like Shorewall or Untangle.

    -d

    -d


    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: whoever pays best (110:110/2002@linuxnet)
  • From detha@110:110/2002 to All on Wed Jan 1 10:03:39 2014
    On Tue, 31 Dec 2013 11:20:40 -0800, Keith Keller wrote:

    On 2013-12-31, David Brown <david.brown@hesbynett.no> wrote:

    And there you see the disadvantage of it - it's a pain in fault-finding.

    One compromise is to block or discard ICMP only from external hosts. This
    way you can still perform troubleshooting with ping internally, but
    external attackers can't find your hosts easily. This can be done at the public-facing router or at each internal host. What you give up in this instance is, if an internal host is compromised, the attacker can now use ping to report other hosts, but in that scenario it seems like you have bigger problems than an attacker knowing your hosts. (OTOH, if you're blocking all ICMP, and reporting them somewhere, then receiving such a
    report might expose a compromised host earlier.)

    --keith

    That doesn't help in debugging routing problems - and as someone already
    said, once you are on the local segment there are tools like arping etc.,
    so it doesn't really add anything.

    Agreed that incoming icmp ping could at least be rate-limited at the
    perimeter firewall. But completely blocking all icmp breaks too much.

    Interesting tidbit: I encountered a firewall the other day that drops
    ICMP echo requests with an incorrect checksum in the ICMP header. Still
    have to investigate /why/ that incorrect checksum was there in the first
    place (something to do with upgrading to latest OpenBSD and NAT rules that don't exclude the case where the packet originates from local machine)

    -d


    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: whoever pays best (110:110/2002@linuxnet)
  • From Aragorn@110:110/2002 to All on Wed Jan 1 11:08:31 2014
    On Wednesday 01 January 2014 10:54, detha conveyed the following to comp.os.linux.networking...

    Don't know Mageia - from a quick look it seems to be one of the
    fluffy-fied distros that wants to be windows.

    Mageia is a Mandriva (formerly Mandrake) spin-off, and it is definitely
    not a Windows wannabe.

    Mandrake began its life as a RedHat clone with KDE added to it and with
    a more recent kernel, back in the days that KDE was still based upon
    non-free Qt libraries. Meanwhile - as of KDE 2.0 onward - KDE is based
    upon Qt libraries which satisfy the requirements of Free/Libre & Open
    Source Software, but RedHat continued to refuse to support KDE for a
    long time still after that and even engaged in KDE bashing campaigns.

    Since that time, Mandrake evolved and developed its own configuration
    and management tools, but it stayed true to what would later on become
    known as the Linux Standards Base. KDE has always been its preferred
    desktop environment, but GNOME and XFCE were also supported, as were all
    kinds of window managers, from twm and fvwm on to WindowMaker,
    AfterStep, BlackBox/FluxBox and even Enlightenment.

    Somewhere in the middle of the past decade, MandrakeSoft, which was a French-American distribution, merged with Conectiva, a South American distribution, and the merger became known as Mandriva. Mandriva as a corporation was heavily plagued by severe mismanagement, and over the
    years many developers were laid off. Eventually, at the end of the past decade, those developers had enough of the corporate mismanagement and
    decided to fork the distribution and release it as a community-developed distro only. There still is a great deal of similarity or even
    parallelism between Mandriva - which now aims more towards the corporate
    user and cloud services - and Mageia, but Mageia now survives on its own thanks to the community.

    Now, I personally don't like some decisions [*] made at Mageia with
    regard to the chosen upstream - which is still following RedHat - but referring to Mageia as a Windows-wannabe is doing it a great disservice. Also, it is one of the few distributions of which you will actually find developers and QA people in the distro-specific Usenet newsgroup - in
    casu, alt.os.linux.mageia.


    [*] The whole systemd/logind/journald thing, and especially the "/usr
    move", whereby /bin, /sbin and /lib become symbolic links to
    /usr/bin and /usr/lib respectively - /usr/sbin is also merged into
    /usr/bin - which makes it impossible to still boot the system
    without an initramfs - e.g. if you build your own kernel - when the
    population of /usr is not on the same filesystem as /.

    --
    = Aragorn =

    http://www.linuxcounter.net - registrant #223157

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: A noiseless patient Strider (110:110/2002@linuxnet)
  • From Jorgen Grahn@1:0/0 to All on Wed Jan 1 11:26:08 2014
    On Tue, 2013-12-31, David Brown wrote:
    On 31/12/13 14:15, detha wrote:
    On Tue, 31 Dec 2013 10:15:54 +0000, Jorgen Grahn wrote:

    On Tue, 2013-12-31, detha wrote:


    The only things I know of that do not respond to ICMP ping
    out-of-the-box are recent Windows versions, [...]

    Even that strikes me as odd. The benefits of complicating IP
    troubleshooting that way seem insignificant in all scenarios I can think >>> of. I.e. what dangerous things can you do with ICMP echo that you cannot >>> do with a TCP SYN? (Not counting broadcast ping.)

    Security by obscurity. What the script kiddie doesn't see in a ping or
    nmap scan it won't try to exploit.

    That's exactly right. Many "drive-by" hacking attempts do pings first -
    and if they fail, then the attacker (or script) just moves on to the
    next target. It is not security as such - ICMP is seldom used in the
    actual attack. But it can reduce the number of attack attempts, saving
    your /real/ security system effort (less wasted bandwidth, less extra
    log file lines, etc.).

    But it seems to me that would just mean the bad guys switch to probing
    via TCP SYN instead, to the few ports they are interested in? Blocking
    ping seems useful if a small minority do it, not if every Windows box
    in the world does.

    It is much the same as putting your sshd daemon
    on a non-standard port.

    Granted, such a machine would be harder to find, if you're picking a non-obvious non-standard port. On the other hand, OpenBSD's sshd is
    one of the few daemons I trust to be secure, so if that's all I intend
    to run I'm not imclined to try to hide it.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From detha@110:110/2002 to All on Wed Jan 1 11:34:40 2014
    On Wed, 01 Jan 2014 11:26:08 +0000, Jorgen Grahn wrote:

    On Tue, 2013-12-31, David Brown wrote:

    It is much the same as putting your sshd daemon on a non-standard port.

    Granted, such a machine would be harder to find, if you're picking a non-obvious non-standard port. On the other hand, OpenBSD's sshd is one
    of the few daemons I trust to be secure, so if that's all I intend to run
    I'm not imclined to try to hide it.


    There is one case where hiding sshd makes sense: if the internet link is usage-capped, with a low cap and relatively high speed. Brute-forcers can
    burn through that cap at a rapid pace.

    -d


    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: whoever pays best (110:110/2002@linuxnet)
  • From David Brown@110:110/2002 to All on Wed Jan 1 11:50:04 2014
    On 01/01/14 12:26, Jorgen Grahn wrote:
    On Tue, 2013-12-31, David Brown wrote:
    On 31/12/13 14:15, detha wrote:
    On Tue, 31 Dec 2013 10:15:54 +0000, Jorgen Grahn wrote:

    On Tue, 2013-12-31, detha wrote:


    The only things I know of that do not respond to ICMP ping
    out-of-the-box are recent Windows versions, [...]

    Even that strikes me as odd. The benefits of complicating IP
    troubleshooting that way seem insignificant in all scenarios I can think >>>> of. I.e. what dangerous things can you do with ICMP echo that you cannot >>>> do with a TCP SYN? (Not counting broadcast ping.)

    Security by obscurity. What the script kiddie doesn't see in a ping or
    nmap scan it won't try to exploit.

    That's exactly right. Many "drive-by" hacking attempts do pings first -
    and if they fail, then the attacker (or script) just moves on to the
    next target. It is not security as such - ICMP is seldom used in the
    actual attack. But it can reduce the number of attack attempts, saving
    your /real/ security system effort (less wasted bandwidth, less extra
    log file lines, etc.).

    But it seems to me that would just mean the bad guys switch to probing
    via TCP SYN instead, to the few ports they are interested in? Blocking
    ping seems useful if a small minority do it, not if every Windows box
    in the world does.

    That is correct, and the "value" of blocking ICMP decreases over time.
    It certainly used to be the case that dropping pings would greatly
    reduce your chances of being attacked, since scripts would ping first
    before checking other ports. I am confident that some scripts (or bad
    guys) will go straight to port 80, port 22, etc., and skip the ping.
    But I don't know of any statistics here - it would be interesting to get
    an idea of the numbers.


    It is much the same as putting your sshd daemon
    on a non-standard port.

    Granted, such a machine would be harder to find, if you're picking a non-obvious non-standard port. On the other hand, OpenBSD's sshd is
    one of the few daemons I trust to be secure, so if that's all I intend
    to run I'm not imclined to try to hide it.

    /Jorgen


    Certainly hiding does not increase its security - if you've got bad
    passwords or other weaknesses in your daemons, hiding does not help.

    The hiding - whether it be with non-standard ports or with dropping
    pings - is about avoiding getting an attack, rather than about surviving
    an attack. It means less resource usage for you (such as wasted
    bandwidth), fewer log lines to wade through looking for /real/ problems,
    and a smaller chance of being unlucky or being hit by newly discovered vulnerabilities. You are simply encouraging the bad guys to move on to
    easier targets.

    It also gives you the possibility of setting up more sophisticated
    firewalls and intrusion detection - if you know that your ssh is not on
    port 22, and that anyone with a valid reason for ssh'ing into your
    system also knows that, then any IP address hitting port 22 can be
    immediately blacklisted. (Of course, that's going to annoy you the
    first time you forget to specify the port when ssh'ing yourself...)
    Similarly, you can detect various types of scans and use that for blacklisting.

    Of course, it is a bit of an arms race - the bad guys then have to make
    more sophisticated scans to avoid detection, and so on. But if you are
    ahead of the masses, the bad guys will go for easier targets.





    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:110/2002@linuxnet)
  • From Chris Davies@110:110/2002 to All on Wed Jan 1 16:23:29 2014
    Reply-To: chris@roaima.co.uk

    unruh <unruh@invalid.ca> wrote:
    On 2013-12-30, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
    On Mon, 2013-12-30, unruh wrote:
    Well, only if there is no firewall which switches off pings. The default >>> seems to be these days to disable pings.

    In Linux distributions? I find that hard to believe (and sad if it's
    true).

    They all come with firewalls activated by default. Often those firewalls
    by default are maximum firewalls (ie reject everything incoming,
    including pings.)

    Debian with no "tasksel" options chosen results in a minimal working
    system. No firewall, but no listening services either. Perfect starting
    point for installation of server-centric applications and services (yes, including a firewall layer of my choice).

    Chris

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: Roaima. Harrogate, North Yorkshire, UK (110:110/2002@linuxnet)
  • From unruh@110:110/2002 to All on Wed Jan 1 19:08:20 2014
    On 2014-01-01, detha <detha@foad.co.za> wrote:
    On Tue, 31 Dec 2013 19:02:10 +0000, unruh wrote:

    On 2013-12-31, detha <detha@foad.co.za> wrote:
    On Mon, 30 Dec 2013 23:35:34 +0000, unruh wrote:

    On 2013-12-30, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
    [quoted text muted]

    They all come with firewalls activated by default. Often those
    firewalls by default are maximum firewalls (ie reject everything
    incoming, including pings.)

    Examples? The only things I know of that do not respond to ICMP ping
    out-of-the-box are recent Windows versions, and the odd firewall
    distribution.

    -d

    I just installed a Mageia 2 distro which had ping disabled in the
    firewall, just as an example.
    Note as I said, the ping disabling IS the firewall, and then you say tht
    the "odd" firewall does it. Well, not so sure it is "odd" but it is
    firewall.

    Don't know Mageia - from a quick look it seems to be one of the
    fluffy-fied distros that wants to be windows.

    It is nice to live in a world in which your assumptions are always
    facts, isn't it.


    'The odd firewall distro' referring to distributions that are primarily intended to be used as router/firewall, like Shorewall or Untangle.

    -d

    -d


    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:110/2002@linuxnet)
  • From Jorgen Grahn@1:0/0 to All on Thu Jan 2 21:24:53 2014
    On Tue, 2013-12-31, unruh wrote:
    On 2013-12-31, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
    On Tue, 2013-12-31, detha wrote:
    On Mon, 30 Dec 2013 23:35:34 +0000, unruh wrote:

    On 2013-12-30, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
    [quoted text muted]

    They all come with firewalls activated by default. Often those firewalls >>>> by default are maximum firewalls (ie reject everything incoming, including
    pings.)

    Examples?

    He wrote "all", so it's already obvious he doesn't know what he's
    talking about.

    Uh, early start on New Year's celebrations?

    No, just grumpy. Sorry.

    The All come with firewalls activated. I believe that is true, but I
    will admit I have not tested all distros.

    That's a much more sensible statement.

    My recent experience is limited to Debian, and it doesn't do this. It
    will configure networking, and then it's up to you if you want a
    firewall. (I use pure iptables myself, but I don't try to hide myself
    using it.)

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From Michael Black@1:0/0 to All on Tue Jan 14 04:00:22 2014
    On Tue, 31 Dec 2013, unruh wrote:

    On 2013-12-31, detha <detha@foad.co.za> wrote:
    On Mon, 30 Dec 2013 23:35:34 +0000, unruh wrote:

    On 2013-12-30, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
    [quoted text muted]

    They all come with firewalls activated by default. Often those firewalls >>> by default are maximum firewalls (ie reject everything incoming, including >>> pings.)

    Examples? The only things I know of that do not respond to ICMP ping
    out-of-the-box are recent Windows versions, and the odd firewall
    distribution.

    -d

    I just installed a Mageia 2 distro which had ping disabled in the
    firewall, just as an example.
    Note as I said, the ping disabling IS the firewall, and then you say tht
    the "odd" firewall does it. Well, not so sure it is "odd" but it is
    firewall.


    No, he's saying the specialized distributions intended as firewalls would
    have just about everything turned off. That makes sense, if it's to put a firewall on a separate machine, you are heavy duty, and want everything blocked until you tell it otherwise.

    I don't have experience with other distributions, but it doesn't seem like
    the firewall is the default here.

    Michael


    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: National Capital Freenet, Ottawa, Ontario, C