Wireshark ------- Source port: timbuktu-srv2 ?

Question

Hello, all I am trying to establish peer to peer (UDP) communication via firefox extension. I have python program that works on command line. I built a xpcom component using it. But surprisingly I could only receive message through it from command line python program.

We tried following ( All working on localhost ) :

Firefox XPCOM component as sender --> firefox XPCOM component as receiver -- did not work

Python command line as sender --> firefox xpcom component as receiver -- Worked

firefox xpcom component as sender --> Python command line as receiver -- did not work

Python commandline as sender --> python command line as receiver -- Worked

When we Observed packets using wireshark we got some differences --

Firefox xpcom to python command line AND firefox xpcom to firefox xpcom (which did not worked) have packet record as follows

Such type of packets(source port marked as non number) produced by

Winsock(C++)

XPCOM component

C#

...UDP  Source port: timbuktu-srv2  Destination port: 30000

python command line to python command line AND Python command line to XPCOM (which did worked) have packet record as follows

... UDP Source port: 30000  Destination port: 30000

I do not know much about the networking, but the record marked ..Source port: timbuktu-srv2.. fails to reach its destination .

I have been trying p2p communication using Python, C++ (Winsock) , C# but could only succeeded with Python only difference I could observe is such type of specific record with python ..

Can some networking gurus flash light over it ?

Answer 1

The timbuktu-srv2 you're seeing is just the result of Wireshark looking up the actual port number against its list of known services. If you check the IANA assigned port numbers list, you'll see this entry:

timbuktu-srv2   1418/udp   Timbuktu Service 2 Port

...so that just means your application used 1418 as the source port of the UDP packet it sent. 30000 doesn't get turned into a text service name because your local services database doesn't have an entry for that port number.

This, on its own, doesn't explain the issue - really, the server side should accept the client using whatever source port it wants. However, it seems likely in this case that the reciever side is only accepting packets with a source port of 30000. To achieve that, you need to bind the socket to the local address INADDR_ANY and port 30000 before sending your packet(s).