compatibility between unreal and eggdrops 1.6

[Averell]

Hello everybody, hello developers,

For a while I have noticed that unrealircd and eggdrops 1.6 (currently 1.6.20) had a small incompatibility between each other. This was due to the fact that eggdrops "photograph" your userhost mask only when you join a chan the eggdrop is on. If you get a vhost after an authentification, and if the eggdrop knows your identity only through this vhost, you have to cycle the chan in order to make the eggdrop update your vhost change; else the bot does not recognize you. Some other ircd (like those of Undernet) seems to solve this kind of problem by simulating a disconnect followed by a join (and sometimes a serverop) everytime the user takes his vhost. Do the developers intend to implement this kind of thing on future releases of Unrealircd? Or was it already implemented, and perhaps abandoned? Or should I activate something in order to get this effect?

Thanks in advance for your answers

[Jobe]

This issue is purely a client desync. The cause however is UnrealIRCd as you rightly noted.

The solution is quite simple, read the documentation for set::allow-userhost-change

I will also note this does class as an UnrealIRCd support issue so Unreal 3.2 Support would have been the right place to post, but ill move the thread when you've replied.

[Averell]

Thanks a lot! I was sure that the developers already planned this kind of thing!

Best

[katsklaw]

Actually the point of fault in this case is arguable. I say this simply because it is indeed the ircd's job to inform the client of such data when it changes *however*, Unreal sends nick!user@host at every privmsg to channel so clients have many opportunities to resync their data. So at that point the ircd has indeed informed the eggdrop of the new host, eggdrop simply didn't updates it's internal records.

There isn't anything in RFC1459 covering this topic because nothing in the RFC says a users host can change without reconnecting, but again there isn't anything say they can't either. Additionally, nothing says that a client can only update it's internal data on JOIN/PART either.

It's most likely safer to make clients cycle upon host change so that a larger number of clients will update it's data. However, nothing says they really have to. Following Jobe's suggestion is the safest bet. Note about force-rejoin is it can make changing hosts kinda noisy. Especially in channels with several users and net heals.