UDP Port 4000 being blocked?

98 views
Skip to first unread message

Andrew Sarangan

unread,
Mar 29, 2026, 11:46:56 AM (5 days ago) Mar 29
to Apps4Av Forum

Is AvareX still using the same UDP port 4000 for ADSB data? 

It looks like AvareX is blocking any other app from receiving the ADSB wifi data. Is this correct? I am trying to figure out how to share the ADSB data between AvareX and another app I am writing that will process traffic data for a different purpose. 


Bruce B

unread,
Mar 29, 2026, 3:43:27 PM (5 days ago) Mar 29
to Apps4Av Forum
I'm going to go out on a limb here, but think you probably know more than I do!
I think this is a unix thing, and has to do with the way a process binds to an address/port.  Once a process binds, maybe depending on via UDP or TCP), it has sole access to the stream.  Think about a serial port, and what it would be like for the OS to manage several processes accessing the data.
I'm not sure if it would be the same way if the port were multicast, but there are certainly ways of writing something that would redirect, so that two processes can have access.
It probably needs a helper in between, or something to fake it out.  Maybe one using the (presumably) wifi interface, and one using the loopback?  Just kind of thinking it though as I go...  But more of an operating system "feature" than a process blocking a port, to it takes a little more to get around it.

Jim English

unread,
Mar 30, 2026, 3:25:40 PM (4 days ago) Mar 30
to Apps4Av Forum
Partially correct. This isn't a Unix-only thing. It is a TCP/IP standard network protocol thing. So, any operating system using the tcp/ip networking protocol suite should exhibit the same behavior, including Unix systems, Windows systems, Android systems, Apple systems, and any others using the tcp/ip network protocol, where tcp and udp are the ip network standard packet styles. At this point, it would be very easy to go down the slippery slope of the protocol definitions and what they mean for the functionality of any program trying to communicate with another program using tcp/ip, but I'll refrain, as we may get lost before addressing the primary question. So, at the risk of oversimplifying parts of it, let me try it at a high level.

Think of the IP address of any device as the address of a very large apartment building, and people in the apartment building with different addresses can communicate with people in the other apartment building only via mailboxes assigned to each person in their respective building. These mailboxes are equivalent to the ports you mentioned, but it gets a little more complicated when you find out that to keep conversations straight, each mailbox can have only a single connection during a given conversation. So, some more elaborate mechanism must be employed if the person that everyone wants to communicate with is going to be able to handle multiple simultaneous conversations. This is the situation faced, for example, when two (or more) tablets running AvareX want to communicate with an ADS-B receiver (like a Stratus or a StratuX device) at the same time. It's really important to note, in this example, that the respective communication endpoints must have their own apartment house address (IP address), because that's how the person/program keeps track of who they are talking to within a given conversation. To accomplish multiple conversations with multiple addresses, both parties initially negotiate over the primary contact mailbox (port address) that they will carry on their conversation using an unused mailbox, or port address (the IP protocol allows for 65535 ports per IP address) that will be allocated just for that person/program's conversation. So in this example,  port 4000 is a universally known initial contact port for a conversation connection (the 1st tablet), which immediately gets negotiated to some other port/mailbox for the duration of that conversation, leaving port 4000 again available to handle the negotiation of another connection request from the 2nd tablet. Thus, the two tablets have initially only been given the the initial contact port number, but their respective conversation with the ADS-B receiver actually takes place over a port they negotiated duing their inital contact conversation. 

So now let's complicate it a bit and suppose that one of those tablets tries to use two different programs who have each been given the same initial contact port on the ADS-B device, like running legacy Avare and AvareX at the same time on the same tablet. Remember I said 'it's really important to note, in this example, that the respective communication endpoints must have their own apartment house address (IP address), because that's how the person/program keeps track of who they are talking to within a given conversation. In this case, both programs requesting a conversation would be using the same IP address. So to keep its conversation straight, the ADS-B receiver will only permit the first requester to connect, and will refuse port 4000 connection requests from all others at the same IP address, because it has determined that it already has an open conversation with someone at that address. The 1st conversation will have to terminate in order for the 2nd one, with the same ip address, to be able to progress.
 

Andrew Sarangan

unread,
Mar 30, 2026, 7:35:49 PM (4 days ago) Mar 30
to Jim English, Apps4Av Forum
Jim

Thank you for that wonderful explanation. It makes sense. So here is a question. If I write an app that will broadcast ADSB packets on 127.0.0.1 port 4000, would that still get through to AvareX running on the same device (while it is also listening on the wifi-provided IP port 4000)?





--
You received this message because you are subscribed to the Google Groups "Apps4Av Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to apps4av-foru...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/apps4av-forum/d205bf1a-103e-438d-acdc-9b8025fe7d44n%40googlegroups.com.

Jim English

unread,
Mar 31, 2026, 12:05:02 PM (3 days ago) Mar 31
to Andrew Sarangan, Apps4Av Forum
Only if you started it running before the ADS-B program started up and grabbed that port. If you did that, then the ADS-B program would not be able to use it, and would probably fail. ONLY one program can be attached to any given port on it's IP's address at any given time. Now I'm sure one could write code in both applications that would release the port so that the other application could use it for a brief time. However when an external application wanted to contact you on port 4000 to establish a conversation, how will you know if they want to communicate with your app, or the ADS-B app. At that point, the protocol standard (and that will affect all apps everywhere) would need to be updated to pass some additional information to tell the port 4000 receiving end what app it wanted to establish a conversation with. So, since that's not supported at this time, the rule is only one program app can bind to a port at a time, and it's on a 1st come, 1st served basis.

So, on any given device who has a single IP address, it's either the ADS-B app, or your app that gets to use Port 4000. If you shut down the 1st app to grab port 4000, then it becomes available for the other app to use it. The one way I see to get around this (kind of), is to multi-home the device, where the device loads and runs two IP address stacks using 2 IP addresses. Then the ADS-B app can have Port 4000 on one IP address, and your app could have Port 4000 on the 2nd IP address. As long as it doesn't matter that your app and the ADS-B app will appear to the world as if they were running on separate server machines (even though they aren't), then that could be your workaround.


From: Andrew Sarangan <asar...@gmail.com>
Sent: Monday, March 30, 2026 7:35:08 PM
To: Jim English <jengl...@gmail.com>
Cc: Apps4Av Forum <apps4a...@googlegroups.com>
Subject: Re: [Apps4Av] Re: UDP Port 4000 being blocked?
 

Andrew Sarangan

unread,
Mar 31, 2026, 12:17:25 PM (3 days ago) Mar 31
to Apps4Av Forum
Hmmm.. lots to think about. On the old Avare, I was able to change the port it was listening to, so that was an easy fix. AvareX doesn't give me that option. It seems to be grabbing port 4000 even if I was already bound to it. 



Apps4av Support

unread,
Mar 31, 2026, 12:28:57 PM (3 days ago) Mar 31
to Andrew Sarangan, Apps4Av Forum
X listens to many ports. 4000 is one of them.



--
Regards,
Apps For Aviators Support,

We encourage users to use the Forum for all questions. Any updates to the forum will help other users, who might have similar questions.
Forum: https://groups.google.com/forum/#!forum/apps4av-forum


Lynn Alley

unread,
Mar 31, 2026, 12:33:15 PM (3 days ago) Mar 31
to Apps4Av Forum
This may not be as much of a problem as is being represented.  I am able to run both Avare and AvareX on my Android simultaneously, and get ADS-B info from my Stratux on both.  When a UDP port is opened for read-only access, I don't believe that operation is exclusive such that it blocks other processes from read-only access. Again, this is working just fine for me in the current versions.

Lynn

Jim English

unread,
Mar 31, 2026, 12:36:22 PM (3 days ago) Mar 31
to Apps4Av Forum
Yeah, Port 4000 has pretty much become the de facto standard port for EFBs and ADS-B receivers to establish communications links on. So, I surmise, there's really little reason anymore to even offer a choice when basically every ADS-B-to-EFB connection will be expecting port 4000. However, I am curious, why does your app need to be tied to port 4000 also? If it were free to use any other unused port (there certainly are enough of them), wouldn't that resolve your problem too?

Bruce B

unread,
Mar 31, 2026, 12:39:12 PM (3 days ago) Mar 31
to Apps4Av Forum
However, the problem would be what port your ADSB-IN device is sending to.  It would be easy to adjust if you were using Stratux, but you are stuck with what Stratus (or whatever) uses.
A big question would be what OS are you writing your app on?  Presumably andriod(linux)?  If you had the ability/access to create another (presumably wifi) interface, you could do that.  I only have experience with the Stratux/Stratus wifi implementation, and since they are a Wifi/DHCP server, in theory you could create a duplicate path.  But again, need enough control of the other OS functions to force that.
Alternatively, maybe a utility that reads from port 4000, then forwards copies of the received data to two virtual interfaces on port 4000...  
Kinda just have to pick something and work it through to see if it works.  Unfortunately, without being able to adjust what X or your ADSB device does, you have to fit somewhere in the middle.

Jim English

unread,
Mar 31, 2026, 1:02:20 PM (3 days ago) Mar 31
to Apps4Av Forum
Yes, your multipath idea is the same as I suggested as a possible workaround through multi-homing. It's sometimes called multi-homing, or interface masquerading. Either way, it means running multiple IP networking stacks on the device's network interface (WiFi or wired) with more than one identity on the network. I think I've seen where some ADS-B receivers have bound more than one network port (Port 4000 being only one of them) as well for device communications, but I have never played with the other ports to see for myself. 

Andrew Sarangan

unread,
Mar 31, 2026, 2:25:48 PM (3 days ago) Mar 31
to Apps4Av Forum

Actually, I don't believe that Avare and AvareX are both simultaneously receiving data. When you change focus, the other app gets minimized, and the port gets grabbed by the one in focus. What I am trying to do is to keep the data flowing even if the app is minimized. I've tried this, and there are gaps in the saved data whenever I bring AvareX into focus. 


You received this message because you are subscribed to a topic in the Google Groups "Apps4Av Forum" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/apps4av-forum/bbNGpYk-Dfc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to apps4av-foru...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/apps4av-forum/73955156-6dbe-4361-9366-fb16718b5ea4n%40googlegroups.com.

Andrew Sarangan

unread,
Mar 31, 2026, 2:29:52 PM (3 days ago) Mar 31
to Apps4Av Forum
Even if I could adjust the port that Stratux sends data (I didn't know that was possible), this is a club plane so I don't want other pilots to run into issues because I changed the port. 


Lynn Alley

unread,
Mar 31, 2026, 3:20:46 PM (3 days ago) Mar 31
to Apps4Av Forum
Hmm.  Maybe they apps aren't receiving data while not in focus.  But perhaps it has nothing at all to do with competition for the UDP port.  It may be true that the app won't receive the data when not in focus whether or not any other app is using the same port.  Have you tried switching to some other app (like a browser) to see if the same gaps appear?

For me, this is working well enough that I can't tell anything is wrong.  When I bring X back into focus, ADS-B info is current within a few seconds.

Andrew Sarangan

unread,
Mar 31, 2026, 3:47:10 PM (3 days ago) Mar 31
to Apps4Av Forum
Lynn

I am running the app as a foreground service, that way even when it is not in focus, it will continue to receive the same resources. I have verified that opening other apps or browsers does not block the flow of data, but opening AvareX does. This makes sense to me because both apps are trying to receive data from port 4000,  but the one in focus seems to be getting the priority. 





Reply all
Reply to author
Forward
0 new messages