Re: "Permission denied" using socket with IPv6
Sounds like a native configuration issue all right. The native
connect appears to be getting an EPERM which according to Linux manpage
could be caused b a local firewall rule
Michael
On 01/06/15 21:14, Bobby Bissett wrote:
Hi all,
Can someone tell me how to diagnose this issue? I can't create a
connection to another node using IPv6 because of the error below -- a
short app demonstrates the problem. Everything I've found online so
far is aimed at using IPv4 instead, but that's not my goal. This is on
a Centos 6.6 virtual machine.
--- begin ---
[root@TWO test]}> java -version
java version "1.7.0_79"
OpenJDK Runtime Environment (rhel-2.5.5.3.el6_6-x86_64 u79-b14)
OpenJDK 64-Bit Server VM (build 24.79-b02, mixed mode)
[root@TWO test]}>
[root@TWO test]}>
[root@TWO test]}> cat IPv6Test.java
import java.net.InetAddress;
import java.net.Socket;
public class IPv6Test {
public static void main(String[] args) {
try {
InetAddress ia =
InetAddress.getByName("fe80::20c:29ff:fe98:9210");
System.err.println("Opening socket for: " + ia);
Socket socket = new Socket(ia, 7800);
System.err.println("We have: " + socket);
} catch (Exception e) {
e.printStackTrace();
}
}
}
[root@TWO test]}>
[root@TWO test]}> javac IPv6Test.java && java IPv6Test
Opening socket for: /fe80:0:0:0:20c:29ff:fe98:9210
java.net.SocketException: Permission denied
at java.net.PlainSocketImpl.socketConnect(Native Method)
at
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:579)
at java.net.Socket.connect(Socket.java:528)
at java.net.Socket.(Socket.java:425)
at java.net.Socket.(Socket.java:241)
at IPv6Test.main(IPv6Test.java:10)
[root@TWO test]}>
[root@TWO test]}> java -version
java version "1.7.0_79"
OpenJDK Runtime Environment (rhel-2.5.5.3.el6_6-x86_64 u79-b14)
OpenJDK 64-Bit Server VM (build 24.79-b02, mixed mode)
--- end ---
From this node, am able to ping6 the address fine:
[root@TWO test]}> ping6 -I eth3 fe80::20c:29ff:fe98:9210
PING fe80::20c:29ff:fe98:9210(fe80::20c:29ff:fe98:9210) from
fe80::20c:29ff:fec6:91a eth3: 56 data bytes
[...]
2 packets transmitted, 2 received, 0% packet loss, time 1023ms
I don't have selinux or a firewall running, not that I think that
would matter since Java can't start to connect anyway from the message
above.
Thanks,
Bobby
Re: "Permission denied" using socket with IPv6
Whoo-hoo! With these two bits of info and some time with my network guru, I can finally connect. Info below: On Tue, Jun 2, 2015 at 5:09 AM, Michael McMahon < michael.x.mcma...@oracle.com> wrote: > Sounds like a native configuration issue all right. The native > connect appears to be getting an EPERM which according to Linux manpage > could be caused b a local firewall rule > On Mon, Jun 1, 2015 at 10:22 PM, Bernd wrote: > For a Link-Local Address you might need to define the device scope with > the % suffix. If you cant specify that in your software, you can use a > /etc/host entry. > Things weren't working for me despite stopping NetworkManager and ip6tables, but the combo of stopping those *and* creating a proper global address for both machines instead of a link-local address means I can connect fine now. I'm not sure I want to try going back to the link-local based on info from my network admin. Thanks everyone for the suggestions. Once I wrap my head around what actually happened (and try this with centos 7 using nmtui) will write up the details and can share with this list. Thank you again, Bobby
Re: "Permission denied" using socket with IPv6
Hello, The reason the IPv6 Stack requires you to specify the interface for a link local address is because such an address has no identifying prefix (since the link local network prefix is the same for all interfaces and therefore the Is no entry in the forwarding information base (routing table). The EPERM is a rather unfortunate choice for that illegal (missing) argument. In some conditions - (especially older OS kernels) it worked if you had only one global interface. Gross Bernd > Am 02.06.2015 um 17:58 schrieb Bobby Bissett : > > Whoo-hoo! With these two bits of info and some time with my network guru, I > can finally connect. Info below: > >> On Tue, Jun 2, 2015 at 5:09 AM, Michael McMahon >> wrote: >> Sounds like a native configuration issue all right. The native >> connect appears to be getting an EPERM which according to Linux manpage >> could be caused b a local firewall rule > >> On Mon, Jun 1, 2015 at 10:22 PM, Bernd wrote: >> For a Link-Local Address you might need to define the device scope with the >> % suffix. If you cant specify that in your software, you can use a /etc/host >> entry. >> > > Things weren't working for me despite stopping NetworkManager and ip6tables, > but the combo of stopping those *and* creating a proper global address for > both machines instead of a link-local address means I can connect fine now. > I'm not sure I want to try going back to the link-local based on info from my > network admin. > > Thanks everyone for the suggestions. Once I wrap my head around what actually > happened (and try this with centos 7 using nmtui) will write up the details > and can share with this list. > > Thank you again, > Bobby >
