linked bots problems with bans

[Spectre]

(12:36:56) <hubbot> [09:37] Linked to leafbot.
(12:36:56) <hubbot> *** Linked to leafbot
(12:36:56) <hubbot> [09:37] Creating resync buffer for leafbot
(12:36:56) <hubbot> [09:37] Sending user file send request to leafbot
(12:36:56) <hubbot> [09:37] Completed userfile transfer to leafbot.
(12:37:07) <testing> .+ban banthem!*@*
(12:37:07) <hubbot> [09:37] #testing# (GLOBAL) +ban banthem!*@* (requested)
(12:37:07) <hubbot> New ban: sik!*@* (requested)

(12:37:07) <leafbot> [09:37] hubbot: global ban banthem!*@* (testing:requested)
(12:37:09) <leafbot> [09:37] hubbot: cancel ban banthem!*@*

thats all the messages i get in dcc afteri followed the botnet link http://www.egghelp.org/enhance.htm but when i set the banthem!*@* mask banned the leaf see it but doesnt set it in the room anyone can explain how to make the bot set it ?

[YooHoo]

Be more helpful if you posted .status and .chaninfo... so we can see how your bot is setup.

[Spectre]

.status
<leaf> #Love : 65 members, enforcing "+tn" (greet)
<hub> #Love : channel is set +inactive
.chaninfo

<Spectre> .chaninfo #Love
<leaf> Settings for dynamic channel #Love:
<leaf> Protect modes (chanmode): +tn
<leaf> Idle Kick after (idle-kick): DON'T!
<leaf> stopnethack: DON'T!
<leaf> aop-delay: 5:30
<leaf> revenge-mode: 0
<leaf> ban-time: 180
<leaf> exempt-time: 0
<leaf> invite-time: 60
<leaf> Other modes:
<leaf> -inactive +statuslog -secret +shared
<leaf> +greet +seen +cycle +dontkickops
<leaf> +protectops -protectfriends -revenge -revengebot
<leaf> -bitch -autoop -autovoice -nodesynch
<leaf> -enforcebans +dynamicbans +userbans -autohalfop
<leaf> -protecthalfops
<leaf> -dynamicexempts +userexempts +dynamicinvites +userinvites
<leaf> flood settings: chan ctcp join kick deop nick
<leaf> number: 9 5 0 3 3 0
<leaf> time : 3 60 0 10 10 0
<leaf> [10:55] #Spectre# chaninfo #Love

<Spectre> .chaninfo #Love
<hub> Settings for dynamic channel #Love:
<hub> Protect modes (chanmode): +tn
<hub> Idle Kick after (idle-kick): DON'T!
<hub> stopnethack: DON'T!
<hub> aop-delay: 5:30
<hub> revenge-mode: 0
<hub> ban-time: 180
<hub> exempt-time: 0
<hub> invite-time: 60
<hub> Other modes:
<hub> +inactive +statuslog -secret +shared
<hub> +greet -seen +cycle +dontkickops
<hub> +protectops -protectfriends -revenge -revengebot
<hub> -bitch -autoop -autovoice -nodesynch
<hub> -enforcebans +dynamicbans +userbans -autohalfop
<hub> -protecthalfops
<hub> +dynamicexempts +userexempts +dynamicinvites +userinvites
<hub> flood settings: chan ctcp join kick deop nick
<hub> number: 7 5 5 3 3 0
<hub> time : 3 60 60 10 10 0
<hub> [10:55] #Spectre# chaninfo #Love

[ZvOO]

That's exactly the same problem I'm having. I posted about it in this forum 4 days ago but no one has answered me yet either. At least you've received one request for more information, so I'll be watching your thread closely.

It seems there has to be a simple config adjustment since ban-sync'ing across eggdrop botnets is presented to work for others within the linking instructions on the egghelp.org site. And you would think that through the years this failure to propagate bans from the hub problem has been experienced by at least a few others beyond you and me within the last two weeks. As such, it seems that someone, somewhere must have figured out how to fix the issue. Unfortunately I've not had success locating anything about it on the web.

Hopefully someone in the know will jump in with some ideas.

Good luck

[nml375]

Spectre:
Hard to tell what is going on. It would seem your leaf eggdrop recieves a "-b" share command just seconds after it recieves the "+b" one.
There is really only two locations in the source where that message is sent from; the first in src/mod/channels.mod/userchan.c: u_delban
the second in src/mod/share.mod/share.c: share_mns_ban

Without going much deeper into where these functions are called, the only way a "-b" message would be sent from the hub, would be if the ban is removed from there.

I guess the raw botnet traffic and raw share traffic log output might provide some further clues, but for now, I can't recall any reasons for this happening. The closest thing I can think of would be setting the expire-time to 1 or 2 seconds, though this would usually cause a log message on the hub when the ban expires.

Regarding setting the ban on the channel; since your channel is configured as dynamicbans, the ban will not automatically be set unless your eggdrop sees someone matching the ban on the channel. Your hubbot would generally add the ban as you execute the .+ban command however.

[speechles]

<hub> #Love : channel is set +inactive

Could also be that to the hub, the channel is inactive. Of course any bans should be neutralized when received by the hub which they are. It cancels them.

[nml375]

speechles:
Are you sure? First of all, the posted example is regarding a global ban, not a channel ban.

Secondly, channel-speciffic ban entries should remain valid within the bot as long as there is a valid channel registered (active or inactive). Atleast, I've set channels +inactive temporarily, yet once I've set them -inactive, the banlist has been intact (and updated when needed).

Or well, never tried adding a ban from a bot with the channel set +inactive, other ways have worked as I recall though.

Edit: Just tried adding and removing various channel banmasks on +inactive channels, and worked like a charm.

[speechles]

speechles:
Are you sure? First of all, the posted example is regarding a global ban, not a channel ban.

That I didn't notice. So yeah, my comments aren't an issue then. It is behaving as if this were an owner issuing the command who doesn't actually have a user record for themselves. It seems they simply /msg bot hello and took ownership of the bot this way. Unless they've also done this to every other bot linked the ban will be negated. This is why after you obtain ownership you craft yourself a user record as well. The original poster needs to let us see his .whois record for his username on his bot to tell if this was done or not.

[nml375]

speechles:
Err... Now I don't quite follow you. The hub bot issues the "+b" share-command, then instantly issues the "-b" share-command for the previously created ban. If someone tried to use the .+ban command without proper privileges, the ban would not be created in the first place, and not shared at all.
And if you're thinking of the "creator" field of the ban record, this is not matched against any of the eggdrops userlists... in fact, the following works just fine:

Code: Select all

.tcl newban "*!user@evil.host.com" "Bogus" "This is a ban with a bogus creator..."

[YooHoo]

Couldn't all this be solved by recompiling the eggdrop? And the owners re-adding themselves correctly?

[nml375]

YooHoo:
I have my doubts that any owner-records are related to this issue at all, and I don't see where re-compiling the binaries come into the picture. If the userfiles were beyond recovery, then it's usually just a matter of deleting these and starting the eggie in user creation mode (-m).