netcat képes portot ,,nyitni''?

Arch Linux

Sziasztok.

Mai rohanó világunkban az ember nem tudja, mit csinál.
Én sem.
Lépéseim egy nyamvadt port használatára a következő volt eddig:
iptables, firewall-cmd, shorewall, socat, majd miután rájöttem, hogy életképtelen vagyok ezekre, jött valami más.
Ez:

tail -f ./gps.minicom | netcat -l -p 10110

a gps.minicom-ba írom azt az adatfolyamot, amit a minicom rögzít RS232-n.

Ezek szerveren futnak.
A szerverre kapcsolódó kliens célprogramja (opencpn) pedig látja, mi érkezik a 10110-es porton.

Kérdés:
valóban azt látom, amit képzelek, azaz a netcat a tail-tól átvett adatfolyamot szétküldi egy megnyitott 10110-es porton?

Kliensen megnéztem, most már nem ,,filtered'' van itt:

# nmap -p 10110 192.168.12.1

Starting Nmap 6.47 ( http://nmap.org ) at 2017-01-31 16:44 CET
Nmap scan report for domain1.com (192.168.12.1)
Host is up (0.0072s latency).
PORT STATE SERVICE
10110/tcp open unknown
MAC Address: 10:7B:EF:CD:0A:D1 (ZyXEL Communications)

Nmap done: 1 IP address (1 host up) scanned in 0.53 seconds

...hanem ,,open''

  • 1742 megtekintés

( blr v | 2017. 01. 31., k – 17:23 )

Nem küldi szét, de ha valahonnan kapcsolódsz, akkor igen, meg fogod kapni az adatfolyamot. Viszont amikor a "kliensoldalon" lezárod a kapcsolatot, a "szerver" is leáll.

A kliensen újraindítottam azt a programot, ami a 2947-es portot figyeli. Folyamatosan jön az adat.
Bontottam a szerverrel a kapcsolatot, újracsatlakoztam, miközben kliensen a program futott. Jönnek az adatok.
Kapcsolatbontás, kliensen a programot is leállítottam, mert paranoiás vagyok, újraindítottam mindent, még mindig jön az adatfolyam.

Hogyan értelmezed, hogy a ,,amikor a "kliensoldalon" lezárod a kapcsolatot, a "szerver" is leáll''?

--------
Közben rájöttem: talán úgy értelmezhetted a leállást, hogy a port bezárul. Igen, closed-re áll.

Érdekesség: Még böngészőben is megjeleníthető a helyi hálózat összes képén:
http :// 192.168.12.1:10110 (space nélkül persze...)

---
--- A gond akkor van, ha látszólag minden működik. ---
---

nc valtozattol fugg a viselkedes, nmap-ncat valtozatnal, a nc server csak egyetlen csatlakozast enged alapbol, ha azzal megszakad a kapcsolat az nc server is leall.
nc -l -k 10000 # tobb kapcsolatot is fogad, tobb kliensnek is elkuldi ugyan azt, nem all le ha kliensek elmennek.
Ha senki nem figyel akkor a feltartja az irot, (tail)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Kipróbálom több klienssel is, bár tulajdonképpen nekem most nem fontos. 


#!/bin/sh

# utolso 10, mar megszurt mondat:
logfile="/tmp/nmea-tail10.tmp"

while [ ! -e $logfile ]
do
  sleep 5
done

while true
do
  # kuldj 5 peldanyt, hatha megis rossz valamelyik:
  cat $logfile | tail -5 | netcat -l -p 2947
done

exit 0

Egyelore ezzel futtatom.
Ronda, primitív és nem szakemberi, de nekem most nagyon aranyos.

---
--- A gond akkor van, ha látszólag minden működik. ---
---

> Hogyan értelmezed, hogy a ,,amikor a "kliensoldalon" lezárod a kapcsolatot, a "szerver" is leáll''?

Szerintem a shutdown(SD_WRITE)-re gondol, ahogy a HTTP/0.9 működik: a POST-nál nincs Content-Length, hanem a kliens 'félig lezárja' (magyarul: half-close) a kapcsolatot a 'body' elküldése után.

( hory v | 2017. 02. 01., sze – 14:22 )

socat javallott ilyen celokra. netcat szinte semmi se tud, raadasul egy hulye feature-e miatt (inkabb bugnak hivnam) tenylegesen lezarja a TCP socket-et, ha EOF-ot er az input-on. Ez akkor ciki, amikor pl. a szerver okos, es ha a kliens 'elment', akkor azonnal megszakitja a kiszolgalast - vagyis gyakran bizony lemaradsz a szerver valaszarol.

Ez a whois.ripe.net -nel volt nagy gond, mert sok ember siman netcat-elt, aztan meg nem latta az eredmenyt.

Asszem csak az egyik netcat csinalja ezt, sajnos pont a legelterjedtebb verzio :(