Hi,
I used to use netcat to check if a particular host is up or if I have internet connection before I run a few scripts. I would use the -z option in particular. But now I see that has been removed:
$ nc -z imap.gmail.com 993 && sync-my-email.sh ncat: invalid option -- 'z'
Here is the excerpt from the old manual page:
-z Specifies that nc should just scan for listening daemons, without sending any data to them. It is an error to use this option in conjunction with the -l option.
Any ideas what happened to it? What can I use as replacement?
Thanks for any ideas.
On Tue, Feb 12, 2013 at 8:21 PM, Suvayu Ali fatkasuvayu+linux@gmail.com wrote:
Hi,
I used to use netcat to check if a particular host is up or if I have internet connection before I run a few scripts. I would use the -z option in particular. But now I see that has been removed:
$ nc -z imap.gmail.com 993 && sync-my-email.sh ncat: invalid option -- 'z'
Here is the excerpt from the old manual page:
-z Specifies that nc should just scan for listening daemons, without sending any data to them. It is an error to use this option in conjunction with the -l option.
Any ideas what happened to it? What can I use as replacement?
Something like this perhaps.
$ 2>/dev/null >/dev/tcp/imap.gmail.com/993 && sync-my-email.sh
John
Hi John,
On Tue, Feb 12, 2013 at 08:37:27PM -0600, inode0 wrote:
Something like this perhaps.
$ 2>/dev/null >/dev/tcp/imap.gmail.com/993 && sync-my-email.sh
This works, but I don't think I understand it. Could you please explain?
Thanks,
On Wed, Feb 13, 2013 at 3:12 AM, Suvayu Ali fatkasuvayu+linux@gmail.com wrote:
Hi John,
On Tue, Feb 12, 2013 at 08:37:27PM -0600, inode0 wrote:
Something like this perhaps.
$ 2>/dev/null >/dev/tcp/imap.gmail.com/993 && sync-my-email.sh
This works, but I don't think I understand it. Could you please explain?
Bash provides built-in ways to manipulate sockets directly. You can read the REDIRECTION section of the bash man page to get the basics. Commonly these are used in conjunction with exec to open a socket, read and/or write data to the socket, then close the socket.
In the simple case here we just have bash attempt to open a tcp socket to imap.gmail.com on port 993 and return whether it was successful or not. The advantage of doing this is that we don't need to rely on any external program to perform such a simple test.
John
On 02/13/2013 09:44 PM, inode0 wrote:
On Wed, Feb 13, 2013 at 3:12 AM, Suvayu Ali fatkasuvayu+linux@gmail.com wrote:
Hi John,
On Tue, Feb 12, 2013 at 08:37:27PM -0600, inode0 wrote:
Something like this perhaps.
$ 2>/dev/null >/dev/tcp/imap.gmail.com/993 && sync-my-email.sh
This works, but I don't think I understand it. Could you please explain?
Bash provides built-in ways to manipulate sockets directly. You can read the REDIRECTION section of the bash man page to get the basics. Commonly these are used in conjunction with exec to open a socket, read and/or write data to the socket, then close the socket.
In the simple case here we just have bash attempt to open a tcp socket to imap.gmail.com on port 993 and return whether it was successful or not. The advantage of doing this is that we don't need to rely on any external program to perform such a simple test.
One thing of interest to note but which may not affect what the OP is doing....
If the port being tested is listed as "filtered" by nmap
[egreshko@meimei ~]$ nmap -Pn -p143 imap.gmail.com
Starting Nmap 6.01 ( http://nmap.org ) at 2013-02-13 21:53 CST Nmap scan report for imap.gmail.com (173.194.64.108) Host is up. Other addresses for imap.gmail.com (not scanned): 173.194.64.109 rDNS record for 173.194.64.108: oa-in-f108.1e100.net PORT STATE SERVICE 143/tcp filtered imap
the command
2>/dev/null >/dev/tcp/imap.gmail.com/143 && echo "yes"
will hang for quite some time....
On Wed, Feb 13, 2013 at 7:57 AM, Ed Greshko Ed.Greshko@greshko.com wrote:
One thing of interest to note but which may not affect what the OP is doing....
If the port being tested is listed as "filtered" by nmap
[egreshko@meimei ~]$ nmap -Pn -p143 imap.gmail.com
Starting Nmap 6.01 ( http://nmap.org ) at 2013-02-13 21:53 CST Nmap scan report for imap.gmail.com (173.194.64.108) Host is up. Other addresses for imap.gmail.com (not scanned): 173.194.64.109 rDNS record for 173.194.64.108: oa-in-f108.1e100.net PORT STATE SERVICE 143/tcp filtered imap
the command
2>/dev/null >/dev/tcp/imap.gmail.com/143 && echo "yes"
will hang for quite some time....
I don't think this is related to the port being filtered as other sites with filtered ports return quickly (same is true of down hosts). Perhaps it is some other rude firewall behavior that causes the delay?!
John
On 02/13/2013 10:43 PM, inode0 wrote:
On Wed, Feb 13, 2013 at 7:57 AM, Ed Greshko Ed.Greshko@greshko.com wrote:
One thing of interest to note but which may not affect what the OP is doing....
If the port being tested is listed as "filtered" by nmap
[egreshko@meimei ~]$ nmap -Pn -p143 imap.gmail.com
Starting Nmap 6.01 ( http://nmap.org ) at 2013-02-13 21:53 CST Nmap scan report for imap.gmail.com (173.194.64.108) Host is up. Other addresses for imap.gmail.com (not scanned): 173.194.64.109 rDNS record for 173.194.64.108: oa-in-f108.1e100.net PORT STATE SERVICE 143/tcp filtered imap
the command
2>/dev/null >/dev/tcp/imap.gmail.com/143 && echo "yes"
will hang for quite some time....
I don't think this is related to the port being filtered as other sites with filtered ports return quickly (same is true of down hosts). Perhaps it is some other rude firewall behavior that causes the delay?!
Well, basically, what the command is doing is causing a SYN packet to be sent out. If the host is down or the firewall doesn't send an RST,ACK it will "hang" until it times out.
So, since the OP is using to test if a system is "alive" a "dead" system will cause a substantial delay before timing out.
Hi John,
On Wed, Feb 13, 2013 at 07:44:56AM -0600, inode0 wrote:
On Wed, Feb 13, 2013 at 3:12 AM, Suvayu Ali fatkasuvayu+linux@gmail.com wrote:
On Tue, Feb 12, 2013 at 08:37:27PM -0600, inode0 wrote:
Something like this perhaps.
$ 2>/dev/null >/dev/tcp/imap.gmail.com/993 && sync-my-email.sh
This works, but I don't think I understand it. Could you please explain?
Bash provides built-in ways to manipulate sockets directly. You can read the REDIRECTION section of the bash man page to get the basics. Commonly these are used in conjunction with exec to open a socket, read and/or write data to the socket, then close the socket.
In the simple case here we just have bash attempt to open a tcp socket to imap.gmail.com on port 993 and return whether it was successful or not. The advantage of doing this is that we don't need to rely on any external program to perform such a simple test.
I know about redirection, but was not aware that I could also open sockets! Thanks a lot for the nice explanation, I'll read up more.
I think I'll end up using this solution as it seems the most portable.
Cheers,
:)
On 13Feb2013 16:03, Suvayu Ali fatkasuvayu+linux@gmail.com wrote: | I know about redirection, but was not aware that I could also open | sockets! Thanks a lot for the nice explanation, I'll read up more.
Unless bash has even more weirdness in it than I thought, the redirection is probably relying on a Linuxism to open a port via a Linux specific /dev entry. Plan 9 pioneered that mechanism. (That said, I know bash sometimes fakes up /dev/stdin etc for platform lacking them, so maybe it fakes /dev/tcp as well...)
| I think I'll end up using this solution as it seems the most portable.
To Linux alone, quite possibly.
Just a thought: why not just make your script fail gracefully it it can't connect? It would avoid all this "probing" that we're all discussing especially since the probing really amounts to "can I connect?" Your script will be trying that anyway, so why probe?
Cheers,
On 15Feb2013 08:48, Cameron Simpson cs@zip.com.au wrote:
On 13Feb2013 16:03, Suvayu Ali fatkasuvayu+linux@gmail.com wrote: | I know about redirection, but was not aware that I could also open | sockets! Thanks a lot for the nice explanation, I'll read up more.
Unless bash has even more weirdness in it than I thought, the redirection is probably relying on a Linuxism to open a port via a Linux specific /dev entry. Plan 9 pioneered that mechanism. (That said, I know bash sometimes fakes up /dev/stdin etc for platform lacking them, so maybe it fakes /dev/tcp as well...)
I had cause to look into this the other week. This isn't a linuxism, it is entirely bash internal i.e. even Linux doesn't have /dev/tcp/... to open a TCP connection. Plan 9 does of course, allowing all programs to do this easily.
Cheers, Cameron Simpson cs@zip.com.au
On 02/13/2013 10:21 AM, Suvayu Ali wrote:
Hi,
I used to use netcat to check if a particular host is up or if I have internet connection before I run a few scripts. I would use the -z option in particular. But now I see that has been removed:
$ nc -z imap.gmail.com 993 && sync-my-email.sh ncat: invalid option -- 'z'
Here is the excerpt from the old manual page:
-z Specifies that nc should just scan for listening daemons, without sending any data to them. It is an error to use this option in conjunction with the -l option.
Any ideas what happened to it? What can I use as replacement?
Thanks for any ideas.
tcping -u 1000000 imap.gmail.com 993 && sync-my-email.sh
Or, will less zeros ....
tcping -t 1 imap.gmail.com 993 :-) :-)
--
Specifically what's going on here is that fedora netcat is not the old netcat you know.
A little while back (I don't remember which release) it was replaced by nmap netcat (ncat):
[root@server ~]# rpm -qf /usr/bin/nc nmap-ncat-6.01-9.fc18.x86_64
This does not have the old -z option as you mention... tcping is the best of the options others have presented (no idea what that person was going on about netstat for...)
The other alternative to tcping is nmap ...
nmap -Pn -p993 imap.gmail.com
Hi James,
On Wed, Feb 13, 2013 at 08:45:39AM +0000, James Hogarth wrote:
Or, will less zeros ....
tcping -t 1 imap.gmail.com 993 :-) :-)
--
Specifically what's going on here is that fedora netcat is not the old netcat you know.
A little while back (I don't remember which release) it was replaced by nmap netcat (ncat):
[root@server ~]# rpm -qf /usr/bin/nc nmap-ncat-6.01-9.fc18.x86_64
This does not have the old -z option as you mention... tcping is the best of the options others have presented (no idea what that person was going on about netstat for...)
The other alternative to tcping is nmap ...
nmap -Pn -p993 imap.gmail.com
Thanks a lot! I had a suspicion the issue was something like this. This is extremely inconvenient though, since now I have to change quite a few scripts, more importantly now I also have to figure out the machine my script is running on (e.g. laptop or institutes servers).
I guess switching to nmap might resolve the second issue.
Cheers,
On Wed, Feb 13, 2013 at 10:18:44AM +0100, Suvayu Ali wrote:
On Wed, Feb 13, 2013 at 08:45:39AM +0000, James Hogarth wrote:
The other alternative to tcping is nmap ...
nmap -Pn -p993 imap.gmail.com
I guess switching to nmap might resolve the second issue.
This presents a different annoyance. Now I have to parse the output to determine if the port scan passed or failed since nmap returns 0 regardless of the results (which is understandable IMO). Now something simple like
$ nc -z imap.gmail.com 993 &> /dev/null && { ... }
becomes
$ nmap -Pn -p993 imap.gmail.com |& grep -q 'Host is up' && { ... }
And of course someday the printed text will change and I'll have to edit my scripts again! Oh well. :-/
On 02/13/2013 05:37 PM, Suvayu Ali wrote:
On Wed, Feb 13, 2013 at 10:18:44AM +0100, Suvayu Ali wrote:
On Wed, Feb 13, 2013 at 08:45:39AM +0000, James Hogarth wrote:
The other alternative to tcping is nmap ...
nmap -Pn -p993 imap.gmail.com
I guess switching to nmap might resolve the second issue.
This presents a different annoyance. Now I have to parse the output to determine if the port scan passed or failed since nmap returns 0 regardless of the results (which is understandable IMO). Now something simple like
$ nc -z imap.gmail.com 993 &> /dev/null && { ... }
becomes
$ nmap -Pn -p993 imap.gmail.com |& grep -q 'Host is up' && { ... }
And of course someday the printed text will change and I'll have to edit my scripts again! Oh well. :-/
I don't think that works very well..... Checking a port which isn't used...
[egreshko@meimei ~]$ nmap -Pn -p666 imap.gmail.com
Starting Nmap 6.01 ( http://nmap.org ) at 2013-02-13 17:41 CST Nmap scan report for imap.gmail.com (173.194.64.109) Host is up. Other addresses for imap.gmail.com (not scanned): 173.194.64.108 rDNS record for 173.194.64.109: oa-in-f109.1e100.net PORT STATE SERVICE 666/tcp filtered doom
Nmap done: 1 IP address (1 host up) scanned in 2.06 seconds
And you still get "Host is up" but, of course, the service you want isn't....
I would still use tcping....
[egreshko@meimei ~]$ tcping -t 1 imap.gmail.com 993 imap.gmail.com port 993 open. [egreshko@meimei ~]$ echo $? 0 [egreshko@meimei ~]$ tcping -t 1 imap.gmail.com 666 imap.gmail.com port 666 user timeout. [egreshko@meimei ~]$ echo $? 2
And you still get "Host is up" but, of course, the service you want isn't....
Err read the man page? -Pn assumes the host is up (skips the initial ping
in case something drops that when you are interested in a port) so it will say the host is up in that case - but we don't care about the host being up... we want the service so you need to parse the service output.
On 02/13/2013 05:47 PM, James Hogarth wrote:
And you still get "Host is up" but, of course, the service you want isn't....Err read the man page? -Pn assumes the host is up (skips the initial ping in case something drops that when you are interested in a port) so it will say the host is up in that case - but we don't care about the host being up... we want the service so you need to parse the service output.
My point being, grepping for "Host is up" doesn't fill the bill. You're saying what I said....just differently.
I still prefer tcping since there is no need to grep or awk anything. Or worry about text being changed in a later release. Just rely on exit status.
My point being, grepping for "Host is up" doesn't fill the bill. You're saying what I said....just differently.
I still prefer tcping since there is no need to grep or awk anything. Or worry about text being changed in a later release. Just rely on exit status.
Ah I agree on tcping being more elegant there - and there's potential security arguments to be had surrounding nmap on user systems if they don't actually need it for a real purpose ;)
I suspect we both wrote messages the same time surrounding 'host is up'
Hi Ed,
On Wed, Feb 13, 2013 at 05:55:53PM +0800, Ed Greshko wrote:
On 02/13/2013 05:47 PM, James Hogarth wrote:
I still prefer tcping since there is no need to grep or awk anything. Or worry about text being changed in a later release. Just rely on exit status.
I would use tcping too, if it were available on these other systems I expect my scripts to run on.
Thanks for spotting my dumb mistake in the parsing.
Cheers,
I would use tcping too, if it were available on these other systems I expect my scripts to run on.
Thanks for spotting my dumb mistake in the parsing.
Are you sure nmap is on all these systems? It quite often isn't (not a default package anyway) for security reasons (no need to make scanning the network any easier) ...
If you need to install nmap you might as well install tcping at the same time ;)
This is where tools like puppet become rapidly useful of course...
On Wed, Feb 13, 2013 at 10:10:47AM +0000, James Hogarth wrote:
I would use tcping too, if it were available on these other systems I expect my scripts to run on.
Thanks for spotting my dumb mistake in the parsing.
Are you sure nmap is on all these systems? It quite often isn't (not a default package anyway) for security reasons (no need to make scanning the network any easier) ...
Well, it is installed on the server I was testing on but then I realised that particular version does not recognize -Pn. So back to square one. :-/
If you need to install nmap you might as well install tcping at the same time ;)
Installing anything is out of the question since I do not have admin rights in any of these other machines.
I guess checking for installed packages is the only option left now.
On 02/13/2013 06:24 PM, Suvayu Ali wrote:
Installing anything is out of the question since I do not have admin rights in any of these other machines.
I guess checking for installed packages is the only option left now.
It is *not* out of the question. tcping doesn't need system privileges.
Download the tcping rpm... Then....
For example do this...
[egreshko@meimei ~]$ rpm2cpio tcping-1.3.5-7.fc18.x86_64.rpm | cpio -idv ./usr/bin/tcping ./usr/share/doc/tcping-1.3.5 ./usr/share/doc/tcping-1.3.5/LICENSE ./usr/share/doc/tcping-1.3.5/README 43 blocks
Now, since I keep user specific binaries in ~/bin
[egreshko@meimei ~]$ mv ./usr/bin/tcping bin/
[egreshko@meimei ~]$ bin/tcping -t 1 imap.gmail.com 993 imap.gmail.com port 993 open.
I'm a little hesitant to chime in, since I screwed up last time, but that brings up a question. In reading this thread, my first thought was "Well, if this guy wants GNU netcat, why not just download GNU netcat?"
Just for giggles, I dowloaded and compiled it from sourceforge, and it seems to work fine from a user home directory, and it has the -z option...
billo
On Wed, 13 Feb 2013, Ed Greshko wrote:
On 02/13/2013 06:24 PM, Suvayu Ali wrote:
Installing anything is out of the question since I do not have admin rights in any of these other machines.
I guess checking for installed packages is the only option left now.
It is *not* out of the question. tcping doesn't need system privileges.
Download the tcping rpm... Then....
For example do this...
[egreshko@meimei ~]$ rpm2cpio tcping-1.3.5-7.fc18.x86_64.rpm | cpio -idv ./usr/bin/tcping ./usr/share/doc/tcping-1.3.5 ./usr/share/doc/tcping-1.3.5/LICENSE ./usr/share/doc/tcping-1.3.5/README 43 blocks
Now, since I keep user specific binaries in ~/bin
[egreshko@meimei ~]$ mv ./usr/bin/tcping bin/
[egreshko@meimei ~]$ bin/tcping -t 1 imap.gmail.com 993 imap.gmail.com port 993 open.
-- Don't be bullied by the judgmental grammar and spelling police. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On Wed, Feb 13, 2013 at 02:11:09PM +0000, Bill Oliver wrote:
On Wed, 13 Feb 2013, Ed Greshko wrote:
On 02/13/2013 06:24 PM, Suvayu Ali wrote:
Installing anything is out of the question since I do not have admin rights in any of these other machines.
I guess checking for installed packages is the only option left now.
It is *not* out of the question. tcping doesn't need system privileges.
Download the tcping rpm... Then....
For example do this...
[egreshko@meimei ~]$ rpm2cpio tcping-1.3.5-7.fc18.x86_64.rpm | cpio -idv
[...]
I guess this would work too. I wasn't aware there were no dependencies for tcping. Since usually home directories are cross mounted on all machines on our cluster, putting the binary in home should be fine.
I'm a little hesitant to chime in, since I screwed up last time, but that brings up a question. In reading this thread, my first thought was "Well, if this guy wants GNU netcat, why not just download GNU netcat?"
Well, compiling my own means I need devel packages installed. They are not always available.
$ nmap -Pn -p993 imap.gmail.com |& grep -q 'Host is up' && { ... }
And of course someday the printed text will change and I'll have to edit my scripts again! Oh well. :-/
Host is up wouldn't be right - you need to parse to see if the port is listed as open or closed...
Something like:
nmap -Pn -p993 imap.gmail.com | awk '$1 ~ /993/ {print $2}' | grep open
Hi Ed and James,
On Wed, Feb 13, 2013 at 09:45:05AM +0000, James Hogarth wrote:
$ nmap -Pn -p993 imap.gmail.com |& grep -q 'Host is up' && { ... }
And of course someday the printed text will change and I'll have to edit my scripts again! Oh well. :-/
Host is up wouldn't be right - you need to parse to see if the port is listed as open or closed...
Something like:
nmap -Pn -p993 imap.gmail.com | awk '$1 ~ /993/ {print $2}' | grep open
I read the man page, but wasn't thinking when I wrote the grep line :-p. You are right, looking for the port/service is the correct way.
I think the older package was nc, but I'm not very much in for of checking versions. That would unnecessarily complicate my simple scripts. I cannot use tcping as Ed suggested because it is not installed in these other systems, hence parsing nmap output seems my only viable option.
Thanks a lot for all the help.
Cheers,
Thanks a lot! I had a suspicion the issue was something like this. This is extremely inconvenient though, since now I have to change quite a few scripts, more importantly now I also have to figure out the machine my script is running on (e.g. laptop or institutes servers).
I guess switching to nmap might resolve the second issue.
You could test if the package installed is netcat (or was it called nc?) or nmap-ncat and then execute as appropriate in your script.
On 13Feb2013 03:21, Suvayu Ali fatkasuvayu+linux@gmail.com wrote: | I used to use netcat to check if a particular host is up or if I have | internet connection before I run a few scripts. [...] | Any ideas what happened to it? What can I use as replacement?
If I want to know if I have an internet connection I look for a default route in the output of "netstat -an", thus:
netstat -rn | egrep '''^(default|0.0.0.0) +[1-9]''' >/dev/null
No default route - no general purpose internet connection. A default route but no connectivity? Then something else is wrong that needs fixing anyway.
Cheers,
On 13Feb2013 01:06, Patrick O'Callaghan pocallaghan@gmail.com wrote: | On Wed, 2013-02-13 at 14:40 +1100, Cameron Simpson wrote: | > If I want to know if I have an internet connection I look for a | > default | > route in the output of "netstat -an", thus: | > | > netstat -rn | egrep '''^(default|0.0.0.0) +[1-9]''' >/dev/null | | netstat -an ...
That prints all the existing connections and sockets. -rn prints the routing table.
On 13Feb2013 09:36, James Hogarth james.hogarth@gmail.com wrote: | > That prints all the existing connections and sockets. | > -rn prints the routing table. | > | and neither has anything to do with the OPs query...
The OP, Suvayu Ali, had as part of his query "or if I have internet connection ... What can I use as replacement" and I was supplying what I use, and why I consider it enough in most circumstances.
It may not be what he wants, but it is on topic.
On Wed, 2013-02-13 at 20:31 +1100, Cameron Simpson wrote:
On 13Feb2013 01:06, Patrick O'Callaghan pocallaghan@gmail.com wrote: | On Wed, 2013-02-13 at 14:40 +1100, Cameron Simpson wrote: | > If I want to know if I have an internet connection I look for a | > default | > route in the output of "netstat -an", thus: | > | > netstat -rn | egrep '''^(default|0.0.0.0) +[1-9]''' >/dev/null | | netstat -an ...
That prints all the existing connections and sockets. -rn prints the routing table.
I was merely pointing out that your two references to netstat use different options.
poc
On 13Feb2013 08:02, Patrick O'Callaghan pocallaghan@gmail.com wrote: | On Wed, 2013-02-13 at 20:31 +1100, Cameron Simpson wrote: | > On 13Feb2013 01:06, Patrick O'Callaghan pocallaghan@gmail.com wrote: | > | On Wed, 2013-02-13 at 14:40 +1100, Cameron Simpson wrote: | > | > If I want to know if I have an internet connection I look for a | > | > default | > | > route in the output of "netstat -an", thus: | > | > | > | > netstat -rn | egrep '''^(default|0.0.0.0) +[1-9]''' >/dev/null | > | | > | netstat -an ... | > | > That prints all the existing connections and sockets. | > -rn prints the routing table. | | I was merely pointing out that your two references to netstat use | different options.
Oh. Whoops; hadn't noticed my typo. -rn is the option set I meant, and that I use for "am I connected to the internet?" in my own scripts.
-
Cameron Simpson -
Ed Greshko -
inode0 -
James Hogarth -
Patrick O'Callaghan -
Suvayu Ali -
William Oliver