View Issue Details

IDProjectCategoryView StatusLast Update
0002767unrealmodule apipublic2006-01-25 07:53
ReporterdecoderAssigned Tosyzop 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Platformx86OSLinuxOS Version2.6.x
Product Version3.2.3 
Target VersionFixed in Version3.2.4 
Summary0002767: SVSSNO/SVS2SNO not being different commands when sent to remote server in m_svssno.c
DescriptionSending SVS2SNO from an ulined server (like services) for a user that is on the server that receives this request first, everything goes fine and the user gets informed with RPL_SNOMASK correctly. If the user is on another server though, he will not get any RPL_SNOMASK notice because m_svssno.c only calls hunt_server_token with SVSSNO, no matter if actually SVSSNO or SVS2SNO was the command that came from the uline. I appended a quickfix which did the job for me, now it seems to work properly:)
Steps To ReproduceAttach services to a network with at least 2 servers. Use /os raw svs2sno localuser +G and /os raw svs2sno remoteuser +G where localuser is a user on the server which holds the services link and remoteuser a user on the other server. You should notice that the remoteuser doesnt get a RPL_SNOMASK notice whereas the localuser gets.

Additional InformationI did not verify this bug on the original Unreal 3.2.3 (Im sure though it's also reproducable there, if someone could check it, that would be nice). Furthermore, I didnt check if that bug was already fixed in CVS, if so, ignore me ;)
TagsNo tags attached.
3rd party modulesUsing a modified UnrealIRCd, m_svssno.c unmodified though (someone please verify on original Unreal, thank you)

Activities

2006-01-23 20:32

 

svssnofix.diff (641 bytes)

aquanight

2006-01-23 21:32

reporter   ~0011044

Yup. Looked at m_svssno.c on mine and found this:

        if (hunt_server_token(cptr, sptr, MSG_SVSSNO, TOK_SVSSNO, "%s %s", 1, pa
rc, parv)
            != HUNTED_ISME)


should probably be (show_change ? MSG_SVS2SNO : MSG_SVSSNO), (show_change ? TOK_SVS2SNO, TOK_SVSSNO) or something like that.

Kinda strange that SVS(2)MODE doesn't have this issue?

decoder

2006-01-24 05:53

reporter   ~0011049

Yea fixing it like that would probably even look better :)

syzop

2006-01-24 08:31

administrator   ~0011050

Can you verify that the fix I put in CVS works properly? I know it should, but.. ;)
Link to download of standalone m_svssno.c file with the fix: http://tinyurl.com/88up4

decoder

2006-01-24 19:24

reporter   ~0011055

I put it into my modified unreal and it seems to work perfectly there (not that my fix didnt, but urs is shorter ;))

syzop

2006-01-25 07:53

administrator   ~0011056

ok.

Issue History

Date Modified Username Field Change
2006-01-23 20:32 decoder New Issue
2006-01-23 20:32 decoder File Added: svssnofix.diff
2006-01-23 20:32 decoder 3rd party modules => Using a modified UnrealIRCd, m_svssno.c unmodified though (someone please verify on original Unreal, thank you)
2006-01-23 21:32 aquanight Note Added: 0011044
2006-01-24 05:53 decoder Note Added: 0011049
2006-01-24 08:31 syzop Note Added: 0011050
2006-01-24 12:10 syzop Status new => feedback
2006-01-24 19:24 decoder Note Added: 0011055
2006-01-25 07:53 syzop Status feedback => resolved
2006-01-25 07:53 syzop Fixed in Version => 3.2.4
2006-01-25 07:53 syzop Resolution open => fixed
2006-01-25 07:53 syzop Assigned To => syzop
2006-01-25 07:53 syzop Note Added: 0011056
2017-01-06 15:48 syzop Category module => module api