[2003] Actieve porten sluiten

[mhoogendam]

Ik ben op zoek naar een programma die porten kunnen sluiten die open staan.

Ik heb een programma draaien (serverwatch) die wil nog wel eens crashen.
Als er een client is geconnect naar de serverwatch webserver of normale server, blijft deze port "in use" en is het programma niet meer remote te benaderen.

De server kan niet gereboot worden om de porten weer vrij te geven.
Het is een ingebouwde webserver in serverwatch dus IISReset e.d. werkt niet.
Het gaat om port 23203 en 81.
Ik heb niets kunnen vinden via de search, google heeft me wel een programma'tje opgeleverd die porten kan sluiten alleen dit werkt niet onder windows 2003 server:
http://download.com.com/3...20&subj=dlpage&tag=button

ik zoek geen firewall

[ Voor 5% gewijzigd door mhoogendam op 21-05-2004 12:09 ]

[Don van Boven]

Een firewall misschien

[mhoogendam]

Ik moet die porten sluiten om daarna het programma weer te kunnen opstarten dus ik zoek GEEN firewall

[Verwijderd]

Hier heb ik een oplossing voor je:

U R L
't is een tooltje om te kijken welke poorten open zijn en met een druk op de knop kun je de service sluiten die de verbinding maakt.

Greetz, Cap.

[mhoogendam]

Bedankt voor je reactie maar dat is het zelfde programmatje die ik in de eerste post heb gezet, en die werkt niet met windows 2003 server.

[Verwijderd]

Ow ok

Dan heb ik hier een url waar je verschillende kunt downloaden..

Probeer maar eens uit.. ben dr 100% cker van dat er ene werkt

Greetz, Cap

[Verwijderd]

Dat tooltje werkt bij TS niet onder Win2003

Kon je wel zien door welke processen de betreffende poorten geopend waren?

[mhoogendam]

Nee, Active Ports hing bij opstarten op 100% cpu gebruik, ik kreeg het programma dus ook niet verder gestart.

[Spider.007]

Volgens mij is het (ook in Windows) zo dat een poort alleen in gebruik kan zijn indien er een actief proces draait dat een serversocket aan deze poort heeft hangen. Oftewel; er moet nog ergens een proces draaien dat deze poort in gebruik houdt. Zou je daarom niet kunnen volstaan met het afsluiten van het proces, om de poorten weer vrij te geven? Bekijk ook je `netstat` output eens; of daar niets meer tussen draait?

[elevator]

Even aanvullend op Spider007 - wat bedoel je precies met 'actief'? Staat de poort in een listening state? Of zijn er nog expiring sessies?

Verder - kan je met ProcessExplorer niet de TCP/IP handle sluiten?

[mhoogendam]

Ik kan nu helaas niet achter de server, en degene die er nu wel bij kan die reageert even niet op IRC. ik ga het even nakijken iig bedankt voor de reacties alvast.

[mhoogendam]

owkee daar zijn we weer, helaas is het niet gelukt.
Netstat -o levert een PID 3588 op. Deze staat dus niet in de Taskmanager, en kan dus geen process gesloten worden.

De PID staat in de state: CLOSE_WAIT

Nog suggesties?

[elevator]

Die poort kan je niet geforceerd sluiten - die staat gewoon te wachten op een bevestigingspakketje van de andere kant.

Ik zie ook geen reden waarom je die connectie zou willen sluiten - je *zou* er helemaal geen last van mogen hebben normaal gesproken?

[mhoogendam]

Normaal gesproken niet nee, maar als ik het programmatje weer opstart dan werkt het wel, alleen is het niet te benaderen via web of client.
En dit nu juist hetgene wat ik weer wil kunnen gebruiken.

[ Voor 19% gewijzigd door mhoogendam op 23-05-2004 02:27 ]

[elevator]

En als je dat programmatje weer start - komt er dan dezelfde poort weer in de 'listening' state te staan?

[Aetje]

www.sysinternals.com -> TCPView.

[Spider.007]

Aetje schreef op 23 mei 2004 @ 02:43:
www.sysinternals.com -> TCPView.

Zal TCPview niet gewoon exact dezelfde informatie weergeven als netstat? Ik weet dat hij daarnaast naar het proces kan linken; maar als netstat reeds verwijst naar een niet bestaand PID kan ik mij niet voorstellen dat TCPview hier enige meerwaarde heeft?

[mhoogendam]

elevator schreef op 23 mei 2004 @ 02:38:
En als je dat programmatje weer start - komt er dan dezelfde poort weer in de 'listening' state te staan?

Deze poort komt idd weer op Listening.

Port 81: Listening
Port 24203: Listening
Port 23203: Listening

Deze porten moeten eerst afgesloten worden voordat Serverwatch weer goed werkt. De Close_Wait is ondertussen al gesloten, de porten hierboven hebben we nog niet kunnen sluiten.

[Aetje]

Spider.007 schreef op 23 mei 2004 @ 13:05:
[...]


Zal TCPview niet gewoon exact dezelfde informatie weergeven als netstat? Ik weet dat hij daarnaast naar het proces kan linken; maar als netstat reeds verwijst naar een niet bestaand PID kan ik mij niet voorstellen dat TCPview hier enige meerwaarde heeft?

Versie die ik heb geeft 't proces, de verbindingsstatus, zender en ontvanger, en het pad naar het proces aan. Met n rightclick kan je dan het proces killen of de verbinding termineren.

Overigens kan een PID niet "niet bestaand" zijn. Wat wel kan is dat een gecrashte of slecht afgesloten verbinding nog bestaat na het verdwijnen van de applicatie. Die verbindingen krijgen uiteindelijk een timeout omdat er niets op je comp staat wat op die verbindingen reageert.

[Edit]Een poort die op "Listening" staat heeft in de PC een proces dat die poorten gebruikt om data op te kunnen ontvangen. Deze poorten zijn niet te sluiten zoals een verbinding: De applicatie die ze bezet houdt moet gesloten worden.

[ Voor 17% gewijzigd door Aetje op 26-05-2004 02:46 ]

[elevator]

mhoogendam schreef op 25 mei 2004 @ 12:05:
Deze poort komt idd weer op Listening.

Port 81: Listening
Port 24203: Listening
Port 23203: Listening

Een poort die 'listening' staat betekent dat die connecties kan aanpakken. Vermoedelijk zorgt ServerWatch ervoor dat die poorten in 'listening' komen te staan (crasht namelijk je server process, worden porten in listening mode automatisch gesloten).

Deze porten moeten eerst afgesloten worden voordat Serverwatch weer goed werkt. De Close_Wait is ondertussen al gesloten, de porten hierboven hebben we nog niet kunnen sluiten.

Vermoedelijk sluiten die vanzelf op het moment dat je ServerWatch stopt