Menu
▾
▴
[Gaim-patches] [ gaim-Patches-996063 ] Simple fix to make oscar file recv work behind proxy
|
From: SourceForge.net <no...@so...> - 2005-02-01 23:42:13
|
Patches item #996063, was opened at 2004-07-22 13:52 Message generated for change (Comment added) made by thekingant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=996063&group_id=235 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Gene Cash (gcash) Assigned to: Mark Doliner (thekingant) Summary: Simple fix to make oscar file recv work behind proxy Initial Comment: I think I've finally fixed an issue with receiving files behind a proxy, using the oscar protocol. v0.80 can send files just fine out of the box, however, if you try to receive files, the proxy kicks the receiver off, and sometimes both parties. In http_canread() in proxy.c, I changed things so it printed the entire error message instead of just the header. This got back info from the proxy server complaining about "loopback" problems. The crash is in oscar_xfer_init_recv() in oscar.c, and I took a look and xfer->remote_ip is the address of the proxy server, instead of the file-sending computer, which is wrong because this attempts to send the file to the proxy server itself, thus the loopback errors. To test things, I hardcoded the IP of the sending computer into xfer->remote_ip and file transfer worked. So it's not the file transfer stuff itself that's the problem, it's the setup code. So it seems oscar_xfer_init_recv() gets called by incomingim_chan2() in oscar.c and it sets up the GaimXfer struct that gets passed to oscar_xfer_init_recv(). It copies things from the aim_incomingim_ch2_args struct that it gets passed. This is in the "if (args->status == AIM_RENDEZVOUS_PROPOSE)" area. OK, looking at aim.h, there are 3 IP address fields in the aim_incomingim_ch2_args struct: proxyip, clientip, and verifiedip. At the moment, verifiedip gets copied to remote_ip. However if you print these 3 fields: proxyip = IP of sending computer clientip = IP of sending computer verifiedip = IP of proxy server itself I have no idea what verifiedip is supposed to represent, but it appears to be swapped with proxyip. I looked at the oscar protocol docs mentioned and they didn't help much. So the fix itself is a simple one-liner. This patch is against v0.80 since I can't get to CVS through the firewall. --- oscar.c.orig Thu Jul 22 10:31:23 2004 +++ oscar.c Thu Jul 22 12:18:55 2004 @@ -3230,7 +3230,7 @@ /* Build the file transfer handle */ xfer = gaim_xfer_new(gc->account, GAIM_XFER_RECEIVE, userinfo->sn); - xfer->remote_ip = g_strdup(args->verifiedip); + xfer->remote_ip = g_strdup(args->clientip); xfer->remote_port = args->port; gaim_xfer_set_filename(xfer, args->info.sendfile.filename); gaim_xfer_set_size(xfer, args->info.sendfile.totsize); Now it works at work behind the proxy. However, I can't test it at home and see if it didn't screw up things for normal people, because I just moved and my laptop is still packed away, so I just have one PC. Can someone give this a swing and see? Thanks... -gc (gen...@or...) ---------------------------------------------------------------------- >Comment By: Mark Doliner (thekingant) Date: 2005-02-01 18:42 Message: Logged In: YES user_id=20979 We try not to use clientip because it's set by the other user, so it's more likely to have a non-routable IP (e.g. 10.0.0.4) address than the verifiedip. It's more reliable to use the IP from the point of view of the AIM server. Note that if the other user IS behind a NAT device, they MUST have some ports forwarded or the file transfer will definitely fail. I'm going to reject this patch because I think it makes things a bit worse for the majority of the people. Ideally we should try the verifiedip. Then if that fails we should try clientip. Then if that fails we should transfer the file through an AOL ft proxy server. ---------------------------------------------------------------------- Comment By: Gene Cash (gcash) Date: 2004-07-26 12:24 Message: Logged In: YES user_id=141974 The receiving session (and sometimes the sending session) gets disconnected from AOL by the proxy and has to reconnect. I can't figure out how the sending session gets interrupted, but hey... Yes, both users are usually behind the same proxy. We have several proxy servers, but the behaviour is the same no matter if they're connected to the same or different server. I went into incomingim_chan2() and printed out proxyip, clientip, verifiedip, etc to make sure of what was going on. > clientip is the IP > address of the other person from the point of view of the > other person. So then since you're sending peer-to-peer, then by this reasoning you should be using clientip anyway, right?? ---------------------------------------------------------------------- Comment By: Tim Ringenbach (marv_sf) Date: 2004-07-24 01:05 Message: Logged In: YES user_id=790708 Did you say there's a crash here, or the proxy just kicks you off? I find it add that verifiedip is the ip address that AIM thinks you're using, and not the IP it thinks the other side has. Or are both users behind the SAME proxy? ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2004-07-22 17:51 Message: Logged In: YES user_id=20979 verifiedip is the IP address of the other person from the point of view of the oscar servers. clientip is the IP address of the other person from the point of view of the other person. I'll think about it some more... but I don't think changing this is a good idea. The change would mean that, when the remote user is behind a NAT device, Gaim will attempt to 192.168.0.123, or some such. So... your change helps the case you describe, but hurts the case I describe. Ideally Gaim should attempt the verified IP first, then if that fails attempt the client IP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=996063&group_id=235 |