Im working with three bots, two on different computers on the same network, and a third on a seperate network. The two on the same network are linked, sharing, and transferring the user file fine. When I link the bot from the seperate network to the hub on the other network, it links, but I get an error when they try to share&transfer the userfile.
This is the error I see from the bot on the seperate network
Downloading user file from hub
[bot2(dcc)] [16:24] Ending sharing with hub (Can't send userfile to you
(internal error)).
This is what I see from the Hub
[20:29] Sending user file send request to bot2
[20:30] BAD FILE -- can't send userfile
Transfer and share mods are loaded, flags are right, so Im not sure really whats going on
The other thing it might be is the firewall on the two bots on the other network, both of their telnet ports are open and have no problems linking with the third bot on the other network, but do they use another port for transfering user files? The third bot on the seperate nework is on the dmz computer.
It would seem your hub is unable to create or open the copy of your userfile that's to be sent. Checked system quotas, write permissions, and such?
Userfile transfers are done on random ports (pretty much like a dcc file transfer - in fact, you can use the same settings to restrict which ports are used for the userfile transfer as with dcc's).
I not sure if this is related. Sound like whats happening to me, except, once the userfile can't be transferred the hub crashes HARD. Then after that, once it queries the nonhub bot, it crashes hard again.
This behavior is with the .18 ubuntu packages as well as the .19 I compiled myself with the ssl patch.
The text files of the outputs from the crashes as well as backtraces are there at the above link. I did not want to drop a massive paste here.
was the source also from ubuntu? since the reason i asked the version, was i couldn't find the given error message in eggdrop1.6.18 source to check why this happens. looks like this might be down to ubuntu's changes to eggdrop source code.
The error-message is present in the "standard" source..
It's raised whenever the userfile copy, that is to be "dcc'd", can't be opened. Or rather, whenever "raw_dcc_send(share_file, "*users", "(users)", share_file))" returns anything greater than 0 (in 1.6.18, see src/mod/share.mod/share.c:1913, and src/mod/transfer.mod/transfer.c:972/1241). More speciffic, DCCSEND_BADFN in this case.
That in turn is caused whenever the "fopen(filename, "r")" instruction in raw_dcc_send returns NULL. Unfortunately, the current code lacks means of getting any further information (some logdumping of errno would've been helpful).
My best suggestions would be to check tmp-paths, file system permissions, and such (are you starting it from the right directory, do you have write-permissions in current directory, etc)
TCL_no_TK wrote:was the source also from ubuntu? since the reason i asked the version, was i couldn't find the given error message in eggdrop1.6.18 source to check why this happens. looks like this might be down to ubuntu's changes to eggdrop source code.
If figured since Eggdrop 1.9 just came out, and Ubuntu does not yet have the source for 1.9,I'd compile the source from the source. Basically no I did not use Ubuntu's .18 source to compile .19.
nml375 wrote:The error-message is present in the "standard" source..
It's raised whenever the userfile copy, that is to be "dcc'd", can't be opened. Or rather, whenever "raw_dcc_send(share_file, "*users", "(users)", share_file))" returns anything greater than 0 (in 1.6.18, see src/mod/share.mod/share.c:1913, and src/mod/transfer.mod/transfer.c:972/1241). More speciffic, DCCSEND_BADFN in this case.
That in turn is caused whenever the "fopen(filename, "r")" instruction in raw_dcc_send returns NULL. Unfortunately, the current code lacks means of getting any further information (some logdumping of errno would've been helpful).
My best suggestions would be to check tmp-paths, file system permissions, and such (are you starting it from the right directory, do you have write-permissions in current directory, etc)
Thank you! I'll check those things and update this thread.
Well, it was because leaf bot's telnet ports could not be reached. The hub would die on failed transmit.
To test that theory, I created and ran a bot from the same machine, and successfully created a two bot botnet.