View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003001 | unreal | ircd | public | 2006-07-17 14:57 | 2006-08-03 18:42 |
| Reporter | tabrisnet | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | unable to duplicate | ||
| Product Version | 3.2.5 | ||||
| Summary | 0003001: Use of JOIN instead of SJOIN, and "fishy timestamp" | ||||
| Description | I'm not sure if this is a bug report or not... it depends on the interpretation of the usage of JOIN at the server-level, when SJ3 is set in PROTOCTL. *** Notice -- Warning! Possible desynch: SJOIN for channel #pojodbz has a fishy timestamp (1) [hydra.surrealchat.net/hydra.surrealchat.net] This appears to be caused by channels that are joined by a channel-bot, but not by users (to enforce a +lL redirect). The channel-bots use JOIN and not SJOIN, which afaik is legal. This suggests to me that the receiving ircd is messing up the SJOIN that it generates, and instead of making a timestamp (based on current-time) it just sets it to 1. Then whenever a user attempts to join such a channel (tho why they're not bounced at the originating server I am not sure either), this message is generated. Am I not allowed to use normal JOINs, and _must_ use SJOIN (necessitating me to track the timestamp), or is this allowed and thus a bug in Unreal? | ||||
| Additional Information | At present we ignore the timestamp, as we "don't need to know" (we're always an endpoint, and thus any problems will be handled elsewhere). If we are not allowed to use JOIN we will have to stick something into the lower layer to keep track of channels' timestamps as well as user-count (to know if to delete channel/reset the timestamp) | ||||
| 3rd party modules | |||||
|
|
I don't see how a JOIN could cause any such problem, nor can I reproduce it. If you can give me a reproducable case, that would be nice, though.. I suspect [see next]. Perhaps you are sending a mode with a server source? Like ':services.x.net MODE #test +Ll #somechan 1', that is incorrect since with MODE's from servers, it is expected that the last parameter is a timestamp (which can be '0' for 'unspecified'). So such a line would result in a timestamp of 1. The correct MODE would be: ':services.x.net MODE #test +Ll #somechan 1 0'. This is only for server sources, not for 'person' sources, so ':ChanServ MODE #somechan +Ll #somechan 1' is ok. |
|
|
Does look like that is the case. you can probably close this bug as 'notabug'. |
|
|
*nod* |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-07-17 14:57 | tabrisnet | New Issue | |
| 2006-08-03 17:59 | syzop | Note Added: 0012135 | |
| 2006-08-03 18:41 | tabrisnet | Note Added: 0012137 | |
| 2006-08-03 18:42 | syzop | Status | new => closed |
| 2006-08-03 18:42 | syzop | Note Added: 0012138 | |
| 2006-08-03 18:42 | syzop | Resolution | open => unable to duplicate |
