$UserIP

aDe · Post by **aDe** » 2003-01-13 07:14

How about an extension to find out your external ip and set it automatically?

Client: $UserIP <nickname>
Server: $UserIP <nickname> <ip address>

When the client gets a userip matching its own nickname it would automatically set it in the settings so that you don't need to find it out yourself everytime DSL users connect to the net!!

NMDC hub can have a simple script to reply to this, and newer hub software can have it implemented..
Obviously this could be used for ops that want to find out a users IP too.. what do you think

sandos · Post by **sandos** » 2003-01-13 09:20

Yup, its nice.

=)

ender · Post by **ender** » 2003-01-13 12:50

better ask for $MyIP then, and the nickname part is useless IMO...
client: $MyIP|
hub: $YourIP 123.45.67.89|

Nev · Post by **Nev** » 2003-01-13 14:04

Hmm.. Good feature, but I think the ender-way is the way to do this...
The protocol should not allow for monitoring other users IP. If one would want that; implement it explicitly in the hubsoft or script!

I have found that sending $jibberish <unknownparam1> ... <unknownparamN>| does not confuse either nmdchub, nmdc or dc++...

Therefore I think all hubs and all clients MUST ignore unspecified and unhandled messages.....

This is important, as with the current rate of new ideas we had lately, we wouldn't want the $Supports to be a mile long. I think only stuff that implies a different behavour from the original protocol should be added to supports. Messages that are ignored by hubs can safely be added to our new venture without bothering with supports....

.. so we could add this easily...

Now we (perhaps) got $Kick and $MyIP and $YourIP.... none taken for granted... Who manages this stuff? Who keeps track of them, and where?
Iceman? Spykie?

aDe · Post by **aDe** » 2003-01-13 14:45

aDe wrote:Obviously this could be used for ops that want to find out a users IP too

If originally thought like ender here, with only myip and response.
But then, i thought- why not let a little room for future development in - and as long as its only for ops, whats the harm.. the individual hub could decide whether to reply to ops requests or not.. and besides.. how hard is it to get a dc users ip if you are already at protocol level.. not very hard..

sandos · Post by **sandos** » 2003-01-13 19:08

Nev wrote: I have found that sending $jibberish <unknownparam1> ... <unknownparamN>| does not confuse either nmdchub, nmdc or dc++...

Yup, with some limit as to sizes, I cant remember if it was 8 or 16 or 32Kb, when the nmdc hub just discards it.

Sedulus · Post by **Sedulus** » 2003-01-14 09:05

let's (1) limit the amount of new commands, and (2) allow the hub(owner) to decide who get's which info -> just use $UserIP

Nev · Post by **Nev** » 2003-01-15 01:54

I'm convinced. We can use $UserIP and let security issues be hubspecific.

sandos · Post by **sandos** » 2003-01-15 10:46

Hubs only protect the ip-addresses of passive mode users anyway, I think we should be able to get everybodys ip. That way, its more fair! ;)

aDe · Post by **aDe** » 2003-01-15 13:22

Ptaczek has agreed to add this command to PtocaX... please read the DCExt post i just made..
http://dcplusplus.sourceforge.net/forum ... .php?t=256

Neimad · Post by **Neimad** » 2003-01-15 15:57

I see no mention of this; maybe it's automatically implied, but I'd be happier for the clarification.

What about the $Supports command? I know Nev has said that he's tested firing off unknown commands at both DC++ and NMDC and both were fine with it, but would it not be a better idea to stick to the idea that Arne pioneered and only use commands when they're supported by both parties?

Neimad

aDe · Post by **aDe** » 2003-01-16 03:56

there is a $Supports coming up for client<->hub communication too, yes.. specifically for QuickList, where is it neccessary for the function to be used, while with this one, you can just send it no matter what, either you get a reply or not, its not that big of a deal..

Gadget · Post by **Gadget** » 2003-01-16 08:27

Added support for $MyIP command to GeneralBot because it was easy enough to add. There are other ways for operators to find out specific users ip, at least i dont want them to be able to collect everyone's IP with a simple mouse click or so.

Code: Select all

Sub DataArival (curUser, sCurData)
  If sCurData="$MyIP" Then CurUser.SendData CStr("$YourIP "+curUser.IP+"|")
End Sub

GeneralBot also supports $BotINFO command for hublist bots (at least one of my own), the format is like:

Client->Hub:
$BotINFO <bot description>
GeneralBot->Client:
$HubINFO <hub name>$<hub address>$<hub description>$<max users>$<min share>$<min slots>$<max hubs>$NMDCHub GeneralBot 0.24$

Where
<bot description> = any string, describes the bot, script will save it just for informational purposes, i.e. "$BotINFO FinHubList 105 hubs, 72 online, 7701 users. http://finhublist.no-ip.org/PublicHubList.config"
<hub name> = frmHub.txtName
<hub address> = frmHub.txtIP (for reducing multiple aliases of one hub)
<hub description> = frmHub.txtDescription (usually out of date on other hublists)
<max users> = frmHub.sldrMaxUsers value (to calculate how full the hub is, current user count can be calculated from $NickList)
<min share> = script's minimum share limit in bytes
<min slots> = script's minimum slot limit
<max hubs> = script's maximum hub limit
And then there is hub type+script name which offered the info, and one additional field after that last $ just for reserve...

There are at this moment also support for following operator commands:

$Ban <username> <reason>
Bans the users name but does not kick the user or send him any data.

$BanIP <username> <reason>
Bans the IP of <username>, does not kick the user or send him any data.

$Kill <username> <reason>
Bans the users name, sends him a reason in PM and kicks him.

$UserInfo <username>
Displays info of the user.

But i think there are too much additions to the protocol, better method could be something like:

$OpCommand <command> <username> <moreinfo>
i.e. "$OpCommand Ban Gadget Talking too much". This method could work just like the command was written to main chat, but it just wont be visible for other users.

I probably add this feature in later versions, any suggestions?

aDe · Post by **aDe** » 2003-01-16 08:56

Gadget wrote:There are other ways for operators to find out specific users ip, at least i dont want them to be able to collect everyone's IP with a simple mouse click or so.

Why not?
Also, why add MyIP when UserIP is the agreed standard.. and, if you don't want to answer the requests for other users ips, then fine.. dont..

Copy the dcext script if you like... from the above link.. "easy enough"

ender · Post by **ender** » 2003-01-16 10:06

FYI, I implemented $UserIP in my hub...

aDe · Post by **aDe** » 2003-01-16 10:22

nice ender, what is the name of your hub? url?

Gadget · Post by **Gadget** » 2003-01-16 12:27

Ok, changed that command, so it's now the same =)

Code: Select all

Sub DataArival (curUser, sCurData) 
  If sCurData="$UserIP "+curUser.sName Then CurUser.SendData CStr("$UserIP "+curUser.sName+" "+curUser.IP+"|")
End Sub

aDe · Post by **aDe** » 2003-02-07 07:50

the new BCDC++ supports UserIP function...

arnetheduck is not convinced this is a 'entirely necessary' function though.. so I don't know if/when we will see this in the official release of DC++...

Post by **GargoyleMT** » 2003-02-15 17:48

aDe wrote:arnetheduck is not convinced this is a 'entirely necessary' function though.. so I don't know if/when we will see this in the official release of DC++...

Well, the first step is to give him a patch. And I just mailed one off. Someone who has their IP unset and is behind a firewall is likely not to have a fixed port mapped through, but I suppose in that case making their active mode IP correct doesn't worsen the situation at all. And for those on dynamic IPs who are clueful about port mapping, this could really help, provided hubs support it.

Phantom · Post by **Phantom** » 2003-02-20 21:27

I like this idea. $userip will help soo many people get into active mode. The only prob is with bcdc 0.232, if you connect to a hub running on your connection with localhost, it will set your ip to 127.0.0.1 . This is fine, but when you try connecting to it at your ip, it will no longer change the ip in the settings. Anyone know why? I've got the $userip script running on my hub, but anyone that connects to it with bcdc 0.232 has the same problem of the hub not setting the ip. It will however tell you *** User .Phantom has IP: 2xx.xxx.xxx.xxx

Phantom · Post by **Phantom** » 2003-02-20 21:55

suppose I should have looked at the code b4 I posted. I wonder how much testing went into this piece of code:

if (SETTING(HUB_IP_SET) && getNick() == userNick &&
userIP.find("127.0.0.1") != string::npos &&
userIP.find("192.168.") != 0)
{
//set own active mode IP
SettingsManager::getInstance()->set(SettingsManager::SERVER, userIP);
}

Looks like a case of the code working in reverse. It will only set your ip if it is local, not the other way around.

Post by **GargoyleMT** » 2003-02-20 22:35

Phantom wrote:suppose I should have looked at the code b4 I posted. I wonder how much testing went into this piece of code:

Looks like a case of the code working in reverse. It will only set your ip if it is local, not the other way around.

Code: Select all

		if (SETTING(HUB_IP_SET) && getNick() == userNick &&
			Util::strnicmp(userIP.c_str(), "127.0.0.1", 9) == 0 && // localhost
			Util::strnicmp(userIP.c_str(), "192.168.", 8) == 0 && // rfc 1918
			Util::strnicmp(userIP.c_str(), "10.", 3) == 0 &&     // ditto - 172.16/12 also there, but not simple to test for
			Util::strnicmp(userIP.c_str(), "169.254.", 8) == 0) // from ietf zeroconf draft

That's in the same style that's used with the url code in HubFrame.cpp. What's the proper way to test for whether an STL string begins with another string? (:oops: my schooling was short on useful items, like stl).

Well, the user IP showing code in BCDC is separate, anyhow.

cologic · Post by **cologic** » 2003-02-21 08:14

Whoops.

cologic · Post by **cologic** » 2003-02-21 08:15

Er, bah, I can't edit posts here. Anyway, there's another range, a 172.something one... I think it's a /12... I need to look that up too.

Sedulus · Post by **Sedulus** » 2003-02-21 08:23

172.16.0.0/12

cologic · Post by **cologic** » 2003-02-21 08:25

I've already made one extra post; another can't hurt.

Anyway, the STL way is to use string.find(), as documented in http://www.sgi.com/tech/stl/basic_string.html. if (userIP.find("blah") != string::npos) do_something();

Sedulus · Post by **Sedulus** » 2003-02-21 08:35

GargoyleMT wrote:

Code: Select all

			Util::strnicmp(userIP.c_str(), "127.0.0.1", 9) == 0 && // localhost

strnicmp, insensitive? that's not necessary.

That's in the same style that's used with the url code in HubFrame.cpp. What's the proper way to test for whether an STL string begins with another string? (:oops: my schooling was short on useful items, like stl).

stl on strings: http://wza.digitalbrains.com/users/walt ... tring.html
hmm.. cologic, I'd go with compare...

Code: Select all

int compare(size_type pos, size_type n, const charT* s, size_type len = npos) const

where pos is start of string-object, n max characters to be compared and s the ascii-Z string.

I can very much recommend the c++ annotations by Frank Brokken, at:
http://www.icce.rug.nl/documents/cpp.shtml

Post by **arnetheduck** » 2003-02-24 04:24

Anyway, the ip handling code needs to be updated to work on a per-hub basis (at least when nothing is entered in the ip field)...after that, I'll seriously consider the patch gmt sent me...

aDe · Post by **aDe** » 2003-03-23 11:27

what do you think about Sedulus' suggestion about allowing to use the command without a nickname, to get all IP's of all logged on clients?

> $UserIP|
< $UserIP user1 user1IP$user2 user2IP$.....

Sedulus · Post by **Sedulus** » 2003-03-23 11:56

actually, I rethought it,
and figured there is no need for the first command, if the server sends a list by itself.

I got it implemented on my own dch++ hub with a plugin,
it works, so now I got my "Copy IP to clipboard" =)

at login the hub checks my userlevel, and if it's high enough, it will send a:
$UserIP user1 ip1$user2 ip2$user3 ip3|
and to all users with high enough userlevel
$UserIP Sedulus myip|

aDe · Post by **aDe** » 2003-12-20 12:02

Finally UserIP made it into official DC++, for more info see
http://dc.ade.se/userip

HaArD · Post by **HaArD** » 2003-12-20 17:29

aDe,

SDCH has supported $UserIP since the beginning. Not sure if it supports $UserIP2 though...

[EDIT: Fixed the link. TheParanoidOne]

TasMan · Post by **TasMan** » 2003-12-20 18:15

Version 0.03 supports UserIP2 as well.

aDe · Post by **aDe** » 2003-12-20 19:27

TasMan wrote:Version 0.03 supports UserIP2 as well.

HaArD wrote:aDe,

SDCH has supported $UserIP since the beginning. Not sure if it supports $UserIP2 though...

added it to the list, thanks

TasMan · Post by **TasMan** » 2003-12-20 22:20

One question though....considering that the client does not add a "UserIP" menu item or anything, if the client supports UserCommand, should the hub send a UserCommand for UserIP? I would've thought the client would automatically create it but what do I know =p. No problem for me either way of course.

TasMan · Post by **TasMan** » 2003-12-20 22:28

Errr in the case above the client is obviously DC++ 0.305 =). Just need to know if the flaw is in the client or hub implementation.

Post by **GargoyleMT** » 2003-12-22 13:04

TasMan wrote:Errr in the case above the client is obviously DC++ 0.305 =). Just need to know if the flaw is in the client or hub implementation.

I haven't sniffed the connection, but I don't think DC++ will use the UserIP reported from the server as your external IP. (Which is something that BCDC's code did.)

DC++

$UserIP

$UserIP

Re: $UserIP

Well, the first step is...