Sto tentando di utilizzare netcat per simulare un protocollo NAT trasversale.Utilizzo di netcat per inviare un pacchetto UDP senza binding
devo un'istanza che intercetta i pacchetti UDP sulla porta 6666, come così:
nc -ul 6666
In un'altra finestra terminale, sto cercando di inviare periodicamente un pacchetto UDP dalla porta 6666 (per aprire il percorso di ritorno sul mio router. questo sarebbe in uno script che si ripete ogni 20 secondi per riaprire la porta)
nc -u -p6666 mypinghost.com 4444
il problema è netcat non riesce su questa chiamata ping con il messaggio:
nc: bind fallito: Indirizzo già in uso
il che implica che l'ascoltatore avendo associato alla porta 6666 sta bloccando un altro processo di inviare da quella porta, o forse che netcat sta cercando di legarsi a 6666 per ascoltare.
E 'così che viene scritto netcat o posso solleticare in qualche modo che mi permetta di inviare un pacchetto senza legarsi alla porta per ascoltare?
Sto riscontrando lo stesso problema e ho capito che SO_REUSEADDRESS evita quell'errore. Ma i messaggi di ritorno non vengono rilevati dal processo di ascolto, a meno che non lo avvii dopo che il processo di invio ha vincolato la porta. La mia comprensione è che l'opzione è usata per "multicast" (che non credo sia il mio caso), ma c'è modo di usarlo in modo che i messaggi inviati alla porta 6666 vadano al processo che vuole riceverli, piuttosto che il processo più recente per legare la porta? – Edmund
@ Edmund I messaggi devono essere inviati a tutti i processi che ricevono da quella porta. – EJP
Per "processi che stanno ricevendo", vuoi dire quelli che sono legati ad esso, o quelli che chiamano 'recvfrom'? Come accade, i datagrammi UDP sembrano essere rilevati in modo affidabile solo dal processo più recente da collegare. Anche se quel processo non chiama mai 'recvfrom', impedisce comunque all'altro di ricevere qualcosa. Ma questa discussione sui commenti si sta affollando, quindi farò una domanda separata e includerò il mio codice, a meno che tu non possa pensare a qualcosa di semplice che probabilmente mi manchi. ;-) – Edmund