For the last 3 months or so I'm having random errors where I can't bind a specific port where our Identity server is running on my local development workstation. At first I thought it's my broken machine, so I reset everything, which kinda fixed the issue for 2 months and now it is back.
In the meanwhile other developers saw the same issue. All of us who experience the issue are running Windows 10, but not everyone with Windows 10 has that issue.
Restarting windows after it was shut down with shutdown /s /f /t 0 is the only reliable solution to open up the port again. After I restart normally (due to windows updates or similar) the issue comes up again an I need to shut down windows with that command.
I wrote a small f# script to test which ports are affected. The exact error message I get is
An attempt was made to access a socket in a way forbidden by its access permissions
When I looked for it, the suggested solutions where to restart the machine, but that seems more like a work around, not a real solution. I've also found https://stackoverflow.com/a/10461978/621366 - but netstat -o doesn't list the port, neither does the tool TCPView. All of us are pretty sure that the port isn't occupied by anything. I also tried running netstat in an administrator console and similar commands inside bash on windows, but couldn't find anything. I can't even connect to the port via telnet, it says nothing is listening on the port.
those ports in question are for instance:
49670 - 49689
49710 - 49749
49760 - 49779
49811 - 49830
49843 - 49882
50197 - 50216
None of us modified anything on the windows firewall or has any additional anti virus tools installed except the windows 10 default ones. So everything should be on default values. And it also worked normally for ~10 months before it broke the first time and afterwards for 2 months. In both cases after some windows updates where installed. The last time it was a bios update (probably due to the meltdown / spectre issues?).
Also trying to open up the ports explicitly on the firewall didn't help.
According to this answer https://stackoverflow.com/a/23982901/621366 TCPView and netstat shouldn't miss any occupied ports, but even when I enable showing unconnected endpoints in TCPView, I don't see any of the ports where I get permission denied when trying to bind them. Here a screen from the occupied ports (I marked the bordering occupied ports which are right before or after the group of permission-denied-ports)
UPDATE:
I've noticed that it always seems to be 160 or 180 (exact numbers) of ports which have permission denied in the ranges of 40,000+ This seems oddly coincidental to me, so obviously something is occupying the ports on purpose, but what? I can't seem to find anything in the windows event logs (although I wouldn't know what to look for exactly) and none of those ports shows up any any of my firewall rules. Also shutting down docker for windows doesn't make any difference and when a colleague mentioned that for them it's enough to restart docker for windows (in the UI go to Reset->Restart) and right now for me, even restarting with the shutdown command doesn't work anymore.
UPDATE 2:
The output of netstat -ano run from an administrator powershell:
Proto Local Address Foreign Address State PID
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 1152
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:2179 0.0.0.0:0 LISTENING 4696
TCP 0.0.0.0:5040 0.0.0.0:0 LISTENING 6616
TCP 0.0.0.0:5357 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:5432 0.0.0.0:0 LISTENING 11100
TCP 0.0.0.0:7680 0.0.0.0:0 LISTENING 7056
TCP 0.0.0.0:17500 0.0.0.0:0 LISTENING 9668
TCP 0.0.0.0:49664 0.0.0.0:0 LISTENING 784
TCP 0.0.0.0:49665 0.0.0.0:0 LISTENING 1628
TCP 0.0.0.0:49666 0.0.0.0:0 LISTENING 2028
TCP 0.0.0.0:49667 0.0.0.0:0 LISTENING 3560
TCP 0.0.0.0:49800 0.0.0.0:0 LISTENING 856
TCP 0.0.0.0:49821 0.0.0.0:0 LISTENING 892
TCP 0.0.0.0:50000 0.0.0.0:0 LISTENING 11100
TCP 0.0.0.0:50001 0.0.0.0:0 LISTENING 11100
TCP 0.0.0.0:51000 0.0.0.0:0 LISTENING 11100
TCP 10.0.75.1:139 0.0.0.0:0 LISTENING 4
TCP 10.0.75.1:445 10.0.75.2:44848 ESTABLISHED 4
TCP 127.0.0.1:843 0.0.0.0:0 LISTENING 9668
TCP 127.0.0.1:944 0.0.0.0:0 LISTENING 688
TCP 127.0.0.1:944 127.0.0.1:50968 TIME_WAIT 0
TCP 127.0.0.1:944 127.0.0.1:50970 TIME_WAIT 0
TCP 127.0.0.1:944 127.0.0.1:50973 TIME_WAIT 0
TCP 127.0.0.1:944 127.0.0.1:50977 TIME_WAIT 0
TCP 127.0.0.1:944 127.0.0.1:50981 TIME_WAIT 0
TCP 127.0.0.1:944 127.0.0.1:50990 TIME_WAIT 0
TCP 127.0.0.1:944 127.0.0.1:50992 TIME_WAIT 0
TCP 127.0.0.1:944 127.0.0.1:50996 TIME_WAIT 0
TCP 127.0.0.1:944 127.0.0.1:51005 TIME_WAIT 0
TCP 127.0.0.1:944 127.0.0.1:51007 TIME_WAIT 0
TCP 127.0.0.1:944 127.0.0.1:51009 TIME_WAIT 0
TCP 127.0.0.1:944 127.0.0.1:51015 TIME_WAIT 0
TCP 127.0.0.1:944 127.0.0.1:51017 ESTABLISHED 688
TCP 127.0.0.1:4380 0.0.0.0:0 LISTENING 11024
TCP 127.0.0.1:6942 0.0.0.0:0 LISTENING 9296
TCP 127.0.0.1:17600 0.0.0.0:0 LISTENING 9668
TCP 127.0.0.1:49668 127.0.0.1:49669 ESTABLISHED 688
TCP 127.0.0.1:49669 127.0.0.1:49668 ESTABLISHED 688
TCP 127.0.0.1:50076 127.0.0.1:50077 ESTABLISHED 8828
TCP 127.0.0.1:50077 127.0.0.1:50076 ESTABLISHED 8828
TCP 127.0.0.1:50173 127.0.0.1:50174 ESTABLISHED 9668
TCP 127.0.0.1:50174 127.0.0.1:50173 ESTABLISHED 9668
TCP 127.0.0.1:50175 127.0.0.1:50176 ESTABLISHED 9668
TCP 127.0.0.1:50176 127.0.0.1:50175 ESTABLISHED 9668
TCP 127.0.0.1:50197 127.0.0.1:50198 ESTABLISHED 9668
TCP 127.0.0.1:50198 127.0.0.1:50197 ESTABLISHED 9668
TCP 127.0.0.1:50335 127.0.0.1:50336 ESTABLISHED 6424
TCP 127.0.0.1:50336 127.0.0.1:50335 ESTABLISHED 6424
TCP 127.0.0.1:50346 127.0.0.1:50347 ESTABLISHED 11100
TCP 127.0.0.1:50347 127.0.0.1:50346 ESTABLISHED 11100
TCP 127.0.0.1:51011 127.0.0.1:51012 ESTABLISHED 9296
TCP 127.0.0.1:51012 127.0.0.1:51011 ESTABLISHED 9296
TCP 127.0.0.1:51013 127.0.0.1:51014 ESTABLISHED 9296
TCP 127.0.0.1:51014 127.0.0.1:51013 ESTABLISHED 9296
TCP 127.0.0.1:51016 0.0.0.0:0 LISTENING 9296
TCP 127.0.0.1:51017 127.0.0.1:944 ESTABLISHED 8828
TCP 127.0.0.1:63342 0.0.0.0:0 LISTENING 9296
TCP 127.94.0.1:946 0.0.0.0:0 LISTENING 688
TCP 127.94.0.2:946 0.0.0.0:0 LISTENING 688
TCP 127.94.0.3:946 0.0.0.0:0 LISTENING 688
TCP 127.94.0.4:946 0.0.0.0:0 LISTENING 688
TCP 169.254.105.83:139 0.0.0.0:0 LISTENING 4
TCP 192.168.0.107:139 0.0.0.0:0 LISTENING 4
TCP 192.168.0.107:49415 111.221.29.134:443 ESTABLISHED 4316
TCP 192.168.0.107:49417 111.221.29.127:443 ESTABLISHED 4316
TCP 192.168.0.107:50185 162.125.66.3:443 CLOSE_WAIT 9668
TCP 192.168.0.107:50246 52.70.31.26:443 CLOSE_WAIT 9668
TCP 192.168.0.107:50253 35.177.204.73:443 ESTABLISHED 2804
TCP 192.168.0.107:50254 35.177.204.73:443 ESTABLISHED 2804
TCP 192.168.0.107:50256 35.177.204.73:443 ESTABLISHED 2804
TCP 192.168.0.107:50257 158.85.224.175:443 ESTABLISHED 10836
TCP 192.168.0.107:50258 13.69.14.160:443 ESTABLISHED 8620
TCP 192.168.0.107:50310 66.102.1.188:443 ESTABLISHED 11184
TCP 192.168.0.107:50329 157.240.20.15:443 ESTABLISHED 10836
TCP 192.168.0.107:50331 111.221.29.74:443 ESTABLISHED 10072
TCP 192.168.0.107:50332 162.125.18.133:443 ESTABLISHED 9668
TCP 192.168.0.107:50351 40.77.226.194:443 ESTABLISHED 8620
TCP 192.168.0.107:50460 66.102.1.189:443 ESTABLISHED 10836
TCP 192.168.0.107:50470 66.102.1.189:443 ESTABLISHED 10836
TCP 192.168.0.107:50501 192.30.253.125:443 ESTABLISHED 11184
TCP 192.168.0.107:50513 40.77.226.194:443 ESTABLISHED 8620
TCP 192.168.0.107:50529 87.98.218.198:443 ESTABLISHED 12540
TCP 192.168.0.107:50530 172.217.21.46:443 ESTABLISHED 10836
TCP 192.168.0.107:50616 172.217.21.46:443 ESTABLISHED 10836
TCP 192.168.0.107:50630 162.125.18.133:443 ESTABLISHED 9668
TCP 192.168.0.107:50641 172.217.21.37:443 ESTABLISHED 10836
TCP 192.168.0.107:50645 162.125.66.4:443 CLOSE_WAIT 9668
TCP 192.168.0.107:50668 87.98.218.198:443 ESTABLISHED 12540
TCP 192.168.0.107:50703 151.101.0.133:443 ESTABLISHED 11184
TCP 192.168.0.107:50709 192.30.253.125:443 ESTABLISHED 11184
TCP 192.168.0.107:50744 87.98.218.198:443 ESTABLISHED 12540
TCP 192.168.0.107:50828 162.125.66.3:443 CLOSE_WAIT 9668
TCP 192.168.0.107:50830 151.101.0.133:443 ESTABLISHED 11184
TCP 192.168.0.107:50831 151.101.0.133:443 ESTABLISHED 11184
TCP 192.168.0.107:50832 151.101.0.133:443 ESTABLISHED 11184
TCP 192.168.0.107:50834 151.101.0.133:443 ESTABLISHED 11184
TCP 192.168.0.107:50835 151.101.0.133:443 ESTABLISHED 11184
TCP 192.168.0.107:50836 151.101.0.133:443 ESTABLISHED 11184
TCP 192.168.0.107:50837 151.101.0.133:443 ESTABLISHED 11184
TCP 192.168.0.107:50839 192.30.253.125:443 ESTABLISHED 11184
TCP 192.168.0.107:50844 151.101.0.133:443 ESTABLISHED 11184
TCP 192.168.0.107:50847 192.30.253.124:443 ESTABLISHED 11184
TCP 192.168.0.107:50857 192.30.253.124:443 ESTABLISHED 11184
TCP 192.168.0.107:50863 162.125.34.137:443 CLOSE_WAIT 9668
TCP 192.168.0.107:50865 172.217.21.46:443 TIME_WAIT 0
TCP 192.168.0.107:50866 172.217.21.46:443 ESTABLISHED 10836
TCP 192.168.0.107:50910 35.186.213.138:443 TIME_WAIT 0
TCP 192.168.0.107:50923 172.217.21.46:443 ESTABLISHED 10836
TCP 192.168.0.107:50925 40.117.190.72:443 ESTABLISHED 4040
TCP 192.168.0.107:50927 172.217.21.42:443 ESTABLISHED 11184
TCP 192.168.0.107:50949 151.101.0.133:443 ESTABLISHED 11184
TCP 192.168.0.107:50950 151.101.0.133:443 ESTABLISHED 11184
TCP 192.168.0.107:50951 151.101.0.133:443 ESTABLISHED 11184
TCP 192.168.0.107:50954 192.30.253.124:443 ESTABLISHED 11184
TCP 192.168.0.107:50959 40.117.190.72:443 TIME_WAIT 0
TCP 192.168.0.107:50969 192.30.253.113:22 TIME_WAIT 0
TCP 192.168.0.107:50978 87.98.218.198:443 ESTABLISHED 12540
TCP 192.168.0.107:50984 151.101.1.69:443 ESTABLISHED 11184
TCP 192.168.0.107:50985 192.0.73.2:443 ESTABLISHED 11184
TCP 192.168.0.107:50986 104.16.112.18:443 ESTABLISHED 11184
TCP 192.168.0.107:50991 198.252.206.25:443 ESTABLISHED 11184
TCP 192.168.0.107:50993 192.168.0.10:3910 TIME_WAIT 0
TCP 192.168.0.107:50994 192.168.0.10:3910 TIME_WAIT 0
TCP 192.168.0.107:50997 23.210.254.37:443 ESTABLISHED 912
TCP 192.168.0.107:50998 23.210.254.37:443 ESTABLISHED 912
TCP 192.168.0.107:50999 23.210.254.37:443 ESTABLISHED 912
TCP 192.168.0.107:51001 23.210.254.37:443 ESTABLISHED 912
TCP 192.168.0.107:51006 40.117.190.72:443 ESTABLISHED 11992
TCP 192.168.0.107:51008 40.69.218.62:443 ESTABLISHED 7056
TCP 192.168.0.107:51010 172.217.21.46:443 ESTABLISHED 11184
TCP [::]:135 [::]:0 LISTENING 1152
TCP [::]:445 [::]:0 LISTENING 4
TCP [::]:2179 [::]:0 LISTENING 4696
TCP [::]:5357 [::]:0 LISTENING 4
TCP [::]:7680 [::]:0 LISTENING 7056
TCP [::]:17500 [::]:0 LISTENING 9668
TCP [::]:49664 [::]:0 LISTENING 784
TCP [::]:49665 [::]:0 LISTENING 1628
TCP [::]:49666 [::]:0 LISTENING 2028
TCP [::]:49667 [::]:0 LISTENING 3560
TCP [::]:49800 [::]:0 LISTENING 856
TCP [::]:49821 [::]:0 LISTENING 892
TCP [::1]:5432 [::]:0 LISTENING 11100
TCP [::1]:50000 [::]:0 LISTENING 11100
TCP [::1]:50001 [::]:0 LISTENING 11100
TCP [::1]:51000 [::]:0 LISTENING 11100
UDP 0.0.0.0:53 *:* 5620
UDP 0.0.0.0:3702 *:* 2084
UDP 0.0.0.0:3702 *:* 2084
UDP 0.0.0.0:5050 *:* 6616
UDP 0.0.0.0:5353 *:* 11184
UDP 0.0.0.0:5353 *:* 11184
UDP 0.0.0.0:5353 *:* 11184
UDP 0.0.0.0:5353 *:* 3080
UDP 0.0.0.0:5353 *:* 11184
UDP 0.0.0.0:5353 *:* 11184
UDP 0.0.0.0:5353 *:* 11184
UDP 0.0.0.0:5353 *:* 11184
UDP 0.0.0.0:5355 *:* 3080
UDP 0.0.0.0:17500 *:* 9668
UDP 0.0.0.0:49670 *:* 2084
UDP 0.0.0.0:57329 *:* 5620
UDP 0.0.0.0:57330 *:* 5620
UDP 0.0.0.0:59529 *:* 8620
UDP 0.0.0.0:60605 *:* 11184
UDP 10.0.75.1:137 *:* 4
UDP 10.0.75.1:138 *:* 4
UDP 10.0.75.1:1900 *:* 2620
UDP 10.0.75.1:61326 *:* 2620
UDP 127.0.0.1:1900 *:* 2620
UDP 127.0.0.1:60816 *:* 4616
UDP 127.0.0.1:61328 *:* 2620
UDP 169.254.105.83:137 *:* 4
UDP 169.254.105.83:138 *:* 4
UDP 169.254.105.83:1900 *:* 2620
UDP 169.254.105.83:61330 *:* 2620
UDP 172.30.146.241:67 *:* 5620
UDP 172.30.146.241:68 *:* 5620
UDP 172.30.146.241:1900 *:* 2620
UDP 172.30.146.241:61329 *:* 2620
UDP 192.168.0.107:137 *:* 4
UDP 192.168.0.107:138 *:* 4
UDP 192.168.0.107:1900 *:* 2620
UDP 192.168.0.107:61327 *:* 2620
UDP [::]:3702 *:* 2084
UDP [::]:3702 *:* 2084
UDP [::]:5353 *:* 11184
UDP [::]:5353 *:* 11184
UDP [::]:5353 *:* 3080
UDP [::]:5353 *:* 11184
UDP [::]:5355 *:* 3080
UDP [::]:49671 *:* 2084
UDP [::]:57331 *:* 5620
UDP [::]:59529 *:* 8620
UDP [::1]:1900 *:* 2620
UDP [::1]:61323 *:* 2620
UDP [fe80::30eb:ad8f:f94a:b774%26]:1900 *:* 2620
UDP [fe80::30eb:ad8f:f94a:b774%26]:61324 *:* 2620
UDP [fe80::718c:22bb:fd97:c06c%23]:1900 *:* 2620
UDP [fe80::718c:22bb:fd97:c06c%23]:61322 *:* 2620
UDP [fe80::85d0:3b5c:7746:6953%5]:1900 *:* 2620
UDP [fe80::85d0:3b5c:7746:6953%5]:61325 *:* 2620
The f# code I used to test for open ports:
open System.Net
open System.Net.Sockets
let ipAddress = IPAddress([| (byte)0; (byte)0; (byte)0; (byte)0 |])
let ipEndpoint portNumber = (IPEndPoint(ipAddress, portNumber), portNumber)
let getPorts = seq { for i in 1 .. 65535 -> i }
let checkIfPortAvailable (endpoint, portNumber) =
use listener = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp)
try
listener.Bind(endpoint)
(portNumber, true, null)
with
| ex -> (portNumber, false, ex)
[<EntryPoint>]
let main argv =
getPorts
|> Seq.map ipEndpoint
|> Seq.map checkIfPortAvailable
|> Seq.where (fun (_, works, _) -> not works)
|> Seq.where (fun (_, _, ex) -> ex.Message.Contains("An attempt was made to access a socket in a way forbidden by its access permissions"))
|> Seq.iteri (fun index (port, _, _) -> printfn "%5d: %d" index port)
0
and the output when executing the application (it was executed right after the netstat command):
0: 445
1: 5357
2: 7680
3: 49670
4: 49671
5: 49672
6: 49673
7: 49674
8: 49675
9: 49676
10: 49677
11: 49678
12: 49679
13: 49680
14: 49681
15: 49682
16: 49683
17: 49684
18: 49685
19: 49686
20: 49687
21: 49688
22: 49689
23: 49710
24: 49711
25: 49712
26: 49713
27: 49714
28: 49715
29: 49716
30: 49717
31: 49718
32: 49719
33: 49720
34: 49721
35: 49722
36: 49723
37: 49724
38: 49725
39: 49726
40: 49727
41: 49728
42: 49729
43: 49730
44: 49731
45: 49732
46: 49733
47: 49734
48: 49735
49: 49736
50: 49737
51: 49738
52: 49739
53: 49740
54: 49741
55: 49742
56: 49743
57: 49744
58: 49745
59: 49746
60: 49747
61: 49748
62: 49749
63: 49750
64: 49751
65: 49752
66: 49753
67: 49754
68: 49755
69: 49756
70: 49757
71: 49758
72: 49759
73: 49770
74: 49771
75: 49772
76: 49773
77: 49774
78: 49775
79: 49776
80: 49777
81: 49778
82: 49779
83: 49780
84: 49781
85: 49782
86: 49783
87: 49784
88: 49785
89: 49786
90: 49787
91: 49788
92: 49789
93: 49790
94: 49791
95: 49792
96: 49793
97: 49794
98: 49795
99: 49796
100: 49797
101: 49798
102: 49799
103: 49825
104: 49826
105: 49827
106: 49828
107: 49829
108: 49830
109: 49831
110: 49832
111: 49833
112: 49834
113: 49835
114: 49836
115: 49837
116: 49838
117: 49839
118: 49840
119: 49841
120: 49842
121: 49843
122: 49844
123: 49845
124: 49846
125: 49847
126: 49848
127: 49849
128: 49850
129: 49851
130: 49852
131: 49853
132: 49854
133: 49855
134: 49856
135: 49857
136: 49858
137: 49859
138: 49860
139: 49861
140: 49862
141: 49863
142: 49864
143: 49866
144: 49867
145: 49868
146: 49869
147: 49870
148: 49871
149: 49872
150: 49873
151: 49874
152: 49875
153: 49876
154: 49877
155: 49878
156: 49879
157: 49880
158: 49881
159: 49882
160: 49883
161: 49884
162: 49885
163: 50274
164: 50275
165: 50276
166: 50277
167: 50278
168: 50279
169: 50280
170: 50281
171: 50282
172: 50283
173: 50284
174: 50285
175: 50286
176: 50287
177: 50288
178: 50289
179: 50290
180: 50291
181: 50292
182: 50293
The port which I'd actually want to have opened is 49786 but the amount of ports reported with permission denied by my small testing algorithm, but not allocated when checking netstat is confusing me
UPDATE 3:
Now that simply running shutdown /s /f /t 0 doesn't work anymore, I've found another workaround which seems to be working fairly reliably in https://social.technet.microsoft.com/Forums/windows/en-US/e0cc1b3e-2c63-451a-abc8-8e1e66a23287/an-attempt-was-made-to-access-a-socket-in-a-way-forbidden-by-its-access-permissions?forum=w7itpronetworking - netsh int ip reset and restarting the computer (normal windows 10 restart is enough) and the port was consistently available on the next start so far (but it was just 3 tries)
UPDATE 4:
Summary of the comments:
setting SO_REUSEADDR in the small f# script makes things only worse
trying to close skype, VPN applications, dropbox and similar didn't have any effect (yes I actually made sure that the processes are terminated)
The reason is that Hyper-V takes over these ports, to prevent it from happening do the following:
dism.exe /Online /Disable-Feature:Microsoft-Hyper-V (will have to restart)
netsh int ipv4 add excludedportrange protocol=tcp startport=<your port> numberofports=1
dism.exe /Online /Enable-Feature:Microsoft-Hyper-V /All
The original solution is here.
If after that you still can't bind to the port do the following:
netsh http add iplisten 0.0.0.0 for IPv4
netsh http add iplisten :: for IPv6
More information is here.
I also had the Hyper-v/WSL problem above, but found a simpler solution:
I had stopped docker before doing this, not sure if it's necessary.
Run as admin:
net stop winnat
net start winnat
A faulty Windows upgrade is the reason for the problems with reserved tcp ports.
See https://github.com/docker/for-win/issues/3171#issuecomment-554587817
With this the problem should be fixed:
netsh int ipv4 set dynamic tcp start=49152 num=16384
That would explain why a clean install fixes these type of problems.
If you face this issue on Win10 2004 that's because of of an issue in this update do the following
netsh int ipv[46] set dynamic tcp start=49152 num=16384
reg add HKLM\SYSTEM\CurrentControlSet\Services\hns\State /v EnableExcludedPortRange /d 0 /f
I face this on opening Jetbrains IDEs and and many other program that use sockets
In case someone lands up here after facing similar issues post updating Windows to May 2020 update which contains WSL2. In my case I also switched docker to WSL2 post which I started facing similar issues with some of my containers.
Note: Run the following commands in powershell (Run as administrator)
Disable Hyper-V.
dism.exe /Online /Disable-Feature:Microsoft-Hyper-V
Remove all hyper-v related network adapters.
Get-HNSNetwork | Remove-HNSNetwork
Reboot.
I am having a similar issue right now(August 2021) and this GitHub issue has some insight into the problem. It seems
net stop winnat
net start winnat
Should fix the issue, you might need to start your application before restarting winnat
Expanding on the selected answer: if you have Hyper-V enabled, you can temporarily disable it during boot by using bcdedit:
bcdedit /Set {current} hypervisorlaunchtype off
Restart and exclude the necessary ports via:
netsh int ipv4 add excludedportrange protocol=tcp startport=<your port> numberofports=1
Then simply re-enable Hyper-V, then restart:
bcdedit /Set {current} hypervisorlaunchtype auto
This prevents having to completely remove and re-add the Hyper-V feature, which requires several restarts.
When I looked for it, the explanation was
An attempt was made to access a socket in a way forbidden by its access permissions. An example is using a broadcast address for sendto without broadcast permission being set using setsockopt(SO_BROADCAST).
Another possible reason for the WSAEACCES error is that when the bind function is called (on Windows NT 4.0 with SP4 and later), another application, service, or kernel mode driver is bound to the same address with exclusive access. Such exclusive access is a new feature of Windows NT 4.0 with SP4 and later, and is implemented by using the SO_EXCLUSIVEADDRUSE option.
[2015-10-11 13:08:26,587][WARN ][transport.netty ] [Joseph] exception caught on transport layer [[id: 0x7e9f652b]], closing connection
java.net.NoRouteToHostException: No route to host
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at sun.nio.ch.SocketChannelImpl.finishConnect(Unknown Source)
at org.elasticsearch.common.netty.channel.socket.nio.NioClientBoss.connect(NioClientBoss.java:152)
at org.elasticsearch.common.netty.channel.socket.nio.NioClientBoss.processSelectedKeys(NioClientBoss.java:105)
at org.elasticsearch.common.netty.channel.socket.nio.NioClientBoss.process(NioClientBoss.java:79)
at org.elasticsearch.common.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337)
at org.elasticsearch.common.netty.channel.socket.nio.NioClientBoss.run(NioClientBoss.java:42)
at org.elasticsearch.common.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
I get this exception when launching the elasticsearch in docker (Actually I only have this problem in CentOS7 docker host)
First, my dockefile exposes the UDP ports.
EXPOSE 9200 9300/udp 9301/udp 9302/udp 9303/udp 9304/udp 9305/udp
When I start the docker container, I opened these ports via -p 9200:9200 -p 9300:9300/udp -p 9301:9301/udp -p 9302:9302/udp -p 9303:9303/udp -p 9304:9304/udp -p 9305:9305/udp
Within docker ps, I do see these ports are opened as 0.0.0.0:9300-9305->9300-9305/udp
And here is some lines of my elasticsearch.yml
cluster.name: changsha
discovery.zen.ping.unicast.hosts: [ "10.0.5.241" ]
network.publish_host: 10.0.5.241
10.0.5.241 is my docker host's IP address. Please what is wrong here? it succeeded in CentOS6 host, but failes on this CentOS7 host.
UPDATE
Following this answer, I get the following result from tcpdump -p -nn icmp.
09:26:53.277117 IP 10.0.5.241 > 172.17.0.8: ICMP host 10.0.5.241 unreachable - admin prohibited, length 68
09:26:53.277494 IP 10.0.5.241 > 172.17.0.8: ICMP host 10.0.5.241 unreachable - admin prohibited, length 68
09:26:53.277822 IP 10.0.5.241 > 172.17.0.8: ICMP host 10.0.5.241 unreachable - admin prohibited, length 68
09:26:53.278043 IP 10.0.5.241 > 172.17.0.8: ICMP host 10.0.5.241 unreachable - admin prohibited, length 68
09:26:54.277753 IP 10.0.5.241 > 172.17.0.8: ICMP host 10.0.5.241 unreachable - admin prohibited, length 68
09:27:04.280703 IP 10.0.5.241 > 172.17.0.8: ICMP host 10.0.5.241 unreachable - admin prohibited, length 68
First, find out the docker interface ip address
# ifconfig
docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.17.42.1 netmask 255.255.0.0 broadcast 0.0.0.0
ether 56:84:7a:fe:97:99 txqueuelen 0 (Ethernet)
RX packets 115761 bytes 12605533 (12.0 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 55687 bytes 22647938 (21.5 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Then add all of the docker IP addresses into whitelist
firewall-cmd --permanent --zone=trusted --add-source=172.17.0.0/16
firewall-cmd --reload
Problem solved
If someone come across the issue in centos 7.4, it`s because of the conflict between docker service and firewalld service.
you can solve by disable firewalld and then restart docker service.
please refer https://sanenthusiast.com/docker-and-firewalld-mess-in-centos-7/
I'm trying to connect to my database from my java application, but it refuses the connection, the error given is this one.
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
at com.mysql.jdbc.Util.handleNewInstance(Util.java:400)
at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1038)
at com.mysql.jdbc.MysqlIO.<init>(MysqlIO.java:339)
at com.mysql.jdbc.ConnectionImpl.coreConnect(ConnectionImpl.java:2247)
at com.mysql.jdbc.ConnectionImpl.connectOneTryOnly(ConnectionImpl.java:2280)
at com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2079)
at com.mysql.jdbc.ConnectionImpl.<init>(ConnectionImpl.java:794)
at com.mysql.jdbc.JDBC4Connection.<init>(JDBC4Connection.java:44)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
at com.mysql.jdbc.Util.handleNewInstance(Util.java:400)
at com.mysql.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:399)
at com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:325)
at java.sql.DriverManager.getConnection(DriverManager.java:664)
at java.sql.DriverManager.getConnection(DriverManager.java:247)
at MainTest.main(MainTest.java:23)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at com.mysql.jdbc.StandardSocketFactory.connect(StandardSocketFactory.java:214)
at com.mysql.jdbc.MysqlIO.<init>(MysqlIO.java:298)
... 20 more
Searching I found that the problem is not the code, but the connection to my localchost, since I can connect to localhost if I go to my web browser and just going to 'localhost', I can't make a telnet to localhost or 127.0.0.1, it refuses the connection.
MacBook-Pro:etc alejandro-trabajo$ telnet localhost
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
Trying fe80::1...
telnet: connect to address fe80::1: Connection refused
telnet: Unable to connect to remote host
I've tried everything I found in the web, make a new 'hosts' file, flushing the dns, restarting the apache server, uncommenting the "ServerName localhost" in the httpd.conf file... I really don't know what to do.
PS: The ping to localhost works perfectly
MacBook-Pro:etc alejandro-trabajo$ ping localhost
PING localhost (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.048 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.075 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.126 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.121 ms
^C
--- localhost ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.048/0.092/0.126/0.032 ms
Maybe this will help.
~ $ ifconfig
...
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 8c:85:90:94:fb:70
inet6 fe80::14aa:f1f1:ede3:b942%en0 prefixlen 64 secured scopeid 0x8
inet 192.168.1.100
~ $ telnet localhost 1234
Trying ::1...`enter code here`
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
telnet: Unable to connect to remote host
~ $ telnet 127.0.0.1 1234
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
telnet: Unable to connect to remote host
~ $ telnet 192.168.1.100 1234
Trying 192.168.1.100...
Connected to 192.168.1.100.
Escape character is '^]'.
This is a simple server
Have a fresh OS X installation here (new VM), and when trying to install Homebrew I just get an SSL error.
fatal: unable to access 'https://github.com/Homebrew/homebrew/': Unknown SSL protocol error in connection to github.com:-9847
Failed during: git fetch origin master:refs/remotes/origin/master -n --depth=1
This is the command I'm using:
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
Checked around a little bit and tried adding --insecure (or -k) and removing the s from https, but it doesn't seem to help. With --insecure I just get that server aborted the SSL handshake.
Anybody have any idea what is wrong here? "xcode-select --install" has been run as well.
EDIT: Following the suggestion below I dumped the packaged with tcpdump to a pcap file and opened that with tshark. From that I'm getting:
1 0.000000 MY_IP_REMOVED -> 192.30.252.130 TCP 78 49451→443 [SYN]
Seq=0 Win=65535 Len=0 MSS=1460 WS=32 TSval=170479114 TSecr=0
SACK_PERM=1
2 0.128228 192.30.252.130 -> MY_IP_REMOVED TCP 78
443→49451 [SYN, ACK] Seq=0 Ack=1 Win=14240 Len=0 MSS=1436 SACK_PERM=1
TSval=2830778812 TSecr=170479114 WS=1024 [ETHERNET FRAME CHECK
SEQUENCE INCORRECT]
3 0.128303 MY_IP_REMOVED -> 192.30.252.130 TCP
66 49451→443 [ACK] Seq=1 Ack=1 Win=132416 Len=0 TSval=170479237
TSecr=2830778812
4 0.150128 MY_IP_REMOVED -> 192.30.252.130 SSL
255 Client Hello
5 0.150913 192.30.252.130 -> MY_IP_REMOVED SSL
1158 Continuation Data [ETHERNET FRAME CHECK SEQUENCE INCORRECT]
6 0.150916 192.30.252.130 -> 81.26.52.196 TCP 64 443→49451 [FIN, ACK] Seq=1101 Ack=190 Win=4237312 Len=0 [ETHERNET FRAME CHECK SEQUENCE
INCORRECT]
7 0.150961 MY_IP_REMOVED -> 192.30.252.130 TCP 66
49451→443 [ACK] Seq=190 Ack=1101 Win=131328 Len=0 TSval=170479257
TSecr=2830778812
8 0.150990 MY_IP_REMOVED -> 192.30.252.130 TCP 66
49451→443 [ACK] Seq=190 Ack=1102 Win=131328 Len=0 TSval=170479257
TSecr=2830778812
9 0.151046 MY_IP_REMOVED -> 192.30.252.130 TCP 66
49451→443 [FIN, ACK] Seq=190 Ack=1102 Win=132416 Len=0 TSval=170479257
TSecr=2830778812
10 0.151156 192.30.252.130 -> MY_IP_REMOVED TCP 64
443→49451 [RST] Seq=1102 Win=4237312 Len=0 [ETHERNET FRAME CHECK
SEQUENCE INCORRECT]
If this is a clean install of OS X I suspect the problem may be a rare issue (bug?) in SecureTransport that could be triggered by a proxy or firewall settings somewhere on your route to github.
Your libcurl is compiled against Security.framework. The error code -9847 means Record overflow:
A record overflow occurred.
Value
–9847
Description
A record overflow occurred.
Available in OS X v10.3 and later.
The error may be pinpointed to this line in tls1Callouts.c. It seems that the client receives a record with unexpected length.
It might be related to similar issue in gnutls:.
There are several issues with TLS connections and the F5 firewall, and
that looks like the case. That firewall terminates a TLS session if
the client hello is between 256 and 512 bytes. If that is the case you
can verify using wireshark.
The solution we adopted in later versions
of gnutls is to add padding:
https://gitlab.com/gnutls/gnutls/commit/b6d29bb1737f96ac44a8ef9cc9fe7f9837e20465
You could try to investigate further with tcpdump/wireshark (replace en0 with your interface name):
$ sudo tcpdump -i en0 —n -s 0 -B 524288 -w test.pcap port 443
View your pcap file in Wireshark (or capture directly in Wireshark) to get detailed info about each phase. There is a good explanation of SSL/TLS on www.sans.org. For comparison, my (successful) conversation goes like this:
$ tshark -r test.pcap
1 0.000000 10.0.0.125 -> 192.30.252.129 TCP 78 51229→443 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=32 TSval=235773429 TSecr=0 SACK_PERM=1
2 0.133049 192.30.252.129 -> 10.0.0.125 TCP 74 443→51229 [SYN, ACK] Seq=0 Ack=1 Win=14240 Len=0 MSS=1460 SACK_PERM=1 TSval=1851779047 TSecr=235773429 WS=1024
3 0.133148 10.0.0.125 -> 192.30.252.129 TCP 66 51229→443 [ACK] Seq=1 Ack=1 Win=131744 Len=0 TSval=235773562 TSecr=1851779047
4 0.138296 10.0.0.125 -> 192.30.252.129 SSL 255 Client Hello
5 0.278168 192.30.252.129 -> 10.0.0.125 TLSv1.2 1490 Server Hello
6 0.278567 192.30.252.129 -> 10.0.0.125 TLSv1.2 1490 Certificate
7 0.278696 10.0.0.125 -> 192.30.252.129 TCP 66 51229→443 [ACK] Seq=190 Ack=2849 Win=129632 Len=0 TSval=235773707 TSecr=1851779083
8 0.278910 192.30.252.129 -> 10.0.0.125 TLSv1.2 399 Server Key Exchange
9 0.278991 10.0.0.125 -> 192.30.252.129 TCP 66 51229→443 [ACK] Seq=190 Ack=3182 Win=130720 Len=0 TSval=235773707 TSecr=1851779083
10 0.339768 10.0.0.125 -> 192.30.252.129 TLSv1.2 141 Client Key Exchange
11 0.551009 192.30.252.129 -> 10.0.0.125 TCP 66 443→51229 [ACK] Seq=3182 Ack=265 Win=15360 Len=0 TSval=1851779144 TSecr=235773767
12 0.551185 10.0.0.125 -> 192.30.252.129 TLSv1.2 157 Change Cipher Spec, Encrypted Handshake Message
13 0.688512 192.30.252.129 -> 10.0.0.125 TCP 66 443→51229 [ACK] Seq=3182 Ack=356 Win=15360 Len=0 TSval=1851779186 TSecr=235773977
14 0.691643 192.30.252.129 -> 10.0.0.125 TLSv1.2 157 Change Cipher Spec, Encrypted Handshake Message
15 0.691720 10.0.0.125 -> 192.30.252.129 TCP 66 51229→443 [ACK] Seq=356 Ack=3273 Win=130976 Len=0 TSval=235774117 TSecr=1851779186
16 0.692351 10.0.0.125 -> 192.30.252.129 TLSv1.2 215 Application Data
If this is really the case a workaround for you might be to compile a custom libcurl with openssl support and make git use your new libcurl. Alternatively you could use ssh instead of https for connecting to github (if you have your public key registered at github).
If you just want a workaround to get Homebrew installed, you could try downloading its install script using another tool. E.g. like this:
$ python -c "import urllib ; urllib.urlretrieve('https://raw.githubusercontent.com/Homebrew/install/master/install', 'install.rb')"
$ ruby install.rb
I'm getting the following error when I try to start JBoss
10:10:43,298 INFO [WebService] Using RMI server codebase: http://127.0.0.1:8083/
10:10:43,938 ERROR [AbstractKernelController] Error installing to Start: name=jboss:service=Naming state=Create mode=Manual requiredState=Installed
java.rmi.server.ExportException: Port already in use: 1098; nested exception is:
java.net.BindException: Address already in use: JVM_Bind
at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:249)
at sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:184)
at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:382)
at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:116)
at sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:180)
at java.rmi.server.UnicastRemoteObject.exportObject(UnicastRemoteObject.java:293)
at java.rmi.server.UnicastRemoteObject.exportObject(UnicastRemoteObject.java:256)
However When I try to see what ports are being listened to. I don't see that port!
H:\>netstat -a -n -o
Active Connections
Proto Local Address Foreign Address State PID
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 824
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:1521 0.0.0.0:0 LISTENING 2036
TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING 752
TCP 0.0.0.0:7717 0.0.0.0:0 LISTENING 2944
TCP 0.0.0.0:8081 0.0.0.0:0 LISTENING 1564
TCP 0.0.0.0:31038 0.0.0.0:0 LISTENING 1436
TCP 127.0.0.1:1038 0.0.0.0:0 LISTENING 2036
TCP 127.0.0.1:1052 0.0.0.0:0 LISTENING 2620
TCP 127.0.0.1:5998 127.0.0.1:5999 ESTABLISHED 4036
TCP 127.0.0.1:5999 127.0.0.1:5998 ESTABLISHED 4036
TCP 127.0.0.1:6000 127.0.0.1:6001 ESTABLISHED 4036
TCP 127.0.0.1:6001 127.0.0.1:6000 ESTABLISHED 4036
TCP 142.174.27.74:139 0.0.0.0:0 LISTENING 4
TCP 142.174.27.74:13148 142.174.12.84:445 ESTABLISHED 4
TCP 142.174.27.74:13253 142.174.134.33:8080 ESTABLISHED 4036
TCP 142.174.27.74:13255 142.174.134.33:8080 ESTABLISHED 4036
TCP 142.174.27.74:13258 142.174.134.33:8080 ESTABLISHED 4036
TCP 142.174.27.74:13259 142.174.134.33:8080 ESTABLISHED 4036
TCP 142.174.27.74:13260 142.174.134.33:8080 ESTABLISHED 4036
TCP 142.174.27.74:13261 142.174.134.33:8080 ESTABLISHED 4036
TCP 142.174.27.74:13262 142.174.134.33:8080 ESTABLISHED 4036
TCP 142.174.27.74:13263 142.174.134.33:8080 ESTABLISHED 4036
UDP 0.0.0.0:445 *:* 4
UDP 0.0.0.0:8081 *:* 1564
UDP 0.0.0.0:8082 *:* 1564
UDP 0.0.0.0:19508 *:* 1244
UDP 127.0.0.1:123 *:* 948
UDP 127.0.0.1:1025 *:* 580
UDP 127.0.0.1:1046 *:* 524
UDP 127.0.0.1:1056 *:* 784
UDP 127.0.0.1:1213 *:* 2888
UDP 127.0.0.1:1257 *:* 2404
UDP 127.0.0.1:2172 *:* 3736
UDP 127.0.0.1:2310 *:* 2188
UDP 142.174.27.74:123 *:* 948
UDP 142.174.27.74:137 *:* 4
UDP 142.174.27.74:138 *:* 4
H:\>
any ideas?
Thanks,
Tam
Try TCPView (TCPView v3.05). I get this "port already in use" quite a lot, and TCPView always usually catches the culprit.
Go to jboss-service.xml under conf folder and change the port for RMI from 1098 to 8099 8099
Restart the server .
We ran into this problem some time ago as well, not just with JBoss, but also MySQL.
I wrote about it in more detail here:
Windows TCP Port Conflicts above 1024
What it comes down to is that Windows uses the port range between 1000 and 5000 for so called "ephemeral" ports. This means that it assigns ports from this range for processes that request a random port.
On Windows 2000/2003 Server installations as well as on Windows XP Pro you can reserve port ranges (even if they only cover a single port) for your applications. Effectively they are not reserved for anything specific, but just excluded from the dynamic allocation. To do so, create or edit the following registry value (type REG_MULTI_SZ/Multi-String Value):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ReservedPorts
In this value specify port ranges in the format xxxx-yyyy with xxxx and yyyy being the lowest and highest port of the range to be reserved. To reserve a single port, just use the same values for both (e. g. 1099).
I guess that port is still in use. You can find that using:
netstat -ao
and
netstat -b
If you can't use that port, find another port and change it in the following XML file:
conf/bindings-beans/META-INF/bindings-jboss-beans.xml
The JBoss 5 has a new ServiceBindingManager which uses bean injection to assign ports at runtime. Changing the port here may do the trick for you.
You can also use a different ports configuration and override the ports by a factor.
Based on the ports mentioned in the file referenced by Sam, and the registry key referenced by Daniel Schneller, the following should do the trick for JBoss EAP 5:
1090-1090 1098-1102 1161-1162 3528-3528 4444-4448 4457-4457 4712-4714 5445-5446 8080-8083 8443-8443
Translated in a .reg file:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"ReservedPorts"=hex(7):31,00,30,00,39,00,30,00,2d,00,31,00,30,00,39,00,30,00,\
20,00,31,00,30,00,39,00,38,00,2d,00,31,00,31,00,30,00,32,00,20,00,31,00,31,\
00,36,00,31,00,2d,00,31,00,31,00,36,00,32,00,20,00,33,00,35,00,32,00,38,00,\
2d,00,33,00,35,00,32,00,38,00,20,00,34,00,34,00,34,00,34,00,2d,00,34,00,34,\
00,34,00,38,00,20,00,34,00,34,00,35,00,37,00,2d,00,34,00,34,00,35,00,37,00,\
20,00,34,00,37,00,31,00,32,00,2d,00,34,00,37,00,31,00,34,00,20,00,35,00,34,\
00,34,00,35,00,2d,00,35,00,34,00,34,00,36,00,20,00,38,00,30,00,38,00,30,00,\
2d,00,38,00,30,00,38,00,33,00,20,00,38,00,34,00,34,00,33,00,2d,00,38,00,34,\
00,34,00,33,00,00,00,00,00
The root cause is that JBOSS was not peoperly shut down.
If you are using Windows,
go to task manager and kill the JBOSS processes.
Reserve the port 1098-1099 in registry.
Restart the oracle service if running, then start the JBOss.
This error is also thrown by Jboss if your default IP address changes due to some problem
means
121...89 to 121...90 Just check it and replace it with a newer IP address. It will work.