View Issue Details

IDProjectCategoryView StatusLast Update
0003879unrealircdpublic2009-11-30 16:27
Reportersamaelszafran Assigned Tosyzop  
PrioritynormalSeveritytweakReproducibilityhave not tried
Status resolvedResolutionduplicate 
Platformi386OSFreeBSDOS Version7.2-STABLE
Product Version3.2.8 
Fixed in Version3.2.9-RC1 
Summary0003879: Problem with mapping IPv4 adresses
DescriptionOkay, so I tried to link to my hub. Let's assume its IP is 192.168.0.1.

I made the link block on the hub and on the server. No firewall rules blocking it.

First I did a link setting looking like this:

hostname 192.168.0.1;
options { autoconnect; };

And the port, password, etc..

Now, here's the funny part. My ircd told me, that it connected - but after a minute it printed "no responce from my.hub (::ffff:192.168.0.1) closing link" (or something like this, I might have rewritten the syntax incorrectly).

So, I have read about the Ipv4v6 mapping issue on freebsd.. So i set my link block to something like this:

hostname [::ffff:192.168.0.1];
options { autoconnect; };

And... nothing. Still the same error. I tried also without the [brackets] - still with no result.

I thought that there must be some issue with the hub - but then I tried something else.

I have removed the autoconnect option from my link block, and made such an option on the hub - they linked immediatelly, without a complaint.
Additional InformationMy IRCD version is 3.2.8.1 compiled with Ipv6
HUBs ircd version is 3.2.8.1 compiled WITHOUT IPv6
HUBs running GNU/Debian

There are no problems when linking to any other hub using Ipv6, but there's always the same issue when linking through v4.

This issue seems to dissapear when using FreeBSD 7.2-RELEASE

I haven't touched any source code.
TagsNo tags attached.
3rd party modules

Activities

samaelszafran

2009-11-22 19:37

reporter   ~0015965

Just a small note:

On the -RELEASE version I've checked there might be a slightly older Unreal compile - as I compiled it about two, or three months ago.

syzop

2009-11-22 21:11

administrator   ~0015966

Perhaps it's this? http://www.vulnscan.org/UnrealIRCd/faq/#98
It's in the FAQ for listen problems, but it probably also happens for connects.

Let me know if this is it, then I'll update the FAQ item.

syzop

2009-11-22 21:12

administrator   ~0015967

Last edited: 2009-11-22 21:13

Btw, it probably is ipv6_ipv4mapping which is the problem (and not net.inet6.ip6.v6only, though you probably want that fixed too if not done already...)

samaelszafran

2009-11-22 21:18

reporter   ~0015968

Neither listen nor ipv6_ipv4mapping is the problem. ipv6_ipv4mapping must be on, or I won't be able to run unreal listening on *.

net.inet6.ip6.v6only is switched off.

The problem is not in listening, but in linking. Listening on v4 works jsut fine - but I can't connect through v4 to my hub. It tells me, that it connects, then it timeouts.

However, the hub is able to connect to me through v4. Like... My server isn't able to connect to the hub correctly? But it has to be in ircd - I tried connecting on different ports to the hub through telnet, and it worked.

syzop

2009-11-23 09:41

administrator   ~0015969

Best way to trace this issue is to make a packet dump, which I can analyze.

I don't know if you're familiar with tcpdump, but it goes like this:
tcpdump -i NAME-OF-INTERFACE -w packetdump -s 0 host IPOFREMOTEHOST
where IPOFREMOTEHOST is straightforward, and NAME-OF-INTERFACE is the interface where packets will travel to/from the remote host.
eg: tcpdump -i eth0 -w packetdump -s 0 host 192.168.0.1

Then, try to link, 'connected' etc..., and once you get that final note of 'no response .. closing link' you hit CTRL-C in your tcpdump screen.
Then send the file called 'packetdump' to [email protected]

Thanks.

samaelszafran

2009-11-23 14:21

reporter   ~0015971

I've sent you the file you wanted.

syzop

2009-11-23 15:25

administrator   ~0015972

First just to verify what I see:
1) First you tried to connect to the hub normally (or autoconnect)
2) After that fails, in other words: a considerable time later, you connect from the hub to the server which works. So, in the other direction
Right?

Ok, now what I see is *very* odd.
In the failed connection attempts I can see it is trying to connect from the ip 0.0.0.1 to your hub. Obviously, that's never going to work.

This reminds me of this fix in CVS (after 3.2.8[.1] release):
- Fixed IPv4 ip's in link::bind-ip on IPv6 builds. This caused issues ranging
  from not binding to that ip when linking, to not being able to link at
  all. Also fixed a very small memory leak upon /REHASH. Bug reported by
  Mr_Smoke (0003858).
Could you check out if the CVS version of Unreal fixes your issue?
http://www.vulnscan.org/UnrealIRCd/cvs/Unr3.2-20091123.tar.gz

samaelszafran

2009-11-30 15:03

reporter   ~0015974

Sorry, out of country. I will try as soon as possible - I'll launch a test one on another IP, because I can't shut the current IRCd down.

And yes, you described it correctly - that's exactly what I did.

samaelszafran

2009-11-30 15:25

reporter   ~0015975

Yeah, the CVS version seems to work.

syzop

2009-11-30 16:26

administrator   ~0015976

Great :)

Issue History

Date Modified Username Field Change
2009-11-22 17:43 samaelszafran New Issue
2009-11-22 19:37 samaelszafran Note Added: 0015965
2009-11-22 21:11 syzop Note Added: 0015966
2009-11-22 21:12 syzop Note Added: 0015967
2009-11-22 21:13 syzop Note Edited: 0015967
2009-11-22 21:13 syzop Note Edited: 0015967
2009-11-22 21:18 samaelszafran Note Added: 0015968
2009-11-23 09:41 syzop Note Added: 0015969
2009-11-23 14:21 samaelszafran Note Added: 0015971
2009-11-23 15:25 syzop Note Added: 0015972
2009-11-30 15:03 samaelszafran Note Added: 0015974
2009-11-30 15:25 samaelszafran Note Added: 0015975
2009-11-30 16:26 syzop QA => Not touched yet by developer
2009-11-30 16:26 syzop U4: Need for upstream patch => No need for upstream InspIRCd patch
2009-11-30 16:26 syzop Note Added: 0015976
2009-11-30 16:26 syzop Status new => resolved
2009-11-30 16:26 syzop Fixed in Version => 3.2.9-RC1
2009-11-30 16:26 syzop Resolution open => duplicate
2009-11-30 16:26 syzop Assigned To => syzop