Opened 8 years ago

Closed 8 years ago

#12643 closed defect

Pidgin/Bonjour doesn't send Instant Message to another Pidgin/Bonjour client, both running on Windows

Reported by: v.plessky Owned by: datallah
Milestone: Component: Bonjour
Version: 2.7.3 Keywords: Bonjour Windows firewall proxy presence
Cc:

Description

Pidgin/Bonjour? doesn't send Instant Message to another Pidgin/Bonjour? client, both running on Windows. Each client can see another client (Status/Presence?). Bonjour services installed - BonjourPSSetup ver.2.0.2.0 from Apple (latest available on Apple web site)

LAN setup:

vadim@ASUS-M51TA  - 192.168.1.30
MSI@MSI-S271      - 192.168.1.51
Router/Internet Gateway - 192.168.1.2

Both computers use default settings (Port: 5298, No Proxy) First PC has firewall, with Pidgin exception enabled. Second PC doesn't have firewall.

Log file:


(23:18:10) util: Writing file prefs.xml to directory C:\Users\Vadim\AppData\Roaming\.purple
(23:18:10) util: Writing file C:\Users\Vadim\AppData\Roaming\.purple\prefs.xml
(23:18:14) gtkspell: Failed to setup GtkSpell: enchant error for language: en
(23:18:14) gtkconv: setting active conversation on toolbar 044058E8
(23:18:14) gtkconv: setting active conversation on toolbar 044058E8
(23:18:14) prefs: /pidgin/conversations/toolbar/wide changed, scheduling save.
(23:18:14) win32placement: Window RECT: L:711 R:1281 T:230 B:710
(23:18:14) win32placement: Working Area RECT: L:0 R:1440 T:0 B:870
(23:18:14) gtkconv: setting active conversation on toolbar 044058E8
(23:18:19) blist: Updating buddy status for MSI@MSI-S271 (Bonjour)
(23:18:20) util: Writing file blist.xml to directory C:\Users\Vadim\AppData\Roaming\.purple
(23:18:20) util: Writing file C:\Users\Vadim\AppData\Roaming\.purple\blist.xml
(23:18:20) util: Writing file prefs.xml to directory C:\Users\Vadim\AppData\Roaming\.purple
(23:18:20) util: Writing file C:\Users\Vadim\AppData\Roaming\.purple\prefs.xml
(23:18:24) bonjour: Starting conversation with MSI@MSI-S271
(23:18:24) dnsquery: Performing DNS lookup for 192.168.1.51
(23:18:24) sound: Playing C:\Program Files\Pidgin\sounds\purple\send.wav
(23:18:24) dnsquery: IP resolved for 192.168.1.51
(23:18:24) proxy: Attempting connection to 192.168.1.51
(23:18:24) proxy: Connecting to 192.168.1.51:5298 with no proxy
(23:18:24) proxy: Connection in progress
(23:18:24) proxy: Connecting to 192.168.1.51:5298.
(23:18:24) proxy: Connected to 192.168.1.51:5298.
(23:18:24) bonjour: receive error: Remote host closed connection.
(23:18:34) blist: Updating buddy status for MSI@MSI-S271 (Bonjour)
(23:18:39) util: Writing file blist.xml to directory C:\Users\Vadim\AppData\Roaming\.purple
(23:18:39) util: Writing file C:\Users\Vadim\AppData\Roaming\.purple\blist.xml
(23:18:42) bonjour: Received incoming connection from 192.168.1.2.
(23:18:42) bonjour: We don't like invisible buddies, this is not a superheroes comic
(23:19:42) bonjour: Received incoming connection from 192.168.1.2.
(23:19:42) bonjour: We don't like invisible buddies, this is not a superheroes comic

Attachments (7)

debug.log (17.5 KB) - added by v.plessky 8 years ago.
Debug file from Pidgin/Windows? PC
debug.2.log (13.8 KB) - added by v.plessky 8 years ago.
Debug file from Pidgin/Linux? - OpenSUSE 11.3
debug-wired.log (22.0 KB) - added by v.plessky 8 years ago.
Same Linux Pidgin client, but connected via Wired iconnection (Ethernet)
debug-Win-to-Linux-wireless.log (19.7 KB) - added by v.plessky 8 years ago.
Log-Windows client trying to send message to Linux client
debug-Win-to-telnet-2.log (15.5 KB) - added by v.plessky 8 years ago.
Pidgin client "contacted" using telnet at port 5298
debug-Win-to-Kopete.log (28.7 KB) - added by v.plessky 8 years ago.
Pidgin/Windows? - talking to Kopete/Linux? (wireless machine)
debug-Win-to-Kopete-3.log (25.8 KB) - added by v.plessky 8 years ago.
Kopete -> message to Pidgin (via Wireless)

Download all attachments as: .zip

Change History (32)

comment:1 Changed 8 years ago by datallah

  • Status changed from new to pending

Please follow the instructions to get a debug log and attach it to this ticket.
Please paste the debug logs from both sides when logging into the bonjour account until a message is sent.

comment:2 Changed 8 years ago by v.plessky

  • Status changed from pending to new

Here is log from Linux computer, after attempt to conect to Pidgin/Windows?:

(00:32:41) bonjour: Starting conversation with vadim@ASUS-M51TA
(00:32:41) dns: DNS query for '192.168.1.30' queued
(00:32:41) dnsquery: IP resolved for 192.168.1.30
(00:32:41) proxy: Attempting connection to 192.168.1.30
(00:32:41) proxy: Connecting to 192.168.1.30:5298 with no proxy
(00:32:41) proxy: Connection in progress
(00:32:41) proxy: Connecting to 192.168.1.30:5298.
(00:32:41) proxy: Connected to 192.168.1.30:5298.
(00:32:41) bonjour: Connection closed (without stream end) by vadim@ASUS-M51TA.
(00:32:41) bonjour: Recieved conversation close notification from vadim@ASUS-M51TA.


Changed 8 years ago by v.plessky

Debug file from Pidgin/Windows? PC

Changed 8 years ago by v.plessky

Debug file from Pidgin/Linux? - OpenSUSE 11.3

comment:3 Changed 8 years ago by datallah

  • Status changed from new to pending

Please follow the instructions to get a debug log and attach it to this ticket.
Please paste the debug logs from both machines from before the account logged in until a message is sent from one machine to the other.

The reason that the conversation connection isn't working is that it appears to becoming from an IP address (192.168.1.2) that isn't related to a Buddy is known about (in the first log, the connection should have been coming from 192.168.1.51).

Changed 8 years ago by v.plessky

Same Linux Pidgin client, but connected via Wired iconnection (Ethernet)

comment:4 follow-up: Changed 8 years ago by v.plessky

  • Status changed from pending to new

Attachment (debug-wired.log) added by ticket reporter.

comment:6 in reply to: ↑ 4 Changed 8 years ago by v.plessky

Replying to v.plessky:

Attachment (debug-wired.log) added by ticket reporter.

I connected Linux computer via Wired interface (Ethenet), instead of wireless connection. And surprise - Pidgin was able to receive message from Pidgin/Windows? computer. Behavior was strange - it not popped up message window, but when I tried to write message from Linux to Windows, message window appeared and there was received text in it.

Therefor, it seems reported problem of "not able to receive/send message" is somehow related to network connection/network detection.

comment:7 Changed 8 years ago by datallah

  • Status changed from new to pending

Here is what is going on according to the logs when it isn't working:

vadim@linux-msi-s271 logs into bonjour account
vadim@ASUS-M51TA logs into bonjour account
vadim@ASUS-M51TA "sees" vadim@linux-msi-s271 advertising Bonjour connectivity on IP Address of 192.168.1.51 and a port of 5298 
vadim@linux-msi-s271 "sees" vadim@ASUS-M51TA advertising Bonjour connectivity on IP Address of 192.168.1.30 and a port of 5298 
vadim@linux-msi-s271 tries to connect to 192.168.1.30:5298 to initiate a conversation with vadim@ASUS-M51TA
vadim@ASUS-M51TA sees the incoming connection, but it appears to be coming from 192.168.1.2, which doesn't match any known buddies, so the connection is dropped.
vadim@ASUS-M51TA tries to connect to 192.168.1.51:5298 to initiate a conversation with vadim@linux-msi-s271
vadim@linux-msi-s271 sees the incoming connection, but it appears to be coming from 192.168.1.2, which doesn't match any known buddies, so the connection is dropped.

It's pretty odd, but it is a problem with your network configuration (I have no idea what specifically).

comment:8 Changed 8 years ago by v.plessky

  • Status changed from pending to new

Problem is not in network. From Linux machine Gateway (192.168.1.2) is visible, and Windows machine (192.168.1.30) is visible as well.

vadim@linux-msi-s271:~> ping 192.168.1.30 PING 192.168.1.30 (192.168.1.30) 56(84) bytes of data. 64 bytes from 192.168.1.30: icmp_seq=1 ttl=128 time=2.60 ms 64 bytes from 192.168.1.30: icmp_seq=2 ttl=128 time=4.41 ms 64 bytes from 192.168.1.30: icmp_seq=3 ttl=128 time=4.09 ms 64 bytes from 192.168.1.30: icmp_seq=4 ttl=128 time=2.65 ms C --- 192.168.1.30 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3004ms rtt min/avg/max/mdev = 2.609/3.443/4.411/0.816 ms vadim@linux-msi-s271:~> ping 192.168.1.2 PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data. 64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=1.40 ms 64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=1.35 ms 64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=2.45 ms 64 bytes from 192.168.1.2: icmp_seq=4 ttl=64 time=2.02 ms C --- 192.168.1.2 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3004ms rtt min/avg/max/mdev = 1.350/1.807/2.454/0.459 ms

Besides, Presence information is available. Both on Windows and Linux machines.

comment:9 Changed 8 years ago by v.plessky

Problem is not in network. From Linux machine Gateway (192.168.1.2) is visible, and Windows machine (192.168.1.30) is visible as well.

vadim@linux-msi-s271:~> ping 192.168.1.30
PING 192.168.1.30 (192.168.1.30) 56(84) bytes of data.
64 bytes from 192.168.1.30: icmp_seq=1 ttl=128 time=2.60 ms
64 bytes from 192.168.1.30: icmp_seq=2 ttl=128 time=4.41 ms
64 bytes from 192.168.1.30: icmp_seq=3 ttl=128 time=4.09 ms
64 bytes from 192.168.1.30: icmp_seq=4 ttl=128 time=2.65 ms
^C
--- 192.168.1.30 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 2.609/3.443/4.411/0.816 ms
vadim@linux-msi-s271:~> ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=1.40 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=1.35 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=2.45 ms
64 bytes from 192.168.1.2: icmp_seq=4 ttl=64 time=2.02 ms
^C
--- 192.168.1.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 1.350/1.807/2.454/0.459 ms
vadim@linux-msi-s271:~>

Besides, Presence information is available. Both on Windows and Linux machines.

Changed 8 years ago by v.plessky

Log-Windows client trying to send message to Linux client

comment:10 Changed 8 years ago by v.plessky

Check this part of last Log file (Windows-to-Linux, wireless connection for Linux machine)

(15:28:19) dnsquery: Performing DNS lookup for 192.168.1.51
(15:28:19) sound: Playing C:\Program Files\Pidgin\sounds\purple\send.wav
(15:28:20) dnsquery: IP resolved for 192.168.1.51
(15:28:20) proxy: Attempting connection to 192.168.1.51
(15:28:20) proxy: Connecting to 192.168.1.51:5298 with no proxy
(15:28:20) proxy: Connection in progress
(15:28:20) proxy: Connecting to 192.168.1.51:5298.
(15:28:20) proxy: Connected to 192.168.1.51:5298.
(15:28:20) bonjour: Connection closed (without stream end) by vadim@linux-msi-s271.
(15:28:20) bonjour: Received conversation close notification from vadim@linux-msi-s271.

Proxy settings for both machines are "No Proxy"

Compare this to log file. Why there are 'proxy' entries in the log? It seems Pidgin for some reason assumes that there is a Proxy, located at 192.168.1.2 (this is my router/Internet Gateway) And uses this proxy for communication.

It explains why client at 192.168.1.51 receives connection request from 192.168.1.2 And as this IP/host is not known to it, rejects communication session.

It seems communication sequence should be fixed. If there is no proxy - Pidgin should communicate directly to specified IP address.

comment:11 Changed 8 years ago by datallah

  • Status changed from new to pending

There is no proxy being used in any of the cases (note the Connecting to ******:5298 with no proxy).

The log uses the prefix "proxy:" just because of how the code is structured, it doesn't mean that a proxy is actually being used.

If it were, then it would explain the situation, but that simply isn't the case.

You can test this yourself by doing the following using your wireless connection:

  1. Log in to your Bonjour account on "vadim@ASUS-M51TA" (192.168.1.30)
  2. From MSI@MSI-S271 (192.168.1.51), open up a cmd prompt and run:
      telnet 192.168.1.30 5298
    
  3. Notice in the debug log of "vadim@ASUS-M51TA" that the connection isn't coming from 192.168.1.51 as it would be expected to.

It isn't a problem of the machines not being able to "see" each other - the connections are clearly occurring, it just that something about your wireless network configuration is masking where connections are actually coming from and making it seem like they're coming from the router instead of the actual source machine on the network.

comment:12 Changed 8 years ago by v.plessky

  • Status changed from pending to new

Do you indeed think that problem is specific to wireless connection? Than I have two possible explanations: 1) problem is specific to OpenSUSE (11.3), which I use on my Linux machine(s).

all distributions have own specifics in network configuration, so I woould probably give a test to Fedora or some other distribution

2) problem is caused by NetworkManager (KNetworkManager)

OpenSUSE 11.3 has two methods of managing network interfaces - Traditional 'ifup' and "Managed by NetworkManager" In this case problem would exist also in Fedora and Ubuntu, which also use NetworkManager. Mandriva has own tools, probably I would need it to test this case.

Another testing possibility - different client. Do you know by chance how to launch Empathy in debug mode? Command line options used by Pidgin do not work with it. Empathy works fine to show Presence, and supports Bonjour("People Nearby"). Question there that I have not seen any options for Proxy configuration.

comment:13 Changed 8 years ago by datallah

  • Status changed from new to pending

I don't think it is a problem caused by your distro or by NetworkManager.

Remember that the problem occurs between two windows machines (which was your first example) when they are using the wireless network.

I'm not familiar with how to debug Empathy. I don't think it'll make any difference though - it is a network level thing, the incoming connection has the wrong origin IP.

Changed 8 years ago by v.plessky

Pidgin client "contacted" using telnet at port 5298

comment:14 Changed 8 years ago by v.plessky

  • Status changed from pending to new

Attachment (debug-Win-to-telnet-2.log) added by ticket reporter.

comment:16 Changed 8 years ago by datallah

See that the telnet connection also looks like it is coming from 192.168.1.2:

(18:39:53) bonjour: Received incoming connection from 192.168.1.2.
(18:39:53) bonjour: We don't like invisible buddies, this is not a superheroes comic
(18:39:56) bonjour: Received incoming connection from 192.168.1.2.
(18:39:56) bonjour: We don't like invisible buddies, this is not a superheroes comic
(18:40:10) bonjour: Received incoming connection from 192.168.1.139.
(18:40:10) bonjour: We don't like invisible buddies, this is not a superheroes comic 

comment:17 follow-up: Changed 8 years ago by v.plessky

Tried method you described. See log attached. two comments on it

1) first two attempts "from 192.168.1.2" - coming from wireless computer 192.168.1.51

(18:39:53) bonjour: Received incoming connection from 192.168.1.2.
(18:39:53) bonjour: We don't like invisible buddies, this is not a superheroes comic
(18:39:56) bonjour: Received incoming connection from 192.168.1.2.
(18:39:56) bonjour: We don't like invisible buddies, this is not a superheroes comic
(18:40:10) bonjour: Received incoming connection from 192.168.1.139.
(18:40:10) bonjour: We don't like invisible buddies, this is not a superheroes comic

Last attempt (also via telnet) from wired connection, computer 192.168.1.149

Pls also note that both computers are Linux machines. Therefor problem is not specific to Windows. And I doubt in this scenario that problem may be caused by Linux- (or Windows-) networking configuration.

2) I have questions on this part of log

(18:39:31) dnsquery: Performing DNS lookup for 192.168.1.2
(18:39:31) dnsquery: IP resolved for 192.168.1.2
(18:39:31) proxy: Attempting connection to 192.168.1.2
(18:39:31) proxy: Connecting to 192.168.1.2:1780 with no proxy
(18:39:31) proxy: Connection in progress
(18:39:31) prefs: /pidgin/blist/width changed, scheduling save.
(18:39:31) prefs: /pidgin/blist/height changed, scheduling save.
(18:39:31) proxy: Connecting to 192.168.1.2:1780.
(18:39:31) proxy: Connected to 192.168.1.2:1780.
(18:39:31) util: request constructed
(18:39:31) util: Response headers: 'HTTP/1.1 200 OK Content-Type: text/xml Content-Length: 3726 Connection: close Pragma: no-cache  '
(18:39:31) util: parsed 3726
(18:39:31) upnp: parse_description_response(): could not get serviceTypeNode 7
(18:39:31) upnp: purple_upnp_parse_description(): control URL is NULL
(18:39:31) bonjour: service advertisement - callback.

Why, for the Heaven's sake, Pidgin making query to 192.168.1.2?

Than 'Attempting connection to 192.168.1.2; Connecting to 192.168.1.2:1780 with no proxy; Connection in progress'

There is no Bonjour client on that host/IP address. Why Pidgin connects it and what negotiates?...

Last part: "Connecting to 192.168.1.2:1780; Connected to 192.168.1.2:1780; request constructed" even more confusing. What kind of request it constructed?..

P.S. probably we need more detailed logging to fix reported problem.

comment:18 in reply to: ↑ 17 Changed 8 years ago by datallah

  • Status changed from new to pending

Replying to v.plessky:

Tried method you described. See log attached. two comments on it

1) first two attempts "from 192.168.1.2" - coming from wireless computer 192.168.1.51

<SNIP/>

Last attempt (also via telnet) from wired connection, computer 192.168.1.149

Pls also note that both computers are Linux machines. Therefor problem is not specific to Windows. And I doubt in this scenario that problem may be caused by Linux- (or Windows-) networking configuration.

Yes, I don't think it is an OS-related thing, it'll be the router config most likely.

2) I have questions on this part of log

<SNIP />

Why, for the Heaven's sake, Pidgin making query to 192.168.1.2?

Than 'Attempting connection to 192.168.1.2; Connecting to 192.168.1.2:1780 with no proxy; Connection in progress'

There is no Bonjour client on that host/IP address. Why Pidgin connects it and what negotiates?...

Last part: "Connecting to 192.168.1.2:1780; Connected to 192.168.1.2:1780; request constructed" even more confusing. What kind of request it constructed?..

This is not at all related to Bonjour, Pidgin is querying information from your router for UPnP.

You can disable that by unchecking the "Use automatically detected IP address" and "Enable automatic router port forwarding" checkboxes in the "Network" section of the preferences.

P.S. probably we need more detailed logging to fix reported problem.

There isn't really any more logging that you're going to get out of pidgin.

I suggest you use something like Wireshark to capture the network traffic during one of these connection attempts for further debugging, but at this point, you really are going to have to look at the router configuration as there isn't anything that can be done from the Pidgin side.

Changed 8 years ago by v.plessky

Pidgin/Windows? - talking to Kopete/Linux? (wireless machine)

comment:19 Changed 8 years ago by v.plessky

  • Status changed from pending to new

Attachment (debug-Win-to-Kopete.log) added by ticket reporter.

comment:21 follow-up: Changed 8 years ago by v.plessky

Tested Kopete running on Linux, machine connected via Wireless connection.

See Log file - Pidgin/Windows? - talking to Kopete/Linux? (wireless machine)

(19:11:48) bonjour: Starting conversation with kopete@linux-msi-s271
(19:11:48) dnsquery: Performing DNS lookup for 192.168.1.51
(19:11:48) sound: Playing C:\Program Files\Pidgin\sounds\purple\send.wav
(19:11:48) dnsquery: IP resolved for 192.168.1.51
(19:11:48) proxy: Attempting connection to 192.168.1.51
(19:11:48) proxy: Connecting to 192.168.1.51:5298 with no proxy
(19:11:48) proxy: Connection in progress
(19:11:48) proxy: Connecting to 192.168.1.51:5298.
(19:11:48) proxy: Connected to 192.168.1.51:5298.
(19:11:48) bonjour: Receive: -<?xml version='1.0' encoding='UTF-8' ?>
<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' from='kopete@linux-msi-s271' to='vadim@ASUS-M51TA'>- 176 bytes
(19:12:31) prefs: /pidgin/conversations/im/x changed, scheduling save.

As you see, problem is not related to network. Kopete connects to Pidgin, and has 192.168.1.51 IP address (correct)

BUT: Message from one client to another not displayed. It seems it's kind of format mismatch. Hope you will understand better from the log.

Therefor, we need to debug network part of Pidgin code, to understand why it doesn't work in Wireless connection.

* I also added one more test user - 'acer' (on wired computer) When I was trying to select it and do some action, Pidgin crashed.

(19:15:11) bonjour: Removed last presence for buddy 'acer@linux-acer6935'; signing off buddy.
(19:15:11) g_log: purple_find_prpl: assertion `id != NULL' failed
(19:15:11) g_log: purple_find_prpl: assertion `id != NULL' failed

Can you pls also look at this problem, or I need to file another bug report?

comment:22 in reply to: ↑ 21 Changed 8 years ago by datallah

  • Status changed from new to pending

Replying to v.plessky:

Tested Kopete running on Linux, machine connected via Wireless connection.

See Log file - Pidgin/Windows? - talking to Kopete/Linux? (wireless machine)

(19:11:48) bonjour: Starting conversation with kopete@linux-msi-s271
(19:11:48) dnsquery: Performing DNS lookup for 192.168.1.51
(19:11:48) sound: Playing C:\Program Files\Pidgin\sounds\purple\send.wav
(19:11:48) dnsquery: IP resolved for 192.168.1.51
(19:11:48) proxy: Attempting connection to 192.168.1.51
(19:11:48) proxy: Connecting to 192.168.1.51:5298 with no proxy
(19:11:48) proxy: Connection in progress
(19:11:48) proxy: Connecting to 192.168.1.51:5298.
(19:11:48) proxy: Connected to 192.168.1.51:5298.
(19:11:48) bonjour: Receive: -<?xml version='1.0' encoding='UTF-8' ?>
<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' from='kopete@linux-msi-s271' to='vadim@ASUS-M51TA'>- 176 bytes
(19:12:31) prefs: /pidgin/conversations/im/x changed, scheduling save.

As you see, problem is not related to network. Kopete connects to Pidgin, and has 192.168.1.51 IP address (correct)

Sorry, but that isn't really relevant and doesn't indicate that it isn't related to the network.

This is a connection from Pidgin to Kopete. I'm guessing that Kopete doesn't validate that the originating IP address for the connection is the expected IP of the user that claims to be connecting and that is why it is working.

If you send the initial message from Kopete to Pidgin, you'll see the same problem because the IP address the connection is coming from is wrong.

BUT: Message from one client to another not displayed. It seems it's kind of format mismatch. Hope you will understand better from the log.

Therefor, we need to debug network part of Pidgin code, to understand why it doesn't work in Wireless connection.

Sorry, but there is nothing to debug within the Pidgin code. It is just the standard accept() function to accept an incoming connection and the OS provides information about where the incoming connection.

As I mentioned in the last message, you'll need to use Wireshark or something to capture the network traffic, but really you need to look at the router for answers.

* I also added one more test user - 'acer' (on wired computer) When I was trying to select it and do some action, Pidgin crashed.

(19:15:11) bonjour: Removed last presence for buddy 'acer@linux-acer6935'; signing off buddy.
(19:15:11) g_log: purple_find_prpl: assertion `id != NULL' failed
(19:15:11) g_log: purple_find_prpl: assertion `id != NULL' failed

Can you pls also look at this problem, or I need to file another bug report?

Without a crash report, there isn't anything that I can do with this.

comment:23 follow-up: Changed 8 years ago by v.plessky

  • Status changed from pending to new

RE: Sorry, but that isn't really relevant and doesn't indicate that it isn't related to the network.

This is a connection from Pidgin to Kopete. I'm guessing that Kopete doesn't validate that the originating IP address for the connection is the expected IP of the user that claims to be connecting and that is why it is working.

If you send the initial message from Kopete to Pidgin, you'll see the same problem because the IP address the connection is coming from is wrong.

It is message coming from Kopete to Pidgin. See word "Receive:" in Log

(19:11:48) bonjour: Receive: -<?xml version='1.0' encoding='UTF-8' ?>
<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' from='kopete@linux-msi-s271' to='vadim@ASUS-M51TA'>- 176 bytes

It seems you misunderstood what I am trying to say. Pidgin - using Bonjour - should not know about existence of 192.168.1.2 address. Instead, it talks to it and making some configs/guesses using it.

Re: As I mentioned in the last message, you'll need to use Wireshark or something to capture the network traffic, but really you need to look at the router for answers.

Please, before making such suggestions understand how Layer2 network works. Host can talk to each other inside 192.168.1.x/24 subnet. Routing is not involved. Therefor, word "router" is not applicable to this scenario or this bug. If "Access Point" makes things better to understand, let's use it.

Access Point - as it installed and configured - forward traffic to host(s) in 192.168.1.x subnet, and back.

May be, you can install Access Point (Wirelss "router" working as AP) and test connection between one Wired and one Wireless client? Problem - as it was initially reported - is "End User" problem. I guess there are some users of Pidgin using it on Windows. Wi-Fi became very popular. People would try Pidgin - and just say "it doesn't work" And make conclusion "all that open-source doesn't work" I guess we want to avoid it, isn't it?

comment:24 in reply to: ↑ 23 Changed 8 years ago by datallah

Replying to v.plessky:

RE: Sorry, but that isn't really relevant and doesn't indicate that it isn't related to the network.

This is a connection from Pidgin to Kopete. I'm guessing that Kopete doesn't validate that the originating IP address for the connection is the expected IP of the user that claims to be connecting and that is why it is working.

If you send the initial message from Kopete to Pidgin, you'll see the same problem because the IP address the connection is coming from is wrong.

It is message coming from Kopete to Pidgin. See word "Receive:" in Log

(19:11:48) bonjour: Receive: -<?xml version='1.0' encoding='UTF-8' ?>
<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' from='kopete@linux-msi-s271' to='vadim@ASUS-M51TA'>- 176 bytes

Yes, Pidgin is Recieving that message from Kopete, but it is receiving it on a connection that was initially made from Pidgin to Kopete - that is where the issue is. Once the connection is made, both side can use it to send data.

Notice that immediately before that in the Pidgin log, it is Pidgin that is connecting to the remote instance - as soon as the connection is accepted by the remote Kopete instance (and apparently Kopete doesn't validate the origin of the connection), Kopete is sending that "<?xml version='1.0'...".

As I said before, if the initial connection had been made from Kopete to Pidgin (assuming the same wireless network configuration), the same problem would happen - it would look like it was coming from the wrong IP. I don't know what I can do to make that more clear.

It seems you misunderstood what I am trying to say. Pidgin - using Bonjour - should not know about existence of 192.168.1.2 address. Instead, it talks to it and making some configs/guesses using it.

You're misunderstanding what is going on.

That stuff in the log about connecting to 192.168.1.2 is completely unrelated to Bonjour! The Bonjour part of Pidgin doesn't know anything about 192.168.1.2 - it is the overall Pidgin initialization that discovers the UPnP service available on 192.168.1.2.

As I mentioned, if you disable the network settings related to UPnP, you wont see those entries in the log.

Re: As I mentioned in the last message, you'll need to use Wireshark or something to capture the network traffic, but really you need to look at the router for answers.

Please, before making such suggestions understand how Layer2 network works. Host can talk to each other inside 192.168.1.x/24 subnet. Routing is not involved. Therefor, word "router" is not applicable to this scenario or this bug. If "Access Point" makes things better to understand, let's use it.

Access Point - as it installed and configured - forward traffic to host(s) in 192.168.1.x subnet, and back.

May be, you can install Access Point (Wirelss "router" working as AP) and test connection between one Wired and one Wireless client? Problem - as it was initially reported - is "End User" problem. I guess there are some users of Pidgin using it on Windows. Wi-Fi became very popular. People would try Pidgin - and just say "it doesn't work" And make conclusion "all that open-source doesn't work" I guess we want to avoid it, isn't it?

You're right - "router" isn't the right word, sorry I used the wrong confusing word. I meant "Wireless Access Point" when I said "router". I'm familiar with how routing works :)

I think you're making the wrong assumption that this occurs with all wireless networks, but that simply isn't the case. It is something very specific that is wrong with your network that is causing the problem.

This isn't a problem that has been reported before. I use Bonjour in Pidgin on my mixed wired/wireless network at home and at work frequently and so do many other users.

What exactly do you mean when you say "Access Point - as it installed and configured - forward traffic to host(s) in 192.168.1.x subnet, and back." - that makes it sound like your access point is configured to do some sort of network bridging or something?

Changed 8 years ago by v.plessky

Kopete -> message to Pidgin (via Wireless)

comment:25 Changed 8 years ago by v.plessky

well, I did more testing. For the records/search engines, and googling - Kopete in Log below (and full log file attached above) is ver.1.0.80 from KDE 4.5.1, OpenSUSE 11.3. Pidgin/Windows? - ver.2.7.3, Windows Vista x86.

I have KDE 4.4.4 "Release 2" and Kopete 1.0.0 on another Linux machine. It seems it behaves differently from 1.0.80. I need to upgrade that notebook before further testing

ok, from Kopete 1.0.80 - chat with Pidgin 2.7.3

(20:37:10) conversation: typed...
(20:37:21) bonjour: Starting conversation with kopete@linux-msi-s271
(20:37:21) dnsquery: Performing DNS lookup for 192.168.1.51
(20:37:21) sound: Playing C:\Program Files\Pidgin\sounds\purple\send.wav
(20:37:21) dnsquery: IP resolved for 192.168.1.51
(20:37:21) proxy: Attempting connection to 192.168.1.51
(20:37:21) proxy: Connecting to 192.168.1.51:5298 with no proxy
(20:37:21) proxy: Connection in progress
(20:37:21) proxy: Connecting to 192.168.1.51:5298.
(20:37:21) proxy: Connected to 192.168.1.51:5298.
(20:37:21) bonjour: Receive: -<?xml version='1.0' encoding='UTF-8' ?>
<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' from='kopete@linux-msi-s271' to='vadim@ASUS-M51TA'>- 176 bytes
(20:38:28) bonjour: Received incoming connection from 192.168.1.51.
(20:38:28) bonjour: Receive: -<?xml version='1.0' encoding='UTF-8' ?>
<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' from='kopete@linux-msi-s271' to='vadim@ASUS-M51TA'><message to='vadim@ASUS-M51TA' from='kopete@linux-msi-s271' type='chat'><body>from MSI to ASUS/Pidgin</body><html xmlns='http://www.w3.org/1999/xhtml'><body><p>from MSI to ASUS/Pidgin</p></body></html><x xmlns='jabber:x:event'><composing /></x></message>- 430 bytes
(20:38:28) bonjour: Found buddy kopete@linux-msi-s271 for incoming conversation "from" attrib.
(20:38:28) bonjour: Matched buddy kopete@linux-msi-s271 to incoming conversation "from" attrib and IP (192.168.1.51)
(20:38:28) jabber: XML parser error for BonjourJabberConversation 049758E8: Domain 1, code 5, level 3: Extra content at the end of the document
(20:38:28) sound: Playing C:\Program Files\Pidgin\sounds\purple\receive.wav
(20:38:37) bonjour: Receive: -<message to='vadim@ASUS-M51TA' from='kopete@linux-msi-s271' type='chat'><body>one more message</body><html xmlns='http://www.w3.org/1999/xhtml'><body><p>one more message</p></body></html><x xmlns='jabber:x:event'><composing /></x></message>- 240 bytes
(20:38:37) sound: Playing C:\Program Files\Pidgin\sounds\purple\receive.wav


so, it works. From my knowledge of XHTML and XML, messages are formatted correctly. Reply from Pidgin (ASUS) to Kopete (MSI) - for some reason not logged. But it was also displayed in chat window.

P.S. Probably I wil make setup just with pure unmanaged switch, no router. And switch off UPnP detection - it was not clear from Log file that "proxy" communication is related to UPnP. May be it will fix some problems.

comment:26 Changed 8 years ago by v.plessky

re: What exactly do you mean when you say "Access Point - as it installed and configured - forward traffic to host(s) in 192.168.1.x subnet, and back." - that makes it sound like your access point is configured to do some sort of network bridging or something?

No, it's pure Access Point. Physically located on Router (192.168.1.2)

comment:27 Changed 8 years ago by datallah

  • Status changed from new to pending
(19:11:48) bonjour: Starting conversation with kopete@linux-msi-s271
(19:11:48) dnsquery: Performing DNS lookup for 192.168.1.51
(19:11:48) sound: Playing C:\Program Files\Pidgin\sounds\purple\send.wav
(19:11:48) dnsquery: IP resolved for 192.168.1.51
(19:11:48) proxy: Attempting connection to 192.168.1.51
(19:11:48) proxy: Connecting to 192.168.1.51:5298 with no proxy
(19:11:48) proxy: Connection in progress
(19:11:48) proxy: Connecting to 192.168.1.51:5298.
(19:11:48) proxy: Connected to 192.168.1.51:5298.
(19:11:48) bonjour: Receive: -<?xml version='1.0' encoding='UTF-8' ?>
<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' from='kopete@linux-msi-s271' to='vadim@ASUS-M51TA'>- 176 bytes 

debug-Win-to-Kopete-3.log still has Pidgin initiating the connection to Kopete (you clicked on the Kopete user in the Pidgin buddy list to start the conversation)!

comment:28 Changed 8 years ago by trac-robot

  • Status changed from pending to closed

This ticket was closed automatically by the system. It was previously set to a Pending status and hasn't been updated within 14 days.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!