Opened 5 years ago

Closed 19 months ago

#1400 closed defect (fixed)

router listens on IPv6 instead of IPv4 despite disabling IPv6

Reported by: rfree Owned by: zzz
Priority: trivial Milestone:
Component: router/transport Version: 0.9.15
Keywords: iputil ipv6 ipv4 ssu ntcp Cc:
Parent Tickets: Sensitive: no

Description

Despite setting in network config:

IPv6 Configuration:
(*) Disable IPv6

the router seems to create internet listening sockets only on IPv6, and not on IPv4:

lsof -i -n | grep LISTEN | grep srv_i2p | grep -v "127.0.0.1:"
java 21272 srv_i2p 63u IPv6 490245 0t0 TCP *:12345 (LISTEN)
java 21272 srv_i2p 66u IPv6 489231 0t0 TCP [::1]:7657 (LISTEN)

# lsof -i -n | grep srv_i2p | grep -i UDP
java 21272 srv_i2p 77u IPv6 491815 0t0 UDP *:12345

where :12345 represents my secret UDP port and secret TCP prot (it is the same number for both tcp/udp)

So if you do not have IPv6 Internet connectivity on your router, you will get no incoming connections (and likely no participating traffic).

This would explain #623

Subtickets

Change History (13)

comment:1 Changed 5 years ago by rfree

Despite changing this setting to:

(*) Prefer IPv4 over IPv6

and restarting the router with "restart" button from the left-side panel, still it does not at all listen on IPv4 protocol (except for some internal localhost connection)

# lsof -i -n | grep srv_i2p | grep IPv4
i2psvc 3954 srv_i2p 6u IPv4 710193 0t0 TCP 127.0.0.1:32001→127.0.0.1:31003 (ESTABLISHED)
java 12551 srv_i2p 3u IPv4 711800 0t0 TCP 127.0.0.1:32001 (LISTEN)

this 2 lines are entire output.

comment:2 Changed 5 years ago by rfree

This is on Debian 7 (with grsecurity but that changes nothing in this case), on java:

Please include this information in bug reports:

I2P version: 0.9.15-0
Java version: Oracle Corporation 1.7.0_65 (OpenJDK Runtime Environment 1.7.0_65-b32)
Wrapper version: 3.5.17
Server version: 8.1.15.v20140411
Servlet version: Jasper JSP 2.1 Engine
Platform: Linux amd64 3.2.63-grsec-mempo.deskmax.0.1.83
Processor: Core i7/i5 (32nm) (corei)
Jbigi: Locally optimized native BigInteger? library loaded from file
Encoding: UTF-8
Charset: UTF-8

$ java -version
java version "1.7.0_65"
OpenJDK Runtime Environment (IcedTea? 2.5.1) (7u65-2.5.1-5~deb7u1)
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)

comment:3 Changed 5 years ago by rfree

More tests - but same result, it does not listen at all on ipv4 instead internal things on localhost

root:~# ps aux | grep i2p
srv_i2p 17632 …
srv_i2p 17637 …
root 23666 0.0 0.0 6312 780 tty2 S+ 11:49 0:00 grep i2p

root:~# sudo netstat -tunelp | grep java | egrep "17632|17637"
tcp 0 0 127.0.0.1:32001 0.0.0.0:* LISTEN 1500 724464 17637/java
tcp6 0 0 127.0.0.1:7660 :::* LISTEN 1500 731809 17637/java
tcp6 0 0 127.0.0.1:6668 :::* LISTEN 1500 731717 17637/java
tcp6 0 0 127.0.0.1:6669 :::* LISTEN 1500 731811 17637/java
tcp6 0 0 127.0.0.1:7601 :::* LISTEN 1500 741512 17637/java
tcp6 0 0 127.0.0.1:5522 :::* LISTEN 1500 740537 17637/java
tcp6 0 0 127.0.0.1:4444 :::* LISTEN 1500 731704 17637/java
tcp6 0 0 127.0.0.1:4445 :::* LISTEN 1500 732495 17637/java
tcp6 0 0 127.0.0.1:4446 :::* LISTEN 1500 739708 17637/java
tcp6 0 0 127.0.0.1:7902 :::* LISTEN 1500 731810 17637/java
tcp6 0 0 127.0.0.1:65534 :::* LISTEN 1500 725783 17637/java
tcp6 0 0 :::12345 :::* LISTEN 1500 725689 17637/java
tcp6 0 0 127.0.0.1:7654 :::* LISTEN 1500 719865 17637/java
tcp6 0 0 127.0.0.1:6664 :::* LISTEN 1500 739351 17637/java
tcp6 0 0 127.0.0.1:5224 :::* LISTEN 1500 734397 17637/java
tcp6 0 0 127.0.0.1:7657 :::* LISTEN 1500 719854 17637/java
tcp6 0 0 ::1:7657 :::* LISTEN 1500 719852 17637/java
tcp6 0 0 127.0.0.1:7658 :::* LISTEN 1500 728522 17637/java
tcp6 0 0 127.0.0.1:7659 :::* LISTEN 1500 731808 17637/java
tcp6 0 0 127.0.0.1:2827 :::* LISTEN 1500 726481 17637/java
udp6 0 0 :::12345 :::* 1500 725728 17637/java

again :12345 is here the udp and tcp internet router port number configured

comment:4 Changed 5 years ago by rfree

Though we think tcp6 0 0 :::12345 and udp6 0 0 :::12345 might listen on ipv4 too; If that is the case, then this is a major bug of not obeying the "ipv4 only" option (maybe that somehow triggers the problem of prorts being not reachable on my system)

comment:5 Changed 5 years ago by rfree

Tested the firewall with socat.

for test on remote computer (over internet, not LAN) I run commands:

while true ; do d=$(LC_ALL=C date); echo "UDP4 $d" | socat - UDP4-SENDTO:1.2.3.4:12345 ; sleep 1 ; done
while true ; do d=$(LC_ALL=C date); echo "TCP4 $d" | socat - TCP4:1.2.3.4:12345 ; sleep 1 ; done

and later:

while true ; do d=$(LC_ALL=C date); echo "UDP6 $d IPv6" | socat - UDP6-SENDTO:1.2.3.4:12345 ; sleep 1 ; done
while true ; do d=$(LC_ALL=C date); echo "TCP6 $d IPv6" | socat - TCP6:1.2.3.4:12345 ; sleep 1 ; done

while on the host computer (that normally runs i2p) I run test server:

socat UDP-RECV:12345 -
socat UDP4-RECV:12345 -
socat UDP6-RECV:12345 -

and later:

socat TCP-RECV:12345 -
socat TCP-LISTEN:12345 -
socat TCP6-LISTEN:12345 -

In each 6 servers I was receiving packets sent both with ipv4 and ipv6 send commands of socat
(though always the IP address was the ipv4 address).

Linux seems to allow receiving ipv4 packets on sockat that is of type ipv6 (udp6,tcp6).

p.s. above 1.2.3.4 is the external public internet IP of the computer that is normally running i2p
and :12345 is the port (same for udp and tcp)

So then

  1. the fact that ipv6, e.g. udp6, tcp6 socket is spawned despite option to disable ipv6

is a bug, but it should not forbid connectivity normally

  1. still, there is some bug/problem with connectivity, since despite firewall/LAN setup working correctly, i2p reports

network as "firewalled", and does not receive inbound traffic (and disables NTCP).

comment:6 Changed 5 years ago by killyourtv

You're misreading the netstat output. The IP 127.0.0.1 is (of course) IPv4…and I don't think your test is testing what you think it's testing.

See this stackexchange post for an explanation of what you're seeing in the netstat output (also: RFC #3493). None of that netstat output points to traffic being routed on IPv6. The console is listening on IPv6 because you haven't disabled that, but that has nothing to do with routing with other systems.

But if you still think IPv6 is a problem, disable IPv6 at the java level, e.g. with wrapper.config

wrapper.java.additional.5=-Djava.net.preferIPv4Stack=true
wrapper.java.additional.6=-Djava.net.preferIPv6Addresses=false

comment:7 in reply to:  3 Changed 5 years ago by somewon

Replying to rfree:

Just so you know, revealing I2P's listening port like that does a good job of almost completely de-anonymizing yourself - anyone can consult their router's netDB and find the IP address of the peer that's listening on that particular port.

So, you may want to make a new pseudonym and burn this one of yours ("rfree") if preserving its anonymity is important to you.

comment:8 Changed 5 years ago by zzz

Milestone: 0.9.160.9.17
Priority: criticalminor

Agreed with killyourtv. Running the lsof command from the OP, I get the same output (with "IPv6" in it), yet I have no public IP address and therefore don't publish an IPv6 address. If the sockets were IPv6 only, I2P wouldn't be working at all. Maybe the man page for lsof and netstat will help understand what it's telling you.

The setting in the OP controls what IPs you publish and whether you use IPv6 to connect to other routers. If you don't have a public IPv6 address, the setting does nothing.

This ticket is unlikely to the the smoking gun you hope it is for #623. As with everything else about #623, the best way to get to the bottom of it is to get all your settings back to the defaults that work for 99.9% of everybody else. That makes it easier to diagnose and less likely that you do something to break it.

Not sure if there's anything in this ticket to fix or not. Linux has a combined networking stack so wildcard listen sockets tend to automatically turn into IPv4 and IPv6. This is different on Windows, which has a "dual stack" implementation, although Java tends to hide all that mess from the application. I think that on linux it's just a natural side-effect of opening a wildcard socket. In the meantime, lowering the priority.

In any case, please don't theories for how to fix one ticket into another ticket, it makes it harder to track things. Thanks.

comment:9 in reply to:  8 Changed 5 years ago by killyourtv

Replying to zzz:

Not sure if there's anything in this ticket to fix or not.

IMHO, if there's anything to fix it's with respect to documentation. That said, I don't know what needs clarifying.

With regards to showing up with tcp6 in lsof or netstat, that's completely normal.

comment:10 Changed 5 years ago by rfree

Ok; So this bug should be that, there should be an option to create only udp, not udp6 - for testing and workaround.
Other java p2p like freenet, does in fact open udp4 socket.

Maybe #623 , or some other bug someone will have one day, will be that "dual stack breaks on my JRE".

I would propose that "disable ipv6" would result in creating strictly tcp/udp instead tcp6/udp6.
Or better, create a new setting "disable ipv6 and create only simple ipv4 sockets".

It is a minor one then.

comment:11 Changed 5 years ago by rfree

Priority: minortrivial

(work around exists, thanks killyourtv)

comment:12 Changed 5 years ago by str4d

Keywords: iputil added; network ip udp tcp removed
Milestone: 0.9.17

comment:13 Changed 19 months ago by Eche|on

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.