The syntax to find out what ports boinc is listening on, on a *nix box, is

netstat -pl|grep boinc

(or possibly with a -i in the grep). Is this right?

If so, why does t never show me as listening on 1043, when that port is obviously in use by BoincView - it just lists the port at 31416.

Ideas?

R~~

It has *never* listened on two ports at the same time. Logic seems to be: try to open one port, if it fails, try the other.

In addition BOINC localhost also uses a random port between 1038-5000. Had to enable that range for BOINC to stop hangs on the BOINCmgr part (windows).

Not exactly. That's how absolutely any connection works. If you connect to a website, it connects to the webserver's port 80, and opens a local port too. That doesn't mean it listens for connections on the local port (so don't need to allow them incoming on firewall, or forward on router). The connection ends up being between www.google.com:80 and localhost:[randomport].

When BOINCmgr connects to the core client, it will be between localhost:31416 (core client) and localhost:[randomport] (manager). The manager can't even control what is the local port used.

In addition BOINC localhost also uses a random port between 1038-5000. Had to enable that range for BOINC to stop hangs on the BOINCmgr part (windows).

Not exactly. That's how absolutely any connection works. If you connect to a website, it connects to the webserver's port 80, and opens a local port too. That doesn't mean it listens for connections on the local port (so don't need to allow them incoming on firewall, or forward on router). The connection ends up being between www.google.com:80 and localhost:[randomport].

When BOINCmgr connects to the core client, it will be between localhost:31416 (core client) and localhost:[randomport] (manager). The manager can't even control what is the local port used.

So are you saying that even though I tell BoincView to use 1043 it is actually using 31416?

In which case I am still puzzled why I have not been seeing BV traffic on the netstat scan of port 31416.

And is BOINC giving up its IANA reservation of port 1043?

River~~

MS ignored the IANA reservations and decided to sometimes use 1043 for itself.


I don't know the behaviour of Boinc in this area, but perhaps it listens on two ports for a connection, and then drops the 'other' port if no connection is forthcoming.

---

To answer my own q's

...So are you saying that even though I tell BoincView to use 1043 it is actually using 31416?

OK, further experiments show BV uses the user-indicated port for several attempts, then before giving up entirely retries on pi. If that works it gives no indication to the user of the change of port, and only if pi also fails does it then tell you the first port was not responding.

I guess this is a legitimate case of 'the program(mer) knows better than the user' even tho it sent me on a wild goose chase...

In which case I am still puzzled why I have not been seeing BV traffic on the netstat scan of port 31416

because before I was not waiting long enough to see BV retry on the alternative port.

R~~

MS ignored the IANA reservations and decided to sometimes use 1043 for itself.

ok, so we needed a workaround, but does BOINC just roll over and let MS steal a reserved port permanently? Surely we need to continue making a fuss till MS behave (without hold our breath for that to happen).

R~~