Python Forum
Listening for broadcasts on port 0
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Listening for broadcasts on port 0
#1
Hi.
I have a device that send some data via broadcast to port 0 in my network.
I can listen to the traffic with wireshark.
Is it possible to get Python to listen to port 0 for UDP packets?
Reply
#2
Maybe start https://wiki.python.org/moin/UdpCommunication

https://docs.python.org/3/library/socket.html
If you can't explain it to a six year old, you don't understand it yourself, Albert Einstein
How to Ask Questions The Smart Way: link and another link
Create MCV example
Debug small programs

Reply
#3
(Mar-11-2021, 09:19 PM)buran Wrote: Maybe start https://wiki.python.org/moin/UdpCommunication

https://docs.python.org/3/library/socket.html

I don't see that any of those pages mention anything about using port 0 ?
Reply
#4
(Mar-11-2021, 09:31 PM)pacmyc Wrote: I don't see that any of those pages mention anything about using port 0 ?
sorry, I misunderstood your question
If you can't explain it to a six year old, you don't understand it yourself, Albert Einstein
How to Ask Questions The Smart Way: link and another link
Create MCV example
Debug small programs

Reply
#5
(Mar-11-2021, 09:44 PM)buran Wrote:
(Mar-11-2021, 09:31 PM)pacmyc Wrote: I don't see that any of those pages mention anything about using port 0 ?
sorry, I misunderstood your question

OK no problem, thanks anyway.
Reply
#6
(Mar-11-2021, 09:09 PM)pacmyc Wrote: Hi.
I have a device that send some data via broadcast to port 0 in my network.
I can listen to the traffic with wireshark.
Is it possible to get Python to listen to port 0 for UDP packets?

Several things to note:
  • You should not use Port 0. This is a bad selection. You want a port number as specified in the document RFC6335 It says,

    Quote:Port numbers are assigned in various ways, based on three ranges: System Ports (0-1023), User Ports (1024-49151), and the Dynamic and/or Private Ports (49152-65535); the difference uses of these ranges is described in [RFC6335]. According to Section 8.1.2 of [RFC6335], System Ports are assigned by the "IETF Review" or "IESG Approval" procedures described in [RFC8126]. User Ports are assigned by IANA using the "IETF Review" process, the "IESG Approval" process, or the "Expert Review" process, as per [RFC6335]. Dynamic Ports are not assigned.
    You should only use port numbers in the "User Ports" range.

  • UDP is a particularly poor protocol to use. In general, you should always use TCP/IP. It is slightly more complex, but TCP/IP is as reliable as a physical wire connecting the two endpoints. In UDP, you never know if your message arrived, and the receiver never knows if you sent a message. With TCP/IP, it is worth the extra effort, because every byte you send will be received, although not always as a single message (it can be split across multiple messages). And if there is a failure, both ends of the communication get a notification. It is worth expending the extra effort to learn to use TCP/IP; once you have done this, you "own" the concept of reliable communication. UDP packets can be dropped, you can receive the same packet more than once, and you can receive packets out of order. Just about the worst possible way to do communications, and you have to be prepared for all of them. Oh, yes, the packet may be truncated without any indication it has been shortened, so there is an upper bound on packet size which you have to be prepared to live with. Send a longer packet, and it may not all get there, and neither you nor the receiver will know it was truncated.
Note also that while TCP/IP does not support "broadcast" or "multicast", these are not particularly good protocols to use. Besides requiring UDP, with all of the above problems, you usually can't get these messages through routers except in very unusual circumstances (the router manager has to approve these packets). You can assume that you do not know what machines your message will be routed through, you have no idea who to contact, and if you do, the chances that they will approve it are approximately zero. Note that for reliability, you again have no indications that the packets have been received. If you think you need broadcast, you need to rethink your design. It might be necessary, but generally it is a Really Bad Idea.
Reply
#7
(Mar-12-2021, 01:11 AM)supuflounder Wrote:
(Mar-11-2021, 09:09 PM)pacmyc Wrote: Hi.
I have a device that send some data via broadcast to port 0 in my network.
I can listen to the traffic with wireshark.
Is it possible to get Python to listen to port 0 for UDP packets?

Several things to note:
  • You should not use Port 0. This is a bad selection. You want a port number as specified in the document RFC6335 It says,

    Quote:Port numbers are assigned in various ways, based on three ranges: System Ports (0-1023), User Ports (1024-49151), and the Dynamic and/or Private Ports (49152-65535); the difference uses of these ranges is described in [RFC6335]. According to Section 8.1.2 of [RFC6335], System Ports are assigned by the "IETF Review" or "IESG Approval" procedures described in [RFC8126]. User Ports are assigned by IANA using the "IETF Review" process, the "IESG Approval" process, or the "Expert Review" process, as per [RFC6335]. Dynamic Ports are not assigned.
    You should only use port numbers in the "User Ports" range.

  • UDP is a particularly poor protocol to use. In general, you should always use TCP/IP. It is slightly more complex, but TCP/IP is as reliable as a physical wire connecting the two endpoints. In UDP, you never know if your message arrived, and the receiver never knows if you sent a message. With TCP/IP, it is worth the extra effort, because every byte you send will be received, although not always as a single message (it can be split across multiple messages). And if there is a failure, both ends of the communication get a notification. It is worth expending the extra effort to learn to use TCP/IP; once you have done this, you "own" the concept of reliable communication. UDP packets can be dropped, you can receive the same packet more than once, and you can receive packets out of order. Just about the worst possible way to do communications, and you have to be prepared for all of them. Oh, yes, the packet may be truncated without any indication it has been shortened, so there is an upper bound on packet size which you have to be prepared to live with. Send a longer packet, and it may not all get there, and neither you nor the receiver will know it was truncated.
Note also that while TCP/IP does not support "broadcast" or "multicast", these are not particularly good protocols to use. Besides requiring UDP, with all of the above problems, you usually can't get these messages through routers except in very unusual circumstances (the router manager has to approve these packets). You can assume that you do not know what machines your message will be routed through, you have no idea who to contact, and if you do, the chances that they will approve it are approximately zero. Note that for reliability, you again have no indications that the packets have been received. If you think you need broadcast, you need to rethink your design. It might be necessary, but generally it is a Really Bad Idea.

Hi. Thanks for your answer.
I am aware of the poor choice of port 0, but it's not my choice to use it.
I have a device in my network that broadcasts to port 0 and I can't change that, but I'd really like to listan to its traffic in Python.
Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Issue listening to a networked device. Will86 2 2,378 Dec-19-2018, 11:41 PM
Last Post: Will86

Forum Jump:

User Panel Messages

Announcements
Announcement #1 8/1/2020
Announcement #2 8/2/2020
Announcement #3 8/6/2020