View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002767 | unreal | module api | public | 2006-01-23 20:32 | 2006-01-25 07:53 |
| Reporter | decoder | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | x86 | OS | Linux | OS Version | 2.6.x |
| Product Version | 3.2.3 | ||||
| Fixed in Version | 3.2.4 | ||||
| Summary | 0002767: SVSSNO/SVS2SNO not being different commands when sent to remote server in m_svssno.c | ||||
| Description | Sending 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 Reproduce | Attach 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 Information | I 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 ;) | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| 3rd party modules | Using a modified UnrealIRCd, m_svssno.c unmodified though (someone please verify on original Unreal, thank you) | ||||
|
|
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? |
|
|
Yea fixing it like that would probably even look better :) |
|
|
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 |
|
|
I put it into my modified unreal and it seems to work perfectly there (not that my fix didnt, but urs is shorter ;)) |
|
|
ok. |
| 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 |
