View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0004720unrealircdpublic2016-07-28 07:172016-09-26 10:31
ReporterCoreDuo Assigned Tosyzop  
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
OSFreeBSD 
Product Version4.0.4 
Fixed in Version4.0.7 
Summary0004720: Server running FreeBSD failing to link over SSL
DescriptionI've recently migrated my network to UnrealIRCd 4.x. All of the servers are working except one that's running FreeBSD. It's a shell host, but I've also been able to reproduce it using a regular FreeBSD install in VMware. It delinks with "Read error" and that's it. There didn't appear to be any additional useful information when I enabled debugging either. The server will link fine if I switch back to Unreal 3.2.10.6.
Additional InformationIn attempting to troubleshoot it, I was able to get it to link to a non-production testing server using the exact same configuration, so I'm out of ideas on what to do next.
TagsNo tags attached.
3rd party modules

Activities

CoreDuo

2016-07-28 07:20

reporter   ~0019357

Forgot to add that it also links fine if I switch to a non-SSL port.

CoreDuo

2016-07-28 19:38

reporter   ~0019363

Last edited: 2016-07-29 00:14

 Per DBoyz's advice, here's what I got on both sides on the link.

Server 1 (live hub):
http://pastie.org/pastes/10922316/text?key=2lauvbgykxk8eisorurgg

Server 2 (non-production test server):
http://pastie.org/pastes/10922015/text?key=vaxojuwtl0lppnxkoihera

syzop

2016-07-29 09:21

administrator   ~0019364

Does it work the other way around? You're currently linking from test -> hub, what happens if you link from hub -> test?

Also, not sure if DBoyz told you, could you enable the eyes and junk snomask prior to the linking attempt?
/MODE Yournick +s +ej
...just in case it spits out something useful while linking

syzop

2016-07-29 09:23

administrator   ~0019365

Oh or are you currently connecting from hub to test, well anyway, switch the direction, see if that helps :D
.. and the snomask thing :)
Thanks!

CoreDuo

2016-07-29 09:36

reporter   ~0019366

Last edited: 2016-07-29 09:50

 Tried linking in the other direction.

http://pastie.org/pastes/10922635/text?key=d7lebjctk3ria7xoalksa

(debugging was still enabled)

The hub doesn't even acknowledge the linking attempt.

EDIT: Second attempt it gave me a "no matching link configuration" error but I can't see anything in the link blocks that's wrong.

http://pastie.org/pastes/10922643/text?key=hsxil1s3zlkrzncz3lhfwg

syzop

2016-07-29 19:21

administrator   ~0019367

Did you set a link::incoming::mask? (In U4 incoming and outgoing are separate sub-blocks)

CoreDuo

2016-07-29 19:51

reporter   ~0019368

Last edited: 2016-07-29 19:56

 Yes, both of them have

incoming {
     mask *;
};

I added them before because from what I recall Unreal throws a specific error for a missing incoming {} sub-block. The error it gives me suggests that the link block doesn't exist at all.

weekend

2016-09-18 06:31

reporter   ~0019411

Last edited: 2016-09-18 08:31

 I am encountering what I think is the same issue. From my testing I can't seem to get the server with Unreal4.0.6 on freebsd to connect to a network that has an other freebsd host (one with 3.2.10.7)

I have done a lot of testing, here are my results:

the set up involves 3 hosts, 4 ircd's

hub running Unreal3.2.10.7 on freebsd 9

wolf runnning Unreal4.0.6 on debian
link (on same host for testing) running Unreal3.2.10.7 on debian

lille running Unreal4.0.6 on freebsd 10


1)
lille can connect to link, link can connect to lille
wolf can connect to lille, lille can connect to wolf

2)
hub to lille: fails
(can't test lille to hub at the moment due to firewall rules at hub)
output: https://paste.hackthissite.org/WQbw7b35 password hub2lille

3)
hub and wolf are linked(along with services, and they have users, I can't really play around much.., though I did the same test without services too)

a) lille connects to wolf: fails, output: https://paste.hackthissite.org/QyE5VbJO password lille2wolf
b) wolf connects to lille: fails, output: https://paste.hackthissite.org/pvbMeb5B password wolf2lille

4) now for the really fun part:
hub and wolf are linked, and lille is is linked to link

a) link connects to wolf: connects but link will drop lille, output https://paste.hackthissite.org/05ZYvREl password link2wolf
b) wolf connects to link: connects but link will drop lille, output https://paste.hackthissite.org/jlbBaaEA password wolf2link
c) link connects to hub: connects but link will drop lille, output https://paste.hackthissite.org/vAG6OPZW password link2hub
d) hub connects to link: connects but link will drop lille, output https://paste.hackthissite.org/gkEkv4Z6 password hub2link

and 1 more paste that includes all the things (in the same order) in case thats more convenient
https://defuse.ca/b/77Sti2oakY2vzCUT8MCWpI password: link2lille2wolf2hub


Unfortunately I can't change the Unreal3.2.10.7 on freebsd 9 yet untill the other freebsd host with unreal 4 is ready to replace it.

I hope this helps track this bug down. Let me know theres something else you'd like me to try or if you want to try out a patch.
(note when I ran lille with debug mode I didn't get more usefull messages but they have since been deleted)

EDIT: I compiled again with debug mode, suddenly things are slightly different.
if hub->wolf->link are connected, lille can connect to link or link to lille
if hub->wolf, lille can't connect to wolf and wolf can't connect to lille
if hub is gone from wolf, lille can connect to wolf, if later wolf connects to hub it all stays connected together. Its past 8am now, maybe I'm just dreaming all this.

syzop

2016-09-19 19:48

administrator   ~0019412

Thanks for your information. I'll see if I can read up on it this week(end) and get back to you.

syzop

2016-09-23 11:51

administrator   ~0019416

Complex case :D

I've never heard before of server Z being delinked when X and Y link. The only exception is if have configured a server as a leaf in a link block, but nowhere in your output this appears the case.

So the problem is 'link' and/or 'lille'. With 'lille' being the main suspect since it doesn't allow an incoming connection from 'hub' and because you say "if hub->wolf, lille can't connect to wolf and wolf can't connect to lille". In that last case "link" is not a player.

I don't have a FreeBSD machine myself, would it be possible for me to get access to 'lille' and do some debugging/linking on it? Are there any IRC users on that server? Could you contact me at [email protected] ? I may have time on Sunday to debug this.

syzop

2016-09-26 10:31

administrator   ~0019417

Thanks to both for the report and to weekend for providing a shell with everything on it so I could reproduce it, debug it and fix things.

The exact fix is here:
https://github.com/unrealircd/unrealircd/commit/bbca690d480c08636530fd9a979148d44f8cdf85
.. as always, the exact fix is "simple" :)

You should now have stable SSL connections on FreeBSD. Or at least as far as UnrealIRCd is concerned :]

*****
commit bbca690d480c08636530fd9a979148d44f8cdf85
Author: Bram Matthys <[email protected]>
Date: Mon Sep 26 10:23:58 2016 +0200

    Fix issue with instable SSL connections on FreeBSD (especially server links)
    Reported by CoreDuo and weekend (0004720). Thanks weekend for providing a shell
    to debug this issue.

commit a9db5b8981146c56f33d5af495becc30adbb428c
Author: Bram Matthys <[email protected]>
Date: Mon Sep 26 10:23:00 2016 +0200

    DEBUGMODE: improve freebsd kevent debug messages

Issue History

Date Modified Username Field Change
2016-07-28 07:17 CoreDuo New Issue
2016-07-28 07:20 CoreDuo Note Added: 0019357
2016-07-28 19:38 CoreDuo Note Added: 0019363
2016-07-28 19:38 CoreDuo Note Edited: 0019363
2016-07-28 19:39 CoreDuo Note Edited: 0019363
2016-07-28 19:40 CoreDuo Note Edited: 0019363
2016-07-29 00:13 CoreDuo Note Edited: 0019363
2016-07-29 00:14 CoreDuo Note Edited: 0019363
2016-07-29 09:21 syzop Note Added: 0019364
2016-07-29 09:23 syzop Note Added: 0019365
2016-07-29 09:36 CoreDuo Note Added: 0019366
2016-07-29 09:37 CoreDuo Note Edited: 0019366
2016-07-29 09:38 CoreDuo Note Edited: 0019366
2016-07-29 09:49 CoreDuo Note Edited: 0019366
2016-07-29 09:49 CoreDuo Note Edited: 0019366
2016-07-29 09:50 CoreDuo Note Edited: 0019366
2016-07-29 19:21 syzop Note Added: 0019367
2016-07-29 19:51 CoreDuo Note Added: 0019368
2016-07-29 19:54 CoreDuo Note Edited: 0019368
2016-07-29 19:55 CoreDuo Note Edited: 0019368
2016-07-29 19:56 CoreDuo Note Edited: 0019368
2016-09-18 06:31 weekend Note Added: 0019411
2016-09-18 08:31 weekend Note Edited: 0019411
2016-09-19 19:48 syzop Note Added: 0019412
2016-09-23 11:51 syzop Note Added: 0019416
2016-09-26 10:31 syzop Note Added: 0019417
2016-09-26 10:31 syzop Status new => resolved
2016-09-26 10:31 syzop Fixed in Version => 4.0.7
2016-09-26 10:31 syzop Resolution open => fixed
2016-09-26 10:31 syzop Assigned To => syzop