Fedora 24 and weexd Weather software
By Dale Reagan | July 17, 2016
I recently upgraded to Fedora 24 Workstation. I typically start my Linux builds with a ‘live’ image and then add what I need/want, including things that you might normally only run on a ‘pure’ server. Note that I do NOT suggest doing this for any system that is ‘on the Internet’…. 🙂 Among the issues I encountered were getting the weather software Weewx to work while running as a local user, AND, as a daemon process (auto-start on boot-up.)
Weewx is a well documented Python solution with active development. In a future post I may explore it further; in this post, I am focused on the problems I encountered and solutions I found for these problems.
A reminder – as with many ‘resources’ you find on the web, it is easy to be mis-directed when problem solving – if you stay close to your ‘errors’ and close to your problem descriptions then you should be able to resolve the issue yourself; unless you get lucky and the first ‘I solved this’ post you encounter gets things working (usually, without really explaining how the ‘solution’ resolves the issue [see my post about ‘Airprint’ issues.]
First Problem – installing ‘missing’ software
# required packages - most of this from the Weewx docs sudo pip install configobj sudo pip install Cheetah sudo pip install pillow # required if hardware is serial or USB: sudo pip install pyserial sudo pip install pyusb # optional for extended almanac information: sudo pip install pyephem ### if errors w/reports you may need to add these (not in the docs) sudo pip install image
Second problem – Weewx local user USB Device access
If you are directly connecting your USB weather station, then one custom Udev rule may work for you. If, however, if, like me, you are using an ‘external’ USB hub connected to your Linux system, and then connecting your USB weather station to the external HUB you may need to create TWO udev rules: one for the eXT HUB and one for the WX device…
Example custom Udev rule (your setup will most likely VARY…) allowing ‘group’ access to the devices. (i.e. create/edit file: /etc/udec/rules.d/70-persistent-YOUR_DEVICE)
## rule for the 4-port-hub - using 'plugdev' group SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="0451", ATTRS{idProduct}=="2046", GROUP="plugdev", MODE="0660", LABEL="4-port-hub_wx" ## rule for Acturite weather station SUBSYSTEM=="usb", ATTRS{idVendor}=="24c0", ATTRS{idProduct}=="0003", GROUP="wx-user", MODE="0660", LABEL="Acurite_Wx Note: you may need to create new 'groups' for the above, i.e. 'plugdev' and 'wx-user' or whatever you use. Once groups are created you then need to add users to the group(s). MODE 660 ~= read/write access for the device 'owner' (usually 'root') and for the group you specify...
Third problem – installing weewx as systemd ‘service’
The Weewx example ‘service file’ did not work for my FC 24 install (~/weewx/util/systemd/weewx.service). However, with a few tweaks it is now working well.
I installed a ‘missing’ service, and edited a ‘mismatch’ service name in the example weewx.services file:
# install ntp, configure, enable and start – missing from my FC 24 install? (perhaps due to the ‘spin’ that I started with…)
dnf install ntp # check/modify config for ntp and then load, enable, start, check systemctl daemon-reload systemctl enable ntpdate.service systemctl start ntpdate.service systemctl status ntpdate.service
# modify /etc/systemd/system/weewx.services
change ‘ntp.service’ to ‘ntpdate.service’
So, BEFORE working on the systemd config, I was able to start Weewx as daemon from the command line – so I knew that it should work – still, systemd was complaining… The error message that I was getting from the systemctl command ended with:
(code=exited, status=203/EXEC)
Ok, first try at searching for something like: weewx systemd 203/exec; search results were somewhat helpful, but did not lead to a solution. The documentation for systemd was also not helpful, until I ‘thought about it’… The fix for me – modify the file weewx.services – tweak the Systemd ExecStart command to INCLUDE the path to Python (or whatever other command you are trying to get working; seems that shebang lines are ‘ignored’ by Systemd?), i.e.:
ExecStart=/bin/python /WEEwxd_Path –daemon –pidfile=/PID_Path/ /Weewxd_CONF_PATH
On a typical install, the above would be something like:
ExecStart=/bin/python /home/weewx/bin/weewxd –daemon –pidfile=/var/run/weather/weewx.pid /home/weewx/weewx.conf
Once above changes were made, then ‘tell’ systemd about the updates and start the service, i.e.
systemctl enable weewx systemctl daemon-reload systemctl start weewx systemctl status weewx
Now check for syslog entries and updated web pages (generated by Weewx.)
Of course, your mileage should vary – good luck! 🙂
Topics: Computer Technology, Hardware, Problem Solving, Sensors, Unix-Linux-Os | Comments Off on Fedora 24 and weexd Weather software
Apple Airprint with HP OfficeJet Pro 8600 – solved
By Dale Reagan | September 27, 2015
This appears to a be a common problem (based on all the web twists and turns I took trying to resolve it.) If you are in a non-Apple environment then printing from an iPad to a NON-Apple printer or with a NON-Apple wifi setup can be a journey to get working… Suggestions included:
- buy an Apple printer
- buy an Apple WiFi Router ## actually thought about this
- buy an ‘app for that’
Side note – Airprint appears to send everything as a PDF document to an endpoint; the endpoint (printer) then ‘interprets/renders’ the PDF; it is very ‘slow’ and there may be limited OPTIONs for managing the printed output (i.e. may not be able to change layout, turn color ‘off’, etc. – at least in my case I can select page print ranges and B&W only printing); you may want to adjust your ‘default print’ options (on the printer) if you do a lot of printing via Airprint…
Other problem symptoms – after you get the first working print job going – time passes and:
- the previously working Airprint printer shows up on an intermittent basis
- the previously working Airprint printer simply disappears
Both of the above show up frequently in Internet searches on both Apple and HP support sites; many suggestions point you to reset/re-power everything – that may get things working but is not a real solution. If may have to ‘dig a bit’ and go through some trial and error approaches since ‘all of the pieces’ are not clearly explained (at least I did not encounter and end-to-end document that explains how this *should* work or how to *get it working*…)
I arrived at this solution by getting enough background on what protocols Airprint uses to correlate them with services that my printer supports (in my case, it appears to be IPP and Bonjour.) Along with that (at least at this time) I also adjusted my router and ‘turned off’ Enable Multicast Streams.
HP OfficeJet Pro 8600 – steps & settings
- make a backup
- upgrade firmware – you have to enable ‘web services’ and then check for ‘updates’; post upgrade dis-able ‘web services’ if not used…
- Note that all Wireless settings are ‘disabled’ since this printer is connected via cable to the LAN
- Wireless Direct Printing – I tried this first; the iPad ‘saw it’ but printing simply did not work…
Airprint with HP Printer Setting/changes that worked for me
- Settings –> Administrator Settings everything disabled (un-checked) except for – the only one that *should* matter is ‘Connectivity Network):
- Connectivity Network ## connected via cable – not using wireless
- Fax
- WebScan
- Color Fax
- Color Copy
This is what gets Airprint working on the HP OfficeJet Pro 8600:
- Advanced Settings
- enable IPP (Internet Printing Protocol
- enable Bonjour (Apple’s version of Zeroconf)
- provide a name for this Bonjour Service
- provide ‘domain name’ for the serv ices
- set priority printing (mine is set to 9100 Printing)
- if the iPad does not ‘see’ the printer when I make the first attempt to ‘select’ a printer, I have to re-activate Bonjour on my HP printer (using the web interface) – the printer shows up almost immediately after I ‘re-apply’ the ‘Enable Bonjour’ setting using the printer’s web interface.
- Also, it seems that once you ‘see’ a printer, you can ‘help remember’ the device by selecting the ‘i’ (info) button; this may not be an option until you successfully print to the printer
- at this point I have re-booted the iPad several times as well as dis-abled/enabled wireless networking on the iPad and I am still able to locate and print to the printer
- next I turned the printer off; the iPad still shows the printer and attempts to connect – of course this fails until I turn the printer back on – at which point it is again presented as an option.
- next I power cycled the router… and I was not able to locate the printer – until I re-applied the ‘Enable Bonjour’ setting…
- next, I simply waited ‘a while’ – and I could not locate the printer until I re-applied the ‘Enable Bounjour’ setting…
- Last change – guessing that this is the ‘real’ problem (likely resolved if you have newer router): un-check Enable Multicast Streams option under ‘Advanced Settings’ (on my Dlink router – your router may or may NOT have this option) ** From Wikipedia:
By default, mDNS only and exclusively resolves host names ending with the
.local
top-level domain (TLD). This can cause problems if that domain includes hosts which do not implement mDNS but which can be found via a conventional unicast DNS server. Resolving such conflicts requires network-configuration changes that violate the zero-configuration goal.
What’s causing this intermittent success with locating a Bonjour Printer?
Some guesses:
- WRONG – So, my guess is that the ‘energy saver’ mode of the printer turns off the required networking broadcasts? once you hit the energy saver threshold – the only choices I have are 5/10 and 15 minutes until ‘saver mode’ (since I cannot turn this feature ‘off’ I cannot provide a 100% correlation that this is the culprit/fix…) I set it to 5 minutes and things were still working after this time frame; I also power-cycled the iPad and the printer was still available/working…
- this seems more likely – the mDNS implementation on the router (or lack of implementation, especially if you have an older router) on the local network.
- Solved – or at least ~10 days later this is still working – biggest ‘problem’ seems to be that the printer will ‘disappear’ after some time passes; this is not a problem for a Windows PC – Apples’s Airprint, however, seems to require lots of ‘network noise’ to confirm that a printer is available. Simple options to ‘bring back’ a previously working printer (so that Airprint will see it):
- ‘wake the printer up’ – i.e. try web accessing the printer’s web console from the Apple device you want to print from Or
- power cycle the printer.
Other possible solutions
- setup you your own mDNS server; most routers default to use the DNS server from your ISP; setting up local DNS/mDNS services is probably the *best* solution but requires a bit of effort (and perhaps a learning curve)
- simplest solution is to upgrade your router to one that supports Airprint…. 🙂
Firewall note – based on other web postings, I tried various SPI-Firewall related settings – this made no difference for me (i.e. Endpoint filtering is set to ‘Port And Address Restricted’.
On my printer (i.e. this may be different on YOUR printer, but look for similar options), the URLs to the above are:
make a backup BEFORE you start tinkering... https://YOUR_HP_8600/index.html#hId-Backup
# Master ‘Service’ Toggle
https://YOUR_HP_8600/index.html#hId-pgAdminSettings
# Bonjour
https://YOUR_HP_8600/index.html#hId-mDNSPage
# Internet Printer Protocol
https://YOUR_HP_8600/index.html#hId-IPPPage
Probably not Relevant since is the firewall ON the PRINTER, but including since this is what I have:
https://YOUR_HP_8600/index.html#hId-advOptPage ## Firewall Options
Firewall Enabled options:
- Enable Failsafe Option
- DHCPv4/BOOTP
- Bonjour
Additional notes – 8600 Printer Service Ports
If you cannot see your printer the confirm that the ports being used are ‘open for traffic’ on your network, i.e. for AirPrint on the 8600 (or similar) printer, you probably need to allow traffic on at least these ports: 515, 5353, and 9100.
https://YOUR_HP_8600/index.html#hId-firewallSvcListPage
Name | Protocol | Service Type | Printer/MFP Port | Remote Port | |
---|---|---|---|---|---|
Bonjour | UDP | Printer/MFP Service | 5353 | Any | |
Bonjour | UDP | Remote | Any | 5353 | |
CIFS | TCP | Printer/MFP Service | 445 | Any | |
DHCPv4/BOOTP | UDP | Remote | Any | 67 | |
DHCPv6 | UDP | Remote | Any | 547 | |
DNS | UDP | Remote | Any | 53 | |
HTTP | TCP | Remote | Any | 80 | |
HTTP | TCP | Printer/MFP Service | 80 | Any | |
HTTP | TCP | Printer/MFP Service | 8080 | Any | |
HTTPS | TCP | Printer/MFP Service | 443 | Any | |
ICMPv4 | ICMPv4 | Printer/MFP Service | None | None | |
ICMPv6 | ICMPv6 | Printer/MFP Service | None | None | |
IGMPv2 | IGMPv2 | Printer/MFP Service | None | None | |
LLMNR | UDP | Remote | Any | 5355 | |
LLMNR | UDP | Printer/MFP Service | 5355 | Any | |
LPD | TCP | Printer/MFP Service | 515 | Any | |
NetBIOS | UDP | Printer/MFP Service | 137 | Any | |
NetBIOS | UDP | Remote | Any | 137 | |
NetBIOS | UDP | Printer/MFP Service | 138 | Any | |
NetBIOS | UDP | Remote | Any | 138 | |
NetBIOS | TCP | Printer/MFP Service | 139 | Any | |
P9100 | TCP | Printer/MFP Service | 9100 | Any | |
SLP | UDP | Printer/MFP Service | 427 | Any | |
SLP | UDP | Remote | Any | 427 | |
SMTP | UDP | Remote | Any | 25 | |
SNMP | UDP | Printer/MFP Service | 161 | Any | |
Syslog | UDP | Remote | Any | 514 | |
WS Discovery | UDP | Printer/MFP Service | 3702 | Any | |
WS Discovery | UDP | Remote | Any | 3702 | |
WS Print | TCP | Printer/MFP Service | 3910 | Any | |
WS Print Eventing | TCP | Remote | Any | 5357 |
As always, your mileage may vary, but, hopefully you will find this as a working solution – and, find it in a few minutes versus the amount of time that I spent getting to an almost-working solution…
Topics: Computer Technology, Hardware, Problem Solving, System and Network Security, Web Problem Solving, Web Technologies | Comments Off on Apple Airprint with HP OfficeJet Pro 8600 – solved
Part 2: Getting Data from Ambient Weather WS-1000 Wireless Weather Station
By Dale Reagan | September 7, 2015
Part 2: Getting Data from Ambient Weather WS-1000 Wireless Weather Station Using a Wifi AP
Soooo, how can you capture the data from *your* WS-1000 and save it locally using the Wifi connection?
Capture Wifi data from this unit requires some level of ‘hacking’…
Man-in-the-middle solutions
- Part 1: ‘tap’ the Wifi channel and do a ‘raw data’ capture
- Part 2: create a Wifi AP and re-direct the traffic to your server of choice with an appropriate data-capture web page
Re-configure the WS-1000
- Part 3: configure the WS-1000 to use your destination server of choice – this is not documented with the product – I stumbled upon this and I will describe in a future post…
Setting up a WiFi Access Point
The goal is to put the pieces together that can:
- provide DNS and proxy services to the WS-1000 such that all traffic is directed to a server of my choice
- via this re-direction, log the WS-1000 data locally, in real time, and finally
- transmit the data out to Internet sites of my choosing, i.e. Wunderground
Note about other options where you could do most of what is described in the next section if your router provides the needed options, i.e.
- specific firewall rule options to redirect traffic of your choice (I have not seen any commercial Wifi routers with this option; you could use an Open Source router solution like DD-WRT for this)
- You could install a second Wifi Router with the desired configuration options – fast & relatively simple since it already has ‘all the pieces’ but it adds another hardware component to the solution – great for testing though…
- provides DNS options so you can point to your local DNS service
- the down-side – all your Wifi traffic now has to first ‘hit’ your local DNS service; if you local DNS service goes ‘down’ then your entire network can no longer connect to the Internet
- I want to isolate the traffic for this project so my end point will most likely involve installing a simple USB Wifi NIC in my Linux server (a server which is ‘always up’ vs my router which operates on a limited schedule, i.e. when I need it…)
Components needed to provide Wifi AP Service
- Requires a configurable Wifi NIC/device (i.e. a Wifi travel AP) OR
- a Wifi NIC in your Linux server/workstation OR
- perhaps, custom routing + firewall tables in your primary router (not something I’m covering…)
- software on your Linux server/workstation to provide the needed ‘host’ services for a Wifi AP (access point)
For my first pass I am using:
- TrendNet TEW-654TR 300 Mbps Wireless N Travel Router Kit – a multi function Wifi device – it can be switched into modes as: a router, an AP Point, and an AP Client.
- A local Linux server
- Apache for HTTP services
- hostapd – software that manages the ‘network services’ required for a Wifi AP, i.e.
- DHCP – assigns an IP address to new ‘devices’, i.e. the WS-1000 console for this project
- DNS – provides host name resolution services, i.e. what is the IP address for some_weather_site.com
- General Wifi AP type configuration, i.e. SID name, any required network management settings like the SID, etc.
Once each of the above components are working then you simply (in theory…) connect the WS-1000 to your new AP and all traffic is sent to your server of choice via man-in-the-middle type tinkering. Essentially, your AP will need to be configured such that it ‘tells’ the WS-1000 that your server of choice (i.e. my local Linux server) is really some_weather_site.com; the WS-1000 then ‘sends’ the data to your local server where you capture/log it. And yes, you could do this for any device connecting to your custom AP (when this is done in a ‘public place’ (i.e. a coffee shop) then *your data* or perhaps even your web-connected-device could be compromised; avoid such connections if possible…)
I have not mentioned how to ‘capture’ the data that the WS-1000 will be sending – the simplest solution:
- create a URI using the same ‘path’ that the WS-1000 is already using
- create a web page with PHP code to capture/log/massage the data
- create a script/process to ‘publish’ the data out to the Internet (you could combine that with step 2 but it is probably ‘better’ to use a secondary process, otherwise the code will become more complex – I prefer simpler solutions…)
You can ‘figure this out’ via any network ‘sniffing tool’ (i.e. WireShark.)
Of course, your mileage will vary – and perhaps, you may have a simpler solution. 🙂
Topics: Computer Technology, Hardware, Problem Solving, Sensors, System and Network Security, Web Problem Solving, Web Technologies | Comments Off on Part 2: Getting Data from Ambient Weather WS-1000 Wireless Weather Station
Part 1: Getting Data from Ambient Weather WS-1000 Wireless Weather Station
By Dale Reagan | August 15, 2014
This is my second Ambient Weather station solution – the ws-1090 console still works but the remote sensors faded away after ~2 years…
The web page for the Ambient Weather WS-1000 personal weather station (PWS) lists quite a number of features (see below.) I either mis-read the information OR based on a lack of adequate information I assumed that I could ‘point’ the ‘upload’ to a server of my choice, i.e. this server. It seems that the version that I have does not permit this – it will only upload to Wunderground. There’s nothing wrong with that – except that I want to store the data locally as well as massage it a bit, i.e. the default upload includes inside temperature and humidity. Also, I have other sensors that I might want to incorporate (i.e. soil temperature, etc.)
While the ws-1000 does provide a means to ‘backup’ your data (via SD card) it is a manual process, and, it is ‘all data’ at once. There are no options for scheduled backups to the SD card (i.e. once per day/week/etc.) If you don’t manually backup the data then your data could ‘go missing’. It is not clear (to me) whether the unit has some sort of internal battery (it is not listed as a ‘feature’), but, the unit does seem to ‘retain’ it’s settings during power-cycle or if you remove and re-attach the power supply. [Side note – the power supply connection on my unit is ‘quirky’ – the console will experience power-loss while I hold it in my hand and fiddle with the settings; my solution was to tape the power connector in place…]
Soooo, how can you capture the data from *your* WS-1000 and save it locally using the Wifi connection?
Capture Wifi data from this unit requires some level of ‘hacking’…
Man-in-the-middle solutions
- ‘tap’ the Wifi channel and do a ‘raw data’ capture
- create a Wifi AP and re-direct the traffic to your server of choice with an appropriate data-capture web page
Re-configure the WS-1000
- to use your destination server of choice – this is not documented with the product – I stumbled upon this and I will describe in a future post…
Setting up an Ethernet/Wifi ‘Tap’
Setting up a network ‘tap’ is not very complicated but it does require:
- that you have a ‘friendly’ Ethernet NIC and/or a modifiable Wifi NIC
- that your connection point is in between (man-in-the-middle) of your WS-1000 Wifi console and your network router; in my case I am using an old 10 megabit hub and have a small Wifi AP appliance that the WS-1000 connects to. My ‘friendly NIC’ is also plugged into this hub. Since the ‘hub’ broadcasts all traffic I can ‘see’ what the WS-1000 is sending across the network…)
- Using Linux, you could use a number of ‘packet capture’ tools – I am using tcpflow (from the Linux shell try: man tcpflow for more info.)
- you will need ‘root level’ access (more than likely)
- sample tcpflow command line examples:
tcpflow -i eth5 ## creates a NEW file for each 'flow'
tcpflow -i eth5 -c ## sends all output to the console/screen
tcpflow -i eth5 -C | tee -a /some_folder/your_desired_log_file.log ## send to ONE log file
tcpflow -i eth5 -C dst host rtupdate.wunderground.com | tee -a /some_folder/your_desired_log_file.log
## above - only saves/captures data sent to specified host: rtupdate.wunderground.com
While using tcpflow works it is a manual approach (yes, you could automate it via scripting and server configs), but, of course, I would prefer an automated solution. Since this is still a work-in-progress I will update when I get the WiFi AP (access point) solution working.
Ambient Weather WS-1000 partial feature/info list:
- Wireless all-in-one integrated sensor array measures wind speed, wind direction, temperature, humidity, wind speed, wind direction, rainfall, and solar radiation.
- wireless indoor thermo-hygrometer-barometer sensor
- Full color TFT LCD full color display
- Supports both imperial and metric units of measure
- 915 MHz RF wireless transmission with 300′ line of sight range (100′ under most conditions, with the exception of metal barriers)
- 14 second real-time updates on the console and the internet
- Encrypted WiFi internet two-way communication
- Calibration for all measured parameters
- NIST time synchronization
- Publish real time data to Wunderground.com. No fees.
Wunderground.com Features:
- The most popular personal weather station (PWS) hosting service in the world
- Free ‘cloud based’ service
- Real-time Streaming Updates (rapid fire flash view)
- Weather Station Google Mapping
- Historical data archiving (daily, monthly, yearly and custom).
- WeatherCam integration with time lapse video and daily archiving (weathercams sold separately)
- Personal weather station stickers for your website
- Graphs and tabular data
- Comma Separated File (csv) export
- XML Feeds
Topics: Computer Technology, Hardware, Problem Solving, Savannah Georgia (USA), Sensors, System and Network Security, Web Problem Solving, Web Technologies | Comments Off on Part 1: Getting Data from Ambient Weather WS-1000 Wireless Weather Station
ZSH: Simple Network Port Checker
By Dale Reagan | April 19, 2014
Ok, I had an itch – I prefer to use what I deem ‘simple’ tools to get things done – in this case I needed a simple solution for checking for open ports (i.e. port traffic is not blocked by a firewall.) After a quick scan of the ZSH man pages I found:
- zshtcpsys Zsh built-in TCP functions
Simple use of these functions is, well, simple. I’ve become fond of ZSH after working with it for a few years – and this relative simplicity continues to entice me.
From the man zshtcpsys page: To use the system where it is available, it should be enough to ‘autoload -U tcp_open’ and run tcp_open as documented below to start a session.
Ok, the simple sequence is:
- load TCP module
- open a tcp session
- close the session
Sample script:
#!/bin/zsh autoload -U tcp_open tcp_open localhost 80 tcp_closeOk, if you run the above there is delay after the tcp_open command. I prefer a quick response so shorten this to:
T_MSG=$(tcp_open localhost 80)
By ‘wrapping things up’ the ‘tcp_close’ is done for you (the tcp_close command, if still present, will announce that there are no open sessions to close…)
So my simple script becomes:
#!/bin/zsh HOST_TO_CHECK="$1" PORT_TO_CHECK="$2" ## load the required ZSH functions autoload -U tcp_open ## capture the text output AND standard Error output from tcp_open T_MSG=$(tcp_open ${HOST_TO_CHECK} ${PORT_TO_CHECK} 2>&1) E_STAT=$? ## capture the 'result code' from the previous command ## print a summary, and remove extra lines from ${T_MSG} results printf "${HOST_TO_CHECK} | ${PORT_TO_CHECK} | ${E_STAT} | ${T_MSG}\n" | head -1
Simple enhancements – add some print formatting:
printf “${HOST_TO_CHECK} | %5d | ${E_STAT} | ${T_MSG}\n” ${PORT_TO_CHECK} |
Save the above as /tmp/chk.port.zsh (adjust path to zsh if needed and chmod 755) and try:
for PORTS in 22 23 80 443 ; do /tmp/chk.port.zsh SYSNAME ${PORT} ; done
You should get something like:
Test_host | Port 22 | 0 | Session 1 (host Test_host, port 22 fd 3) opened OK. Setting default TCP session 1 Test_host | Port 23 | 1 | tcp_open:ztcp:174: connection failed: connection refused Test_host | Port 80 | 0 | Session 1 (host Test_host, port 80 fd 3) opened OK. Setting default TCP session 1 Test_host | Port 443 | 1 | tcp_open:ztcp:174: connection failed: connection refused
We can clean this up a bit more by removing repetitive messages/info, i.e. with an update:
printf "${HOST_TO_CHECK} | ${PORT_TO_CHECK} | ${E_STAT} | ${T_MSG}\n" | head -1 | \ sed -e 's/tcp_open:ztcp:174://g'"
“Wait, Wait!”, you say… “Isn’t tool XYB ‘better’ for port checking?…”
Hmm, perhaps, but the point here is that I can do ‘something’ by taking advantage of an existing resource without having to introduce yet-another-tool…
Some ‘enhancements’ you might consider would be to ‘paralellize’ this process, i.e. run N-background processes – this takes some tinkering but can speed things up quite a bit (but mind that you don’t consume all of your system resources!)
As always, I’d expect your mileage (and opinions) to vary – at least a bit. 🙂
Topics: Problem Solving, System and Network Security, Unix-Linux-Os | Comments Off on ZSH: Simple Network Port Checker
« Previous Entries