Hi,

I'm trying NativeBOINC on my Android phone (since the original BOINC was not really doing great job). Everything works OK, much better than the original (has a faster optimized app and a real cache for example), I just can't access the client from the BOINC Manager on my laptop, which was actually reason #1 why I tried it. Whatever I do, I always get the message, that the password is wrong.

What I have tried so far:
1. I copied the password from gui_rpc_auth.cfg from my laptop (I always copy the file to my other computers so I don't need to type anything).
2. I tried other password.

Both of these with the network name or IP of the laptop in the list of allowed computers.

According to the information on the NativeBOINC homepage, that's all that should be necessary.

If it helps: this is the Android phone, this is the laptop I try to access it from.

---

Have tried it here; on install i only had set the password and i can access the tablet without any problems from my PC with BoincTasks 1.59.
You use the right Port (31416) for connecting?

---

- Performance is not a simple linear function of the number of CPUs you throw at the problem. -

Have tried it here; on install i only had set the password and i can access the tablet without any problems from my PC with BoincTasks 1.59.
You use the right Port (31416) for connecting?

I use the official BOINC Manager 6.10.18, I could always access all other computers with it, also such with newer version of BOINC. I just enter the IP, I hope the Manager knows which port to use... It's also not a connection issue, I get an answer, it clearly says wrong password.

---

That is rather odd. I just tested with my Galaxy S4 & the 6.10.48 Manager I use with success.
I only had one issue. With my wireless devices sometimes I have to send a packet from each one to the other before they will actually talk to one another. I'll normally just run ping address -t on both ends until I see responses.

I have seen the wrong password message when connecting to hosts before with manager. Even with connecting back to the local host.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

I'll normally just run ping address -t on both ends until I see responses.

THAT WAS IT! Apparently it helps to ping the device first, than the password works! But don't ask me for an explanation... one more weird computer thing.

---

I've had to do that when trying to connect to my notebook when it is on the wireless. I think it is just something in the home AP hardware that goes wonky. As I don't see this kind of issue at work with the wireless. Which is why I'm planning on upgrading to an Cisco WAP561 in the near future.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

Well, on the second thought, it's possible that I had the original BOINC client still running and that was disturbing... Whatever it was, it seems to work now.

---

With my wireless devices sometimes I have to send a packet from each one to the other before they will actually talk to one another. I'll normally just run ping address -t on both ends until I see responses.

That is a symptom I have seen before. If you have a chance to run a tcpdump or other network traffic analysis tool you will see that the device is not responding to ARP requests. If that is the case, then this has nothing to do with BOINC, but would be purely a bug in the IP stack of the device.


Regards, Jan

With my wireless devices sometimes I have to send a packet from each one to the other before they will actually talk to one another. I'll normally just run ping address -t on both ends until I see responses.

That is a symptom I have seen before. If you have a chance to run a tcpdump or other network traffic analysis tool you will see that the device is not responding to ARP requests. If that is the case, then this has nothing to do with BOINC, but would be purely a bug in the IP stack of the device.


Regards, Jan

To make it even weirder. The wireless device will have a connection to the internet & several of the other the wired systems. Normally just not the host I happen to be on at the moment. As I mentioned I am pretty sure it is an issue with the hardware in between. Given my one notebook, I take back & forth to work sometimes, doesn't present this same issue on my work network.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

To make it even weirder. The wireless device will have a connection to the internet & several of the other the wired systems. Normally just not the host I happen to be on at the moment.

Some wireless access points by default are configured with Client Isolation enabled. This means that wireless systems cannot talk directly to each other. Check your access point configuration for that.


Regards, Jan

To make it even weirder. The wireless device will have a connection to the internet & several of the other the wired systems. Normally just not the host I happen to be on at the moment.

Some wireless access points by default are configured with Client Isolation enabled. This means that wireless systems cannot talk directly to each other. Check your access point configuration for that.

Regards, Jan

AP isolation defaults to disabled on mine. I would imagine if that was enabled it would tend to cause a more permanent inability to connect to the system rather than intermittent.
It's just an old cheap Cisco/Linksys E2000 wireless router I'm using just for an AP & extra GB ports. I originally only bought it so I could do WiFi calling with my cell. So I wasn't worried about having a great AP. I know the issues I have with it and work around them for now.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

Then I guess it's back to the previous theory, that the device in question doesn't respond (reliably) to ARP Requests.

Note that ARP is only spoken between systems on the same IP segment. So there is a difference if there is a router in between the device and your workstation/host, or not. You said that the device is having internet connections. That means that it is initiating connections, that involve contacting the router, so the router will probably always know it's MAC address. If your workstation/host tries to contact it from another segment through the router, it will work. However, if your workstation/host is on the same segment, then the device needs to properly respond to the ARP Request sent by your host.

When you ping your host from the device, the ARP request sent from the device to your host is also telling your host the device's MAC address, which your host will remember temporarily in its ARP cache. That would explain why ping seems to fix the problem.

Try adding a static ARP entry to your host.